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

cardstack/cardstack 277

The mono-repo for the core Cardstack framework.

cardstack/merkle-tree-payment-pool 36

Merkle Tree based Payment Pool

cardstack/cardstack-token 19

Smart contracts governing Cardstack Token

broccolijs/broccoli-concat 18

Concatenate broccoli trees

cardstack/stupendous-rentals 10

A Cardstack tutorial app.

ef4/are-my-node-modules-messed-up 4

It's a question worth asking.

ef4/backbone 1

Give your JS App some Backbone with Models, Views, Collections, and Events

pull request commentemberjs/rfcs

Enable Embroider

Yes, but only addons that need to extend the build system. Most addons don't need to do that, and many addons that have custom broccoli code today only do so to achieve things that they can achieve with @embroider/macros instead, which are portable to any build system.

thoov

comment created time in 4 hours

pull request commentemberjs/rfcs

Enable Embroider

A followup toward addressing concerns raised above:

  1. For fingerprinting, the goal will be to iterate and land https://github.com/emberjs/rfcs/pull/763 with a solution that works in both classic and embroider.

  2. For addons that extend the build pipeline like ember-cli-sass, ember-css-modules, etc: the goal here is to stop needing to make ember-specific wrappers around that kind of functionality. When building with webpack, there are perfectly good webpack solutions for each of those things. The same will be true for whatever alternative bundlers people may adopt in the future.

  3. ember-intl falls partly into that same category. Partly it provides runtime API like helpers and services, which is straightforward to support under Embroider. But partly it extends the build pipeline, so the reliable way for it to do that under Embroider is to tell app authors how to plug it into their build, with directions specific to the bundlers that it actually supports. For example, it could tell people to do this for webpack:

    compatBuild(app, Webpack, {
      packagerOptions: {
        webpackConfig: {
          rules: [
    +         require('ember-intl/webpack-rule')
          ]
        }
    })
    

    This is more explicit than people are used to with addons, but that is why addons have been locked into a single inflexible build system for so long.

thoov

comment created time in 6 hours

Pull request review commentef4/ember-auto-import

Avoid EBADF on ReadStream early close in Node 12

 class Deserializer {   // keeps consuming chunks until we read null (meaning no buffered data   // available) or the state machine decides to stop   private run() {+    if (this.state.type === 'done') {+      return;+    }

Is it definitely our own this.source.read(1024) that triggers the EBADF?

If yes, presumably it's happening because the readable event can fire while the stream is already shutting down, in which case this change by itself should be sufficient to guard that case, and the other changes aren't really needed?

An alternative would be to unregister the event handlers before calling this.source.destroy().

If I'm following correctly, we can get a race such that the readable event fires after we've started destroying the stream, and then we attempt to read from it again causing EBADF?

If that is right, then I think this change is the only change that's really needed, and the others aren't.

maxfierke

comment created time in a day

PullRequestReviewEvent

push eventcardstack/cardstack

Matic Jurglic

commit sha 520f8b6e94cf21886d7ff4351350e720a6931b1f

Temporarily disable card pay in production for the pre-mainnet black out period

view details

Matic Jurglič

commit sha 16ea4aac3dcd754968ae6dc40875b08227ff1239

Merge pull request #2265 from cardstack/disable-card-pay-prod-cs-2190 Temporarily disable card pay in production for the pre-mainnet black out period

view details

Matic Jurglic

commit sha 03e18b2a812fb6f2a90943e100225a51a150a62b

v0.27.12

view details

Aierie

commit sha f5ae6deb5800195659d4ac013c188efb91c5e8f1

v0.27.13

view details

Aierie

commit sha 16bacb010b00e9ce010e155d197ea08ad8938c99

Basic image uploader (#2239) * basic upload + validation

view details

Hassan Abdel-Rahman

commit sha f320fc4fd6c7ea35e0d9a9d293a5679a63d7c503

scaling waypoint hub apps to 0

view details

Hassan Abdel-Rahman

commit sha 36234abc18a0ba62758d760554b813d2f6d1e8cc

scaling wapypoint apps back up

view details

Hassan Abdel-Rahman

commit sha 77cde4e35367d37e136306537b85fc41b2fae1ba

Add production waypoint deploy for hub-bot (#2266)

view details

Hassan Abdel-Rahman

commit sha 1b0a4cd66e64e2ebc71975f93aee620d30fd4cc6

Discord Bot Command Test Driver (#2264) * First pass at a bot command test driver * adding test helpers for mock discord API * fix lint errors * clarified assertion failure message * more efficient conatiner usage in tests * helpful comment * updated to be able to query the MockChannel for the various message items

view details

Hassan Abdel-Rahman

commit sha 2ce9fb6ff8adc6b38e2c607ad601be6c3179ee57

v0.27.14

view details

Hassan Abdel-Rahman

commit sha 757d3322caef89712003113883b211cd61ac04c8

Adding production hub config (#2270)

view details

Edward Faulkner

commit sha 4dd54e5a27a7365381ecf59ce7de4c2e66da2d0d

fix cardie deploy ref handling Attempting a fix for #2271.

view details

Edward Faulkner

commit sha beeee134ae8b8184cc4437655cf755d5045f4b99

adjust the other two manual workflows to match

view details

Edward Faulkner

commit sha 190dc0ac574c187fd85e5d8cb85f81e0631939a9

Merge pull request #2272 from cardstack/bot-fix fix cardie deploy ref handling

view details

Edward Faulkner

commit sha 3df94e135a1a94b2de35f8a0a5d4cec7e27f3923

Merge branch 'main' into docker-deploy

view details

push time in a day

push eventcardstack/cardstack

Edward Faulkner

commit sha 4dd54e5a27a7365381ecf59ce7de4c2e66da2d0d

fix cardie deploy ref handling Attempting a fix for #2271.

view details

Edward Faulkner

commit sha beeee134ae8b8184cc4437655cf755d5045f4b99

adjust the other two manual workflows to match

view details

Edward Faulkner

commit sha 190dc0ac574c187fd85e5d8cb85f81e0631939a9

Merge pull request #2272 from cardstack/bot-fix fix cardie deploy ref handling

view details

push time in a day

PR merged cardstack/cardstack

fix cardie deploy ref handling

Attempting a fix for #2271.

+8 -48

0 comment

7 changed files

ef4

pr closed time in a day

push eventcardstack/cardstack

Edward Faulkner

commit sha beeee134ae8b8184cc4437655cf755d5045f4b99

adjust the other two manual workflows to match

view details

push time in a day

PR opened cardstack/cardstack

fix cardie deploy ref handling

Attempting a fix for #2271.

+3 -18

0 comment

3 changed files

pr created time in a day

create barnchcardstack/cardstack

branch : bot-fix

created branch time in a day

issue commentcardstack/cardstack

Cardie deploy does not respect `ref` argument

It's actually more confusing that implied above. Here:

https://github.com/cardstack/cardstack/blob/2ce9fb6ff8adc6b38e2c607ad601be6c3179ee57/.github/workflows/manual-hub.yml#L21

the workflow does respect the user's chosen ref to checkout the code. But at that point the workflow is already running the code from the default branch. So you get a mix of both. My guess is that you get the workflow files from the default branch, but the custom actions from the user's given branch.

ef4

comment created time in a day

issue openedcardstack/cardstack

Cardie deploy does not respect `ref` argument

The ref argument to the !deploy command doesn't have any effect.

There are two different places where changes are probably needed to fix this. The first is here:

https://github.com/cardstack/cardstack/blob/2ce9fb6ff8adc6b38e2c607ad601be6c3179ee57/packages/cardie/commands/deploy.ts#L62-L67

The ref argument here governs which version of the code will actually run within the workflow. It is always running the default branch, not the user's chosen ref.

The inputs.ref argument here does respect what the user asked for, but it gets passed ultimately into the deploy hub action here:

https://github.com/cardstack/cardstack/blob/2ce9fb6ff8adc6b38e2c607ad601be6c3179ee57/.github/actions/deploy-hub/action.yml#L5

which is never used. Instead of using it here, it would be better to remove this unused argument and not try to allowed the deployed version to diverse from the version running within the workflow.

created time in a day

issue commentorbitjs/orbit

LocalStorageSource doesn't run any serializers

It looks like even the built-in serializers for fields like date do not run when writing to LocalStorage.

ef4

comment created time in 2 days

issue commentef4/ember-auto-import

Occasional EBADF during Analyzer runs on 2.2.3

There is concurrency, so setting the environment variable JOBS=1 might make the crash happen more reliably, or make it disappear.

I'm surprised Node lets us cause an EBADF since as far as I can tell we're only using public API of a ReadStream provided by fs.

If you can find any way to share a reliable reproduction of the crash that would help immensely, otherwise this is going to be hard to find.

maxfierke

comment created time in 2 days

create barnchcardstack/cardstack

branch : docker-deploy

created branch time in 2 days

PR opened embroider-build/embroider

template compilation improvements

First, I'm refactoring so that we standardize all template compilation as inline template compilation, within Javascript, because that is the more fully-featured case. Specifically, a standalone HBS file can go through a trivial transformation to make it into a Javascript file:

<Hello />
import { hbs } from 'ember-cli-htmlbars';
export default hbs("<Hello />");

After which point we can share all the same standard machinery for compiling forward from there.

Second, I'm going to take advantage of template lexical scope in non-string mode which we just successfully landed in ember-source 3.28.4. That will significantly streamline the build output when using staticComponents, etc, because we can pass the statically-resolved things directly into the template and completely sidestep the runtime resolver.

The first commit here is just testing out the basic idea, it needs further cleanup refactoring.

+26 -46

0 comment

5 changed files

pr created time in 4 days

create barnchembroider-build/embroider

branch : template-compilation

created branch time in 4 days

push eventembroider-build/embroider

Edward Faulkner

commit sha 51abbb4ebc0ae1e6ff311de9a5715d6f013feb85

more logging for frequently-failing setup step in ci

view details

push time in 4 days

push eventembroider-build/embroider

Edward Faulkner

commit sha edfe9a00844a93fa6fbabd6c61acb10a1bf3658a

Apply compileStyles to custom treeForAddonStyles It looks to me as if this was always supposed to be present. I noticed because an addon with a customized treeForAddonStyles broke under embroider on ember-cli 3.18+, because its customized output was not getting wrapped in the __COMPILED_STYES__ directory as expected.

view details

Edward Faulkner

commit sha aaaa2e5fafd0b4a441a6b0fb850727a5236e4fb2

Merge pull request #1009 from embroider-build/compile-styles-fix Apply compileStyles to custom treeForAddonStyles

view details

push time in 4 days

delete branch embroider-build/embroider

delete branch : compile-styles-fix

delete time in 4 days

PR merged embroider-build/embroider

Apply compileStyles to custom treeForAddonStyles

It looks to me as if this was always supposed to be present. I noticed because an addon with a customized treeForAddonStyles broke under embroider on ember-cli 3.18+, because its customized output was not getting wrapped in the COMPILED_STYES directory as expected.

+4 -1

0 comment

1 changed file

ef4

pr closed time in 4 days

PR opened embroider-build/embroider

Apply compileStyles to custom treeForAddonStyles

It looks to me as if this was always supposed to be present. I noticed because an addon with a customized treeForAddonStyles broke under embroider on ember-cli 3.18+, because its customized output was not getting wrapped in the COMPILED_STYES directory as expected.

+4 -1

0 comment

1 changed file

pr created time in 4 days

Pull request review commentcardstack/cardstack

Basic image uploader

+import Component from '@glimmer/component';+import { action } from '@ember/object';+import { tracked } from '@glimmer/tracking';+import { getBase64String } from '@cardstack/web-client/utils/image';+import * as Sentry from '@sentry/browser';++export interface ImageUploadSuccessResult {+  file: File;+  preview: string;+}++interface ImageUploaderArguments {+  onUpload(image: ImageUploadSuccessResult): unknown;+  onError?(e: Error): unknown;+  onRemoveImage(): unknown;+}++export default class ImageUploaderComponent extends Component<ImageUploaderArguments> {+  @tracked image: string | undefined;+  uploader!: HTMLInputElement;++  @action setUploader(element: HTMLInputElement) {+    this.uploader = element;

(It is unfortunately a little confusing that the ember-modifier addon doesn't ship in the default blueprint. IMO it should, and probably will eventually.)

Aierie

comment created time in 5 days

PullRequestReviewEvent

Pull request review commentcardstack/cardstack

Basic image uploader

+import Component from '@glimmer/component';+import { action } from '@ember/object';+import { tracked } from '@glimmer/tracking';+import { getBase64String } from '@cardstack/web-client/utils/image';+import * as Sentry from '@sentry/browser';++export interface ImageUploadSuccessResult {+  file: File;+  preview: string;+}++interface ImageUploaderArguments {+  onUpload(image: ImageUploadSuccessResult): unknown;+  onError?(e: Error): unknown;+  onRemoveImage(): unknown;+}++export default class ImageUploaderComponent extends Component<ImageUploaderArguments> {+  @tracked image: string | undefined;+  uploader!: HTMLInputElement;++  @action setUploader(element: HTMLInputElement) {+    this.uploader = element;

This pattern is a hint that you could implement a modifier instead of a component to do this more easily.

See https://github.com/ember-modifier/ember-modifier

The did-insert modifier and friends are really more of a stepping stone to help people port classic Ember components to Glimmer components. Writing your own modifier is more expressive. They're especially good for integrating third-party DOM-manipulation libraries.

Aierie

comment created time in 5 days

PullRequestReviewEvent

pull request commentemberjs/ember.js

Don't pass falsy `locals` to glimmer precompile

This and https://github.com/glimmerjs/glimmer-vm/pull/1354 should probably get released together as 3.28.3.

ef4

comment created time in 6 days

PR opened emberjs/ember.js

Don't pass falsy `locals` to glimmer precompile

Fixes #19797.

+9 -0

0 comment

1 changed file

pr created time in 6 days

create barnchemberjs/ember.js

branch : guard-null-locals

created branch time in 6 days

PR opened glimmerjs/glimmer-vm

Followup for loose-mode lexical scope

#1351 was incomplete, and the test suite didn't make that clear because it doesn't exercise real template precompilation.

This time I've manually tested end-to-end in a real app (alongside ember canary).

+2 -4

0 comment

1 changed file

pr created time in 6 days