profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/acfoltzer/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

acfoltzer/cargo-fund 63

Discover funding links for your project's dependencies.

acfoltzer/cereal-vector 5

Serialize instances for Data.Vector types

acfoltzer/bit-vector 2

Simple bit vectors for Haskell

acfoltzer/accelerate 1

Embedded language for high-performance array computations

acfoltzer/cereal-derive 1

Derive instances of Serialize

acfoltzer/CloudHaskell 1

A distributed computing framework for Haskell

PullRequestReviewEvent

push eventacfoltzer/.emacs.d

Adam C. Foltzer

commit sha 7caa51b99865aa0d40181c66754fb95afe79b6c2

disable magit-delta until it gets faster

view details

push time in 11 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventacfoltzer/http

Anthony Ramine

commit sha 5c40eca8c0bf7f739196647c29f8f394b8f007d8

Allow `{`, `"` and `}` in URI paths (#474)

view details

Sean McArthur

commit sha 97c35dd0c10ee623922e3071a68fdfb779f963d2

v0.2.4

view details

DavidKorczynski

commit sha f42f706ec5e4d8040f24af98ffe517ddc44aa834

Initial fuzzer set up. (#478)

view details

Stephen M. Coakley

commit sha fc49fe39b73427d4d95f8a7eff7968b75383293d

Add TryFrom implementations for owned types for HeaderName (#479) `HeaderValue` implements `TryFrom` over both reference and owned types, but `HeaderName` does not. This seemed like an accidental omission to me rather than something intentionally absent. Including this conversion slightly increases ergonomics by allowing you to create a `HeaderMap` from a `HashMap<String, String>` and in similar other constraints. See also https://github.com/sagebind/isahc/issues/314.

view details

Arnav Singh

commit sha 73c723edb4d16c92aef2a682cf43b00ce988a40a

Add missing TryFrom<String> and TryFrom<Vec<u8>> impls. (#477) Also fix PathAndQuery's TryFrom<String> impl to not copy the bytes into a new Bytes.

view details

walfie

commit sha 1179d6fa90fc6d680c718450b18f223cb0b25aeb

Fix typo in docs (#482)

view details

Jerome Gravel-Niquet

commit sha e54da7175a9af490a2e04003c5b49ff259222a88

HeaderValue::from_static can be const (#481) * HeaderValue::from_static can be const * bump MSRV to 1.46.0 for const loop

view details

Dave Schuyler

commit sha 58c6290bf94fd36b04e9fa781ada6f0c3a90bc22

Minor changes to var names in examples (#493) Using "res" for Response rather than "req".

view details

Ben Boeckel

commit sha d2fda209f1a6b0472039c11b52dd47f01aefc3d9

request: add Builder::version_ref to query the version in use (#495) This is needed to manually clone `Builder` instances reliably.

view details

Ben Boeckel

commit sha cc2f3ed7fc7a119f20e6cbe9a6573dbda5eb38df

extensions: add methods to detect the presence of extensions (#497) This is useful to know that a `Builder` instance cannot be duplicated faithfully since the extensions cannot be cloned into a new instance.

view details

push time in a month

pull request commentfastly/cli

Fix the rust toolchain lookup to use rustc --version and stable

D'oh, that CI problem sounds devilish. I'm afraid I don't have much experience with this sort of thing other than on Linux, but might be a bug to report to action-rs?

Regarding questions of which checks to perform, I think there are several simplifying assumptions we can make:

  1. If a user wants to use anything other than a stable toolchain that is within our version constraints, they need to use --force. So, no worries about how to compare a nightly version string against a stable semver version.
  2. Likewise if a user wants to use a non-rustup install, they should use --force. I know I raised the non-rustup question above but the more I think about it the more I don't want us to commit to being totally comprehensive about supporting all the various ways our ecosystem languages might be packaged.
  3. We should assume cargo and rustc versions are kept in lockstep, as they are by rustup. If someone wants to use a stable cargo with a rustc they compiled themselves, I think --force remains okay.

I'm quick to fall back on --force for these more complex situations because I suspect anyone wanting to do these more advanced types of workflows will probably be more comfortable using cargo commands directly, and only using the CLI at the end to fastly compute deploy. That is just my guess, though.

So to go in more detail through the points in your earlier comment https://github.com/fastly/cli/pull/371#issuecomment-899460329:

  • Lookup rustc in $PATH.

    • If there is an error: tell the user rustc is not found and they should ensure it's installed.
    • I'm presuming the remediation message should NOT suggest using rustup and leave the how to the user.

I think we should point to this page to remediate a missing rustc.

  • Execute rustc --version.

    • Compare the version output to the CLI config toolchain_constraint field.

      • Need to ensure our parsing logic accounts for x.x.x-nightly (e.g. don't just split on spaces).

Let's make sure we account for nightly so the parser doesn't crash, but we shouldn't try to do a comparison against the toolchain constraint. A nightly or beta or custom toolchain should always just fail and require --force.

  • If the constraint isn't met: tell the user their constraint isn't met and leave it to the user to choose the approach.

Yeah, this is tricky. If our new standard practice is to use stable in the rust-toolchain file of starter kits, we should probably recommend rustup update stable as a remediation.

But that won't fix it if the issue is a rust-toolchain file that specifies a more specific version. Maybe something like "Run rustup update stable, or ensure your rust-toolchain file specifies a version matching $toolchain_constraint".

  • Validate wasm32-wasi target is installed.

    • Look inside $(rustc --print sysroot)/lib/rustlib to see if there is a wasm32-wasi directory.
    • If the directory doesn't exist: tell the user they need to install the target.

NOTE: In the main branch we use rustup target list to see if the target is installed but as per discussions we don't want to rely on user having rustup installed, it means we have to use the above approach instead.

I think rustup target list --installed is the right approach here.

  • Lookup cargo in $PATH.

    • If there is an error: tell the user it's not found and they should ensure it's installed.
    • I'm presuming the remediation message should NOT suggest how to install cargo.

I think we can skip this step due to simplifying assumption 3 above.

  • Lookup Cargo.toml.

    • If there is an error: tell the user they're missing this file.

I don't think we need this step. cargo already gives a suitable message in this case:

❯ cargo build
error: could not find `Cargo.toml` in `/tmp/foo` or any parent directory
  • Validate fastly-sys crate version.

    • If fastly_sys_constraint isn't met: tell user to update the fastly crate to the latest version via Cargo.toml.
  • Validate fastly crate version.

    • If not using latest fastly crate version: suggest user update the fastly crate to the latest version via Cargo.toml.

These sound good.

Integralist

comment created time in a month

PullRequestReviewEvent

pull request commentbytecodealliance/lucet

uffd: fix eager heap init bug, add testing, update defaults to reflect production

  • add better testing coverage, checking the existing uffd test with both lazy (default, as before) and eager heap disposition, and add a test specifically for the bug fixed above.
  • update impl Default for UffdConfig to the values we use in production.

Are there commits missing here?

pchickey

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

push eventbytecodealliance/lucet

Adam C. Foltzer

commit sha e83d8c9b0d7856b6e0fcce2a59c4fc3ffad5a61c

🦀 Update to Rust 1.54.0, `userfaultfd-rs` 0.3.2 Also includes a `cargo update` to avoid locking to vulnerable and yanked crates.

view details

Adam C. Foltzer

commit sha d0efc11f3655ed10dda62776cfe6fa16a015888b

Merge pull request #668 from bytecodealliance/acf/rust-updates 🦀 Update to Rust 1.54.0, `userfaultfd-rs` 0.3.2

view details

push time in 2 months

delete branch bytecodealliance/lucet

delete branch : acf/rust-updates

delete time in 2 months

PR merged bytecodealliance/lucet

🦀 Update to Rust 1.54.0, `userfaultfd-rs` 0.3.2 gardening

Also includes a cargo update to avoid locking to vulnerable and yanked crates.

+374 -327

0 comment

5 changed files

acfoltzer

pr closed time in 2 months

pull request commentfastly/userfaultfd-rs

📼 Update to bindgen 0.59.1

Tagged and published

acfoltzer

comment created time in 2 months

created tagfastly/userfaultfd-rs

taguserfaultfd-sys-0.3.1

Rust bindings for the Linux userfaultfd functionality

created time in 2 months

delete branch fastly/userfaultfd-rs

delete branch : acf/bindgen-update

delete time in 2 months

push eventfastly/userfaultfd-rs

Adam C. Foltzer

commit sha 85330df0969ab1a02a22fbf1eefc75df1b2cb447

📼 Update to bindgen 0.59.1

view details

Adam C. Foltzer

commit sha 5e4e984c997b8d25d774180176061f26397d6ba8

Merge pull request #20 from fastly/acf/bindgen-update 📼 Update to bindgen 0.59.1

view details

push time in 2 months

PR merged fastly/userfaultfd-rs

📼 Update to bindgen 0.59.1

I'll want to do a release just of userfaultfd-sys after this.

+7 -7

0 comment

2 changed files

acfoltzer

pr closed time in 2 months

push eventbytecodealliance/lucet

Pat Hickey

commit sha 25309e680db95df05d629c8ea309f11776565404

remove wasmtime submodule, depend on latest wasmtime packages from crates.io (#660)

view details

katelyn martin

commit sha 843093a87ca9dd7e09e2c163fd45ef5e505f4c11

update witx dependencies The 0.9.1 release of witx most importantly includes WebAssembly/WASI#434, which is a bug-fix affecting transitive imports in witx documents.

view details

katelyn martin

commit sha 1cbef2f67920617fe8b4b7c97b12e7bede0ec76d

update lockfile

view details

katelyn martin

commit sha bdfe084c891cb786d59a1d99c69c2d203a0927b0

Merge pull request #661 from bytecodealliance/katie/update-witx Update witx dependencies

view details

Chris Fallin

commit sha 500a768dc823f0d36afaa576956fdacabe2e4075

Integrate VeriWasm. This commit brings in VeriWasm, a static analysis tool that independently verifies the sound heap-sandboxing and other properties of machine code generated by Cranelift as used by Lucet. It adds an option `--veriwasm` to the compiler `lucetc` so that, in concert with changes recently made to VeriWasm and Cranelift, we can verify generated code in memory, right after we generate it, and with reasonable overhead (measured at ~30% additional compile time for some simple test cases).

view details

Chris Fallin

commit sha ac2db4754c2a487b985bbd454da1385f1f917b3f

Merge pull request #658 from bytecodealliance/cfallin/veriwasm Integrate VeriWasm.

view details

Pat Hickey

commit sha 7d25f16344f93bfc2e6470fae78cde38179b684a

fix cargo audit failures (#666) cargo update -p: pin-project-lite sha2 crossbeam-epoch tokio

view details

Pat Hickey

commit sha d49c47905d1a9ebb368f7ee1ce635e21a2b00884

lucet-runtime-example: fix regression from #655 (#664) closes #663

view details

Pat Hickey

commit sha bdca6f93eab6facfcd2b3a7ac88f6654b0d36498

readme: Lucet powers Fastly Compute@Edge (#665) Terrarium was an early experiment, and is no longer supported

view details

Chris Fallin

commit sha 76bd5785e5bb442cfc1f06f4f8dc29ce314dea5c

Add fuzz target to test VeriWasm validation. (#662) This fuzz target tests the property: any Wasm module that Lucet can compile should produce an artifact that validates with VeriWasm. We are looking for both "false positive" bugs in VeriWasm, i.e. compilation results which are correct but which the validator can't handle, as well as "true positive" validator errors that result from a genuine Lucet miscompilation. If we see neither, then we have some more confidence that both (i) Lucet is less likely to have heap-soundness bugs, and (ii) VeriWasm is solid enough that one could consider requiring it to pass before using a module.

view details

Adam C. Foltzer

commit sha e83d8c9b0d7856b6e0fcce2a59c4fc3ffad5a61c

🦀 Update to Rust 1.54.0, `userfaultfd-rs` 0.3.2 Also includes a `cargo update` to avoid locking to vulnerable and yanked crates.

view details

push time in 2 months

PR opened bytecodealliance/lucet

Reviewers
🦀 Update to Rust 1.54.0, `userfaultfd-rs` 0.3.2 gardening

Also includes a cargo update to avoid locking to vulnerable and yanked crates.

+366 -352

0 comment

5 changed files

pr created time in 2 months

create barnchbytecodealliance/lucet

branch : acf/rust-updates

created branch time in 2 months

delete branch bytecodealliance/lucet

delete branch : acf/userfaultfd-0.3.2

delete time in 2 months

PR closed bytecodealliance/lucet

Reviewers
Update `userfaultfd` dependency to 0.3.2 gardening

This is to allow a newer version of bindgen to be picked up in the dependency tree.

+1 -1

1 comment

1 changed file

acfoltzer

pr closed time in 2 months

pull request commentbytecodealliance/lucet

Update `userfaultfd` dependency to 0.3.2

Cargo audit found some stuff, so I will just combine this with a Rust 1.54.0 update to get all the gardening out of the way together

acfoltzer

comment created time in 2 months

PR opened bytecodealliance/lucet

Reviewers
Update `userfaultfd` dependency to 0.3.2 gardening

This is to allow a newer version of bindgen to be picked up in the dependency tree.

+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchbytecodealliance/lucet

branch : acf/userfaultfd-0.3.2

created branch time in 2 months

created tagfastly/prometheus-utils

tagv0.5.1

created time in 2 months

delete branch fastly/prometheus-utils

delete branch : acf/0.5.1

delete time in 2 months