profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/fireproofsocks/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.
Everett Griffiths fireproofsocks Fireproof Socks Earth

fireproofsocks/dto 76

Data Transfer Object (DTO) in PHP using JSON Schema

fireproofsocks/dotenvy 17

An Elixir port of the Ruby dotenv package

opengeek/tacit 10

Tacit is a high-performance REST server framework for PHP built on the Slim framework

fireproofsocks/cowrie 2

Cowrie helps you print beautiful and consistent Terminal output to the Shell of your Elixir apps using familiar functions inspired by HTML

fireproofsocks/xray 2

Offers utility functions for inspecting string binaries and code points in Elixir

fireproofsocks/jenerator 1

Generates valid seed data from JSON Schema definitions

fireproofsocks/pockets 1

Pockets is an Elixir wrapper around Erlang :ets and :dets, a disk-based term storage

fireproofsocks/tacocat 1

A playful collection of Elixir text effects including upside down and backwards

fireproofsocks/zendesk-jwt-sso 1

Implements Zendesk Single Sign-on (SSO) using JSON web tokens (JWT)

aicentaur/los_angeles_parking_citations 0

Machine learning project on LA parking citations data

startedfireproofsocks/dotenvy

started time in 7 hours

push eventexercism/problem-specifications

Erik Schierboom

commit sha daf620d47ed905409564dec5fa9610664e294bde

🤖 Update labels (#1807) * Define repo-specific labels. This commit adds a `.appends/.github/labels.yml` file, which contains the repo-specific labels. This file will automatically be combined with the Exercism-wide labels defined in https://github.com/exercism/org-wide-files/blob/main/global-files/.github/labels.yml to form the `.github/labels.yml` file. * Define the labels used in this repo. This commit adds a `.github/labels.yml` file, which contains the full list of labels that this repo can use. This file is a combination of the `.appends/.github/labels.yml` file and the Exercism-wide labels defined in https://github.com/exercism/org-wide-files/blob/main/global-files/.github/labels.yml. * Add a GitHub Actions workflow to automatically sync the repository labels. This commit adds a `.github/workflow/sync-labels.yml` file, which defines a workflow that syncs this repository's labels with the contents of the `.github/labels.yml` file. The labels are synced automatically whenever the `.github/labels.yml` file changes.

view details

push time in 11 hours

delete branch exercism/problem-specifications

delete branch : update-labels

delete time in 11 hours

PR merged exercism/problem-specifications

🤖 Update labels v3-migration 🤖

This PR adds:

  • A .github/labels.yml file containing this repository's labels
  • An .appends/.github/labels.yml file, which contains all the repository-specific labels currently used in this repo.
  • A .github/workflows/sync-labels.yml workflow to automatically synchronize this repository's labels

With this setup, the labels that can be used in this repo are all defined in a single file: the .github/labels.yml file. The sync-labels.yml workflow automatically runs whenever this file changes, and will update the repository's label to match the labels defined in the .github/labels.yml file. Note that is will remove any labels not in the .github/labels.yml file, so be careful with removing labels from the .github/labels.yml file.

The .github/labels.yml file is auto-generated by concatenating these two files:

  • The Exercism-wide labels defined in https://github.com/exercism/org-wide-files/blob/main/global-files/.github/labels.yml
  • The repo-specific labels defined in .appends/.github/labels.yml

Whenever one of these two files change, a pull request is automatically submitted to update the .github/labels.yml file. Merging that pull request will then trigger the sync-labels workflow, and the labels will be updated.

With this setup, we are able to guarantee that each repository can use both the Exercism-wide labels and any track-specific labels.

Tracking

https://github.com/exercism/v3-launch/issues/41

+361 -0

0 comment

3 changed files

ErikSchierboom

pr closed time in 11 hours

startedfireproofsocks/dotenvy

started time in 13 hours

startedfireproofsocks/dotenvy

started time in 16 hours

startedfireproofsocks/cowrie

started time in 21 hours

issue commentexercism/problem-specifications

Implement new exercise, two-fer

On a new checkout of this problem and running npm test I get the below error. I can run npm test fine on the Hello World exercise, fwiw.

❯ npm test

> @exercism/javascript@1.2.0 test /home/elijah/exercism/javascript/two-fer
> jest --no-cache ./*

sh: line 1: jest: command not found
npm ERR! Test failed.  See above for more details.
kytrinyx

comment created time in a day

startedfireproofsocks/dotenvy

started time in 3 days

startedfireproofsocks/dotenvy

started time in 3 days

pull request commentexercism/problem-specifications

Update sync documentation

I use git bash all the time, but it's important to note that those bash scripts only work in a git bash environment, which you're not always in.

I would prefer keeping both the "cross-env-if-you're-bash-like" and "always-works-on-windows" scripts.

ErikSchierboom

comment created time in 4 days

pull request commentexercism/problem-specifications

Update sync documentation

Since this targets track maintainers, I think it's less important what the OS image comes with and more important what developers will have installed.

Correct, until we centralize the documentation in one place, in which case it will become aimed at students too.

Anyway - I know Bash won't be installed on Windows by default, but what is the developer setup these days for a Windows dev?

Unless you're running things exclusively in WSL, Windows users will probably have installed Git locally too. That means they'll have Git bash, but I never used in my 10+ years of running Git on Windows.

ErikSchierboom

comment created time in 4 days

pull request commentexercism/problem-specifications

Update sync documentation

I'm fine with not further specifying OSs. It's kinda minor; I think Windows developers will recognize a .ps1 as a powershell script, and non-windows developers will ignore it because it's foreign. BSD developers are used to software (outside of ports) not working out-of-the-box

Rambly thoughts follow:

Since this targets track maintainers, I think it's less important what the OS image comes with and more important what developers will have installed. I'm not a Windows expert, though I do have one machine that runs it, and I even ran a Windows machine for a few weeks recently for work... though I just used it as a shell to reach other remote hosts I could use for development

Anyway - I know Bash won't be installed on Windows by default, but what is the developer setup these days for a Windows dev? Not all Linux distros will have git installed by default, but we expect people to have at least gotten that far if they're maintaining tracks. I thought the Cygwin/MinGW/GitBash days were mostly over since Windows Subsystem Linux 2.0 can be run as a (non-virtualized) peer to windows now. Not sure if that's what people are using, though. I've heard of some difficulties when you want to do deeper Linux networking things, since Windows can gate the Linux environment.

ErikSchierboom

comment created time in 4 days

Pull request review commentexercism/problem-specifications

Update sync documentation

 This is an example of what a re-implementation looks like:  If a track implements an exercise for which test data exists, the exercise _must_ contain a `.meta/tests.toml` file. The goal of this file is to keep track of which tests are implemented by the exercise. Tests in this file are identified by their UUID and each test has a boolean value that indicates if it is implemented by that exercise. -A `tests.toml` file for a track's `two-fer` exercise looks like this:+A `tests.toml` file for a track's `two-fer` exercise might contain:  ```toml-[canonical-tests]+[19709124-b82e-4e86-a722-9e5c5ebf3952]+description = "no name given" -# no name given-"19709124-b82e-4e86-a722-9e5c5ebf3952" = true+[3451eebd-123f-4256-b667-7b109affce32]+description = "a name given"+include = false -# a name given-"3451eebd-123f-4256-b667-7b109affce32" = true--# another name given-"653611c6-be9f-4935-ab42-978e25fe9a10" = false+[653611c6-be9f-4935-ab42-978e25fe9a10]+description = "another name given"

I like the suggestion. @ee7?

ErikSchierboom

comment created time in 4 days

pull request commentexercism/problem-specifications

Update sync documentation

Many Windows users are more familiar with bash than PowerShell.

In my experience, I've not found this to be true. Bash isn't even installed by default on Windows, so I don't think we can assume Windows users will just be able to run the Bash command.

Also: in the future, can we have a single source of truth for configlet installation instructions? If so, should that be in exercism/docs, or exercism/configlet? Then the instructions in exercism/problem-specifications can be minimal, and point elsewhere for more details.

I think having the documentation be in exercism/configlet and referring to that from the docs and prob-specs repos makes the most sense.

ErikSchierboom

comment created time in 4 days

issue openedexercism/problem-specifications

Update binary search tree documentation

In the tests for the binary-search-tree exercise, I think this assertion may be wrong as inserting a duplicate value into a BST has no effect (as checked by bstValue tshouldBeJust 4) and therefore I believe that bstLeft should be Nothing.

https://github.com/exercism/haskell/blob/23a8841dc163c0f82b9b999a16d5cf41e77c0fe3/exercises/practice/binary-search-tree/test/Tests.hs#L35

created time in 4 days

pull request commentexercism/problem-specifications

pythagorean-triplets: Fix maths notation in instructions

If we prefer superscripts to ^ then we should consider changing the other exercises that use ^. This could be done in a separate PR, if desired. ** is indeed rarer than ^ currently:

In #1655 people brought up that superscripts that aren't a number, e.g. <sup>n</sup> aren't as easy to read (the LaTeX-based rendering would likely address this), so we'd likely still have a mix of ^ and superscripts for now.

SaschaMann

comment created time in 4 days

PR opened exercism/problem-specifications

pythagorean-triplets: Fix maths notation in instructions

** is not commonly used for exponentiation. I went with ² but ^ would also be a more common choice than **. In v3, this should probably be updated to use Mathjax/KaTeX notation instead. (see https://github.com/exercism/website/issues/476)

+2 -2

0 comment

1 changed file

pr created time in 5 days

create barnchexercism/problem-specifications

branch : SaschaMann-patch-1

created branch time in 5 days

pull request commentexercism/problem-specifications

Update sync documentation

All sounds reasonable to me

ErikSchierboom

comment created time in 5 days

pull request commentexercism/problem-specifications

Update sync documentation

@hiljusti: Thanks for the review. You raise some good points about the wording, but it's a little tricky to find a great one.

Some things to consider:

  1. A user can run a bash script on Windows, and when running on Windows, the fetch-configlet script correctly downloads the Windows release of configlet.
  2. We might prefer to point Windows users towards the bash script because:
    1. The bash script is in every track repo, but the PowerShell script is only in 11 of 79 track repos. (The repos are: cpp, csharp, dart, fsharp, javascript, red, solidity, typescript, wren, z3, zig).
    2. Many Windows users are more familiar with bash than PowerShell.
    3. The bash script has been reviewed much more thoroughly than the PowerShell script.
  3. A user can theoretically run a PowerShell script on a non-Windows OS. However, the fetch-configlet.ps1 always downloads the Windows release of configlet, so we should indeed communicate "only run the .ps1 script on Windows".
  4. We currently only build configlet releases for Linux, macOS, and Windows (all x86_64 only).
  5. The fetch-configlet script does run without error on the BSDs (as long as bash is installed). It downloads the Linux binary.
  6. The Linux binary works fully on FreeBSD and NetBSD if Linux binary compatibility is enabled, as described e.g. here. However, I have not documented this fact, and we don't test it during CI. But I am willing to document it - I think it will stay working.
  7. The Linux binary is statically linked, which makes it easier to run on the BSDs that provide Linux binary compatibility.
  8. On BSDs that don't provide Linux binary compatibility (e.g. OpenBSD) a user who wants to use configlet must compile it themselves, or run a release binary in a VM.
  9. I have tested that configlet compiles and runs properly on at least FreeBSD, OpenBSD, and NetBSD.

@ErikSchierboom any thoughts on the wording here?

Also: in the future, can we have a single source of truth for configlet installation instructions? If so, should that be in exercism/docs, or exercism/configlet? Then the instructions in exercism/problem-specifications can be minimal, and point elsewhere for more details.

ErikSchierboom

comment created time in 5 days

pull request commentexercism/problem-specifications

Update sync documentation

Minor suggestions aside... lgtm

ErikSchierboom

comment created time in 7 days

Pull request review commentexercism/problem-specifications

Update sync documentation

 This is an example of what a re-implementation looks like:  If a track implements an exercise for which test data exists, the exercise _must_ contain a `.meta/tests.toml` file. The goal of this file is to keep track of which tests are implemented by the exercise. Tests in this file are identified by their UUID and each test has a boolean value that indicates if it is implemented by that exercise. -A `tests.toml` file for a track's `two-fer` exercise looks like this:+A `tests.toml` file for a track's `two-fer` exercise might contain:  ```toml-[canonical-tests]+[19709124-b82e-4e86-a722-9e5c5ebf3952]+description = "no name given" -# no name given-"19709124-b82e-4e86-a722-9e5c5ebf3952" = true+[3451eebd-123f-4256-b667-7b109affce32]+description = "a name given"+include = false -# a name given-"3451eebd-123f-4256-b667-7b109affce32" = true--# another name given-"653611c6-be9f-4935-ab42-978e25fe9a10" = false+[653611c6-be9f-4935-ab42-978e25fe9a10]+description = "another name given"

Maybe also give an example of a comment? (I think this is how they would look)

[653611c6-be9f-4935-ab42-978e25fe9a10]
description = "another name given"
comment = "comments like this will persist across syncs"
ErikSchierboom

comment created time in 7 days

Pull request review commentexercism/problem-specifications

Update sync documentation

 This is an example of what a re-implementation looks like:  If a track implements an exercise for which test data exists, the exercise _must_ contain a `.meta/tests.toml` file. The goal of this file is to keep track of which tests are implemented by the exercise. Tests in this file are identified by their UUID and each test has a boolean value that indicates if it is implemented by that exercise. -A `tests.toml` file for a track's `two-fer` exercise looks like this:+A `tests.toml` file for a track's `two-fer` exercise might contain:  ```toml-[canonical-tests]+[19709124-b82e-4e86-a722-9e5c5ebf3952]+description = "no name given" -# no name given-"19709124-b82e-4e86-a722-9e5c5ebf3952" = true+[3451eebd-123f-4256-b667-7b109affce32]+description = "a name given"+include = false -# a name given-"3451eebd-123f-4256-b667-7b109affce32" = true--# another name given-"653611c6-be9f-4935-ab42-978e25fe9a10" = false+[653611c6-be9f-4935-ab42-978e25fe9a10]+description = "another name given" ``` -In this case, the track has chosen to implement two of the three available tests.+In this case, the track has chosen to implement two of the three available tests (`include = true` is the default and is omitted).  If a track uses a _test generator_ to generate an exercise's test suite, it _must_ use the contents of the `tests.toml` file to determine which tests to include in the generated test suite.  ### Track Test Data Tooling -To make it easy to keep the `tests.toml` up to date, tracks can use the [`canonical_data_syncer` application](https://github.com/exercism/canonical-data-syncer). This application is a small, standalone binary that will compare the tests specified in the `tests.toml` files against the tests that are defined in the exercise's canonical data. It then interactively gives the maintainer the option to include or exclude test cases that are currently missing, updating the `tests.toml` file accordingly.+To make it easy to keep the `tests.toml` up to date, tracks can use the [`configlet` application](https://github.com/exercism/configlet)'s `sync` command.+A plain `configlet sync` performs no changes, and just compares the tests specified in the `tests.toml` files against the tests that are defined in the exercise's canonical data - if there are tests defined only in the latter, it prints a summary and exits with a non-zero exit code.++To interactively update the `tests.toml` files, use `configlet sync --update`.+For each missing test, this prompts the user to choose whether to include/exclude/skip it, and updates the corresponding `tests.toml` file accordingly.++To non-interactively include every missing test for an exercise `foo`, use:++```+configlet sync --exercise foo --update --mode include+```++or the short form `configlet sync -e foo -u -mi`.++The `sync` command operates on Practice Exercises that are in the track-level `config.json` file.+If you are adding an exercise that has canonical data to a track, first add that exercise to the track-level `config.json`, and then run a `configlet sync` command to create the corresponding `tests.toml` file. -To use the canonical data syncer tool, tracks should copying the [`fetch-canonical_data_syncer`](https://github.com/exercism/canonical-data-syncer/blob/main/scripts/fetch-canonical_data_syncer) and/or [`fetch-canonical_data_syncer.ps1`](https://github.com/exercism/canonical-data-syncer/blob/main/scripts/fetch-canonical_data_syncer.ps1) scripts into their repository. Then, running either of these scripts will download the latest version of the tool to the track's `bin` directory. The tool can be run using `./bin/canonical_data_syncer` or `.\bin\canonical_data_syncer.exe`, depending on your operating system.+To download the latest version of the `configlet` tool, please run the [`fetch-configlet`](https://github.com/exercism/configlet/blob/main/scripts/fetch-configlet) script or the [`fetch-configlet.ps1`](https://github.com/exercism/configlet/blob/main/scripts/fetch-configlet.ps1) script. At least one of these scripts should already exist in every track repo's `bin` directory - the script will also download `configlet` to this location. You can then sync the tests by running `./bin/configlet sync` (on Linux or macOS) or `.\bin\configlet.exe sync` (on Windows).

Maybe lead with macOS over Linux (just because of popularity) and also add an idea of "or similar" for our BSD and other platform friends. (I used to run mainly BSDs until Void Linux sucked me in)

To download the latest version of the `configlet` tool, please run the [`fetch-configlet`](https://github.com/exercism/configlet/blob/main/scripts/fetch-configlet) script (on macOS/Linux/similar) or the [`fetch-configlet.ps1`](https://github.com/exercism/configlet/blob/main/scripts/fetch-configlet.ps1) script (on Windows). At least one of these scripts should already exist in every track repo's `bin` directory - the script will also download `configlet` to this location. You can then sync the tests by running `./bin/configlet sync` (on macOS/Linux/similar) or `.\bin\configlet.exe sync` (on Windows).
ErikSchierboom

comment created time in 7 days

pull request commentexercism/problem-specifications

Update sync documentation

Thanks! Ping @exercism/reviewers

ErikSchierboom

comment created time in 7 days

pull request commentexercism/problem-specifications

Update sync documentation

I've also added some extra docs.

In the future, it would be nice if we didn't have to maintain 3 sets of configlet docs (in exercism/configlet, exercism/docs, and exercism/problem-specifications).

ErikSchierboom

comment created time in 7 days

push eventexercism/problem-specifications

ee7

commit sha d9c2c69faee231104208b6804b3f13e10ca061ac

README: reflect latest sync changes

view details

ee7

commit sha b316725ced298777ec6d1c9d08b07fbbe31d69d3

README: tweak wording around `tests.toml` Avoid saying "looks like this" because: - It could imply that every `tests.toml` for `two-fer` has an `include = false`. - We have omitted the comment that begins a `tests.toml` file.

view details

ee7

commit sha 0ae5bdc3c94a268d26c15de6055ad07502dce28b

README: add more docs for `sync`

view details

push time in 7 days

pull request commentexercism/problem-specifications

Update sync documentation

This PR should no longer be merged as-is - I'll update it to reflect the latest changes to configlet sync. A plain configlet sync is no longer interactive.

ErikSchierboom

comment created time in 8 days

push eventexercism/elixir-test-runner

Erik Schierboom

commit sha 8bcc5e26a4ee3fbb7255ada23840fb2d19eb4aff

🤖 Update labels (#40) * Define repo-specific labels. This commit adds a `.appends/.github/labels.yml` file, which contains the repo-specific labels. This file will automatically be combined with the Exercism-wide labels defined in https://github.com/exercism/org-wide-files/blob/main/global-files/.github/labels.yml to form the `.github/labels.yml` file. * Define the labels used in this repo. This commit adds a `.github/labels.yml` file, which contains the full list of labels that this repo can use. This file is a combination of the `.appends/.github/labels.yml` file and the Exercism-wide labels defined in https://github.com/exercism/org-wide-files/blob/main/global-files/.github/labels.yml. * Add a GitHub Actions workflow to automatically sync the repository labels. This commit adds a `.github/workflow/sync-labels.yml` file, which defines a workflow that syncs this repository's labels with the contents of the `.github/labels.yml` file. The labels are synced automatically whenever the `.github/labels.yml` file changes.

view details

push time in 8 days