profile
viewpoint
Steve Purcell purcell Wellington, New Zealand http://www.sanityinc.com/ Haskell/Emacs enthusiast, startup and software team builder.

melpa/melpa 2020

Recipes and build machinery for the biggest Emacs package repo

magnars/multiple-cursors.el 1742

Multiple cursors for emacs.

bbatsov/emacs-lisp-style-guide 804

A community-driven Emacs Lisp style guide

eschulte/rinari 412

Rinari Is Not A Rails IDE (it is an Emacs minor mode for Rails)

congomongo/congomongo 347

Clojure wrapper for the mongo-db java api

jcollard/elm-mode 345

Elm mode for emacs

nex3/haml-mode 141

Emacs mode for Haml.

jlr/rainbow-delimiters 113

Emacs rainbow delimiters mode

purcell/ac-slime 109

Emacs auto-complete plugin for Slime symbols

nex3/sass-mode 89

Emacs mode for Sass

issue commentledger/ledger-mode

ledger incorrectly parses the currency from the last transaction in an org src block

I wonder if those org source blocks have no trailing newline. How about if you add a blank line before #+END_SRC?

heikkil

comment created time in a day

issue commentmagit/magit

Stashes are not saved when using envrc

10 FIX PROBLEM 20 CAUSE PROBLEM 30 GOTO 10

glasserc

comment created time in a day

issue commentmagit/magit

Stashes are not saved when using envrc

I didn't think of envrc-global-mode when getting this problem.

Oh? I always assume that @purcell guy broke it.

glasserc

comment created time in a day

issue commentmagit/magit

Stashes are not saved when using envrc

My thinking was that if the @,body of magit-with-temp-index creates a new buffer, that buffer will tend to trigger envrc-mode, which would mask any let-bound process-environement. But I absolutely could be wrong.

glasserc

comment created time in a day

issue commentmagit/magit

Stashes are not saved when using envrc

Actually, it's probably due to the following behaviour of envrc.el, which I plan to rework imminently: when envrc-mode calls direnv, it applies it (explicitly) to the default value for process-environment, not to the any local or let-bound version: https://github.com/purcell/envrc/blob/master/envrc.el#L330

That's necessary right now, because it keeps some of the env var merging logic simple and consistent, but ultimately it's wrong. Obviously, in this case, it has the effect of throwing away the GIT_INDEX_FILE var when run.

So, sorry about the unfortunate interaction with magit. FWIW, I hadn't really noticed it myself yet, despite using magit intensively. I'll look at reworking this code as a matter of urgency.

glasserc

comment created time in 2 days

issue commentmagit/magit

Stashes are not saved when using envrc

Hey @glasserc, could you try enabling envrc-debug? Then you should get some info in a buffer called something like *envrc debug* which might help us figure this out.

glasserc

comment created time in 2 days

issue commentmagit/magit

Stashes are not saved when using envrc

Thanks for tagging me in. I'll take a look.

glasserc

comment created time in 2 days

Pull request review commentNixOS/nixpkgs

libpromhttp: init at 0.1.1, build in combination with libprom

+{ stdenv+, fetchFromGitHub+, fetchpatch+, cmake+, libmicrohttpd+}:+let+  build =+    { pname+    , subdir+    , buildInputs ? [ ]+    , description+    }:+    stdenv.mkDerivation rec {+      inherit pname;+      version = "0.1.1";++      src = fetchFromGitHub {+        owner = "digitalocean";+        repo = "prometheus-client-c";+        rev = "v${version}";+        sha256 = "0g69s24xwrv5974acshrhnp6i8rpby8c6bhz15m3d8kpgjw3cm8f";+      };++      nativeBuildInputs = [ cmake ];+      inherit buildInputs;+      doCheck = false;

Yep, avoidable merge commits are gross.

purcell

comment created time in 2 days

Pull request review commentNixOS/nixpkgs

libpromhttp: init at 0.1.1, build in combination with libprom

+{ stdenv+, fetchFromGitHub+, fetchpatch+, cmake+, libmicrohttpd+}:+let+  build =+    { pname+    , subdir+    , buildInputs ? [ ]+    , description+    }:+    stdenv.mkDerivation rec {+      inherit pname;+      version = "0.1.1";++      src = fetchFromGitHub {+        owner = "digitalocean";+        repo = "prometheus-client-c";+        rev = "v${version}";+        sha256 = "0g69s24xwrv5974acshrhnp6i8rpby8c6bhz15m3d8kpgjw3cm8f";+      };++      nativeBuildInputs = [ cmake ];+      inherit buildInputs;+      doCheck = false;

Squashed and pushed locally instead.

purcell

comment created time in 2 days

push eventpurcell/nixpkgs

Steve Purcell

commit sha dcfd6141c1195b5e23062a698369594d5831b5d2

libpromhttp: init at 0.1.1, build in combination with libprom

view details

push time in 2 days

push eventpurcell/nixpkgs

Steve Purcell

commit sha 3baf82b04fbb72f5996ff2c9021576d657a8510a

libpromhttp: doCheck need not be overridden Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com>

view details

push time in 2 days

Pull request review commentNixOS/nixpkgs

libpromhttp: init at 0.1.1, build in combination with libprom

+{ stdenv+, fetchFromGitHub+, fetchpatch+, cmake+, libmicrohttpd+}:+let+  build =+    { pname+    , subdir+    , buildInputs ? [ ]+    , description+    }:+    stdenv.mkDerivation rec {+      inherit pname;+      version = "0.1.1";++      src = fetchFromGitHub {+        owner = "digitalocean";+        repo = "prometheus-client-c";+        rev = "v${version}";+        sha256 = "0g69s24xwrv5974acshrhnp6i8rpby8c6bhz15m3d8kpgjw3cm8f";+      };++      nativeBuildInputs = [ cmake ];+      inherit buildInputs;+      doCheck = false;

Makes perfect sense: I will commit this suggestion, and then it can be squashed in at merge time.

purcell

comment created time in 2 days

pull request commentNixOS/nixpkgs

libpromhttp: init at 0.1.1

Collaborating with @cfsmp3, this has been reformulated as #91908, which should then probably be preferred to this PR.

cfsmp3

comment created time in 3 days

pull request commentNixOS/nixpkgs

libpromhttp: init at 0.1.1, build in combination with libprom

/cc @cfsmp3

purcell

comment created time in 3 days

PR opened NixOS/nixpkgs

libpromhttp: init at 0.1.1, build in combination with libprom
Motivation for this change

This is an alternative formulation of #91323, to eliminate duplication of the source spec w.r.t. its sister library libprom (added in #90706).

Things done

<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->

  • [x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • [x] NixOS
    • [x] macOS
    • [ ] other Linux distributions
  • [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • [ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • [ ] Tested execution of all binary files (usually in ./result/bin/)
  • [ ] Determined the impact on package closure size (by running nix path-info -S before and after)
  • [x] Ensured that relevant documentation is up to date
  • [x] Fits CONTRIBUTING.md.
+75 -49

0 comment

3 changed files

pr created time in 3 days

create barnchpurcell/nixpkgs

branch : libpromhttp

created branch time in 3 days

issue commentnix-community/emacs-overlay

Ignore use-package declarations with :disabled t

I know that @talyz was working on a proper emacs lisp parser in Nix. Once we have that we can start supporting all sorts of interesting use-package features.

I'd be keen to get my hands on such a parser for purposes like #38, but I'd be wary of expecting that it would allow robust support of various use-package features, since values passed to :disabled, :ifetc. can be expressions that would need to be evaluated to know their values. A simple example would be:if (eq system-type 'darwin). Without evaluation, users will always need to craft their Emacs init files a certain way to avoid such issues when inspected byemacs-overlay` functions.

benley

comment created time in 4 days

PR opened nix-community/nix-direnv

README updates
  • Make it clearer this is a re-implementation of use_nix
  • Grammar/spelling fixes
  • Clarifications

Thanks for this project!

+26 -24

0 comment

1 changed file

pr created time in 5 days

push eventpurcell/nix-direnv

Steve Purcell

commit sha 9149cf89856ece5f6df90672f49abcb7b3bfe8d4

README updates - Make it clearer this is a re-implementation of `use_nix` - Grammar/spelling fixes - Clarifications

view details

push time in 5 days

fork purcell/nix-direnv

A fast, persistent use_nix implementation for direnv [maintainer=@Mic92]

fork in 5 days

pull request commentnix-community/emacs-overlay

Add emacsWithPackagesFromPackageRequires

I don't think I'm going to do more to generalise this right now, so I'd say this is ready to be merged in its current state.

purcell

comment created time in 5 days

pull request commentqmk/qmk_firmware

shell.nix improvements, and fix problems on Darwin

So it does not look like your PR makes things worse on linux.

Cool, thanks for confirming - this should be unproblematic to merge, then.

purcell

comment created time in 5 days

issue commentledger/ledger-mode

Feature Request: link to attached files

I think you can already do this with something like Emacs' built-in goto-addr library or org-link-minor-mode. It's not something that needs to be added to ledger-mode. Note also that - even without any configuration - you can still run M-x ffap (find-file-at-point) with point on the path, and Emacs will open that file for you.

chrpinedo

comment created time in 5 days

issue commenttarget/lorri

Reload running programs when a build finishes

One approach to this might be to support a project-local config file like .lorrirc, and allow the user to specify hook commands in there, which would simply be shell commands executed by lorri in response to certain events. This way, one person could use a hook command to restart locally-running services, and another could ping their editor to reload the direnv (thinking slightly about emacs here).

I feel like this might help keep lorri small and focused, as opposed to worrying about things like lorri services, but of course it's not without some complexity. For example, what happens when hook commands block, and should they be executed in the new env, or responsible for querying direnv themselves etc.? Structured information could potentially be passed to the hook callback commands as additional command-line args.

Skyfold

comment created time in 5 days

PR opened utdemir/hs-nix-template

Fix broken cookiecutter link
+1 -1

0 comment

1 changed file

pr created time in 5 days

push eventpurcell/hs-nix-template

Steve Purcell

commit sha 4f157392f91e21ea21824e5a5d275d57bb494835

Fix broken cookiecutter link

view details

push time in 5 days

fork purcell/hs-nix-template

A Haskell project template that can be built with nix and developed by ghcid and cabal-install.

fork in 5 days

pull request commentqmk/qmk_firmware

shell.nix improvements, and fix problems on Darwin

I think i'm a bit confused about how many keyboards there are and how many i should be able to build.

I guess the key question is whether you get more or fewer failures/successes with or without this PR. I can imagine blanking out NIX_TARGET_CFLAGS_COMPILE might have negative effects in some cases, but it was actively necessary for me to do that with avr-gcc.

purcell

comment created time in 7 days

PR opened qmk/qmk_firmware

shell.nix improvements, and fix problems on Darwin

Improvements to shell.nix were made in #8910 by @thorstenweber83, but the result was that the nix shell no longer worked on Darwin.

I have tidied up and improved some of the Nix expression, fixing this issue along the way. If someone would be kind enough to test this on Linux too, that would be appreciated.

Description

  • Removed unnecessary overrides
  • Provided a more complete Python environment, adequate for actually running/developing bin/qmk
  • Unset NIX_TARGET_CFLAGS_COMPILE in the Nix shell, to avoid incompatible host CC flags getting picked up by avr-gcc.

Types of Changes

  • [ ] Core
  • [x] Bugfix
  • [ ] New feature
  • [x] Enhancement/optimization
  • [ ] Keyboard (addition or update)
  • [ ] Keymap/layout/userspace (addition or update)
  • [ ] Documentation

Issues Fixed or Closed by This PR

  • None

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

  • [x] My code follows the code style of this project.
  • [ ] My change requires a change to the documentation.
  • [ ] I have updated the documentation accordingly.
  • [x] I have read the CONTRIBUTING document.
  • [ ] I have added tests to cover my changes.
  • [x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).
+34 -14

0 comment

1 changed file

pr created time in 8 days

create barnchpurcell/qmk_firmware

branch : shell-nix-darwin

created branch time in 8 days

pull request commentNixOS/nixpkgs

dockerTools: add streaming image support, improve speed and reduce IO

This likely also closes #89075, #75810 and #75888.

purcell

comment created time in 9 days

pull request commentNixOS/nixpkgs

dockerTools: split raw and cooked images

I suspect this is superseded by #91084, and could be closed when that is merged?

tomberek

comment created time in 9 days

pull request commentNixOS/nixpkgs

Calculate sha256 on the fly on dockerTools.buildLayeredImage

This can be closed when #91084 is merged.

utdemir

comment created time in 9 days

issue commentNixOS/nixpkgs

Labels for dockerTools

Seems like this can be closed.

fubarbaz

comment created time in 9 days

pull request commentNixOS/nixpkgs

dockerTools: add streaming image support, improve speed and reduce IO

I think we forgot to tag @grahamc in to take a look at this too...

purcell

comment created time in 9 days

issue openedNixOS/nixpkgs

google-cloud-sdk breaks with GCE support

Describe the bug

The google-cloud-sdk package can be built with a use-gce option, and such a version of it is exposed as google-cloud-sdk-gce in nixpkgs. However, when run on a (NixOS) machine in GCE, the google-compute-engine support breaks:

$ nix-shell -p google-cloud-sdk-gce
[nix-shell:~somedir]$ gsutil
Traceback (most recent call last):
  File "/nix/store/d6x4kl6a3darjlwybh35m43f2gjpnis3-google-cloud-sdk-297.0.1/google-cloud-sdk/platform/gsutil/gsutil", line 21, in <module>
    gsutil.RunMain()
  File "/nix/store/d6x4kl6a3darjlwybh35m43f2gjpnis3-google-cloud-sdk-297.0.1/google-cloud-sdk/platform/gsutil/gsutil.py", line 122, in RunMain
    import gslib.__main__
  File "/nix/store/d6x4kl6a3darjlwybh35m43f2gjpnis3-google-cloud-sdk-297.0.1/google-cloud-sdk/platform/gsutil/gslib/__main__.py", line 53, in <module>
    import boto
  File "/nix/store/d6x4kl6a3darjlwybh35m43f2gjpnis3-google-cloud-sdk-297.0.1/google-cloud-sdk/platform/gsutil/gslib/vendored/boto/boto/__init__.py", line 1216, in <module>
    boto.plugin.load_plugins(config)
  File "/nix/store/d6x4kl6a3darjlwybh35m43f2gjpnis3-google-cloud-sdk-297.0.1/google-cloud-sdk/platform/gsutil/gslib/vendored/boto/boto/plugin.py", line 93, in load_plugins
    _import_module(file)
  File "/nix/store/d6x4kl6a3darjlwybh35m43f2gjpnis3-google-cloud-sdk-297.0.1/google-cloud-sdk/platform/gsutil/gslib/vendored/boto/boto/plugin.py", line 75, in _import_module
    return imp.load_module(name, file, filename, data)
  File "/nix/store/h215sh6f5hs752pbn0nq357f3wkz9vn9-google-compute-engine-20190124/lib/python2.7/site-packages/google_compute_engine/boto/boto_config.py", line 29, in <module>
    from google_compute_engine import config_manager
ImportError: No module named google_compute_engine

Tested with current nixpkgs, but I suspect this has been broken for a little while.

To Reproduce Steps to reproduce the behavior:

  1. Access a GCE machine (this is the inconvenient part)
  2. nix-shell -p google-cloud-sdk-gce
  3. Run gsutil in the nix shell

Expected behavior

Would expect no error from gsutil, and ability to access google storage with it using GCE-based auth.

Additional context

If one overrides the python to python3 in google-cloud-sdk-gce, then the resulting backtrace gets even more interesting, since it ends like this:

  File "/nix/store/jli50q24fvik6pfsnjs1jd90g3dy4p6y-python3-3.8.3/lib/python3.8/imp.py", line 234, in load_module
    return load_source(name, filename, file)
  File "/nix/store/jli50q24fvik6pfsnjs1jd90g3dy4p6y-python3-3.8.3/lib/python3.8/imp.py", line 171, in load_source
    module = _load(spec)
  File "/nix/store/h215sh6f5hs752pbn0nq357f3wkz9vn9-google-compute-engine-20190124/lib/python2.7/site-packages/google_compute_engine/boto/boto_config.py", line 29, in <module>
    from google_compute_engine import config_manager
ModuleNotFoundError: No module named 'google_compute_engine'

Note the mix of Python versions involved.

I suspect that the google-compute-engine and google-cloud-sdk packages have somewhat diverged in compatibility, or that the python involved in those two and boto have to be lined up to be consistent, but I haven't dug deeply into either of those possibilities.

Notify maintainers

CC @andir, who I know has worked on some of this, and is working on the same project as me.

Metadata

  • system: "x86_64-linux"
  • host os: Linux 4.19.118, NixOS, 20.03.2015.e7752db2fb6 (Markhor)
  • multi-user?: yes
  • sandbox: yes
  • version: nix-env (Nix) 2.3.5
  • channels(root): "nixos-20.03.2015.e7752db2fb6"
  • channels(steve): "nixpkgs-20.09pre228165.00df2371122"
  • nixpkgs: `/home/steve/.nix-defexpr/channels/nixpkgs

(But have tested in shell with latest nixpkgs pinned.)

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: [ google-cloud-sdk google-cloud-sdk-gce google-compute-engine ]
# a list of nixos modules affected by the problem
module:

created time in 9 days

issue commentNixOS/nixpkgs

pkgs.dockerTools.buildLayeredImage issues

This is likely a regression introduced in https://github.com/NixOS/nixpkgs/commit/2dd94af18650aee1b53c9509832068b60c1b1225 (cc @roberth): nix is renamed to __Nix__ but the code still tries to add nix to the tarball.

It would be relatively straightforward to fix this, but we have a parallel PR pending (#91084) which rewrites buildLayeredImage entirely, so I'd suggest a more efficient way forward in terms of testing effort might be to try the rewritten code for your use case, and try to get that merged soon. If you have pointers to the underlying Nix expr, I'd be happy to help confirm that it works with our rewrite.

Hoverbear

comment created time in 10 days

issue commentNixOS/nixpkgs

pkgs.dockerTools.buildLayeredImage issues

Can you point us at the default.nix?

Hoverbear

comment created time in 10 days

issue commentnex3/haml-mode

Apostrophes count as unmatched delimiters

M-x newline-and-indent takes me from:

%li
  %a{href: "#returners-hideout"} Returner's Hideout<>|

to

%li
  %a{href: "#returners-hideout"} Returner's Hideout<>
  |

and from

%li
  %a{href: "#returners-hideout"} Returner\'s Hideout<>|

to

%li
  %a{href: "#returners-hideout"} Returner\'s Hideout<>
  |
ascclemens

comment created time in 11 days

issue commentnex3/haml-mode

Apostrophes count as unmatched delimiters

The point has to be at the end of the line.

Even then, I get the same behaviour with and without the backslash. And same with emacs -Q, so it's not my local config either.

What haml-mode version do you have? I'm using

;; Package-Version: 20190219.2102
ascclemens

comment created time in 11 days

issue commentnex3/haml-mode

Apostrophes count as unmatched delimiters

If I were to hit enter with the apostrophe escaped, the new line would be indented. If I hit enter without it escaped, the new line is not indented (also reproduced without h-i-g on, but it's a useful indicator).

With point (represented by |) before the apostrophe in your example, after hitting RET (newline-and-indent) I get:

%li
  %a{href: "#returners-hideout"} Returner\|'s Hideout

=>

%li
  %a{href: "#returners-hideout"} Returner\
  |'s Hideout

and

%li
  %a{href: "#returners-hideout"} Returner|'s Hideout

=>

%li
  %a{href: "#returners-hideout"} Returner
  |'s Hideout

So I suspect something else is going on in your config. I suggest you start emacs with -Q, M-x load-file on haml-mode.el, then try to repeat the experiment.

ascclemens

comment created time in 11 days

issue commentnex3/haml-mode

Apostrophes count as unmatched delimiters

Ah, sorry, I think I misread the issue you were seeing.

Regarding enter and indenting, it would be an anti-pattern for haml-mode to decide that you always wanted ENTER to indent. Emacs provides two commands: newline and newline-and-indent. I do this in my config:

(global-set-key (kbd "RET") 'newline-and-indent)

but you might prefer

(with-eval-after-load 'haml-mode
  (define-key haml-mode-map (kbd "RET") 'newline-and-indent))

Starting from the first snippet you posted, what would be the exact sequence of steps to reproduce the apostrophe issue? I can't seem to do that.

ascclemens

comment created time in 12 days

issue commentnex3/haml-mode

Apostrophes count as unmatched delimiters

That's not to say that some changes might be needed for Emacs 28, but the release of that stream will probably be in about 15 months. :-)

ascclemens

comment created time in 12 days

pull request commentNixOS/nixpkgs

libprom: init at 0.1.1

Disk appears full on the machine running checks, hence the failure.

cfsmp3

comment created time in 12 days

issue commentpurcell/cl-libify

Fail trans for let form

Yes, it's not very smart.

conao3

comment created time in 12 days

issue commentnex3/haml-mode

Apostrophes count as unmatched delimiters

This doesn't happen in the latest stable Emacs release, so I'd have to guess that it's an Emacs HEAD bug, which is not uncommon.

ascclemens

comment created time in 12 days

issue commentpurcell/ivy-smex

The MELPA does not have any ivy-smex package

Yes, see the note in the README:

NOTE: This package is redundant, given counsel-M-x, but I'm leaving it here anyway.

szikes-adam

comment created time in 12 days

pull request commentNixOS/nixpkgs

fast-downward: 2019-05-13 -> 19.12, build on darwin, fix runtime issues

I actually had no idea we had this in nixpkgs! At work we have our own derivation to build this.

I'm guessing your own derivation would put downward in $out/bin, since that's what you're calling directly from the Haskell wrapper. I believe in this one it ends up in libexec.

purcell

comment created time in 12 days

pull request commentNixOS/nixpkgs

fast-downward: 2019-05-13 -> 19.12, build on darwin, fix runtime issues

Also /cc @ocharles, who may well be using this.

purcell

comment created time in 12 days

pull request commentmelpa/melpa

Add a recipe for erblint.el

Couple of notes here:

  • Avoid building commands using strings and concat, which will bite users when paths contain spaces or special shell characters. Prefer lists of args, splice them together (e.g. with mapconcat) at the last minute, and use shell-quote-argument on everything but the first arg (executable name) just to be safe.
  • The code refers to projectile-rails-compilation-mode, which may or may not be installed.
  • You're rolling your own project-root functionality, while simultaneously looking for specific root files that indicate a user might be using projectile. None of this belongs in this package! Instead, consider providing a defcustom called erb-lint-project-root-function or similar. Set it to vc-root-dir by default, and suggest that users might prefer to set it to projectile-root. Then funcall that function when you need it. Done! :-)
leodcs

comment created time in 13 days

pull request commentnix-community/emacs-overlay

Add emacsWithPackagesFromPackageRequires

I think it would be possible to use Emacs to parse S expressions, as shown in this example for dhall-nix. You can use any external program to generate a Nix expression from a given input and then import it. I am not sure if it is a desirable solution here, but I hope it will help.

Yes, it's quite a bit more heavy-weight though. We don't actually need the ability to evaluate the elisp, since the forms involved don't support arbitrary evaluation. Having a simple sexp parser written in Nix would probably be the best way to do this tbh.

(Note that - in contrast to this - the existing emacsWithPackagesFromUsePackage functionality isn't something that can be assumed completely safe to parse from Nix, because users could reasonably write macros that produce use-package forms, and those could not be detected without at least macro-expanding the user's init file with Emacs. But short of that, a simple elisp parser would make that code more robust too.)

purcell

comment created time in 13 days

push eventpurcell/emacs-overlay

Steve Purcell

commit sha fa7e127f03b93113f61d9d9405bc7e5a0aa9885d

Renamed packageFile arg to packageElisp for clarity

view details

push time in 13 days

push eventpurcell/emacs-overlay

Steve Purcell

commit sha 257557be073e697c61e70005d32642ac9515451b

Add docstring with example Package-Requires parse inputs and results

view details

push time in 14 days

push eventpurcell/emacs-overlay

Steve Purcell

commit sha 8439afbe1e1fca1b64c91aac302764d465212bca

Add emacsWithPackagesFromPackageRequires This provides a mechanism for creating an Emacs closure that contains the runtime dependencies for a given Emacs package source file, by inspecting its Package-Requires header.

view details

Steve Purcell

commit sha 1b7520aab8594c1e231974273db5d8515d415bc3

Match more liberally in Package-Requires lists

view details

push time in 14 days

push eventpurcell/emacs-overlay

Steve Purcell

commit sha bb51014108620836395d296b1f1a8d59189807eb

Match more liberally in Package-Requires lists

view details

push time in 14 days

pull request commentnix-community/emacs-overlay

Add emacsWithPackagesFromPackageRequires

Also, what's the best way to add a few little tests for various Package-Requires lists?

purcell

comment created time in 14 days

PR opened nix-community/emacs-overlay

Add emacsWithPackagesFromPackageRequires

This provides a mechanism for creating an Emacs closure that contains the runtime dependencies for a given Emacs package source file, by inspecting its Package-Requires header.

I wanted to explore using emacs-overlay to simplify the process of provisioning tailored Emacsen for testing packages in CI and locally, as an alternative to using/integrating with Cask: this is the result, and I'm quite excited about it. Further work could add support for parsing -pkg.el files, or even Cask files, though it's pretty annoying to use builtins.* to dig through sexps.

There's an opportunity to somewhat unify the interface between the functions in elisp.nix and packreq.nix, but it wasn't immediately clear how best to factor that to avoid it getting clunky or unnatural, so I thought I'd post this here for thoughts.

+115 -26

0 comment

5 changed files

pr created time in 14 days

create barnchpurcell/emacs-overlay

branch : packages-from-package-requires

created branch time in 14 days

fork purcell/emacs-overlay

Bleeding edge emacs overlay [maintainer=@adisbladis]

fork in 15 days

Pull request review commentNixOS/nixpkgs

dockerTools: add streaming image support, improve speed and reduce IO

+"""+This script generates a Docker image from a set of store paths. Uses+Docker Image Specification v1.2 as reference [1].++It expects a JSON file with the following properties and writes the+image as an uncompressed tarball to stdout:++* "architecture", "config", "os", "created", "repo_tag" correspond to+  the fields with the same name on the image spec [2].+* "created" can be "now".+* "created" is also used as mtime for files added to the image.+* "store_layers" is a list of layers in ascending order, where each+  layer is the list of store paths to include in that layer.++The main challenge for this script to create the final image in a+streaming fashion, without dumping any intermediate data to disk+for performance.++A docker image has each layer contents archived as separate tarballs,+and they later all get enveloped into a single big tarball in a+content addressed fashion. However, because how "tar" format works,+we have to know about the name (which includes the checksum in our+case) and the size of the tarball before we can start adding it to the+outer tarball.  We achieve that by creating the layer tarballs twice;+on the first iteration we calculate the file size and the checksum,+and on the second one we actually stream the contents. 'add_layer_dir'+function does all this.++[1]: https://github.com/moby/moby/blob/master/image/spec/v1.2.md+[2]: https://github.com/moby/moby/blob/4fb59c20a4fb54f944fe170d0ff1d00eb4a24d6f/image/spec/v1.2.md#image-json-field-descriptions+"""  # noqa: E501+++import io+import os+import re+import sys+import json+import hashlib+import tarfile+import itertools+import threading+from datetime import datetime+from collections import namedtuple+++# Adds the given store paths to as a tar to the given writable stream.+def archive_paths_to(obj, paths, mtime, add_nix, filter=None):+    filter = filter if filter else lambda i: i++    # gettarinfo makes the paths relative, this makes them+    # absolute again+    def append_root(ti):+        ti.name = "/" + ti.name+        return ti++    def apply_filters(ti):+        ti.mtime = mtime+        return filter(ti)++    def dir(path):+        ti = tarfile.TarInfo(path)+        ti.type = tarfile.DIRTYPE+        return ti++    with tarfile.open(fileobj=obj, mode="w|") as tar:+        # To be consistent with the docker utilities, we need to have+        # these directories first when building layer tarballs. But+        # we don't need them on the customisation layer.+        if add_nix:+            tar.addfile(apply_filters(dir("/nix")))+            tar.addfile(apply_filters(dir("/nix/store")))++        for path in paths:+            ti = tar.gettarinfo(os.path.join("/", path))+            tar.addfile(apply_filters(append_root(ti)))++            for root, dirs, files in os.walk(path, topdown=True):+                for name in itertools.chain(dirs, files):+                    name = os.path.join(root, name)+                    ti = append_root(tar.gettarinfo(name))++                    # copy hardlinks as regular files+                    if ti.islnk():+                        ti.type = tarfile.REGTYPE++                    ti = apply_filters(ti)+                    if ti.isfile():+                        with open(name, "rb") as f:+                            tar.addfile(ti, f)+                    else:+                        tar.addfile(ti)+++# A writable stream which only calculates the final file size and+# sha256sum, while discarding the actual contents.+class ExtractChecksum:+    def __init__(self):+        self._digest = hashlib.sha256()+        self._size = 0++    def write(self, data):+        self._digest.update(data)+        self._size += len(data)++    def extract(self):+        return (self._digest.hexdigest(), self._size)+++# Some metadata for a layer+LayerInfo = namedtuple("LayerInfo", ["size", "checksum", "path", "paths"])+++# Given a list of store paths 'paths', creates a layer add append it+# to tarfile 'tar'. Returns some a 'LayerInfo' for the layer.+def add_layer_dir(tar, paths, mtime, add_nix=True, filter=None):+    assert all(i.startswith("/nix/store/") for i in paths)++    # First, calculate the tarball checksum and the size.+    extract_checksum = ExtractChecksum()+    archive_paths_to(+        extract_checksum,+        paths,+        mtime=mtime,+        add_nix=add_nix,+        filter=filter+    )+    (checksum, size) = extract_checksum.extract()++    path = f"{checksum}/layer.tar"+    ti = tarfile.TarInfo(path)+    ti.size = size+    ti.mtime = mtime++    # Then actually stream the contents to the outer tarball.+    read_fd, write_fd = os.pipe()+    with open(read_fd, "rb") as read, open(write_fd, "wb") as write:+        def producer():+            archive_paths_to(+                write,+                paths,+                mtime=mtime,+                add_nix=add_nix,+                filter=filter+            )+            write.close()++        # Closing the write end of the fifo also closes the read end,+        # so we don't need to wait until this thread is finished.+        #+        # Any exception from the thread will get printed by the default+        # exception handler, and the 'addfile' call will fail since it+        # won't be able to read required amount of bytes.+        threading.Thread(target=producer).start()+        tar.addfile(ti, read)++    return LayerInfo(size=size, checksum=checksum, path=path, paths=paths)+++# Adds the contents of the store path to the root as a new layer.+def add_customisation_layer(tar, path, mtime):+    def filter(ti):+        ti.name = re.sub("^/nix/store/[^/]*", "", ti.name)+        return ti+    return add_layer_dir(+        tar,+        [path],+        mtime=mtime,+        add_nix=False,+        filter=filter+      )+++# Adds a file to the tarball with given path and contents.+def add_bytes(tar, path, content, mtime):+    assert type(content) is bytes++    ti = tarfile.TarInfo(path)+    ti.size = len(content)+    ti.mtime = mtime+    tar.addfile(ti, io.BytesIO(content))+++# Main

Definitely, yes. We'll change that too, thanks!

purcell

comment created time in 15 days

Pull request review commentNixOS/nixpkgs

dockerTools: add streaming image support, improve speed and reduce IO

+"""+This script generates a Docker image from a set of store paths. Uses+Docker Image Specification v1.2 as reference [1].++It expects a JSON file with the following properties and writes the+image as an uncompressed tarball to stdout:++* "architecture", "config", "os", "created", "repo_tag" correspond to+  the fields with the same name on the image spec [2].+* "created" can be "now".+* "created" is also used as mtime for files added to the image.+* "store_layers" is a list of layers in ascending order, where each+  layer is the list of store paths to include in that layer.++The main challenge for this script to create the final image in a+streaming fashion, without dumping any intermediate data to disk+for performance.++A docker image has each layer contents archived as separate tarballs,+and they later all get enveloped into a single big tarball in a+content addressed fashion. However, because how "tar" format works,+we have to know about the name (which includes the checksum in our+case) and the size of the tarball before we can start adding it to the+outer tarball.  We achieve that by creating the layer tarballs twice;+on the first iteration we calculate the file size and the checksum,+and on the second one we actually stream the contents. 'add_layer_dir'+function does all this.++[1]: https://github.com/moby/moby/blob/master/image/spec/v1.2.md+[2]: https://github.com/moby/moby/blob/4fb59c20a4fb54f944fe170d0ff1d00eb4a24d6f/image/spec/v1.2.md#image-json-field-descriptions+"""  # noqa: E501+++import io+import os+import re+import sys+import json+import hashlib+import tarfile+import itertools+import threading+from datetime import datetime+from collections import namedtuple+++# Adds the given store paths to as a tar to the given writable stream.+def archive_paths_to(obj, paths, mtime, add_nix, filter=None):+    filter = filter if filter else lambda i: i++    # gettarinfo makes the paths relative, this makes them+    # absolute again+    def append_root(ti):+        ti.name = "/" + ti.name+        return ti++    def apply_filters(ti):+        ti.mtime = mtime+        return filter(ti)++    def dir(path):+        ti = tarfile.TarInfo(path)+        ti.type = tarfile.DIRTYPE+        return ti++    with tarfile.open(fileobj=obj, mode="w|") as tar:+        # To be consistent with the docker utilities, we need to have+        # these directories first when building layer tarballs. But+        # we don't need them on the customisation layer.+        if add_nix:+            tar.addfile(apply_filters(dir("/nix")))+            tar.addfile(apply_filters(dir("/nix/store")))++        for path in paths:+            ti = tar.gettarinfo(os.path.join("/", path))+            tar.addfile(apply_filters(append_root(ti)))++            for root, dirs, files in os.walk(path, topdown=True):

Yep, agree, will look at that.

purcell

comment created time in 15 days

Pull request review commentNixOS/nixpkgs

dockerTools: add streaming image support, improve speed and reduce IO

 rec {     })   ); +  streamLayeredImage = {+    # Image Name+    name,+    # Image tag, the Nix's output hash will be used if null+    tag ? null,+    # Files to put on the image (a nix store path or list of paths).+    contents ? [],+    # Docker config; e.g. what command to run on the container.+    config ? {},+    # Time of creation of the image. Passing "now" will make the+    # created date be the time of building.+    created ? "1970-01-01T00:00:01Z",+    # Optional bash script to run on the files prior to fixturizing the layer.+    extraCommands ? "",+    # We pick 100 to ensure there is plenty of room for extension. I+    # believe the actual maximum is 128.+    maxLayers ? 100+  }:+    assert+      (lib.assertMsg (maxLayers > 1)+      "the maxLayers argument of dockerTools.buildLayeredImage function must be greather than 1 (current value: ${toString maxLayers})");+    let+      streamScript = writePython3 "stream" {} ./stream_layered_image.py;+      baseJson = writeText "${name}-base.json" (builtins.toJSON {+         inherit config;+         architecture = buildPackages.go.GOARCH;+         os = "linux";+      });+      customisationLayer = runCommand "${name}-customisation-layer" { inherit extraCommands; } ''+        cp -r ${contentsEnv}/ $out++        if [[ -n $extraCommands ]]; then
        if [[ -n "$extraCommands" ]]; then
purcell

comment created time in 15 days

PR opened NixOS/nixpkgs

dockerTools: add streaming image support, improve speed and reduce IO

<!-- To help with the large amounts of pull requests, we would appreciate your reviews of other pull requests, especially simple package updates. Just leave a comment describing what you have tested in the relevant package/service. Reviewing helps to reduce the average time-to-merge for everyone. Thanks a lot if you do! List of open PRs: https://github.com/NixOS/nixpkgs/pulls Reviewing guidelines: https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/download/1/nixpkgs/manual.html#chap-reviewing-contributions -->

Motivation for this change

In the context of client work, we (@utdemir and myself) have been producing large (multi-GB) docker images with Nix. These work nicely once produced, with the obvious limitations of unwieldy images, but the machinery for producing them via Nix is costly in a couple of senses:

  1. A great deal of IO is performed in the course of building images, since intermediate tar files are created for each layer, then a final tar created for the full image.
  2. Docker images are often immediately loaded into a docker daemon or copied around with tools like skopeo, but dockerTools always realises them into the Nix store, where they will be included in binary caches and generally take up lots of disk space, particularly in a CI environment.

We set about addressing both these costs, by using the following scheme:

  • Firstly, we rewrite the Nix + bash code for producing a docker image tarball as a Python program which avoids creating intermediate files.
  • Next, we provide streamImage and streamLayeredImage functions, analogous to buildImage and buildLayeredImage, but which produce as their outputs scripts which - when run - write the corresponding docker image to stdout, streaming directly from the underlying layer content store paths. For many users, this will be all they need.
  • buildImage and buildLayeredImage use the new "stream" machinery to realise the image tarballs into the Nix store as before, for those users who still want this functionality.
  • buildImage uses buildLayeredImage to build a one-layered image, where previously those two functions had parallel implementations.

Our results have been encouraging locally. Given the following example large image definition:

{nixpkgs}:
let
  pkgs = import nixpkgs { };
in
pkgs.dockerTools.buildLayeredImage {
  name = "test";
  maxLayers = 4;
  tag = "latest";
  contents = [
    (pkgs.writeScriptBin "test" "echo 1212")
    pkgs.ghc
    pkgs.qt4
    pkgs.qemu
    pkgs.clang
  ];
  config = {
    Cmd = "ghci";
  };
}

building after these changes takes 1m33s vs 5m58s with the previous code. Additionally, with the streamLayeredImage function, the same image can be piped to docker load in 2 minutes 30 seconds.

We're presenting these changes for feedback on API and approach. Some further notes:

  • These changes pass the existing nixos tests.
  • Other offline testing in our local project environment has taken place.
  • We target a newer Docker image standard (1.2) than the previous code, and therefore do not need to use tarsum. We believe that the newer standard - which has been supported since Docker 1.12 - should be fine for all reasonable real-world uses.
  • There was previously the ability to override ownership of files in images to a non-root user, but this does not seem necessary or desirable, and we have not provided that option.
  • If additional documentation is needed as part of this, we'd be happy to provide it if directed.
  • We have yet to add some separate tests for the streaming API: the code is covered by existing tests, but specific test cases may be helpful to prevent regressions later.

Thanks!

Things done

<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->

  • [ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • [x] NixOS
    • [ ] macOS
    • [ ] other Linux distributions
  • [x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • [ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • [x] Tested execution of all binary files (usually in ./result/bin/)
  • [ ] Determined the impact on package closure size (by running nix path-info -S before and after)
  • [ ] Ensured that relevant documentation is up to date
  • [x] Fits CONTRIBUTING.md.
+395 -300

0 comment

4 changed files

pr created time in 15 days

issue commentpurcell/whole-line-or-region

How to configure `whole-line-or-region` to use `cua-mode` copy/paste shortcuts

I've never done this, and I'm not quite sure what you mean.

As far as I know, cua-mode binds certain keys to cua-* commands, e.g. cua-cut-region and cua-paste, and those aren't particularly overridden by whole-line-or-region, so there wouldn't be anything "in" whole-line-or-region to bind those keys to.

sridharrajs

comment created time in 15 days

Pull request review commentNixOS/nixpkgs

libprom: init at 0.1.1

+{ gccStdenv+, fetchFromGitHub+, cmake+}:+let+  stdenv = gccStdenv; # So it builds on Mac

Not sure either, but I was the one who wrote this part, having tested on MacOS and found that the default clang stdenv on Darwin did not work.

cfsmp3

comment created time in 16 days

push eventpurcell/emacs.d

Steve Purcell

commit sha 48ae5264c6042eeb1e8abc9608536ffad052848e

Use rg (if available) to list files in generic projectile roots

view details

push time in 17 days

push eventpurcell/emacs.d

Steve Purcell

commit sha 95239d59518a3439b6c439e123dc7adce1a0978f

Don't enable flycheck-relint by default

view details

Steve Purcell

commit sha b14be4b670416a48fd18e1cf0cbed6d7818211ba

Don't bother aliasing with-eval-after-load

view details

push time in 17 days

issue closedmelpa/melpa

gnus package

add https://github.com/velkyel/gnus-article-treat-patch to melpa please. thank you

closed time in 17 days

velkyel

issue commentmelpa/melpa

gnus package

Sure, please open a pull request adding a recipe (see the README), and follow the guidelines in https://github.com/melpa/melpa/blob/master/CONTRIBUTING.org to ensure it's a well-formed package.

velkyel

comment created time in 17 days

issue closedtarget/lorri

Crashes when run with a PTY

Describe the bug <!-- A clear and concise description of what the bug is. -->

I'd like to run "lorri daemon" headless inside Emacs, but when launched in this non-PTY environment, it crashes immediately.

To Reproduce Steps to reproduce the behavior:

  1. Make a new Emacs buffer
  2. M-: (start-process "lorri" (current-buffer) "lorri" "daemon") RET

Expected behavior

Would expect the regular output, ideally sans ANSI escape chars.

Metadata

name = 'lorri'
operating_system = 'unix:OSX'
crate_version = '1.0.0'
explanation = '''
Panic occurred in file '<::std::macros::panic macros>' at line 5
'''
cause = 'slog::Fuse Drain: Custom { kind: Other, error: "term error: operation not supported by the terminal" }'�
method = 'Panic'
backtrace = '''

   0: 0x101882b38 - <slog::Fuse<D> as slog::Drain>::log::{{closure}}::h69b136a754729aaf
   1: 0x101879d75 - std::sys_common::backtrace::__rust_begin_short_backtrace::h32f957c880701dd3
   2: 0x101836102 - std::panicking::try::do_call::hf6ec1bc2242853f3
   3: 0x101a72eeb - __rust_maybe_catch_panic
   4: 0x1018927b2 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h6b1895114b4bb57d
   5: 0x101a5b94e - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h5537a38c17bbeeaa
   6: 0x101a54b0b - std::sys_common::thread::start_thread::h0e097bc28f949695
   7: 0x101a66289 - std::sys::unix::thread::Thread::new::thread_start::h3345078aa123cf09
   8: 0x7fff717a1109 - _pthread_start'''
$ lorri --version
lorri 1.0.0

<!-- Please run uname -a and paste its output here. -->

$ uname -a
Darwin HOSTNAME 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64 i386 MacBookPro14,2 Darwin

closed time in 17 days

purcell

issue commenttarget/lorri

Crashes when run with a PTY

Oops, yes, looks similar -- sorry for the noise: I only looked at open tickets before filing this. I might try building the latest lorri if I get chance, otherwise I'll try again after the next release.

purcell

comment created time in 17 days

issue closedpurcell/nix-emacs-ci

Build Emacs versions back to 24.1 or perhaps 23.4

Emacs 24.3 introduced a bunch of developer-facing changes, e.g. the inclusion of cl-lib, so it would be nice to be able to regression-test against older versions.

However, at least on MacOS (where I typically develop), it's not possible to build 24.1 and 24.2.

It would probably be possible to support 24.1 and 24.2 on Linux without too much trouble, though.

closed time in 17 days

purcell

issue commentpurcell/nix-emacs-ci

Build Emacs versions back to 24.1 or perhaps 23.4

Not going to work on adding additional older builds, so closing this now.

purcell

comment created time in 17 days

issue closedpurcell/nix-emacs-ci

Probably broken on MacOS due to Catalina

This uses Nix, and the Nix installer is broken on Catalina. A workaround for those who need it might be to use https://github.com/cachix/install-nix-action first, which does some contortions in order to install Nix on this OS. Otherwise, I intend to wait until the official Nix installer works correctly on Catalina.

closed time in 17 days

purcell

issue openedtarget/lorri

Crashes when run with a PTY

Describe the bug <!-- A clear and concise description of what the bug is. -->

I'd like to run "lorri daemon" headless inside Emacs, but when launched in this non-PTY environment, it crashes immediately.

To Reproduce Steps to reproduce the behavior:

  1. Make a new Emacs buffer
  2. M-: (start-process "lorri" (current-buffer) "lorri" "daemon") RET

Expected behavior

Would expect the regular output, ideally sans ANSI escape chars.

Metadata

name = 'lorri'
operating_system = 'unix:OSX'
crate_version = '1.0.0'
explanation = '''
Panic occurred in file '<::std::macros::panic macros>' at line 5
'''
cause = 'slog::Fuse Drain: Custom { kind: Other, error: "term error: operation not supported by the terminal" }'�
method = 'Panic'
backtrace = '''

   0: 0x101882b38 - <slog::Fuse<D> as slog::Drain>::log::{{closure}}::h69b136a754729aaf
   1: 0x101879d75 - std::sys_common::backtrace::__rust_begin_short_backtrace::h32f957c880701dd3
   2: 0x101836102 - std::panicking::try::do_call::hf6ec1bc2242853f3
   3: 0x101a72eeb - __rust_maybe_catch_panic
   4: 0x1018927b2 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h6b1895114b4bb57d
   5: 0x101a5b94e - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h5537a38c17bbeeaa
   6: 0x101a54b0b - std::sys_common::thread::start_thread::h0e097bc28f949695
   7: 0x101a66289 - std::sys::unix::thread::Thread::new::thread_start::h3345078aa123cf09
   8: 0x7fff717a1109 - _pthread_start'''
$ lorri --version
lorri 1.0.0

<!-- Please run uname -a and paste its output here. -->

$ uname -a
Darwin HOSTNAME 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64 i386 MacBookPro14,2 Darwin

created time in 17 days

PR closed purcell/package-lint

Warn if indentation is inconsistent with elisp defaults

I suspect this one's a bit slow. What do you think, @Fanael?

+38 -14

11 comments

2 changed files

purcell

pr closed time in 17 days

pull request commentpurcell/package-lint

Warn if indentation is inconsistent with elisp defaults

Closing due to issues described previously.

purcell

comment created time in 17 days

pull request commentfluxfederation/pumpkin

Haskell backend improvements, including Docker support

Feel like a million years since we were hacking on this...

purcell

comment created time in 17 days

pull request commentfluxfederation/pumpkin

Haskell backend improvements, including Docker support

Running out of work to do so trawling through old PRs @purcell? 😂

Found this in my list of still-open PRs on github so, yes, tidying up! LOL.

purcell

comment created time in 17 days

issue closeddataloop-ai/dtlpy

Declared dependency on opencv-python is problematic

opencv-python is a specific pre-compiled packaging of cv2, but other popular packages exist, e.g. opencv-contrib-python from the same authors, which contains cv2 plus extra features.

If a project which is using opencv-contrib-python for its extra features tries to also include dtlpy, the result will be two incompatible cv2 modules getting installed, and the project can fail to find the extra contrib features. At my current client, we have encountered this issue, and are unable to use dtlpy without maintaining a local fork.

In practice, it it also common for cv2 to be installed in the Python enviromment using system packaging, in which case pre-compiled python package of opencv from pypi are undesirable.

The suggested resolution would be to remove the explicit dependency on opencv-python, and instead note in documentation that cv2 must be installed by the user, either via system packages or by installing a precompiled version such as opencv-python or opencv-contrib-python.

Thanks!

closed time in 17 days

purcell

issue commentdataloop-ai/dtlpy

Declared dependency on opencv-python is problematic

This appears resolved in 1.16.10 - thanks!

purcell

comment created time in 17 days

PR closed travisbhartwell/nix-emacs

Fix broken detection of nix context
  • Backend raised errors in non-nix-related buffers that were not associated with a file, e.g. *scratch*
  • derived-mode-p is the correct way to test for the current major modes
  • Also enable in nix-repl-mode
+3 -3

1 comment

1 changed file

purcell

pr closed time in 17 days

pull request commenttravisbhartwell/nix-emacs

Fix broken detection of nix context

Closing due to lack of response, to get it off my list of open PRs.

purcell

comment created time in 17 days

push eventpurcell/package-lint

Steve Purcell

commit sha ff88d39dc47b4dd86e9d35614d8b5e227220339c

Warn if depending on future versions of Emacs

view details

push time in 18 days

pull request commentNixOS/nixpkgs

netcdf: prevent bogus runtime dependency on gcc

/cc recent committers @r-ryantm, @markuskowa

purcell

comment created time in 19 days

issue commentpurcell/nix-emacs-ci

emacs 27 versions?

You can bet I'll have support added here promptly after the release: the try-27-pre branch was to make sure that will be possible without unexpected complications. :-) Happy emacsing!

ibizaman

comment created time in 19 days

pull request commentNixOS/nixpkgs

fast-downward: 2019-05-13 -> 19.12, build on darwin, fix runtime issues

Fixed now, updated and improved.

purcell

comment created time in 20 days

push eventpurcell/nixpkgs

Steve Purcell

commit sha af76ba6c576b450dacfb91ebd692503d080796db

fastdownward: 2019-05-13 -> 19.12 - Use supplied build.py mechanism instead of working around it - Freeze release location into resulting Python so fast-downward script actually works

view details

push time in 20 days

pull request commentNixOS/nixpkgs

netcdf: prevent bogus runtime dependency on gcc

That worked nicely, @doronbehar, thanks.

purcell

comment created time in 20 days

push eventpurcell/nixpkgs

Steve Purcell

commit sha b460e8bbb49f22adb6af23a8391bbc7b8649a8a3

netcdf: prevent bogus runtime dependency on gcc Installation includes the the captured compilation settings in the outputs, and the full gcc path then leads to a bogus runtime dependency. To defeat this, we remove any occurrences of the compiler's store dir prefix from this file after installation.

view details

push time in 20 days

pull request commentNixOS/nixpkgs

fast-downward: also build on darwin

The existing package is broken even on Linux, in fact:

nix run -f '<nixpkgs>'  fast-downward -c fast-downward domain.pddl problem-1.pddl --search "astar(add())"                                                                         /tmp
INFO     Running translator.
Could not find build 'release' at /nix/store/d0xizg2aqqar6g1ls9mjmzj38z67r422-fast-downward-2019-05-13/lib/python3.7/site-packages/builds/release/bin. Please run './build.py release'.

I'm having a quick look at fixing this.

purcell

comment created time in 20 days

pull request commentNixOS/nixpkgs

fast-downward: also build on darwin

Hmm, bear with me, testing this a little more first.

purcell

comment created time in 20 days

PR opened NixOS/nixpkgs

fast-downward: also build on darwin

<!-- To help with the large amounts of pull requests, we would appreciate your reviews of other pull requests, especially simple package updates. Just leave a comment describing what you have tested in the relevant package/service. Reviewing helps to reduce the average time-to-merge for everyone. Thanks a lot if you do! List of open PRs: https://github.com/NixOS/nixpkgs/pulls Reviewing guidelines: https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/download/1/nixpkgs/manual.html#chap-reviewing-contributions -->

Motivation for this change

This package also builds happily on Darwin.

Things done

<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->

  • [ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • [ ] NixOS
    • [x] macOS
    • [ ] other Linux distributions
  • [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • [ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • [ ] Tested execution of all binary files (usually in ./result/bin/)
  • [ ] Determined the impact on package closure size (by running nix path-info -S before and after)
  • [ ] Ensured that relevant documentation is up to date
  • [x] Fits CONTRIBUTING.md.
+1 -1

0 comment

1 changed file

pr created time in 20 days

create barnchpurcell/nixpkgs

branch : fast-downward-darwin

created branch time in 20 days

pull request commentNixOS/nixpkgs

netcdf: prevent bogus runtime dependency on gcc

Thanks @doronbehar, that's a helpful pointer.

purcell

comment created time in 20 days

issue commentpurcell/nix-emacs-ci

emacs 27 versions?

I thought about this, but I plan to wait for the official release. I don't want to get into maintaining pre versions. Also they'd have to be labelled as 27 and not 27-pre, since if people started using the latter, I'd either have to keep that working forever or break builds by removing it.

ibizaman

comment created time in 20 days

push eventpurcell/emacs.d

Steve Purcell

commit sha 0340a2d0fb54a58d502691f615e8a80f5b3274ce

Reformulate init-nix

view details

push time in 21 days

pull request commentmelpa/melpa

Add directories.el

Nice! I feel like the "directories" package name is a little too broad, and is likely to lead to confusion, since "directories" has a lot of connotations. Might I suggest "platform-directories", "shared-directories", "standard-directories" or "common-directories"? I know they're a bit longer, but I think that's a good thing in this case. (You could always contract "-directories" to "-dirs" or "-paths", of course.)

lafrenierejm

comment created time in 21 days

more