profile
viewpoint
Lily Ballard lilyball Twitch San Francisco, CA https://blog.eridi.us iOS Developer at Twitch. Open source contributor. Programming language aficionado. She/her.

apple/swift 52880

The Swift Programming Language

apple/swift-evolution 11362

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

apple/swift-package-manager 7880

The Package Manager for the Swift Programming Language

apple/swift-corelibs-foundation 3955

The Foundation Project, providing core utilities, internationalization, and OS independence

apple/swift-corelibs-libdispatch 1853

The libdispatch Project, (a.k.a. Grand Central Dispatch), for concurrency on multicore hardware

apple/swift-corelibs-xctest 846

The XCTest Project, A Swift core library for providing unit test support

apple/swift-llbuild 792

A low-level build system, used by Xcode and the Swift Package Manager

apple/swift-lldb 647

This is the version of LLDB that supports the Swift programming language & REPL.

startedjaywcjlove/awesome-mac

started time in a day

issue openedlilyball/Tomorrowland

Rename the master branch

We should rename the default branch from master to main. GitHub is working on doing seamless support for this migration "later this year". I'm not sure most of that stuff matters though, there's no in-flight PRs or draft releases or branch protection policies. The only applicable thing here is the potential to automatically redirect users who git fetch or git clone the master branch.

created time in a day

delete branch lilyball/nixpkgs

delete branch : cocoapods-beta

delete time in a day

issue openedjorgebucaran/fisher

Consider fetching HEAD instead of main/master

The release notes for v3.3.0 says that fisher now defaults to /main before /master if the tag/branch isn't specified.

This seems weird to me. It should just default to whatever HEAD is, because the remote HEAD declares the default branch. Not only would this more closely match the behavior of other tools that use git, but it also avoids enshrining any particular branch name at all.

created time in a day

issue openedNixOS/nixpkgs

fetchers should be overridable

Describe the bug None of the fetchers that I've looked at so far support overriding the fetch arguments. This is rather annoying when trying to override derivations that use them, as I need to repeat the original fetcher in my override instead of merely overriding the arguments I want to change.

This could be solved by wrapping all of the fetchers with lib.makeOverridable. I don't know what the performance implications are of turning these functions into functors instead, but I would hope it's negligible.

I was going to simply submit a PR for this, but we have a lot more fetchers than I thought, and I didn't want to do that work unless I knew it would be accepted.

As an example, if I want to change the version of ffsend, right now I have to write

ffsend.overrideAttrs (super: rec {
  version = "0.2.64";
  cargoSha256 = "…";
  src = fetchFromGitLab {
    owner = "timvisee";
    repo = "ffsend";
    rev = "v${version}";
    sha256 = "…";
  };
})

This is repeating stuff that I really shouldn't have to do here, including the fact that ffsend uses GitLab instead of GitHub, and the repo/owner. I should be able to instead write

ffsend.overrideAttrs (super: rec {
  version = "0.2.64";
  cargoSha256 = "…";
  src = super.src.override {
    rev = "v${version}";
    sha256 = "…";
  };
})

And with the mkDerivation changes proposed in #94198 that would shrink even further to

ffsend.overrideAttrs (super: {
  version = "0.2.64";
  cargoSha256 = "…";
  src = super.src.override {
    sha256 = "…";
  };
})

created time in 6 days

pull request commentNixOS/nixpkgs

stdenv.mkDerivation: Support argument being a fixed-point function (self: { … }) instead of rec { … }

I guess a problem with the proposed lib.recursiveUpdateDrvs is if fetchers become overridable then I'd actually want to be able to say

lib.recursiveUpdateFoo hello {
  version = "2.9";
  src.sha256 = "…";
}

as something that expands to

hello.overrideAttrs (super: {
  version = "2.9";
  src = super.src.override {
    sha256 = "…";
  };
})

So I'll sit on that thought for a while; it's orthogonal to this PR anyway.

lilyball

comment created time in 6 days

pull request commentNixOS/nixpkgs

stdenv.mkDerivation: Support argument being a fixed-point function (self: { … }) instead of rec { … }

My other thought is that overriding derivations is still annoying when dealing with fetchers. It might be nice to introduce something like lib.recursiveUpdateDrvs that works kind of like lib.recursiveUpdate by merging attrsets, except if it finds a derivation on the lhs and an attrset on the rhs it would call overrideAttrs on it (to be specific, if the lhs is a derivation with an overrideAttrs attr and the rhs is a non-derivation attrset). This way I could write

lib.recursiveUpdateDrvs hello {
  version = "2.9";
  src.outputHash = "…";
}

and it would evaluate to

hello.overrideAttrs (super: {
  version = "2.9";
  src = super.src.overrideAttrs (_: {
    outputHash = "…";
  });
})

This is less obviously helpful with the current state of nixpkgs, because src generally needs to be replaced rather than merely overridden (due to the inability to change the arguments passed to fetchers).

lilyball

comment created time in 6 days

pull request commentNixOS/nixpkgs

stdenv.mkDerivation: Support argument being a fixed-point function (self: { … }) instead of rec { … }

My biggest question here is whether this impacts performance. For existing code, this effectively changes mkDerivation to go from mkDerivation attrs to mkDerivation (lib.fix (_: attrs)) plus a call to lib.isFunction (I'm ignoring overrideAttrs since that's rarely used within nixpkgs itself). I'm hoping there's no measurable difference with this change, but I'm also not sure how to reasonably measure this.

If there is a measurable performance difference, the definition of mkDerivation can be split in two based on the result of lib.isFunction such that one path looks just like the old code. But I'm guessing that lib.fix (_: attrs) is negligible.

lilyball

comment created time in 6 days

PR opened NixOS/nixpkgs

stdenv.mkDerivation: Support argument being a fixed-point function (self: { … }) instead of rec { … }
Motivation for this change

This came out of https://discourse.nixos.org/t/avoid-rec-expresions-in-nixpkgs/8293/6?u=lilyball as a proposed way to avoid using rec { … } with mkDerivation. The problem with rec { … } is it makes it harder to override, as any reference to an attribute from the set needs to be overridden. In particular, version tends to be re-used, requiring overriding it in multiple places, especially in the URLs given to src fetchers.

The approach taken here is to have mkDerivation detect if it's given a function instead of an attrset, and if it is a function, then it makes that function into a fixed point, calling it with a self value that's the fully-evaluated arguments (not the result of mkDerivation, just the arguments given to it). Switching to this style produces no changes in the resulting derivation, so it causes no rebuilds. But what it does is make overrideAttrs easier. Instead of saying

hello.overrideAttrs (super: {
  version = "2.9";
  src = fetchurl {
    url = "mirror://gnu/hello/hello-2.9.tar.gz";
    sha256 = "19qy37gkasc4csb1d3bdiz9snn8mir2p3aj0jgzmfv0r2hi7mfzc";
  };
  meta = super.meta // {
    changelog = "https://git.savannah.gnu.org/cgit/hello.git/plain/NEWS?h=v2.9";
  };
})

you can now write

hello.overrideAttrs (super: {
  version = "2.9";
  src = super.src.overrideAttrs (_: {
    outputHash = "19qy37gkasc4csb1d3bdiz9snn8mir2p3aj0jgzmfv0r2hi7mfzc";
  });
})

(sadly none of the fetchers I looked at, including fetchurl, allow you to override the arguments given to them directly, but overriding outputHash works for all the fetchers I inspected (fetchurl, fetchFromGitHub, and fetchzip)).

As a second step, this PR also updates overrideAttrs to support its argument as either super: { … )} or self: super: { … }, in case the overrideAttrs expects that it might be further customized and wants to introduce its own self-referential values.

This works by passing the super value to the argument and checking if it gets a function back; if so, it re-calls the argument with self super instead. I chose this approach because any existing overrideAttrs expects just super and must return an attrset, so if we get a function then it must be the new approach.

I also updated the stdenv adapters, though I haven't actually tested them.

TODO

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
  • [ ] Fits CONTRIBUTING.md.
+42 -24

0 comment

3 changed files

pr created time in 6 days

create barnchlilyball/nixpkgs

branch : mkDerivation-fixed-point-arg

created branch time in 6 days

CommitCommentEvent

issue commentNixOS/nix

macOS 11 (Big Sur beta 3) further locks down /

I just read that post, and it sounds like the changes here aren't actually related to being unable to mount a volume rw on a path listed in synthetic.conf, as none of this touches the system volume. It definitely just seems like a bug.

ryanbooker

comment created time in 7 days

issue commentfastlane/fastlane

scan: include_simulator_logs collects months worth of log data

fastlane env isn't particularly helpful here. I'm passing include_simulator_logs: true in my scan args, and scan is invoking log collect on the simulator without providing either --start or --last, so it collects everything.

lilyball

comment created time in 7 days

issue commentCanop/broot

Move shell scripts to standalone files in repo, `include_str!()` them in the source

After giving this even more thought, it occurs to me if I only take over fish and not bash, broot doesn't know what shell it was invoked from so it will prompt to install the bash function anyway. It also occurs to me that installing broot with Nix but fish with a separate package manager means Nix can't provide functions to fish, so maybe I don't want a compile-time flag.

Does broot know not to do this if given the --outcmd flag, since that implies it's being called from the br function?

Given all this, I think the setup that works best for me is:

  • If --outcmd is provided, disable shell installation checking since it's presumably already being invoked from br.
  • Use either an env var or a flag that disables shell installation checking. I like env var so that way ps isn't showing extra flags, but maybe a flag would be better so that way it's not inherited by subprocesses, because either way, I'm going to need to wrap broot myself to set the env var or flag.

With this, I can then vend broot to everyone, include the fish function in cases where Nix installed fish itself, and also provide a fish function that wraps broot in order to set the env var / flag that disables shell checking, in case the user runs broot instead of br. This way if they then run broot from bash, they'll get prompted.

The downside here is installation from a run from bash will still reinstall the fish function and there's not much I can do about that given that I can't assume that Nix will provide the fish function.

lilyball

comment created time in 7 days

issue openedfastlane/fastlane

scan: include_simulator_logs collects months worth of log data

New Issue Checklist

Issue Description

Now that include_simulator_logs finally works, I did a run and my collected logarchive contained about 3.5 months worth of data totaling 500MB. This is extremely unwieldy.

It looks like scan is just trying to collect everything. Instead it should take note of the time prior to launching the tests, and then collect with the --start flag to only grab logs from the relevant time frame.

created time in 7 days

issue closedfastlane/fastlane

scan: include_simulator_logs silently fails always in recent iOS

New Issue Checklist

Issue Description

When passing include_simulator_logs: true, the log collection silently fails 100% of the time against a recent simulator. I assume it worked against iOS 12 simulators (but have not tested) because otherwise I don't know how this would have been missed, but against an iOS 13 simulator (I've tested iOS 13.4 and iOS 13.5) it produces an empty logarchive folder. Running the command by hand (without suppressing stderr) produces

log: failed to collect LiveData: No such file or directory (2)
Archive successfully written to /path/to/system_logs-iPhone 8_iOS_13.5.logarchive

The culprit here is the --standalone flag. This flag was introduced in https://github.com/fastlane/fastlane/pull/15440 as a misguided fix for https://github.com/fastlane/fastlane/issues/15205. The real problem with #15205 was attempting to collect logs from a shutdown device. This is what the --standalone flag is for, except log collect doesn't work in a standalone fashion, not even when the device is booted.

The correct fix here is for scan to ensure the device is booted prior to running the tests (assuming it wants to collect logs), then collect logs without --standalone, then shut down the device (assuming it booted it in the first place). If the device is already booted when xcode is told to run its tests, xcode will leave the device in the booted state after the tests are done (as opposed to shutting it down, which is what xcode does if it had to boot the device in the first place). By keeping it booted, it can collect the logs without --standalone, which should work, and then it can shut it down.

Ideally it would do a build-for-testing first, then boot the sim, then a test, then shut down the sim. This way the sim isn't running prematurely. It should also ensure that it catches any exceptions thrown during the test process (e.g. because it was signalled) in order to shut down the simulator (if it had booted it).

closed time in 7 days

lilyball

issue commentfastlane/fastlane

scan: include_simulator_logs silently fails always in recent iOS

This was fixed by #16833.

lilyball

comment created time in 7 days

issue commentCanop/broot

Move shell scripts to standalone files in repo, `include_str!()` them in the source

I didn't know about the --print-shell-function commands. That helps. But --set-install-state doesn't because I can't run that as part of the Nix build. Nix builds can't touch anything outside of the Nix store (the results are made available to PATH via a symlink), and broot stores its install state in ~/.config/broot/launcher/installed-v1 which Nix can't set.

In order to use this from Nix, I'd have to replace broot with a shell script that does something like

path/to/real/broot --set-install-state installed
exec path/to/real/broot "$@"

Given the existence of --print-shell-function, all I need at this point is a way to statically declare that it should never auto-install (preferably with separate flags for bash and fish)

lilyball

comment created time in 7 days

issue commentNixOS/nix

macOS 11 (Big Sur beta 3) further locks down /

@ryanbooker What you describe sounds like Catalina. It's unclear to me what's changed in this regard for Big Sur, besides the volume mounting bug.

ryanbooker

comment created time in 7 days

startedlilyball/Tomorrowland

started time in 8 days

issue openedlilyball/Tomorrowland

Add Operation subclass that works with Promise

It would be useful to have an async Operation subclass that wraps a computation and has an associated Promise. This would make it easier to integrate promises into dependency management that Operation is good at expressing.

With this approach, the client would create an instance of the Operation subclass, and the instance would have an associated read-only promise property that returns a promise that is resolved by the operation's computation. No computation occurs until the operation starts (either by calling start() or by adding it to a queue). Requesting cancellation of the promise should call cancel() on the operation, and calling cancel() on the operation should request cancellation of the promise.

created time in 8 days

issue commentlyndsey-ferguson/fastlane-plugin-test_center

Logs from simulators empty

I finally got a chance to test this, and I finally have logs! 🎉

lyndsey-ferguson

comment created time in 8 days

release lilyball/Tomorrowland

v1.4.0

released time in 8 days

issue commentNixOS/nix

macOS installer "failed to configure synthetic.conf"

It sounds like the install script should override the umask before making any modifications.

As for whether your umask will affect anything, I'm really not sure. Since you used --daemon, unprivileged commands (e.g. nix-env -iA foo) will ask the daemon to make the changes, so your local shell's umask shouldn't affect it. But I think commands executed with sudo may just manipulate the store directly (and in particular nix-channel --update requires sudo here), and I'm not sure if nix will reset the umask itself. Your best bet is to test it and see if anything breaks, especially since you still have a fresh install and therefore wiping and reinstalling isn't too onerous if you end up in a state where permissions are screwy.

steshaw

comment created time in 8 days

issue commentmanosim/gitify

Gitify does not send any notification from github.com if it is not able to access to GitHub Enterprise server.

It doesn't just not send notifications, but it also replaces the entire UI with a "Something went wrong" page so I can't even check the notifications myself.

pddg

comment created time in 8 days

issue commentNixOS/nix

macOS 11 (Big Sur beta 3) further locks down /

The fact that mounting a volume using synthetic.conf in Big Sur isn't working seems like a bug, and Apple is aware of it. It remains to be seen whether it will be fixed, but I'm hopeful, as this was one of the two primary use-cases for synthetic.conf and it would be pretty bad for Apple to introduce this mechanism in one release only to break it in the next.

ryanbooker

comment created time in 8 days

issue openedNixOS/nix

`nix search` uses config dir to store temp files, doesn't clean them up

Describe the bug

I just checked my ~/.config/nix dir and I have a number of empty temporary package-search.json.tmp.### files, presumably from interrupted nix search invocations.

I expect nix search -u opens a temporary file as output, writes to it, and then when it's done it closes the file and moves it over the cache. This would be great, except the fact that they're empty suggests to me that it's actually buffering all the data in-memory. This may be because the JSON output contains no newlines, so if the file is line-buffered the buffer won't be flushed until it's closed.

Besides being empty, the other problem is just that they're there at all. Nothing is cleaning them up. Some are from today, some are from a couple of weeks ago.

Ideally these files would be written to $TMPDIR instead, so that way they'll at least be cleaned up on reboot; I'm not sure offhand what the right behavior to do if $TMPDIR is on a different filesystem though, as I'm assuming this is relying on file moving to be atomic in order to overwrite the current cache (macOS has an API specifically to ask for a temporary directory appropriate for a given path, but I don't know how to solve this generically). Alternatively, nix search could learn to delete any package-search.json.tmp.### files it finds if the trailing pid doesn't exist anymore, and perhaps ideally would also learn to clean up its tmpfile if it's interrupted prior to exiting.

Steps To Reproduce

  1. ls ~/.config/nix

Expected behavior

There shouldn't be any temporary files hanging out here.

nix-env --version output

nix-env (Nix) 2.3.7

created time in 8 days

issue commentNixOS/nix

Use /etc/zshenv instead of /etc/zshrc on macOS Catalina

Looks like this issue can be closed now.

surajbarkale

comment created time in 8 days

issue commentNixOS/nix

macOS installer "failed to configure synthetic.conf"

What is the output of type grep? The install script uses the status code from grep -q "^nix$" /etc/synthetic.conf 2>/dev/null to determine whether /etc/synthetic.conf has the nix line in it.

steshaw

comment created time in 8 days

issue openedNixOS/nix

`nix search` should indicate when a package doesn't support my platform

Is your feature request related to a problem? Please describe. When I use nix search to find a package, it's not obvious when the package doesn't support my platform.

Describe the solution you'd like nix search should have some indicator on the output when a package doesn't support my platform, and perhaps even a flag that filters out packages that don't support my platform.

It should probably also have a flag to let me override the notion of current platform, for when the computer I'm doing the lookup on isn't the one I'm going to install the software on.

created time in 8 days

issue openedNixOS/nix

Flag for `nix search` to include other meta attributes such as homepage

Is your feature request related to a problem? Please describe. I often have to look up the homepages of software when searching, either because the description is too generic, or missing (e.g. with autogenerated packages), or because I want more info.

Describe the solution you'd like nix search should have flags that include additional meta properties, including homepage, longDescription, and licenses.

created time in 8 days

issue openedNixOS/nix

`nix search` should detect when the cache is out of date and update it automatically

Is your feature request related to a problem? Please describe. nix search uses a cache to speed up searching, but it gets out of date very quickly, and any time it's used it prints a warning about how it's using the cache. There's no information as to whether the cache is actually out of date or not.

Describe the solution you'd like Typical usage of nix search is with configured channels. The current revision of each channel can be hashed to produce an identifier that can be embedded in the config and then tested to see if it's changed.

The four scenarios this simplistic approach doesn't handle:

  • Using -f to specify an alternative. The file in question could be hashed, but that won't take into account anything it imports. We could just fall back to current functionality for -f (also see #3866 which establishes a separate cache for -f).
  • When NIX_PATH contains something other than a channel. If it's a git checkout, nix search could detect this and use the currently-checked-out commit (this will ignore local modifications but I think that's okay). If it's something else, it could fall back to current functionality.
  • packageOverrides. nix search could include a hash of ~/config/nixpkgs/config.nix in the identifier. Probably a good idea anyway as various config options could enable/disable packages.
  • Overlays. nix search could just hash the entire directory tree for the overlays since it's unlikely to be especially large, or it could just declare that overlays aren't considered and that if the user updates their overlays they should explicitly pass -u to nix search.

Describe alternatives you've considered For -f, nix search could instrument the Nix evaluation such that it records every imported path and use that to build a tree of files to consult for the check. This seems rather complicated though, especially since it would need to recognize when a <nixpkgs> reference is used (or just always assume the NIX_PATH affects evaluation).

created time in 8 days

issue openedNixOS/nix

`nix search` should take -f flag into account for the cache

Is your feature request related to a problem? Please describe. If I run nix search -f … it applies an existing cache even if the cache wasn't made for the given file. If I use nix search -u -f … it overwrites the shared cache, which means subsequent nix search commands will use that cache even though it doesn't apply.

Describe the solution you'd like By default, using -f should imply --no-cache. Using -fwith -u should use a separate cache file keyed on the realpath of the file argument.

created time in 8 days

issue openedNixOS/nix

`nix search` should show me how old the cache is

Is your feature request related to a problem? Please describe. When I run nix search it always gives me a warning about how it's using cached results. That's fine, but it doesn't tell me how old the cache is.

Describe the solution you'd like It would be great if it could include the cache age (could be the absolute date of the cache, but ideally it would be how old the cache is, e.g. "5 hours old", "107 days old", etc).

created time in 8 days

issue openedmanosim/gitify

Multiple instances for different accounts

Right now if I log into both github.com and GHE, Gitify uses a single status bar item (macOS) that shows notifications for both in a single window.

I'd really like to be able to get a separate status bar item per account, ideally with customization of the colors (so I can quickly distinguish them at a glance) or perhaps varying image options. This way I can tell just by glancing at my status bar whether I have notifications for github.com or for GHE and I can deal with them separately.

Ideally this would be a single app that has multiple status items, which suggests the preferences would need to go into their own window instead of replacing the current window contents. Less ideally, if there was a simple way of making multiple Gitify instances on disk with unique identifiers (so their persisted settings don't conflict) such that I can run them separately.

created time in 8 days

issue commentmanosim/gitify

Can't add github.com account after I've configured Enterprise

I went ahead and logged out of GHE, then logged in to github.com, and then back into GHE. Very annoying, but it mostly worked. I actually had to then quit and relaunch Gitify before it showed the GHE notifications for some reason.

lilyball

comment created time in 8 days

issue openedmanosim/gitify

Can't add github.com notifications after I've configured Enterprise

I configured Gitify for GHE and skipped github.com during initial setup. Looking at it now, there's no way to add the github.com support; the Settings page just has an "Add Enterprise" button that, when clicked, takes me back to the already-configured enterprise (which I suppose means there's no way to add multiple GHE installations either).

created time in 8 days

push eventlilyball/git-scripts

Lily Ballard

commit sha 49c1d65000bb8f8b741a13dfb9b318ad1a27f2e9

Add support for the 'main' branch git-close-merged: main is now a protected ref like master git-close-current-branch: default to the main branch for an unspecified mainline unless master exists and main doesn't.

view details

push time in 8 days

push eventlilyball/git-scripts

Lily Ballard

commit sha a7d823ec5767a815d7fb4c0487678ee3940e2169

Fix shellcheck warnings

view details

push time in 8 days

push eventlilyball/git-scripts

Lily Ballard

commit sha 4055946b09ff62dbd2f73a7e5edd8038ddb342e1

Initial commit

view details

Lily Ballard

commit sha 24250351895a2807e17a1104a6b8c0f6dcdb5b38

Tweak README.md

view details

Lily Ballard

commit sha 3864b064d546f18fe0b00d4e29a83ad58eeee8c7

Import scripts

view details

Lily Ballard

commit sha 18614698e81e40efb48fb18c418e2fd238be2d56

Fix some issues with the color function in utils.bash

view details

Lily Ballard

commit sha 6138e459dd8f83b1aea5a70f30df73569321f739

Port git-dirs over to utils.bash

view details

Lily Ballard

commit sha d5fd09de205ad6b46fe400bc4fadd2106bbfb371

Tweak script utilities * Add print_lines * Add _expect * Update color and fatal

view details

Lily Ballard

commit sha 894d864ac76b6a2c33a3e98c62734fb80da055a6

Teach git-close-merged how to delete upstream branches

view details

Lily Ballard

commit sha ae4bdc46bfe04d31a34935ad4c23152c7f80c5f0

Document git-close-current-branch

view details

Lily Ballard

commit sha b8bdd1d7c0930d68c8e30b0d198fd3b31cb2c1b9

Document git-close-merged

view details

Lily Ballard

commit sha 12fb79bcaf09923d0621a4ae615f31cdd2c93984

Document git-dirs

view details

Lily Ballard

commit sha 9e2f7d19014ea4327c544d63b7392b2869f51edc

Document git-find-merge

view details

Lily Ballard

commit sha dc6cdcd81694a78dc1a76ae3d98ff75db3aa3721

Document git-find-tree

view details

Lily Ballard

commit sha 4ec208750cedbf4eb6e2242c97a774ba75e4386e

Document git-fugitive

view details

Lily Ballard

commit sha 8a369ee8690c0447a74920646f083c08901a1490

Tweak README to reference `-h` instead of `--help` It seems `git some-script --help` looks for a manpage even when `git some-script` is provided by a third-party script. Using `git some-script -h` instead works.

view details

Lily Ballard

commit sha e2f3670f5543345a52c5c9c08d1b6bfff2a81d4d

Document git-rebase-noninteractive

view details

Lily Ballard

commit sha 24754c7e54e15322b2440064feafb4db4156fb25

Document git-update-branch

view details

Lily Ballard

commit sha e28c06ceb0bfc02ed9a449ecc7f5233ac2959dfa

Merge branch 'documentation' Provide documentation for all commands.

view details

Lily Ballard

commit sha c68717f576b329296bbbc43183f7c3f0d53e5648

Tweak README formatting to look better on GitHub

view details

Lily Ballard

commit sha 63ac6d26f68a4ca44714fbcbe9b50ee970de3cdf

Add new script git-merge-pr

view details

Lily Ballard

commit sha d8c1ac34cba73f7bbbefcbeb64eb760294c3c51c

Fix git-rebase-noninteractive

view details

push time in 8 days

push eventlilyball/git-scripts

Lily Ballard

commit sha 4055946b09ff62dbd2f73a7e5edd8038ddb342e1

Initial commit

view details

Lily Ballard

commit sha 24250351895a2807e17a1104a6b8c0f6dcdb5b38

Tweak README.md

view details

Lily Ballard

commit sha 3864b064d546f18fe0b00d4e29a83ad58eeee8c7

Import scripts

view details

Lily Ballard

commit sha 18614698e81e40efb48fb18c418e2fd238be2d56

Fix some issues with the color function in utils.bash

view details

Lily Ballard

commit sha 6138e459dd8f83b1aea5a70f30df73569321f739

Port git-dirs over to utils.bash

view details

Lily Ballard

commit sha d5fd09de205ad6b46fe400bc4fadd2106bbfb371

Tweak script utilities * Add print_lines * Add _expect * Update color and fatal

view details

Lily Ballard

commit sha 894d864ac76b6a2c33a3e98c62734fb80da055a6

Teach git-close-merged how to delete upstream branches

view details

Lily Ballard

commit sha ae4bdc46bfe04d31a34935ad4c23152c7f80c5f0

Document git-close-current-branch

view details

Lily Ballard

commit sha b8bdd1d7c0930d68c8e30b0d198fd3b31cb2c1b9

Document git-close-merged

view details

Lily Ballard

commit sha 12fb79bcaf09923d0621a4ae615f31cdd2c93984

Document git-dirs

view details

Lily Ballard

commit sha 9e2f7d19014ea4327c544d63b7392b2869f51edc

Document git-find-merge

view details

Lily Ballard

commit sha dc6cdcd81694a78dc1a76ae3d98ff75db3aa3721

Document git-find-tree

view details

Lily Ballard

commit sha 4ec208750cedbf4eb6e2242c97a774ba75e4386e

Document git-fugitive

view details

Lily Ballard

commit sha 8a369ee8690c0447a74920646f083c08901a1490

Tweak README to reference `-h` instead of `--help` It seems `git some-script --help` looks for a manpage even when `git some-script` is provided by a third-party script. Using `git some-script -h` instead works.

view details

Lily Ballard

commit sha e2f3670f5543345a52c5c9c08d1b6bfff2a81d4d

Document git-rebase-noninteractive

view details

Lily Ballard

commit sha 24754c7e54e15322b2440064feafb4db4156fb25

Document git-update-branch

view details

Lily Ballard

commit sha e28c06ceb0bfc02ed9a449ecc7f5233ac2959dfa

Merge branch 'documentation' Provide documentation for all commands.

view details

Lily Ballard

commit sha c68717f576b329296bbbc43183f7c3f0d53e5648

Tweak README formatting to look better on GitHub

view details

Lily Ballard

commit sha 63ac6d26f68a4ca44714fbcbe9b50ee970de3cdf

Add new script git-merge-pr

view details

Lily Ballard

commit sha d8c1ac34cba73f7bbbefcbeb64eb760294c3c51c

Fix git-rebase-noninteractive

view details

push time in 8 days

issue openedCanop/broot

Move shell scripts to standalone files in repo, `include_str!()` them in the source

Is your feature request related to a problem? Please describe. Broot installs shell files on first launch, which not only means it's mucking with my user config, but if I then uninstall broot later, it leaves the files behind. For bash/zsh it looks like this modifies my rc/profile files, and for fish it adds an extra file to my ~/.config/fish/functions dir.

My package manager should be able to manage at least some of this for me. In particular, my package manager should be able to manage the fish script such that uninstalling broot removes it. bash/zsh support are a bit harder but possibly doable if my package manager writes out an rc file.

What's more, allowing the package manager to deal with this means the script can be written in a single place for systemwide installations, instead of separate per user.

Describe the solution you'd like This could be handled by making two changes:

  1. Move the bash/fish script contents to separate files in the repo in a predictable location, use include_str!() to pull them back into the source. This means no functional change to broot except my package manager can now find the files.
  2. Add a feature flag that disables broot's built-in shell integration. This way broot doesn't have to try to figure out whether my package manager has installed the files, it will simply use the feature. Ideally we'd actually have two features, one for bash/zsh and one for fish, because it's much easier for a package manager to deal with the fish script than the bash/zsh script.

Additional context I personally only care about Fish support, which is relatively easy to do with the proposed changes. If these changes are made, I can pretty easily update the Nix package to manage the Fish script directly.

created time in 8 days

CommitCommentEvent

issue commentjunegunn/fzf

Suggestion: Add keybinding to execute a preview command

I'm embarrassed to admit I didn't realize this was actually resolved with a commit. I came back to this ticket because I saw sholland1's comment, and I saw that the ticket was closed, but I didn't look closely at the reason for it being closed.

Now that I'm aware, I haven't tested the new code as it's not in a published release, but the manpage for the new code sounds like it does precisely what I want, thanks.

lilyball

comment created time in 8 days

issue commentNixOS/nix

macOS updates often break nix installation (updates replace path-hooks on multi-user install)

I filed feedback for Apple (FB8181728). In the meantime, nix-daemon will need to learn how to modify the files appropriately on launch.

amckinlay

comment created time in 8 days

Pull request review commentNixOS/nixpkgs

document nix-env bug relating to multiple output installation

   <title>Installing a split package</title>    <para>-   When installing a package via <varname>systemPackages</varname> or <command>nix-env</command> you have several options:+   When installing a package with multiple outputs, the package's <varname>meta.outputsToInstall</varname> attribute determines which outputs are actually installed. <varname>meta.outputsToInstall</varname> is a list whose <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/make-derivation.nix#L289">default installs binaries and the associated man pages</link>. The following sections describe ways to install different outputs.   </para> -  <itemizedlist>-   <listitem>-    <para>-     You can install particular outputs explicitly, as each is available in the Nix language as an attribute of the package. The <varname>outputs</varname> attribute contains a list of output names.-    </para>-   </listitem>-   <listitem>-    <para>-     You can let it use the default outputs. These are handled by <varname>meta.outputsToInstall</varname> attribute that contains a list of output names.-    </para>+  <section xml:id="sec-multiple-outputs-installing-nixos">+   <title>Selecting outputs to install via NixOS</title>++   <para>+    NixOS provides two ways to select the outputs to install for packages listed in <varname>environment.systemPackages</varname>:+   </para>++   <itemizedlist>+    <listitem>+     <para>+      The configuration option <varname>environment.extraOutputsToInstall</varname> is appended to each package's <varname>meta.outputsToInstall</varname> attribute to determine the outputs to install. It can for example be used to install for <literal>info</literal> documentation or debug symbols for all packages.+     </para>+    </listitem>+    <listitem>+     <para>+      The outputs can be listed as packages in <varname>environment.systemPackages</varname>. For example, the <literal>"out"</literal> and <literal>"info"</literal> outputs for the <varname>coreutils</varname> package can be installed by including <varname>coreutils</varname> and <varname>coreutils.info</varname> in <varname>environment.systemPackages</varname>.+     </para>+    </listitem>+   </itemizedlist>+  </section>++  <section xml:id="sec-multiple-outputs-installing-nix-env">+   <title>Selecting outputs to install via <command>nix-env</command></title>++   <para>+    <command>nix-env</command> lacks an easy way to select the outputs to install. When installing a package, <command>nix-env</command> always installs the outputs listed in <varname>meta.outputsToInstall</varname>, even when the user explicitly selects an output.+   </para>++   <warning>     <para>-     TODO: more about tweaking the attribute, etc.+     <command>nix-env</command> silenty disregards the outputs selected by the user, and instead installs the outputs from <varname>meta.outputsToInstall</varname>. For example,     </para>-   </listitem>-   <listitem>+<programlisting>$ nix-env -iA nixpkgs.coreutils.info</programlisting>     <para>-     NixOS provides configuration option <varname>environment.extraOutputsToInstall</varname> that allows adding extra outputs of <varname>environment.systemPackages</varname> atop the default ones. It's mainly meant for documentation and debug symbols, and it's also modified by specific options.+     installs the <literal>"out"</literal> output (<varname>coreutils.meta.outputsToInstal</varname> is <literal>[ "out" ]</literal>) instead of the requested <literal>"info"</literal>.     </para>-    <note>-     <para>-      At this moment there is no similar configurability for packages installed by <command>nix-env</command>. You can still use approach from <xref linkend="sec-modify-via-packageOverrides" /> to override <varname>meta.outputsToInstall</varname> attributes, but that's a rather inconvenient way.-     </para>-    </note>-   </listitem>-  </itemizedlist>+   </warning>++   <para>+    The only recourse to select an output with <command>nix-env</command> is to override the package's <varname>meta.outputsToInstall</varname>, using the functions described in <xref linkend="chap-overrides" />. For example, the following overlay installs the <literal>"out"</literal> and <literal>"info"</literal> outputs for the <varname>coreutils</varname> package:+   </para>++<programlisting>self: super:+{+  coreutils = super.coreutils.overrideAttrs (oldAttrs: {+    meta = oldAttrs.meta // { outputsToInstall = [ "out" "info" ]; };+  });+}

It would be nice to change this to showing how to add info instead of overriding the existing outputs. coreutils doesn't currently have a man output (which is a shame, I'd like to be able to get the GNU coreutils manpages since darwin has the FreeBSD ones), but many other packages do so we shouldn't accidentally instruct the user to throw that away.

    The only recourse to select an output with <command>nix-env</command> is to override the package's <varname>meta.outputsToInstall</varname>, using the functions described in <xref linkend="chap-overrides" />. For example, the following overlay adds the <literal>"info"</literal> output for the <varname>coreutils</varname> package:
   </para>

<programlisting>self: super:
{
  coreutils = super.coreutils.overrideAttrs (oldAttrs: {
    meta = oldAttrs.meta // { outputsToInstall = oldAttrs.meta.outputsToInstall or [ "out" ] ++ [ "info" ]; };
  });
}
dudebout

comment created time in 8 days

Pull request review commentNixOS/nixpkgs

document nix-env bug relating to multiple output installation

 in rec {           name = attrs.name or "${attrs.pname}-${attrs.version}";            # If the packager hasn't specified `outputsToInstall`, choose a default,-          # which is the name of `p.bin or p.out or p`;+          # which is the name of `p.bin or p.out or p` along with `p.man` when+          # present;           # if he has specified it, it will be overridden below in `// meta`.

Since you're editing this, can we remove the unnecessarily gendered pronoun here?

dudebout

comment created time in 8 days

Pull request review commentNixOS/nixpkgs

document nix-env bug relating to multiple output installation

   <title>Installing a split package</title>    <para>-   When installing a package via <varname>systemPackages</varname> or <command>nix-env</command> you have several options:+   When installing a package with multiple outputs, the package's <varname>meta.outputsToInstall</varname> attribute determines which outputs are actually installed. <varname>meta.outputsToInstall</varname> is a list whose <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/make-derivation.nix#L289">default installs binaries and the associated man pages</link>. The following sections describe ways to install different outputs.   </para> -  <itemizedlist>-   <listitem>-    <para>-     You can install particular outputs explicitly, as each is available in the Nix language as an attribute of the package. The <varname>outputs</varname> attribute contains a list of output names.-    </para>-   </listitem>-   <listitem>-    <para>-     You can let it use the default outputs. These are handled by <varname>meta.outputsToInstall</varname> attribute that contains a list of output names.-    </para>+  <section xml:id="sec-multiple-outputs-installing-nixos">+   <title>Selecting outputs to install via NixOS</title>++   <para>+    NixOS provides two ways to select the outputs to install for packages listed in <varname>environment.systemPackages</varname>:+   </para>++   <itemizedlist>+    <listitem>+     <para>+      The configuration option <varname>environment.extraOutputsToInstall</varname> is appended to each package's <varname>meta.outputsToInstall</varname> attribute to determine the outputs to install. It can for example be used to install for <literal>info</literal> documentation or debug symbols for all packages.+     </para>+    </listitem>+    <listitem>+     <para>+      The outputs can be listed as packages in <varname>environment.systemPackages</varname>. For example, the <literal>"out"</literal> and <literal>"info"</literal> outputs for the <varname>coreutils</varname> package can be installed by including <varname>coreutils</varname> and <varname>coreutils.info</varname> in <varname>environment.systemPackages</varname>.+     </para>+    </listitem>+   </itemizedlist>+  </section>++  <section xml:id="sec-multiple-outputs-installing-nix-env">+   <title>Selecting outputs to install via <command>nix-env</command></title>++   <para>+    <command>nix-env</command> lacks an easy way to select the outputs to install. When installing a package, <command>nix-env</command> always installs the outputs listed in <varname>meta.outputsToInstall</varname>, even when the user explicitly selects an output.+   </para>++   <warning>     <para>-     TODO: more about tweaking the attribute, etc.+     <command>nix-env</command> silenty disregards the outputs selected by the user, and instead installs the outputs from <varname>meta.outputsToInstall</varname>. For example,     </para>-   </listitem>-   <listitem>+<programlisting>$ nix-env -iA nixpkgs.coreutils.info</programlisting>     <para>-     NixOS provides configuration option <varname>environment.extraOutputsToInstall</varname> that allows adding extra outputs of <varname>environment.systemPackages</varname> atop the default ones. It's mainly meant for documentation and debug symbols, and it's also modified by specific options.+     installs the <literal>"out"</literal> output (<varname>coreutils.meta.outputsToInstal</varname> is <literal>[ "out" ]</literal>) instead of the requested <literal>"info"</literal>.
     installs the <literal>"out"</literal> output (<varname>coreutils.meta.outputsToInstall</varname> is <literal>[ "out" ]</literal>) instead of the requested <literal>"info"</literal>.
dudebout

comment created time in 8 days

Pull request review commentNixOS/nixpkgs

document nix-env bug relating to multiple output installation

   <title>Installing a split package</title>    <para>-   When installing a package via <varname>systemPackages</varname> or <command>nix-env</command> you have several options:+   When installing a package with multiple outputs, the package's <varname>meta.outputsToInstall</varname> attribute determines which outputs are actually installed. <varname>meta.outputsToInstall</varname> is a list whose <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/make-derivation.nix#L289">default installs binaries and the associated man pages</link>. The following sections describe ways to install different outputs.   </para> -  <itemizedlist>-   <listitem>-    <para>-     You can install particular outputs explicitly, as each is available in the Nix language as an attribute of the package. The <varname>outputs</varname> attribute contains a list of output names.-    </para>-   </listitem>-   <listitem>-    <para>-     You can let it use the default outputs. These are handled by <varname>meta.outputsToInstall</varname> attribute that contains a list of output names.-    </para>+  <section xml:id="sec-multiple-outputs-installing-nixos">+   <title>Selecting outputs to install via NixOS</title>++   <para>+    NixOS provides two ways to select the outputs to install for packages listed in <varname>environment.systemPackages</varname>:+   </para>++   <itemizedlist>+    <listitem>+     <para>+      The configuration option <varname>environment.extraOutputsToInstall</varname> is appended to each package's <varname>meta.outputsToInstall</varname> attribute to determine the outputs to install. It can for example be used to install for <literal>info</literal> documentation or debug symbols for all packages.
      The configuration option <varname>environment.extraOutputsToInstall</varname> is appended to each package's <varname>meta.outputsToInstall</varname> attribute to determine the outputs to install. It can for example be used to install <literal>info</literal> documentation or debug symbols for all packages.
dudebout

comment created time in 8 days

Pull request review commentNixOS/nixpkgs

document nix-env bug relating to multiple output installation

   <title>Installing a split package</title>    <para>-   When installing a package via <varname>systemPackages</varname> or <command>nix-env</command> you have several options:+   When installing a package with multiple outputs, the package's <varname>meta.outputsToInstall</varname> attribute determines which outputs are actually installed. <varname>meta.outputsToInstall</varname> is a list whose <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/make-derivation.nix#L289">default installs binaries and the associated man pages</link>. The following sections describe ways to install different outputs.   </para> -  <itemizedlist>-   <listitem>-    <para>-     You can install particular outputs explicitly, as each is available in the Nix language as an attribute of the package. The <varname>outputs</varname> attribute contains a list of output names.-    </para>-   </listitem>-   <listitem>-    <para>-     You can let it use the default outputs. These are handled by <varname>meta.outputsToInstall</varname> attribute that contains a list of output names.-    </para>+  <section xml:id="sec-multiple-outputs-installing-nixos">+   <title>Selecting outputs to install via NixOS</title>++   <para>+    NixOS provides two ways to select the outputs to install for packages listed in <varname>environment.systemPackages</varname>:+   </para>++   <itemizedlist>+    <listitem>+     <para>+      The configuration option <varname>environment.extraOutputsToInstall</varname> is appended to each package's <varname>meta.outputsToInstall</varname> attribute to determine the outputs to install. It can for example be used to install for <literal>info</literal> documentation or debug symbols for all packages.+     </para>+    </listitem>+    <listitem>+     <para>+      The outputs can be listed as packages in <varname>environment.systemPackages</varname>. For example, the <literal>"out"</literal> and <literal>"info"</literal> outputs for the <varname>coreutils</varname> package can be installed by including <varname>coreutils</varname> and <varname>coreutils.info</varname> in <varname>environment.systemPackages</varname>.

The fact that outputs are vended as attributes on the package hasn't been explained yet. That happens in the next section Using a split package. We may need to pull that first sentence from that section up to this section (not inside this list item, but in the intro paragraph, perhaps right after explaining the outputs attribute).

dudebout

comment created time in 8 days

Pull request review commentNixOS/nixpkgs

document nix-env bug relating to multiple output installation

   <title>Installing a split package</title>    <para>-   When installing a package via <varname>systemPackages</varname> or <command>nix-env</command> you have several options:+   When installing a package with multiple outputs, the package's <varname>meta.outputsToInstall</varname> attribute determines which outputs are actually installed. <varname>meta.outputsToInstall</varname> is a list whose <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/make-derivation.nix#L289">default installs binaries and the associated man pages</link>. The following sections describe ways to install different outputs.   </para> -  <itemizedlist>-   <listitem>-    <para>-     You can install particular outputs explicitly, as each is available in the Nix language as an attribute of the package. The <varname>outputs</varname> attribute contains a list of output names.

This sentence seems useful, especially since this is the introduction to split packages

dudebout

comment created time in 8 days

Pull request review commentNixOS/nixpkgs

document nix-env bug relating to multiple output installation

   <title>Installing a split package</title>    <para>-   When installing a package via <varname>systemPackages</varname> or <command>nix-env</command> you have several options:+   When installing a package with multiple outputs, the package's <varname>meta.outputsToInstall</varname> attribute determines which outputs are actually installed. <varname>meta.outputsToInstall</varname> is a list whose <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/make-derivation.nix#L289">default installs binaries and the associated man pages</link>. The following sections describe ways to install different outputs.

Linking to a particular line of the master ref risks the reference going stale. You can press y on GitHub to canonicalize the current URL, which will change it to a blob reference so the line number will always be accurate, at the cost of the linked file not necessarily reflecting what's in master anymore. We should probably canonicalize this.

Note that since this PR was submitted, the referenced line number is in fact no longer accurate. The new correspond line number is 310, though we can go ahead and select the whole range too.

   When installing a package with multiple outputs, the package's <varname>meta.outputsToInstall</varname> attribute determines which outputs are actually installed. <varname>meta.outputsToInstall</varname> is a list whose <link xlink:href="https://github.com/NixOS/nixpkgs/blob/f1680774340d5443a1409c3421ced84ac1163ba9/pkgs/stdenv/generic/make-derivation.nix#L310-L320">default installs binaries and the associated man pages</link>. The following sections describe ways to install different outputs.
dudebout

comment created time in 8 days

PR opened NixOS/nixpkgs

cocoapods-beta: 1.9.3 -> 1.10.0.beta.1
Motivation for this change

https://github.com/CocoaPods/CocoaPods/releases/tag/1.10.0.beta.1

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)
    • [ ] 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"
  • [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)
  • [X] Ensured that relevant documentation is up to date
  • [X] Fits CONTRIBUTING.md.
+68 -53

0 comment

2 changed files

pr created time in 9 days

create barnchlilyball/nixpkgs

branch : cocoapods-beta

created branch time in 9 days

PR opened NixOS/nixpkgs

jazzy: 0.13.3 -> 0.13.5
Motivation for this change

https://github.com/realm/jazzy/releases/tag/v0.13.4 https://github.com/realm/jazzy/releases/tag/v0.13.5

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)
    • [ ] 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"
  • [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)
  • [X] Ensured that relevant documentation is up to date
  • [X] Fits CONTRIBUTING.md.
+47 -47

0 comment

2 changed files

pr created time in 9 days

create barnchlilyball/nixpkgs

branch : jazzy

created branch time in 9 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha 803732503e635c355f73acc6fd4d2a7aeb902df9

Rebuild docs Use a newer Jazzy version.

view details

push time in 9 days

created taglilyball/Tomorrowland

tagv1.4.0

Lightweight Promises for Swift & Obj-C

created time in 9 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha ac7e0d306dee322808473c820e01926f5f055607

Bump version to v1.4.0

view details

Lily Ballard

commit sha e141ba9815123f28aef2fcec5bacdfb699500533

Rebuild docs

view details

push time in 9 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha 4f5ca9d4def0bebad44f40169f0b39ceee0b9b39

Remove hard line wrapping from the README

view details

push time in 9 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha 70780293d97ac7191b0b54966a75f334553d9f6a

Add Promise.makeChild() Fixes #56.

view details

push time in 9 days

issue closedlilyball/Tomorrowland

Add Promise.makeChild()

When using Promise.propagatingCancellation(on:cancelRequested:) the client should always hand a child back to its caller. Right now the best way of producing a child looks like .then(on: .immediate, { _ in }) which is ugly and not necessarily obvious. We can add a .makeChild() method which produces a child that participates in automatic cancellation propagation, and then document this convenience on Promise.propagatingCancellation(on:cancelRequested:).

closed time in 9 days

lilyball

push eventlilyball/Tomorrowland

Lily Ballard

commit sha 5a58c73f43c20db472e2dd63994836acb2f64f0a

Document that tap().requestCancel() does nothing Fixes #55.

view details

push time in 9 days

issue closedlilyball/Tomorrowland

Document that .tap().requestCancel() does nothing

The documentation for .tap() doesn't make it clear that calling .requestCancel() on the tap promise does nothing.

closed time in 9 days

lilyball

push eventlilyball/Tomorrowland

Lily Ballard

commit sha 1af474bd6763ec96f5d87f5b53a53a18f91590ba

Change cancellation propagation behavior of onCancel When it has siblings, it no longer prevents automatic cancellation propagation if all siblings request cancel. Without siblings, requesting cancellation still propagates to the parent. Fixes #57.

view details

push time in 9 days

issue closedlilyball/Tomorrowland

onCancel() handler prevents automatic cancellation propagation

The existence of an onCancel handler prevents automatic cancellation propagation from other children from cancelling the upstream parent. An onCancel handler should always act like a tap, as it's rather surprising that registering to be notified when a promise is cancelled would prevent the promise from being cancelled.

closed time in 9 days

lilyball

push eventlilyball/Tomorrowland

Lily Ballard

commit sha f880cb8d910a102f3c69ebf0dc23534856653b8d

Fix cancellation propagation of resolve(with:) and flatMap Previously it was requesting cancellation of the upstream promise immediately even if it hadn't yet sealed or had other registered callbacks. Fixes #54.

view details

push time in 9 days

issue commentlilyball/Tomorrowland

onCancel() handler prevents automatic cancellation propagation

This one is complicated because making it behave like tap means ignoring cancellation requests, except we need requestCancel() to continue working as promise.then(…).catch(…).onCancel(…) should have the same behavior as promise.always(…).

Currently, any promise that propagates cancellation also prevents its parent from being automatically cancelled if the child hasn't been cancelled. What we want for onCancel is a way to tell the parent that it should cancel if it goes out of scope and it has no children that propagate cancellation.

We could possibly do this by having the cancellation request increment the upstream promise's observer count prior to propagating the cancel. This way the upstream promise is then marked as having had observers if it hadn't already.

lilyball

comment created time in 9 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha adb4a105f6c3c420aa9b500493e84a1ecee2f862

Enhance Obj-C test helpers for expectations Add the ability to fulfill an existing expectation based on a promise, like the Swift test helpers have. Add an assertion for when a promise should not be resolved.

view details

Lily Ballard

commit sha 5a68d9c0529518e6e8b03224e08e5223cb4dc46e

Fix cancellation propagation of resolve(with:) and flatMap Previously it was requesting cancellation of the upstream promise immediately even if it hadn't yet sealed or had other registered callbacks. Fixes #54.

view details

push time in 9 days

issue closedlilyball/Tomorrowland

Resolver.resolve(with: Promise) handles cancellation incorrectly

This method is documented as propagating cancellation upwards. The current implementation means if the receiver is asked to cancel, it immediately asks the upstream promise to cancel too. What it should do is propagate cancellation like the built-in promise children do. In effect, it should convert the receiver into a child of the given promise.

closed time in 9 days

lilyball

issue openedlilyball/Tomorrowland

onCancel() handler prevents automatic cancellation propagation

The existence of an onCancel handler prevents automatic cancellation propagation from other children from cancelling the upstream parent. An onCancel handler should always act like a tap, as it's rather surprising that registering to be notified when a promise is cancelled would prevent the promise from being cancelled.

created time in 10 days

pull request commentNixOS/nixpkgs

macvim: add configuration similar to vim_configurable and neovim

I recommend using "Hide whitespace changes" as most changed lines are just indentation.

lilyball

comment created time in 10 days

create barnchlilyball/nixpkgs

branch : macvim-plugins

created branch time in 12 days

PR opened NixOS/nixpkgs

macvim: add configuration similar to vim_configurable and neovim
Motivation for this change

I wanted to stop managing my own plugins as much as possible, I'd rather have Nix just keep them up to date. It also bothered me that vim and neovim supports Nix configuration but MacVim didn't.

To that end, this PR adds configuration to MacVim similar to vim_configurable and neovim. In MacVim's case, it looks like

macvim.configure {
  customRC = ''
    # Your configuration here
  '';
  packages.myVimPackage = with pkgs.vimPlugins; {
    start = [ youcompleteme fugitive ];
    opt = [ phpCompletion elm-vim ];
  }
}

The resulting derivation just wraps the original MacVim rather than rebuilding it.

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)
    • [ ] 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"
  • [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.

I didn't update documentation on Vim in the manual because I think MacVim is a rather esoteric package for people to be using and documentation on it doesn't apply to most Nix users.

+207 -144

0 comment

1 changed file

pr created time in 12 days

issue commentjunegunn/fzf

Suggestion: Add keybinding to execute a preview command

I suppose a hacky way to accomplish this is to skip the preview and instead do something like --bind "enter:execute(cat file | awk {q} | less)", but having it switch away from fzf to show the output would be annoying.

Ignoring the fzf-live-repl link for a moment, I think it might be more useful to just focus on the use-case of wanting to be able to manually transform the preview. For example, I want to be able to do something like find . -name '*.json' | fzf --preview cat --bind 'ctrl-f:preview(jq -C <{})'. This way it would just show the file contents by default, but ctrl-f would update the preview to show the formatted version using jq.

lilyball

comment created time in 13 days

issue commentjunegunn/fzf

Suggestion: Add keybinding to execute a preview command

No, that flag changes nothing at all about the example shown in https://paweldu.dev/posts/fzf-live-repl/.

lilyball

comment created time in 13 days

issue openedlilyball/Tomorrowland

Add Promise.makeChild()

When using Promise.propagatingCancellation(on:cancelRequested:) the client should always hand a child back to its caller. Right now the best way of producing a child looks like .then(on: .immediate, { _ in }) which is ugly and not necessarily obvious. We can add a .makeChild() method which produces a child that participates in automatic cancellation propagation, and then document this convenience on Promise.propagatingCancellation(on:cancelRequested:).

created time in 14 days

issue openedlilyball/Tomorrowland

Document that .tap().requestCancel() does nothing

The documentation for .tap() doesn't make it clear that calling .requestCancel() on the tap promise does nothing.

created time in 14 days

issue closedhomebridge-plugins/homebridge-platform-wemo

Add support for Wemo Mini Smart Plug

Is your feature request related to a problem? Please describe. The Wemo Mini Smart Plug supports HomeKit natively, but its HomeKit support is really awful. It keeps breaking, where HomeKit can’t talk to it but the Wemo app can. It looks like the reason is its _hap._tcp. Bonjour service keeps vanishing.

Describe the solution you'd like Since the Wemo app generally works, and I assume that’s the approach used by this plugin, it would be great if this plugin could support the Wemo Mini Smart Plug so I could bypass its native HomeKit support.

closed time in 15 days

lilyball

issue commenthomebridge-plugins/homebridge-platform-wemo

Add support for Wemo Mini Smart Plug

Apparently the mini plug already works, it just takes several minutes before it shows up for some reason.

lilyball

comment created time in 15 days

issue commentjunegunn/fzf

Suggestion: Add keybinding to execute a preview command

Actually, looking at the original issue again, the suggested resolution doesn't address the problem. The problem isn't that I want to refresh preview, it's that I want to avoid refreshing preview on every keypress even though the preview command includes the query string. Avoiding refreshing it on every keypress does require being able to then trigger a refresh, but without the ability to suppress the auto-refresh it doesn't help.

lilyball

comment created time in 15 days

issue commentjunegunn/fzf

Suggestion: Add keybinding to execute a preview command

A benefit of being able to do something like --bind "enter:preview(…)" is being able to bind different keys to do different previews. For example, if I wanted to filter by json files, I could have the normal preview just show the file and then bind a key to pipe the file through jq and back into the preview window, in order to prettify it.

lilyball

comment created time in 15 days

push eventlilyball/.vim

Lily Ballard

commit sha a3f77c05c2c80ccd7e129f2cce002a6c35b5b65d

Update bundle/swift

view details

push time in 18 days

push eventlilyball/.vim

Lily Ballard

commit sha 8d1912f093901e532be51a1d93a4c5684c66c19f

Add .mailmap

view details

push time in 18 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha 9d80673ef4c993502e2a35c48dc3a05cc29176db

Update .mailmap

view details

push time in 18 days

issue openedhomebridge-plugins/homebridge-platform-wemo

Add support for Wemo Mini Smart Plug

Is your feature request related to a problem? Please describe. The Wemo Mini Smart Plug supports HomeKit natively, but its HomeKit support is really awful. It keeps breaking, where HomeKit can’t talk to it but the Wemo app can. It looks like the reason is its _hap._tcp. Bonjour service keeps vanishing.

Describe the solution you'd like Since the Wemo app generally works, and I assume that’s the approach used by this plugin, it would be great if this plugin could support the Wemo Mini Smart Plug so I could bypass its native HomeKit support.

created time in 19 days

issue openedlilyball/Tomorrowland

Resolver.resolve(with: Promise) handles cancellation incorrectly

This method is documented as propagating cancellation upwards. The current implementation means if the receiver is asked to cancel, it immediately asks the upstream promise to cancel too. What it should do is propagate cancellation like the built-in promise children do. In effect, it should convert the receiver into a child of the given promise.

created time in 19 days

issue commentmanosim/gitify

How do you create a clientid/secret for Enterprise?

Actually this issue affects regular GitHub too; I hadn't tried it before, but it's doing the same in-app browser window for login there, which means it's in a position to steal my GitHub username/password.

ayoung

comment created time in 19 days

issue commentmanosim/gitify

How do you create a clientid/secret for Enterprise?

Looks like it's not just overkill; Gitify is showing the OAuth login dialog itself rather than deferring to the browser. This is really concerning because it defeats the whole point of OAuth; Gitify is in a position to intercept my username and password. Using the browser would require having a callback URL that actually went back to the app, but that's certainly possible on macOS and I would sure hope it's possible on Windows and Linux too.

Or just use a Personal Access Token and bypass all of this. PATs are used the same way that OAuth tokens are.

ayoung

comment created time in 19 days

issue commentmanosim/gitify

How do you create a clientid/secret for Enterprise?

Is there a reason Gitify can't use a Personal Access Token instead? It seems overkill to create an OAuth app just for myself to get a token.

ayoung

comment created time in 19 days

issue commentNixOS/nix

macOS updates often break nix installation (updates replace path-hooks on multi-user install)

If they keep updating these files, perhaps we should file an Apple Feedback report asking them to add /etc/bashrc.d/ and /etc/zshrc.d folders whose contents get sourced by the default scripts? This way we can add configuration there that won't get overridden.

Beyond that, the only automatic solution that comes to mind would be to have nix-daemon check these files on launch and re-add the Nix block if it's missing.

amckinlay

comment created time in 19 days

Pull request review commentfastlane/fastlane

Fix empty simulator logs

 def test_results       File.read(Scan.cache[:temp_junit_report])     end +    def prelaunch_simulators+      return unless Scan.devices.to_a.size > 0 # no devices selected, no sims to launch++      # Return early unless the user wants to prelaunch simulators. Or if the user wants simulator logs+      # and the sim OS version is >= 13, then we must prelaunch simulators because Xcode's headless+      # mode launches and shutsdown the simulators before we can collect the logs.+      os_at_least_13 = Gem::Version.new(Scan.devices.first.os_version) >= Gem::Version.new('13.0')+      return unless Scan.config[:prelaunch_simulator] || (Scan.config[:include_simulator_logs] && os_at_least_13)++      FastlaneCore::Simulator.launch(Scan.devices.first)

I took a look at what FastlaneCore::Simulator.launch does and it's actually booting the GUI simulator. This is not what we want in order to collect logs. I expect it will slow down testing, and also just be annoying. Instead we want to run xcrun simctl boot <UDID> to boot it. We'll also want to check the current status prior to booting, in order to shut the simulator down again if we booted it (but keep it running if we didn't). Which is to say, we want to replicate Xcode's headless behavior.

And please do the shutdowns in a manner that will still occur even if an exception is thrown. In particular, if Jenkins interrupts fastlane due to a timeout, I don't want booted simulators left lying around.

lyndsey-ferguson

comment created time in 23 days

Pull request review commentfastlane/fastlane

Fix empty simulator logs

 def test_results       File.read(Scan.cache[:temp_junit_report])     end +    def prelaunch_simulators+      return unless Scan.devices.to_a.size > 0 # no devices selected, no sims to launch++      # Return early unless the user wants to prelaunch simulators. Or if the user wants simulator logs+      # and the sim OS version is >= 13, then we must prelaunch simulators because Xcode's headless+      # mode launches and shutsdown the simulators before we can collect the logs.+      os_at_least_13 = Gem::Version.new(Scan.devices.first.os_version) >= Gem::Version.new('13.0')

It turns out iOS version is irrelevant. I just tested on an iOS 11.4 sim and it behaved identically to the iOS 13.5 sim with respect to spawning and collecting logs. I suspect we're seeing the results of an Xcode change, and that xcrun simctl spawn used to boot the device as needed and now it doesn't. So you could try and figure out what Xcode version introduced this (perhaps Xcode 11?) but really it would be simpler just to prelaunch sims if we're collecting logs.

lyndsey-ferguson

comment created time in 23 days

Pull request review commentfastlane/fastlane

Fix empty simulator logs

 def test_results       File.read(Scan.cache[:temp_junit_report])     end +    def prelaunch_simulators+      return unless Scan.devices.to_a.size > 0 # no devices selected, no sims to launch++      # Return early unless the user wants to prelaunch simulators. Or if the user wants simulator logs+      # and the sim OS version is >= 13, then we must prelaunch simulators because Xcode's headless+      # mode launches and shutsdown the simulators before we can collect the logs.+      os_at_least_13 = Gem::Version.new(Scan.devices.first.os_version) >= Gem::Version.new('13.0')+      return unless Scan.config[:prelaunch_simulator] || (Scan.config[:include_simulator_logs] && os_at_least_13)++      FastlaneCore::Simulator.launch(Scan.devices.first)

Why is this only prelaunching the first? I know that was the old behavior, but if I'm running on multiple devices, all will need to be booted, as it collects logs from all devices.

lyndsey-ferguson

comment created time in 23 days

issue commentrust-lang/rfcs

-0.0 should format with a minus sign by default

The module-level std::fmt documentation explicitly states

The format functions provided by Rust's standard library do not have any concept of locale, and will produce the same results on all systems regardless of user configuration.

It's certainly possible that an alternative version of Rust might choose to make changes to the Display implementations for stdlib types, but that would likely be considered an incompatible change; while the stdlib does not document how the floating point primitives have chosen to implement Display, the current behavior is to produce a machine-parseable representation, and various libraries may make assumptions about the particulars of the output (e.g. that it will always match ^-?\d+(\.\d+)?).

rprichard

comment created time in 23 days

issue commentlyndsey-ferguson/fastlane-plugin-test_center

HtmlTestReport::TestSuite::remove_duplicate_testcases can throw exception in some cases

I ran a full build of the test suite with your modified plugin, no failure. I then ran a build with collate_reports: false so I could inspect the individual html files. There's a lot so I couldn't look at everything, but every test failure I looked at had associated failure details.

So this doesn't actually tell me what was failing. However, PR #251 should fix the actual crash, with the unless failure_details.nil? check.

lilyball

comment created time in 25 days

Pull request review commentlyndsey-ferguson/fastlane-plugin-test_center

issue-250 fix collate crash w/ no failure details

 def duplicate_testcases?         end          def remove_duplicate_testcases-          nonuniq_testcases = testcases-          uniq_testcases = nonuniq_testcases.uniq { |tc| tc.title }-          (nonuniq_testcases - uniq_testcases).each do |tc|+          # get a list of all the testcases in the report's testsuite+          # and order them according to their passing status+          # that way, `uniq`, which traverses the array in order, keeping the first+          # will have the passing case of a list of duplicated testcases+          ordered_nonuniq_testcases = testcases.sort_by { |tc| tc.passing? ? 0 : 1 }+          # for example, if `ordered_nonuniq_testcases` is+          # `['a(passing)', 'b(passing)', 'c(passing)', 'dup1(passing)', 'dup2(passing)', 'dup2(failing)', 'dup2(failing)' ]`+          # then `uniq_testcases` will be+          # `['a(passing)', 'b(passing)', 'c(passing)', 'dup1(passing)', 'dup2(passing)']`+          uniq_testcases = ordered_nonuniq_testcases.uniq { |tc| tc.title }+          (ordered_nonuniq_testcases - uniq_testcases).each do |tc|+            # here, we would be deleting ['dup1(failing)', 'dup2(failing)']

That's a good point about failing tests should always be after the equivalent passing. This is assuming the html report lists tests in the order they were executed, but I assume that's a safe assumption.

Also I kind of forgot the point of uniquing test cases was to then calculate what to remove, as opposed to what to keep, meaning the distinction I made about ordering between my two suggestions is meaningless.

In any case, given the reasonable assumption about test run relative ordering, uniq'ing the reversed list to grab the last run of each test seems like a reasonable approach.

lyndsey-ferguson

comment created time in 25 days

issue openedlyndsey-ferguson/fastlane-plugin-test_center

multi_scan doesn't collate results when it uses a single batch

New Issue Checklist

  • [X] Updated fastlane-plugin-test_center to the latest version
  • [X] I read the README.md
  • [X] I reviewed the example(s) for the action(s) I am using
  • [X] I have removed any sensitive data such as passwords, authentication tokens, or anything else I do not want to world to see

If you love this fastlane plugin, consider sponsoring it or asking your company to sponsor it. I would really appreciate any gesture: https://github.com/sponsors/lyndsey-ferguson. 😍

Issue Description

I'm invoking multi_scan with the following options:

try_count: 2, # retry failed tests x times
batch_count: 1, # divide tests into x batches
parallel_testrun_count: 4, # run on x simulators

However if I also pass only_testing with a single test, multi_scan doesn't behave as expected. In particular, despite the single test, it still creates 4 simulators (based on the fact that it deletes 4 when it's done), spins up a worker, runs a single batch on the worker, and then exits without attempting to collate that single batch. That leaves the output in an unexpected state; instead of test_output/TargetUITests/report-files-go-here I'm left with test_output/TargetUITests/TargetUITests-batch-1/report-files-go-here, and the collected log archive also has the batch-1-try-0- prefix.

The simple fix would be to just "collate" the single batch, moving the files upwards. Though really it would be better if multi_scan would realize it only has 1 batch to run and disable batching entirely. I'm not sure how retries interact with batching though. Also it shouldn't create more simulators than it actually needs; even if I were to do 3 batches, it shouldn't create 4 simulators.

created time in 25 days

issue openedlyndsey-ferguson/fastlane-plugin-test_center

multi_scan expects `xcresult` in output_types, but scan doesn't

New Issue Checklist

  • [X] Updated fastlane-plugin-test_center to the latest version
  • [X] I read the README.md
  • [X] I reviewed the example(s) for the action(s) I am using
  • [X] I have removed any sensitive data such as passwords, authentication tokens, or anything else I do not want to world to see

If you love this fastlane plugin, consider sponsoring it or asking your company to sponsor it. I would really appreciate any gesture: https://github.com/sponsors/lyndsey-ferguson. 😍

Issue Description

When I pass output_types: "html,junit" I don't get an xcresult bundle. When I pass output_types: "html,junit,xcresult" I do, but scan emits a warning about how xcresult isn't a known output type. It seems that scan wants me to just pass result_bundle: true to get the xcresult, but when I give that to multi_scan it prints a warning about how the "test_result" bundle will be a symlink to the xcresult, and assuming collation actually happens (e.g. assuming I actually have more than one batch or simulator) then I do in fact get a symlink.

This is on Xcode 11 of course.

Here's what I think test_center should do:

  • Don't add the symlink when I provide result_bundle: true. scan doesn't do this, why should multi_scan?
  • Given the fact that existing callers are passing xcresult as an output type and living with the warning (we're certainly doing that so I assume others are too), test_center should strip that from the output_types it passes to scan.

It's also entirely possible I'm misunderstanding something here, but in my experiments with scan, if I pass output_types: "html,junit" I don't get an xcresult bundle without result_bundle: true. Digging through the test_center code it looks like test_center is actually trying to strip result_bundle from the parameters, and if true then I don't know how it's getting an xcresult from scan, unless it's digging through the Derived Data since there seems to be an .xcresult bundle in there.

Ultimately, even after doing all this testing and looking through code, I'm still confused as to what test_center wants me to do.

created time in 25 days

issue openedlyndsey-ferguson/fastlane-plugin-test_center

multi_scan interprets skip_build differently than scan does

New Issue Checklist

  • [X] Updated fastlane-plugin-test_center to the latest version
  • [X] I read the README.md
  • [X] I reviewed the example(s) for the action(s) I am using
  • [X] I have removed any sensitive data such as passwords, authentication tokens, or anything else I do not want to world to see

If you love this fastlane plugin, consider sponsoring it or asking your company to sponsor it. I would really appreciate any gesture: https://github.com/sponsors/lyndsey-ferguson. 😍

Issue Description

By default scan will run xcodebuild build test. This means it builds twice (assuming the default configuration of CLI build as Release and test as Debug). This can be modified with skip_build, test_without_building, or build_for_testing. In particular, skip_build makes it just omit that build keyword so it just does test; it's not actually skipping the build step entirely, just the extra build.

multi_scan is interpreting skip_build in a different way. I'm not really sure precisely what it's doing, but from the code it looks like it's skipping batching of tests, and the output I get is a bit different.

Given that multi_scan already does a build_for_testing followed by a test_without_building by default, I'd have expected it to just ignore the skip_build.

created time in 25 days

more