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 51828

The Swift Programming Language

apple/swift-evolution 11154

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

apple/swift-package-manager 7754

The Package Manager for the Swift Programming Language

apple/swift-corelibs-foundation 3888

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

apple/swift-corelibs-libdispatch 1817

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

apple/swift-corelibs-xctest 822

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

apple/swift-llbuild 771

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

apple/swift-lldb 643

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

pull request commentNixOS/nixpkgs

code-server: init at 3.2.0

code-server 3.4.0 is out now.

BTW when updating to 3.4.0, the lib/vscode/build/builtInExtensions.json file is gone and the data was migrated into lib/vscode/product.json. You’ll likely need to use something like jq to modify the file as needed, if you don’t want to maintain a patch.

offlinehacker

comment created time in 12 hours

Pull request review commentNixOS/nixpkgs

code-server: init at 3.2.0

+{ stdenv, fetchFromGitHub, python, zip, makeWrapper, fetchurl, pkgconfig, git+, rsync, makeDesktopItem, runtimeShell, writeScript, runCommand+, nodejs, yarn, libsecret, xorg, ripgrep, electron }:++with stdenv.lib;++let+  system = stdenv.hostPlatform.system;++in stdenv.mkDerivation rec {+  pname = "code-server";+  version = "3.2.0";+  commit = "fd36a99a4c78669970ebc4eb05768293b657716f";++  src = fetchFromGitHub {+    owner = "cdr";+    repo = "code-server";+    rev = version;+    sha256 = "PX2WE4Wr4XUcJFw/FfKZ7PxueMXCOV/qQRGVqPThTqQ=";+    fetchSubmodules = true;+  };++  yarnCache = stdenv.mkDerivation {+    name = "${pname}-${version}-${system}-yarn-cache";+    inherit src;+    phases = ["unpackPhase" "buildPhase"];+    nativeBuildInputs = [ yarn git ];+    buildPhase = ''+      export HOME=$PWD++      # apply code-server patches as code-server has patched vscode yarn.lock+      yarn vscode:patch++      yarn config set yarn-offline-mirror $out+      find "$PWD" -name "yarn.lock" -printf "%h\n" | \+        xargs -I {} yarn install --cwd {} \+          --frozen-lockfile --ignore-scripts --ignore-platform --ignore-engines --no-progress --non-interactive+    '';+    outputHashMode = "recursive";+    outputHashAlgo = "sha256";++    # to get hash values use nix-build -A code-server.yarnPrefetchCache --argstr system <system>+    outputHash = {+      x86_64-linux = "197v9660yqhvazalyhc87ciy6q2ii8xxi5bc5y96bck2w0d2y8if";+      aarch64-linux = "LiIvGuBismWSL2yV2DuKUWDjIzuIQU/VVxtiD4xJ+6Q=";+    }.${system} or (throw "Unsupported system ${system}");+  };++  # Extract the Node.js source code which is used to compile packages with+  # native bindings+  nodeSources = runCommand "node-sources" {} ''+    tar --no-same-owner --no-same-permissions -xf ${nodejs.src}+    mv node-* $out+  '';++  nativeBuildInputs = [ nodejs yarn python pkgconfig zip makeWrapper git rsync ];

The docs on building vscode say

  • Python, at least version 2.7 (version 3 is not supported)
    • Note: Python 2.7 will be automatically installed for Windows users through installing windows-build-tools npm module (see below)

Curiously the Homebrew formula for code-server declares a dependency on python3.8. I think someone was confused though based on the above, and it probably only works because macOS still ships with python 2 (though it likely won’t in macOS 10.16).

offlinehacker

comment created time in 12 hours

Pull request review commentNixOS/nixpkgs

code-server: init at 3.2.0

+{ stdenv, fetchFromGitHub, python, zip, makeWrapper, fetchurl, pkgconfig, git+, rsync, makeDesktopItem, runtimeShell, writeScript, runCommand+, nodejs, yarn, libsecret, xorg, ripgrep, electron }:++with stdenv.lib;

Is this even being used outside of the meta attribute? It’s a lot more common to use meta = with stdenv.lib; { … } than to import it like this at the top level.

If you do need easy access to lib it’s also more common to do something like let inherit (stdenv) lib; in or just put lib in the arguments.

offlinehacker

comment created time in 12 hours

Pull request review commentNixOS/nixpkgs

code-server: init at 3.2.0

+{ stdenv, fetchFromGitHub, python, zip, makeWrapper, fetchurl, pkgconfig, git+, rsync, makeDesktopItem, runtimeShell, writeScript, runCommand+, nodejs, yarn, libsecret, xorg, ripgrep, electron }:++with stdenv.lib;++let+  system = stdenv.hostPlatform.system;++in stdenv.mkDerivation rec {+  pname = "code-server";+  version = "3.2.0";+  commit = "fd36a99a4c78669970ebc4eb05768293b657716f";++  src = fetchFromGitHub {+    owner = "cdr";+    repo = "code-server";+    rev = version;+    sha256 = "PX2WE4Wr4XUcJFw/FfKZ7PxueMXCOV/qQRGVqPThTqQ=";+    fetchSubmodules = true;+  };++  yarnCache = stdenv.mkDerivation {+    name = "${pname}-${version}-${system}-yarn-cache";+    inherit src;+    phases = ["unpackPhase" "buildPhase"];+    nativeBuildInputs = [ yarn git ];+    buildPhase = ''+      export HOME=$PWD++      # apply code-server patches as code-server has patched vscode yarn.lock+      yarn vscode:patch++      yarn config set yarn-offline-mirror $out+      find "$PWD" -name "yarn.lock" -printf "%h\n" | \+        xargs -I {} yarn install --cwd {} \+          --frozen-lockfile --ignore-scripts --ignore-platform --ignore-engines --no-progress --non-interactive+    '';+    outputHashMode = "recursive";+    outputHashAlgo = "sha256";++    # to get hash values use nix-build -A code-server.yarnPrefetchCache --argstr system <system>+    outputHash = {+      x86_64-linux = "197v9660yqhvazalyhc87ciy6q2ii8xxi5bc5y96bck2w0d2y8if";+      aarch64-linux = "LiIvGuBismWSL2yV2DuKUWDjIzuIQU/VVxtiD4xJ+6Q=";+    }.${system} or (throw "Unsupported system ${system}");+  };++  # Extract the Node.js source code which is used to compile packages with+  # native bindings+  nodeSources = runCommand "node-sources" {} ''+    tar --no-same-owner --no-same-permissions -xf ${nodejs.src}+    mv node-* $out+  '';++  nativeBuildInputs = [ nodejs yarn python pkgconfig zip makeWrapper git rsync ];+  buildInputs = [ libsecret xorg.libX11 xorg.libxkbfile ];++  patchPhase = ''+    export HOME=$PWD++    # apply code-server vscode patches+    yarn vscode:patch++    # allow offline install for vscode+    substituteInPlace lib/vscode/build/npm/postinstall.js --replace '--ignore-optional' '--offline'++    # remove all built-in extensions, as these are 3rd party extensions that gets+    # downloaded from vscode marketplace+    echo '[]' > lib/vscode/build/builtInExtensions.json++    # patch commit as autodetection does not work if we don't have .git+    sed -i '/const commit/c\const commit = "${commit}";' ci/build.ts+  '';++  configurePhase = ''+    # set offline mirror to yarn cache we created in previous steps+    yarn --offline config set yarn-offline-mirror "${yarnCache}"++    npm config set nodedir "${nodeSources}"+  '';++  buildPhase = ''+    yarn install --frozen-lockfile --offline --no-progress --non-interactive++    # install without running scripts, for all required packages that needs patching+    for d in lib/vscode lib/vscode/build; do+      yarn install --cwd $d --frozen-lockfile --offline --no-progress --non-interactive --ignore-scripts+    done++    # put ripgrep binary into bin folder, so postinstall does not try to download it+    find -name vscode-ripgrep -type d \+      -execdir mkdir -p {}/bin \; \+      -execdir ln -s ${ripgrep}/bin/rg {}/bin/rg \;++    # patch shebangs of everything, also cached files, as otherwise postinstall+    # will not be able to find /usr/bin/env, as it does not exists in sandbox+    patchShebangs .++    (+      cd lib/vscode++      # rebuild binaries, we use npm here, as yarn does not provider alternative+      npm rebuild --update-binary++      # run postinstall scripts, which eventually do yarn install on all additional requirements+      yarn postinstall --offline --frozen-lockfile+    )++    yarn build+  '';++  installPhase = ''+    mkdir -p $out/libexec/code-server $out/bin+    cp -R -T build $out/libexec/code-server++    makeWrapper "${nodejs}/bin/node" "$out/bin/code-server" \+      --add-flags "$out/libexec/code-server/out/node/entry.js"+  '';++  passthru = {+    prefetchYarnCache = overrideDerivation yarnCache (d: {+      outputHash = "0000000000000000000000000000000000000000000000000000000000000000";

BTW stdenv.lib.fakeSha256 exists with this same value, if you want to avoid embedding a long string of zeroes and maybe make it more semantically meaningful.

      outputHash = stdenv.lib.fakeSha256;
offlinehacker

comment created time in 12 hours

create barnchlilyball/nixpkgs

branch : cocoapods

created branch time in 20 hours

PR opened NixOS/nixpkgs

cocoapods: 1.9.2 -> 1.9.3
Motivation for this change

https://github.com/CocoaPods/CocoaPods/releases/tag/1.9.3 https://github.com/CocoaPods/Core/releases/tag/1.9.3

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.
+14 -14

0 comment

4 changed files

pr created time in 20 hours

startedcdr/code-server

started time in 21 hours

issue commentstkb/Rewrap

Add support for Nix

It looks like there’s a library json5 that not only supports comments but also trailing commas. It sounds like comment-json’s strength is in preserving comments so they can be serialized back out again, which doesn’t seem useful for what you’re doing.

lilyball

comment created time in 2 days

startedapple-open-source/macos

started time in 2 days

issue openedHammerspoon/hammerspoon

hs.eventtap.event.rawFlagMasks has incorrect documentation about device keys

The documentation on hs.eventtap.event.rawFlagMasks has incorrect documentation. It says the basic modifiers (alternate, command, control, shift) correspond to the left key, and it lists alternates beginning with deviceLeft that are part of a section saying these haven't been observed.

I just set up a quick tap and what I'm seeing on macOS 10.15.5 (19F96) is that the basic modifiers are present for both left and right modifiers, but left modifiers also include the deviceLeft version and right modifiers also include the deviceRight version. By that I mean if I press left shift, the flags I see present are deviceLeftShift, shift, nonCoalesced. If I press right shift I get shift, nonCoalesced, deviceRightShift. If I press both at the same time I get deviceLeftShift, shift, nonCoalesced, deviceRightShift. This holds true for the other modifiers as well.

There also exists a constant NSEventModifierFlagDeviceIndependentFlagsMask with the value 0xffff0000UL that can be used to filter out the deviceLeft* and deviceRight* flags. We should probably add that to the table too.

created time in 3 days

pull request commentNixOS/nixpkgs

wireguard-go: fix executable name

I’m using a script set up by my company that relies on wg-quick. It actually was expecting this to be installed with Homebrew but I modified it for Nix; however I don’t know enough about Wireguard to feel confident at doing anything other than modifying the path it expects wg-quick to exist at.

I’m also pushing for my team to adopt Nix for other reasons, and I think requiring nix-darwin is too high of a burden for that. Of course the rest of my team is free to still use Homebrew as well, so they could just get wireguard-tools from that; I refuse to use Homebrew for personal reasons.

Ma27

comment created time in 3 days

pull request commentNixOS/nixpkgs

wireguard-go: fix executable name

I filed this ticket because I needed wireguard-tools from Nix on macOS, which relies on wireguard-go.

Ma27

comment created time in 3 days

issue commentstkb/Rewrap

Add support for Nix

FWIW I'm surprised the parsing error wasn't logged by the release version of your extension.

lilyball

comment created time in 3 days

issue commentstkb/Rewrap

Add support for Nix

Ah hah! I'm using a modified Nix extension and my nix.language-configuration.json had a trailing comma a final array element. This isn't allowed by standard JSON but VSCode's JSON parser accepts it. So this meant the extension worked fine in VSCode except it couldn't be parsed by your extension.

I don't know why Haxe didn't work for me though, unless your extension bailed on parsing language configurations in general when it encountered the JSON error in the Nix extension.

In any case, removing that trailing comma and trying again seems to work.

lilyball

comment created time in 3 days

push eventlilyball/vscode-nix

Lily Ballard

commit sha b21d151a3cb8cd291f736a691f7cf99b70ed59f3

Remove trailing comma in language configuration JSON VSCode accepts this but it's not valid JSON so other extensions that parsed the configuration file were failing.

view details

push time in 3 days

issue commentpostmates/PMKVObserver

Swift 5.2 compiler optimization crash

The type-check in TSAO is a bit different, it's testing if the type conforms to AnyObject, whereas the Swift bug worked around in 778390212076933d66325756a3f91d26698e4e34 was about protocol types (e.g. T.Protocol). While I haven't looked at TSAO in a while, I doubt it's hitting the same issue. If it did, that would just result in unnecessary boxing. And in a quick test, what TSAO is doing works just fine in Swift 5.2.4.

which makes me think it's accessing other labels in the AssocMap and finding deallocated labels

This can't be the case as AssocMap doesn't actually store any data at all, it's a wrapper around associated types, so UILabel.map[self] is actually a wrapper around objc_getAssociatedValue(self, …).

What I'm curious about is you're reporting a crash with UILabel.text.setter, but that's an SDK method, what you've got in your code snippet is a separate property textStyle. And in particular, the crash you screenshotted is in function signature specialization <Arg[0] = Exploded> of Swift.String._bridgeToObjectiveCImpl() -> Swift.AnyObject. Which is to say, it's crashing when you assign a String to UILabel.text and it tries to bridge it to NSString. This suggests you've got some sort of damaged string object. I assume you're looking at PMKVObserver because you're observing the text property, except this crash appears to happen prior to even entering the SDK's actual -[UILabel setText:] method, much less invoking the KVO observer.

jstart

comment created time in 3 days

delete branch lilyball/nixpkgs

delete branch : bat

delete time in 4 days

create barnchlilyball/nixpkgs

branch : bat

created branch time in 4 days

PR opened NixOS/nixpkgs

bat: 0.15.3 -> 0.15.4
Motivation for this change

https://github.com/sharkdp/bat/releases/tag/v0.15.4

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.
+3 -3

0 comment

1 changed file

pr created time in 4 days

delete branch lilyball/nixpkgs

delete branch : bat

delete time in 4 days

push eventlilyball/nixpkgs

Lily Ballard

commit sha e3f1712b7a9c00ff84ba06e7e04fc27491384bef

bat: 0.15.1 -> 0.15.3

view details

push time in 5 days

create barnchlilyball/nixpkgs

branch : bat

created branch time in 5 days

PR opened NixOS/nixpkgs

bat: 0.15.1 -> 0.15.3
Motivation for this change

https://github.com/sharkdp/bat/releases/tag/v0.15.2 https://github.com/sharkdp/bat/releases/tag/v0.15.3

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.
+3 -21

0 comment

2 changed files

pr created time in 5 days

issue commentNixOS/nix

adding support for a nix.fish script along side $HOME/.nix-profile/etc/profile.d/nix.sh

I just pushed a new commit to my plugin that should make it work on multi-user installs. I don't have a (non-NixOS) multi-user install to test with though.

cartazio

comment created time in 5 days

pull request commentlilyball/nix-env.fish

Support daemon installs

I went ahead and pushed a commit that does basically what you have here but swapping the paths. I figure that's the safer approach.

Thank you for raising this issue and proposing a fix!

jdelStrother

comment created time in 5 days

push eventlilyball/nix-env.fish

Lily Ballard

commit sha dffcee7997f1d361b2744b27c8162b9dd5bdbd06

Add multi-user support We're assuming that /nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh will only exist on a multi-user install. It's possible to construct this path on a single-user install but it would be exceedingly strange to do so. This is safer than the inverse, of testing for ~/.nix-profile/etc/profile.d/nix.sh first, because in a multi-user install there's nothing stopping the user from writing `nix-env -iA nix` which will add that path to their profile. Fixes #1.

view details

push time in 5 days

PR closed lilyball/nix-env.fish

Support daemon installs

I'm still new to nix, so this may be nonsensical, but having installed nix via sh <(curl https://nixos.org/nix/install) --daemon, I don't have a ~/.nix-profile/etc/profile.d/nix.sh.

Would something like this make sense? (Or, being the daemon profile script, maybe it goes against the grain to have it in here rather than /etc/fish/config.fish ?)

+3 -0

2 comments

1 changed file

jdelStrother

pr closed time in 5 days

issue commentNixOS/nix

Unified profile script that detects single-user vs multi-user

I guess a unified script would actually work after all, because I could then just do something like

if test -e ~/.nix-profile/etc/profile.d/unified-nix.sh; then
  . ~/.nix-profile/etc/profile.d/unified-nix.sh
elif test -e /nix/var/nix/profiles/default/etc/profile.d/unified-nix.sh; then
  . /nix/var/nix/profiles/default/etc/profile.d/unified-nix.sh
fi
lilyball

comment created time in 5 days

pull request commentlilyball/nix-env.fish

Support daemon installs

That said, an issue with adding multi-user support to this plugin is ideally multi-user support would be at the system level, not a per-user plugin. I suppose installs of non-nixpkgs fish could manually install this plugin into /etc/fish/conf.d but that won't work for nixpkgs fish. For nixpkgs fish you can add your own /etc/fish/nixos-env-preinit.fish that's responsible for setting up the environment (in particular PATH and NIX_PROFILES), that will cause nixpkgs-installed fish to do all of the necessary configuration automatically, but this is really a hack just to get fish working in NixOS and isn't really suitable for use outside of that.

The default nixpkgs install of fish does source /etc/fish/config.fish (this is controlled by the useOperatingSystemEtc flag that defaults to true) so you could copy this plugin into that file for a multi-user install (sourcing /nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh instead), but this is a manual setup that can't be automated by a plugin.

Ultimately, having said all that, I guess a per-user plugin is the only reasonably portable approach to setting this up even in a multi-user install.

jdelStrother

comment created time in 5 days

issue commentlilyball/nix-env.fish

I could only manage to have the function on my path one time

I apologize for the late response, it seems I never got an email about this.

Are you using a single-user or a multi-user install? This plugin was designed for single-user as I don't have a non-NixOS multi-user install to test with. #1 is an open PR to fix this, if you're using a multi-user install.

i-am-the-slime

comment created time in 5 days

issue commentNixOS/nix

Unified profile script that detects single-user vs multi-user

I've just realized that in a multi-user scenario you don't use ~/.nix-profile/etc/profile.d/* at all, so a unified script actually doesn't help as there wouldn't be a unified path (unless it's at a constant path within the nix store itself). So perhaps just focusing on an officially-supported and documented way to test if we're in a single-user vs multi-user install would be best.

lilyball

comment created time in 5 days

pull request commentlilyball/nix-env.fish

Support daemon installs

I apologize for ignoring this PR, it looks like I never got an email about it.

What you propose looks like a reasonable patch, as long as the user never installs nix into their local user profile. If you run nix-env -iA nix then you'll likely end up with a ~/.nix-profile/etc/profile.d/nix.sh script and this plugin will then do a single-user install.

Earlier today I just filed https://github.com/NixOS/nix/issues/3630 asking for an official way to initialize a shell for both single-user and multi-user installs. In the meantime we may want to actually invert this test, looking for /nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh first as it's a lot less likely that on a single-user install someone will manually install nix into a profile named default. Or maybe we could just check "is /nix owned by root?" or something like that. I'm hoping to get a more reliable answer in the above-linked issue.

jdelStrother

comment created time in 5 days

Pull request review commentNixOS/nix

darwin sandbox

 Settings::Settings()     sandboxPaths = tokenizeString<StringSet>("/bin/sh=" SANDBOX_SHELL); #endif -    allowedImpureHostPrefixes = tokenizeString<StringSet>(DEFAULT_ALLOWED_IMPURE_PREFIXES);++/* chroot-like behavior from Apple's sandbox */+#if __APPLE__+    sandboxPaths = tokenizeString<StringSet>("/System/Library/Frameworks /System/Library/PrivateFrameworks /bin/sh /bin/bash /private/tmp /private/var/tmp /usr/lib");

I really wish there was some way to say "allow /bin/bash but only when executed by /bin/sh" 🤷‍♀️

LnL7

comment created time in 5 days

issue openedNixOS/nixpkgs

fetchgit fetches submodules sequentially instead of in parallel

Describe the bug fetchgit clones each submodule in sequence instead of in parallel, which is unnecessarily slow for repos that have a lot of submodules (such as bat which has 64 direct submodules).

At first I thought this was because git's submodule.fetchJobs setting defaults to 1, but it turns out fetchgit doesn't even use that, it instead recursively clones the submodules by hand. @nbp it looks like you added this 10 years ago; is there any reason we can't just use git submodule update --init --recursive today?

I don't know why it doesn't just use git's built-in submodule handling, doing so would make fixing this trivial. Parallelizing the manual clone loop seems a lot more complicated (especially because of the problem of mixed output).

To Reproduce Steps to reproduce the behavior:

  1. Build bat.src from scratch.

Expected behavior It should clone the repo in a reasonable amount of time.

Notify maintainers Last few changes to fetchgit/nix-prefetch-git were @Mic92 and @bhipple

Metadata

  • system: "x86_64-darwin"
  • host os: Darwin 19.4.0, macOS 10.15.4
  • multi-user?: no
  • sandbox: no
  • version: nix-env (Nix) 2.3.4
  • channels(lily): "nixpkgs-20.09pre226586.571212eb839"
  • nixpkgs: /Users/lily/.nix-defexpr/channels/nixpkgs

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: fetchgit
# a list of nixos modules affected by the problem
module:

created time in 5 days

issue commentNixOS/nix

Unified profile script that detects single-user vs multi-user

The test there was "if user isn't root OR /nix/var/nix/db isn't writable". This is the nix-daemon.sh script so it's already assuming it's multi-user. The ! -w /nix/var/nix/db test was introduced because

In NixOS containers, root doesn't have write permission to /nix/var/nix/db, so it has to use the daemon.

lilyball

comment created time in 5 days

issue commentNixOS/nix

Unified profile script that detects single-user vs multi-user

A concern I have with that is I believe /nix/var/nix/db is owned and writable by root, right? (I'm on a single-user install right now so I can't verify this on a non-NixOS system, but the install scripts suggest this is the case). So root is still supposed to source nix-daemon.sh. But in my external tooling, if it's running as root then using test -w /nix/var/nix/db would tell me it's single-user. This test may work for determining whether it's okay to manipulate the store, but using it would result in setting up the wrong env vars (e.g. the single-user install doesn't put /nix/var/nix/profiles/default into the PATH).

To be fair, I'm not expecting my tooling to be run as root, but it would be great to have a solution that works. And I don't want my tooling to run a bash interactive shell because I don't want per-user configuration to screw with it. I suppose I could source /etc/bashrc and then check if Nix has been set up, and if not then source the single-user profile script, but that still seems awkward, and it risks other system-wide configuration being weird (for example on macOS if the var TERM_PROGRAM exists then /etc/bashrc sets up a bunch of session saving/restoration stuff; that var shouldn't exist for my external tooling but it's an example of how /etc/bashrc is liable to assume that we're running from a terminal).

Looking at /nix/var/nix right now my NixOS machine has /nix/var/nix/daemon-socket and my single-user macOS install doesn't; if this exists on all multi-user installs (not just NixOS) then it's a candidate for detection. But I don't like the idea of rolling my own detection because without being officially sanctioned by Nix it runs the risk of breaking, just like how I have a script right now that checked NIX_REMOTE except that's no longer set for multi-user installs >_<

lilyball

comment created time in 5 days

issue openedNixOS/nix

Unified profile script that detects single-user vs multi-user

Is your feature request related to a problem? Please describe. A problem I have when writing tooling that wants to use Nix outside the context of a terminal is making it support both single-user and multi-user Nix installs. The problem is that a different profile script needs to be sourced for single-user vs multi-user in order to set up the environment for accessing Nix-installed stuff.

Describe the solution you'd like I'd really like a single profile script I can source that detects whether it's a single-user or a multi-user install. This could replace both existing scripts, or it could just source whichever one is correct; the latter is more appropriate if the test for single-user vs multi-user isn't sufficiently cheap.

This also requires having some official way to tell the difference between the two prior to sourcing any scripts. This mechanism should not be "check for the existence of nixbld1" or anything like that as rm -rf /nix doesn't clear that up; ideally it's some defined path in /nix that only exists for multi-user installs, preferably something stable that external tooling can use too without worrying about it changing in a later release.

Describe alternatives you've considered If Nix just provides the official "here's how you detect a multi-user install outside of a bash login shell" then I can pick the profile script to source myself, but simplifying it by having a script that does that already would be very convenient.

created time in 5 days

delete branch lilyball/nixpkgs

delete branch : cocoapods

delete time in 7 days

release lilyball/Tomorrowland

v1.3.0

released time in 8 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha fc1fb7e2ef17050c5f6ba9d538f727d8a827d3d7

Bump version to v1.3.0

view details

Lily Ballard

commit sha 2fc1168f0c63cf84720cebbf9b43f5b7b5cf640d

Rebuild docs

view details

push time in 8 days

created taglilyball/Tomorrowland

tagv1.3.0

Lightweight Promises for Swift & Obj-C

created time in 8 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha cc82f2c06fee8b261ce1b3204a6a55d21deafd73

Fix some timeout tests Recently-added timeout tests for `.nowOr` weren't testing the Error variant.

view details

Lily Ballard

commit sha 4fcfdc8c1577abf425ece4465f394be7ab8b5ec9

Fix Promise.timeout's default context for the Error overload

view details

Lily Ballard

commit sha f150ebf5419e52b7de2afbb4b4bbd6f28c62ec83

Fix Promise.timeout behavior with delay <= 0 We now skip the timer and hop on the context immediately for the timeout. If the context is `.immediate` or `.nowOr` this means the returned promise will always be resolved. Fixes #49.

view details

push time in 8 days

issue closedlilyball/Tomorrowland

timeout should skip the timer if the delay is <= 0

If the delay is zero or negative, instead of running a timer we should immediately check if the promise is resolved, and if not then time it out. This avoids an unnecessary timer and possibly operation queue work.

Implementation note: We should hop on the context, then run the timeout block there. Don't check it synchronously. The timeout block already does what we want and verifies that the promise hasn't resolved yet.

Design note: The above is different than checking result immediately and timing out if not. In particular, if we're using a context other than immediate, if the promise's upstream has resolved and the propagation is pending on that context, it may resolve the given promise prior to the timeout block firing. This matches current behavior. We should document that if the user wants to do the equivalent of if promise.result == nil { timeout() } then they can pass the .immediate context, or the nowOr(_) context (see #34).

closed time in 8 days

lilyball

issue commentlilyball/Tomorrowland

timeout should skip the timer if the delay is <= 0

It occurs to me that this will change the behavior of timeout(on: .immediate, delay: 0). With the old behavior that would timeout on the same queue as .auto, thus giving the promise a chance to resolve first, but with the new behavior it wouldn't. This is not documented behavior though.

Example:

DispatchQueue.main.async {
    let promise = Promise<Int,String>(on: .main, { (resolver) in
        resolver.fulfill(with: 42)
    }).timeout(on: .immediate, delay: 0)
    // old behavior will fulfill asynchronously on the main queue
    // new behavior will reject synchronously with a timeout error
}
lilyball

comment created time in 8 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha 3c4a20edaac3e9309ad6f7b83e0e6e071cc7e975

Add convenience methods to Obj-C for then+catch Fixes #45.

view details

push time in 8 days

issue closedlilyball/Tomorrowland

Add convenience methods to Obj-C for then+catch

The Obj-C API is a little awkward with the nested method calls thanks to Obj-C messaging style. We might want to consider adding the following methods for convenience:

- (TWLPromise *)then:(void (^)(ValueType value))thenHandler catch:(void (^)(ErrorType error))catchHandler;

- (TWLPromise *)onContext:(TWLContext *)context then:(void (^)(ValueType value))thenHandler catch:(void (^)(ErrorType error))catchHandler;
- (TWLPromise *)onContext:(TWLContext *)context token:(nullable TWLInvalidationToken *)token then:(void (^)(ValueType value))thenHandler catch:(void (^)(ErrorType error))catchHandler;

- (TWLPromise *)then:(void (^)(ValueType value))thenHandler catch:(void (^)(ErrorType error))catchHandler whenCancelled:(void (^)(void))cancelHandler;
- (TWLPromise *)onContext:(TWLContext *)context then:(void (^)(ValueType value))thenHandler catch:(void (^)(ErrorType error))catchHandler whenCancelled:(void (^)(void))cancelHandler;
- (TWLPromise *)onContext:(TWLContext *)context token:(nullable TWLInvalidationToken *)token then:(void (^)(ValueType value))thenHandler catch:(void (^)(ErrorType error))catchHandler whenCancelled:(void (^)(void))cancelHandler;

closed time in 8 days

lilyball

push eventlilyball/Tomorrowland

Lily Ballard

commit sha bb8dbb590d1a79cc4648b4fd6ea8060c779ebfb1

Add tests for .nowOr with promise chaining When a promise was resolved on PromiseContext.nowOr this shouldn't cause callbacks registered with .nowOr to execute synchronously.

view details

Lily Ballard

commit sha 27e9b2cfdd600cdad701e04780fa00b29044efc4

Generalize the helper queues from the .nowOr tests Expose the queues and queue assertions to all tests instead of limiting them just to the .nowOr tests. Use the new helpers in `DelayedPromiseTests`.

view details

Lily Ballard

commit sha 4e57ae5c7c49df968f2f3dffc3a942cba9fdea16

Tweak some tests to dispatch async instead of sync This doesn't really affect anything, but there's no reason to be using sync in these spots.

view details

Lily Ballard

commit sha a43bbeceef7f8a15eb8f2d2d2934054fc5b17b4e

Add another test for DelayedPromise with promise chaining Also add a missing test for `TWLDelayedPromise`.

view details

Lily Ballard

commit sha e857163be18e45e492d349da7754cf975f8d150f

Fix equality, hashing, and description for +[TWLContext nowOrContext:]

view details

Lily Ballard

commit sha 49ccbdb6ece8fb2e2a12d39b6da94ae01654d310

Add PromiseContext.isExecutingNow Fixes #53.

view details

Lily Ballard

commit sha be9deefd7552d78318aa78a47ca1a40a02de8d9c

Add some documentation on .nowOr to the README

view details

push time in 8 days

issue closedlilyball/Tomorrowland

Can we add something like PromiseContext.isExecutingNow?

A problem with PromiseContext.nowOr(_:) is there's no easy way to tell in the callback whether it's being executed synchronously. If we register the callback from the main thread and use .nowOr(.main) we could use a local variable that we set to false after registering the callback, but this is a little awkward and requires knowing what thread you're registering the callback from.

The thought is maybe we could use TLS to store whether the context is executing synchronously or asynchronously and then expose this value in a property like PromiseContext.isExecutingNow. All cases where a promise callback is invoked should be directly nested inside a call to context.execute so there should be no risk of returning stale info from this property, but this should be audited.

Question: In order to implement .nowOr we piped an isSynchronous flag through the seal enqueuing and context execution. Could we instead use TLS that's set when the seal runs its enqueued callbacks and query it from the context? I didn't implement it that way to begin with because I wasn't sure if there was any way to end up with stale data at the context.execute call (e.g. if there are any context.executes that aren't direct children of a seal.enqueue), but it may be safe to represent it that way.

closed time in 8 days

lilyball

create barnchlilyball/nixpkgs

branch : cocoapods

created branch time in 9 days

PR opened NixOS/nixpkgs

cocoapods: 1.9.1 -> 1.9.2
Motivation for this change

https://github.com/CocoaPods/CocoaPods/releases/tag/1.9.2

There's literally nothing in the release notes for this. From inspecting the diff it appears this release exists solely to blacklist activesupport 4.2.11.12. Let's update anyway just to avoid users wondering why we don't have the latest version.

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.
+65 -63

0 comment

4 changed files

pr created time in 9 days

issue commentstkb/Rewrap

Add support for Nix

This doesn't appear to work with Haxe either. I just installed the extension, created a new scratch buffer, set the file type to Haxe, wrote the following

// a
// b
c
d

and pressed alt-q and got

// a // b c d

If by "developer console" you mean the web inspector from "Toggle Developer Tools", there's nothing that looks relevant, just some warnings about extensions overwriting grammar file mappings for a couple of languages.

lilyball

comment created time in 9 days

issue openedlilyball/Tomorrowland

Can we add something like PromiseContext.isExecutingNow?

A problem with PromiseContext.nowOr(_:) is there's no easy way to tell in the callback whether it's being executed synchronously. If we register the callback from the main thread and use .nowOr(.main) we could use a local variable that we set to false after registering the callback, but this is a little awkward and requires knowing what thread you're registering the callback from.

The thought is maybe we could use TLS to store whether the context is executing synchronously or asynchronously and then expose this value in a property like PromiseContext.isExecutingNow. All cases where a promise callback is invoked should be directly nested inside a call to context.execute so there should be no risk of returning stale info from this property, but this should be audited.

Question: In order to implement .nowOr we piped an isSynchronous flag through the seal enqueuing and context execution. Could we instead use TLS that's set when the seal runs its enqueued callbacks and query it from the context? I didn't implement it that way to begin with because I wasn't sure if there was any way to end up with stale data at the context.execute call (e.g. if there are any context.executes that aren't direct children of a seal.enqueue), but it may be safe to represent it that way.

created time in 9 days

release lilyball/Tomorrowland

v1.2.0

released time in 9 days

created taglilyball/Tomorrowland

tagv1.2.0

Lightweight Promises for Swift & Obj-C

created time in 9 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha b2a66315c529149d6f503bdda7e72b9b7d8774af

Bump version to v1.2.0

view details

Lily Ballard

commit sha c569a3f12f0507653908ef0ca1a3b6299c5f181f

Rebuild docs

view details

push time in 9 days

issue closedlilyball/Tomorrowland

Consider adding `Promise.guard` method

We might consider adding a method like Promise.guard<U>(on context: PromiseContext, token: PromiseInvalidationToken? = nil, _ onSuccess: @escaping (Value) -> PromiseResult<U,Error>).

closed time in 9 days

lilyball

issue commentlilyball/Tomorrowland

Consider adding `Promise.guard` method

Closing this as unnecessarily complicated.

lilyball

comment created time in 9 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha 2e3be3b58b79cb6460f947c711c6edb5b2b76b1f

Allow when(fulfilled:…) to resolve synchronously if possible Fixes #52.

view details

push time in 9 days

issue closedlilyball/Tomorrowland

when(fulfilled:…) should be able to resolve synchronously

The when(fulfilled:…) family takes a QoS and does all of its work there. The downside here is it can't resolve synchronously even if all inputs have resolved. By contrast, when(first:cancelRemaining:) will resolve synchronously if any of the inputs have fulfilled/rejected.

Implementation note: One solution is to use .nowOr(_:) (see #34) on the interior work. We can then test the group to see if it's ready synchronously. We could also rewrite the enqueue loop to only hop on the context if it's rejecting/cancelling, because writing to resultBuffer can happen on any thread. Note that in this case we can still do the group.leave() outside of the context, as the resultBuffer entry will be nil and thus our processing of the buffer will safely abort.

closed time in 9 days

lilyball

push eventlilyball/Tomorrowland

Lily Ballard

commit sha abff1305651ac4b1572f2019f9cc716eafa88cc0

Tweak when(first:cancelRemaining:)'s behavior for pre-cancelled input If all input promises were already cancelled, `when(first:cancelRemaining:)` now guarantees that its returned promise will have already been cancelled too. Fixes #51.

view details

push time in 9 days

issue closedlilyball/Tomorrowland

when(first:cancelRemaining:) won't cancel synchronously if all inputs have cancelled

From reading the code it appears that when(first: [Promise(with: .cancelled)]) returns a pending promise that will be cancelled asynchronously (on the .utility queue). We should fix this so it synchronously cancels if all inputs were already cancelled. This will make it consistent because it already fulfills/rejects synchronously if any input has been fulfilled/rejected.

closed time in 9 days

lilyball

push eventlilyball/Tomorrowland

Lily Ballard

commit sha 6e97eb4987a26bc7895d915e0f4f96c4269f8577

Fix timeout .nowOr test This test wasn't actually using the `.nowOr` context.

view details

Lily Ballard

commit sha 2d5816559de95f43e15fdc94753ce238fad5b621

Fix test -testRaceCancelRemaining This test wasn't listening for all expectations, which would occasionally lead to an assertion firing after the test had finished executing.

view details

Lily Ballard

commit sha 9939ad5c6ef16f9e7568e4f51b9c5fc152ba282e

Fix indentation issue in README

view details

Lily Ballard

commit sha 178b6cf42e360d5933f079d8cbaefa0aed2d2256

Change timeout's default context to .nowOr(.auto) This change means the returned promise will already be resolved if the receiver was already resolved, otherwise it behaves the same. Fixes #50.

view details

push time in 9 days

issue closedlilyball/Tomorrowland

Consider changing timeout's default context to .nowOr(.auto)

The default context for timeout is .auto. The downside here is if the upstream promise has already resolved, the timeout promise won't immediately propagate that. If we use .nowOr(.auto) that makes the timeout promise resolve immediately if the upstream promise is already resolved but otherwise changes no behavior.

See #34 for .nowOr(.auto)

closed time in 9 days

lilyball

push eventlilyball/Tomorrowland

Lily Ballard

commit sha 70f4dd2c6af8234f898dad853db41279d747347a

Add Promise.Resolver.hasRequestedCancel This property returns whether the promise has requested cancellation or already been cancelled. If the promise is fulfilled or rejected it returns `false` even if the promise had previously requested cancellation. Fixes #47.

view details

push time in 10 days

issue closedlilyball/Tomorrowland

Add Promise.Resolver.isCancelled property

We should have a way to test a resolver to see if it's been cancelled yet. The use-case here is when I'm performing a non-cancellable async action followed up by more work, I want to be able to skip the subsequent work if I was cancelled by the time the action finishes.

closed time in 10 days

lilyball

issue openedNixOS/nixpkgs

wireguard-go: binary has wrong name, breaks wireguard-tools

Describe the bug The wireguard-go package is supposed to vend a binary called wireguard-go. Instead it's vending a binary called wireguard. The upstream repo has a Makefile that explicitly passes -o wireguard-go to go build. I don't see any equivalent in our wireguard-go package (which bypasses the Makefile).

This is a problem both because of breaking expectations, and also because the wireguard-tools package makes the assumption that wireguard-go provides a binary called wireguard-go. In particular, the wg-quick script tries to invoke the binary wireguard-go as part of the wg-quick up subcommand.

To Reproduce Steps to reproduce the behavior:

  1. Build wireguard-go
  2. See what binaries it provides

Expected behavior It should provide wireguard-go.

Notify maintainers @elseym @kirelagin @yegortimoshenko @zx2c4

Also the wireguard-tools maintainers, in case the resolution is to change wireguard-tools to use the name wireguard instead of wireguard-go: @elseym @ericsagnes @mic92 @zx2c4 @globin @ma27 @xwvvvvwx

Metadata

  • system: "x86_64-darwin"
  • host os: Darwin 19.4.0, macOS 10.15.4
  • multi-user?: no
  • sandbox: no
  • version: nix-env (Nix) 2.3.4
  • channels(lilyball): "nixpkgs-20.09pre226388.a0d7927a8c7"
  • nixpkgs: /Users/lilyball/.nix-defexpr/channels/nixpkgs

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: [wireguard-go, wireguard-tools]
# a list of nixos modules affected by the problem
module:

created time in 10 days

issue commentchrisvest/xxv

Panic when reading from fifo or named pipe

At a bare minimum, we shouldn't panic in a way that puts the terminal in a bad state. The minimal fix here is detecting that the file is a pipe and gracefully erroring.

But yes, I think a better long-term fix is to funnel the data into a temporary file and seek on that. I'd say maybe seeking on a memory buffer except then you have to deal with dumping it to disk once it gets sufficiently large, so maybe just using a temporary file always is a good idea.

lilyball

comment created time in 10 days

issue commentstkb/Rewrap

Add support for Nix

I just verified the nix.language-configuration.json file for the extension does declare comments:

{
  "comments": {
    "lineComment": "#",
    "blockComment": [ "/*", "*/" ]
  },
  "brackets": [
    ["{", "}"],
    ["[", "]"],
    ["(", ")"]
  ],
  "autoClosingPairs": [
    { "open": "{", "close": "}" },
    { "open": "[", "close": "]" },
    { "open": "(", "close": ")" },
    { "open": "\"", "close": "\"", "notIn": ["string"] },
    { "open": "''", "close": "''", "notIn": ["string"] },
  ],
  "surroundingPairs": [
    [ "(", ")" ],
    [ "[", "]" ],
    [ "{", "}" ],
    [ "<", ">" ],
    [ "\"", "\"" ]
  ]
}
lilyball

comment created time in 10 days

issue commentstkb/Rewrap

Add support for Nix

I have Rewrap 1.10.1 installed as well as the Nix plugin (bbenoist.nix), but wrapping is still not detecting comments.

lilyball

comment created time in 10 days

push eventlilyball/Tomorrowland

Lily Ballard

commit sha 70e489393fa0dfccac9a898a3af62d96d323f44e

Add PromiseContext.nowOr(context) This context will run the callback synchronously if the promise has already resolved, otherwise it will register the callback with `context`. The Obj-C version of this API is `+[TWLContext nowOrContext:]`. Fixes #34.

view details

push time in 10 days

issue closedlilyball/Tomorrowland

Add a .mainImmediate context

Occasionally I'd like to do something like "execute on the main queue, but as .immediate if that would run on the main queue". This is fairly esoteric, but I want it for scenarios like

return makeSomePromise()
    .fork({ $0.then(on: .mainImmediate, { (value) in
        self.recordValue(value)
    })})

The rationale here is if my client then attaches an .immediate listener and that ends up running on the main thread, I need my own work to have been completed first. In the then case I can work around this by using .immediate and dispatching to the main queue myself if I'm not on the main thread, but that won't work for the map case.

I'm not sold on the .mainImmediate name.

closed time in 10 days

lilyball

delete branch lilyball/nixpkgs

delete branch : ffsend

delete time in 11 days

PR opened NixOS/nixpkgs

ffsend: don't require openssl on darwin
Motivation for this change

ffsend no longer requires openssl on macOS so we should stop declaring this dependency.

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.
+3 -3

0 comment

1 changed file

pr created time in 11 days

create barnchlilyball/nixpkgs

branch : ffsend

created branch time in 11 days

pull request commentNixOS/nixpkgs

installShellFiles: Enhance installShellCompletion

Given that darwin.cctools now depends on this, which means all of stdenv does, do I need to point this at staging? FWIW darwin.cctools just uses installManPage which this PR doesn't touch.

lilyball

comment created time in 11 days

issue openedlilyball/Tomorrowland

when(fulfilled:…) should be able to resolve synchronously

The when(fulfilled:…) family takes a QoS and does all of its work there. The downside here is it can't resolve synchronously even if all inputs have resolved. By contrast, when(first:cancelRemaining:) will resolve synchronously if any of the inputs have fulfilled/rejected.

Implementation note: One solution is to use .nowOr(_:) (see #34) on the interior work. We can then test the group to see if it's ready synchronously. We could also rewrite the enqueue loop to only hop on the context if it's rejecting/cancelling, because writing to resultBuffer can happen on any thread. Note that in this case we can still do the group.leave() outside of the context, as the resultBuffer entry will be nil and thus our processing of the buffer will safely abort.

created time in 11 days

issue openedlilyball/Tomorrowland

when(first:cancelRemaining:) won't cancel synchronously if all inputs have cancelled

From reading the code it appears that when(first: [Promise(with: .cancelled)]) returns a pending promise that will be cancelled asynchronously (on the .utility queue). We should fix this so it synchronously cancels if all inputs were already cancelled. This will make it consistent because it already fulfills/rejects synchronously if any input has been fulfilled/rejected.

created time in 11 days

issue openedlilyball/Tomorrowland

Consider changing timeout's default context to .nowOr(.auto)

The default context for timeout is .auto. The downside here is if the upstream promise has already resolved, the timeout promise won't immediately propagate that. If we use .nowOr(.auto) that makes the timeout promise resolve immediately if the upstream promise is already resolved but otherwise changes no behavior.

See #34 for .nowOr(.auto)

created time in 11 days

issue openedlilyball/Tomorrowland

timeout should skip the timer if the delay is <= 0

If the delay is zero or negative, instead of running a timer we should immediately check if the promise is resolved, and if not then time it out. This avoids an unnecessary timer and possibly operation queue work.

Implementation note: We should hop on the context, then run the timeout block there. Don't check it synchronously. The timeout block already does what we want and verifies that the promise hasn't resolved yet.

Design note: The above is different than checking result immediately and timing out if not. In particular, if we're using a context other than immediate, if the promise's upstream has resolved and the propagation is pending on that context, it may resolve the given promise prior to the timeout block firing. This matches current behavior. We should document that if the user wants to do the equivalent of if promise.result == nil { timeout() } then they can pass the .immediate context, or the nowOr(_) context (see #34).

created time in 11 days

issue openedchrisvest/xxv

Panic when reading from fifo or named pipe

If I pass xxv a fifo or a named pipe (such as /dev/stdin) it promptly panics, leaving my terminal in a bad state.



Panic in xxv 0.1.2, 2020-05-20T11:03:25-07:00.
System: macos (unix), x86_64.
Location: src/hex_view.rs:397:13.

   0:        0x10628140d - backtrace::capture::Backtrace::new::ha9f89a6fa35894cc
   1:        0x10626fffb - xxv::panic_hook::install::{{closure}}::h8cc3772e827e167c
   2:        0x1062aeca4 - std::panicking::rust_panic_with_hook::he4f5d8b43533efd5
   3:        0x1062aea69 - rust_begin_unwind
   4:        0x106285e4f - core::panicking::panic_fmt::h3559129da805eab4
   5:        0x106286025 - core::result::unwrap_failed::h170de03e7ee26a1a
   6:        0x10625a28d - cursive::view::view_wrapper::<impl cursive::view::view_trait::View for T>::layout::hd14996d839b09c6c

created time in 11 days

issue commentchrisvest/xxv

Viewing data piped from stdin

I just hit this. I would love to see this supported.

chrisvest

comment created time in 11 days

issue commentlilyball/Tomorrowland

Add a .mainImmediate context

I think I'll do this as .nowOr(context) rather than tying it to main.

lilyball

comment created time in 11 days

pull request commentNixOS/nixpkgs

ffsend: 0.2.61 -> 0.2.64

We could also opt to enable a feature that restores direct usage of openssl everywhere (default now is to use ring instead), but I don't see any benefit to doing that.

filalex77

comment created time in 13 days

issue commentrealm/SwiftLint

Exit with Code 0 in Case No Files Left to Lint because of Excluded Config

I just hit this issue. It looks like an opt-in config parameter allow_zero_lintable_files was added in #2732, which solves my problem, but I'm really surprised this is opt-in.

fabb

comment created time in 13 days

pull request commentNixOS/nixpkgs

ffsend: 0.2.61 -> 0.2.64

openssl is no longer required on macOS and Windows, but is still required on Linux and FreeBSD (apparently this is because of an indirect dependency that's pulling it in). We should probably update the Nix dependencies accordingly.

filalex77

comment created time in 13 days

issue commentMic92/nixpkgs-review

GitHub token seems to be required now, with bad error message

Actually, only one of my computers has an outdated token there. The other computer has a perfectly valid token for a GitHub Enterprise installation and no token for github.com. So it looks like nixpkgs-review isn't validating the domain before it grabs the token.

lilyball

comment created time in 16 days

issue commentMic92/nixpkgs-review

GitHub token seems to be required now, with bad error message

Yes I do. I'm rather surprised that nixpkgs-review would be reading .config/hub.

lilyball

comment created time in 16 days

issue commentNixOS/nixpkgs

nixpkgs.tcltls doesn't seem to work

I just ran into this again. It's really frustrating because it means I can't use nix-shell with a shebang to invoke tclsh with the appropriate libraries. I was really hoping to be able to do that. I guess we do need a tcl build hook.

lilyball

comment created time in 16 days

issue closedeth-p/bat-extras

./build.sh prints all output to stderr except for the smfmt warning

If I run ./build.sh 2>/dev/null the only output I get is

> ./build.sh 2>/dev/null
Warning: cannot find shfmt. Unable to minify scripts.
>

This seems rather backwards; I'd have expected the warning to go to stderr and everything else to go to stdout.

closed time in 16 days

lilyball

issue commenteth-p/bat-extras

./build.sh prints all output to stderr except for the smfmt warning

Looks great. Thanks!

lilyball

comment created time in 16 days

issue commentsharkdp/bat

assets::tests::syntax_detection_invalid_utf8 failed with 0.15.1

Confirmed fixed, thank you.

lilyball

comment created time in 16 days

pull request commentNixOS/nixpkgs

installShellFiles: Enhance installShellCompletion

I wasn't sure if I should put it in the release file or not. Are you recommending that I do? Or should I just put it in installShellFiles.passthru.tests?

lilyball

comment created time in 16 days

pull request commentNixOS/nixpkgs

installShellFiles: Enhance installShellCompletion

It looks as though darwin.cctools (which is part of the darwin stdenv) has sprouted a dependency on installShellFiles at some point between this PR's creation and current master. This is why the PR suddenly requires a rebuild of the entire darwin world.

lilyball

comment created time in 17 days

issue openedMic92/nixpkgs-review

GitHub token seems to be required now, with bad error message

When I try to run nix-review now I get an HTTP 401 Unauthorized error. I'm not giving nix-review a token, and it should only be accessing public data by default, so I don't know why it's failing. The error is rather obtuse as it's just a very long stack trace but it's definitely coming from the call to the GitHub API.

created time in 18 days

issue commenteth-p/bat-extras

./build.sh prints all output to stderr except for the smfmt warning

Here I was thinking that you could move the initial printc_err "\x1B[G\x1B[K%s" "$data1" into the case, because you're printing this after each test has run, not before, so we already know what the result was and can just direct it into the appropriate bucket from the get-go. Something like

	while read -r action data1 data2 splat; do
		[[ "$action" == "result" ]] || continue

		case "$data2" in
			fail)
				printc_err "\x1B[G\x1B[K%s failed.\n" "$data1"
				((FAIL++)) || true
				;;

			skip)
				printc_msg "\x1B[G\x1B[K%s" "$data1"
				((SKIP++)) || true
				;;

			*)
				printc_msg "\x1B[G\x1B[K%s" "$data1"
				;;
		esac
	done < <("${HERE}/test.sh" --compiled --porcelain --jobs=8)
lilyball

comment created time in 18 days

pull request commentNixOS/nixpkgs

installShellFiles: Enhance installShellCompletion

I'm surprised at how much stuff indirectly depends on this. I guess cargo is using it for something, not sure what other non-leaf packages use it. I'm also wondering why ofborg slapped the more extreme labels on here when I added the test; AFAIK the addition of the test file shouldn't affect anything at all unless you explicitly build the test by name (should I be adding it to installShellFiles.passthru.tests? I'm not familiar with that).

lilyball

comment created time in 18 days

issue commentHammerspoon/hammerspoon

Using newKeyEventSequence

I'm thinking that perhaps the best approach is to keep the additional keyUp/keyDown events for each modifier, but also add in the flags containing all the modifiers to the key we're actually trying to invoke.

Ideally if we're doing shift+alt+ctrl+q we'd do {({}, "shift", true), ({"shift"}, "alt", true), ({"shift", "alt"}, "ctrl", true), ({"shift", "alt", "ctrl"}, "q", true), ({"shift", "alt", "ctrl"}, "q", false), ({"shift", "alt", "ctrl", false), ({"shift"}, "alt", false), ({}, "shift", false)} though the flags on the modifier events probably don't really matter.

Edan-Purple

comment created time in 19 days

issue commentHammerspoon/hammerspoon

Using newKeyEventSequence

I just ran into this problem when returning a table of events from an event tap, and what I eventually determined was the keyUp/keyDown events for the modifiers don't matter. What matters is the flags on the event for the character itself. newKeyEventSequence() isn't setting those flags. So using newKeyEventSequence({"shift"}, "left") didn't work at all (even if I was holding shift when I triggered this code), but constructing the events myself as {newKeyEvent({"shift"}, "left", true), newKeyEvent({"shift"}, "left", false)} worked just fine.

FWIW this was on macOS 10.15.4 (19E287)

Edan-Purple

comment created time in 19 days

issue commentsharkdp/bat

assets::tests::syntax_detection_invalid_utf8 failed with 0.15.1

Maybe the Travis OSX VMs use a file system that allows for invalid UTF-8 filenames...

It looks like HFS+ allows invalid UTF-8 by transforming the filename. The name invalid_\xFEutf8_filename.rs ends up on-disk as a file named invalid_%FEutf8_filename.rs instead. APFS doesn't do this, it just rejects the filename.

lilyball

comment created time in 19 days

issue commenteth-p/bat-extras

./build.sh prints all output to stderr except for the smfmt warning

Thanks! This is very nearly correct, except the tests are still using stderr, which looks odd when I run ./build.sh >/dev/null. I see each test name printed with no context, and then when it finishes the final test is left intact.

It looks to me as though it's printing tests on stderr because if the test fails it wants that to go to stderr. In this case it should print the test to stderr if it failed, otherwise print to stdout.

lilyball

comment created time in 19 days

more