Separate Formik State and API Surface

Replaces #2828
Creates a @formik/core package which contains the central Formik API useFormikCore, then creates a new Ref-loving version of Formik which uses that API. Isolating the Core API will allow us to experiment with switching between useContextSelector, useMutableSource, refs, etc. It will also let us unit test the individual bits of Formik instead of using integration tests as unit tests.
Up next:

Move tests to @formik/core using the new selectors.

The new Core API @formik/core
The new Formik Core API is being used in the background by all Formik wrappers. This Formik Core API is meant to be separate from the actual React bindings (though it still has a dependency on React, for now), and be interchangeable between different implementations (useMutableSource, useContextSelector, etc). It takes four parameters, getState, dispatch, formikProps and isMounted, and from only those four parameters, it generates the following API surface.
return {
  handleBlur,
  handleChange,
  handleReset,
  handleSubmit,
  resetForm,
  setErrors,
  setFormikState,
  setFieldTouched,
  setFieldValue,
  setFieldError,
  setStatus,
  setSubmitting,
  setTouched,
  setValues,
  submitForm,
  validateFormWithLowPriority,
  validateFormWithHighPriority,
  validateField,
  unregisterField,
  registerField,
  getFieldProps,
  getFieldMeta,
  getFieldHelpers,
};

Anywhere the API needs to get a value from Formik's state, it calls getState, and anytime it needs to dispatch an update, it calls dispatch. This is a redux-like inversion of control.
The new implementation framework
Any implementation of the Formik API will expose the FormikCore API as well as the following helpers:
return {
  ...formikCoreApi,
  getState,
  validateForm, // generally, formikCoreApi.validateFormWithHighPriority
  // dispatch, // not sure if we should expose ??
  // addFormEffect, // this is specific to this refs implementation
}

I've added a new Formik implementation, @formik/reducer-refs which uses a redux-like state machine to dispatch changes to its internal state (via dispatch) to React's UI state (via useState). As of right now, that implementation isn't complete, BUT! it provides a great example of how I will modify the original formik to use the new @formik/core API. Basically, Formik would just pass getState() as a callback () => state from useReducer, and the dispatch as is.
The implementation now exposes a stable useFormikApi which doesn't trigger UI updates (or it won't, when I'm done!), and useFormikContext decorates that API with state which will trigger UI updates. I hope eventually to deprecate useFormikContext in favor of const [state, api] = useFormikState(); because it is more React-like.

But how does the new Reduxy API work?!

Great question! As described #2846 , the new reduxy API works like this:
Form effects
const useFormikContext = () => {
  const formikApi = useFormikApi<Values>();
  const [formikState, setFormikState] = React.useState(formikApi.getState());

  React.useEffect(() => {
    // every time the reducer is updated and committed, the next useEffect will pass that state to each listener
    return formikApi.addFormEffect(setFormikState);
  }, []);

  return {
    ...formikApi,
    ...formikState,
  };
};

Field effects
const useField = <Val>(props: FieldHookConfig<Val>) => {
  const formik = useFormikApi();
  const fieldMetaRef = React.useRef(getFieldMeta<Val>(fieldName));
  const [fieldMeta, setFieldMeta] = React.useState(fieldMetaRef.current);

  const maybeUpdateFieldMeta = React.useCallback<FormEffect<Values>>((formikState) => {
    const fieldMeta = selectGetFieldMeta(() => formikState /* hint: getState */)(name);

    if (!isEqual(fieldMeta , fieldMetaRef.current)) {
      fieldMetaRef.current = meta;
      setFieldMeta(meta);
    }
  }, [name, /* never update >> */ setFieldMeta, fieldMetaRef]);

  React.useEffect(() => {
    // every time the reducer is updated and committed, the next useEffect will pass that state to us
    // and we'll slice it and update our field values
    return formik.addFormEffect(maybeUpdateFieldMeta);
  }, [maybeUpdateFieldMeta]);

  return [formik.getFieldProps(props), fieldMeta, formik.getFieldHelpers(props)];
}

The useField implementation is one example of how we can optimize things and also let users optimize things their own queries to Formik's parameters. For example, if a user only needs to re-render if isValid changes, they can do this. Consequently, this would be the exact definition of useIsValid from the new useContextSelector-based API.
const [isValid, setIsValid] = useState(formikApi.getState().isValid);
const updateIsValid = React.useCallback((formikState) => setIsValid(formikState.isValid),  []);

React.useEffect(() => {
  return addFormEffect(updateIsValid);
}, [addFormEffect, updateIsValid]);

We will also provide the full set of hooks added by v3 in the useContextSelector changes, which will use this method.

Updated the description to include a heck of a lot of details on how the Core API will work, and how my experimental refs implementation will work.
@jaredpalmer

I just optimized a few things and now the performance is close to v3. @jaredpalmer how did you get timing metrics for testing performance?
In my last set of changes, I rewired the /app so that it compiles the Formik packages while running, and breakpoints etc are accessible via a vs code Chrome launch task. No more yarn link. I didn't touch the tsdx build process.
To try it out, pull this PR, run npm start and navigate to localhost:3000. Or run the vscode "launch chrome" profile and set some breakpoints to test.
I added 2 pages, one that tests 500 inputs using v3 and one that tests 500 inputs using @formik/reducer-refs. I couldn't tell which was faster by feeling alone.

Switched /app to integrate with Lerna Workspace.
Set up unit test environment for vscode.
Set up dev environment for vscode.
Wrote example unit test for @formik/core.

The current issue with is a TypeScript inference issue. It seems like for some reason there are two @types/react and that one is used for inference but isn't locally installed, resulting in the error:
semantic error TS2742: The inferred type of 'Form' cannot be named without a reference to 'hoist-non-react-statics/node_modules/@types/react'. This is likely not portable. A type annotation is necessary.

Seems like https://github.com/microsoft/TypeScript/issues/29808

Resolved typescript issue with resolutions in package.json.

Simplified useFormikStateSlice per https://github.com/formium/formik/issues/2433#issuecomment-759844122
And fixed all the Jest Tests. Now just need to fix the cypress tests.

Simplified useFormikStateSlice per https://github.com/formium/formik/issues/2433#issuecomment-759844122
And fixed all the Jest Tests. Now just need to fix the cypress tests.

OMG a fully working build! 🥇

OMG a fully working build! 🥇

Here's a comparison of the underlying features of each implementation:
| Implementation | Render-optimized | Access to "future" state | Batching | Versioning | Notes |
| v2 | ❌| ❌| ✅ | ✅ | Use of Context provides automatic batching and versioning, preventing tearing. |
| useContextSelector | ✅ | ❌| ✅ | ✅ | useContextSelector uses both unstable_runWithPriority and unstable_batchedUpdates to achieve batching. getState() is render dependent and cannot be used to get future state until the next render is committed |
| reducer-refs | ✅ | ✅| ❌ | ❌ | getState() provides ref access to the underlying current state, but does not currently use batching or versioning. May risk tearing and extra renders without further optimization |

Here's a comparison of the underlying features of each implementation:
| Implementation | Render-optimized | Access to "future" state | Batching | Versioning | Notes |
| v2 | ❌| ❌| ✅ | ✅ | Use of Context provides automatic batching and versioning, preventing tearing. |
| useContextSelector | ✅ | ❌| ✅ | ✅ | useContextSelector uses both unstable_runWithPriority and unstable_batchedUpdates to achieve batching. getState() is render dependent and cannot be used to get future state until the next render is committed |
| reducer-refs | ✅ | ✅| ❌ | ❌ | getState() provides ref access to the underlying current state, but does not currently use batching or versioning. May risk tearing and extra renders without further optimization |

RE: https://github.com/formium/formik/issues/2433#issuecomment-761273638 @dantman

I'm not concerned about tearing in legacy mode.

I will be advocating using a different version of Formik for concurrent mode, and with the way things are looking the underlying implementation will be with useMutableSource. Jared and I discussed using Feature Flags in webpack or some other method of opting into concurrent mode. I like the feature flag method because it doesn't require understanding the underlying implementation or changing code, but the API is yet to be finalized. My PR here isn't focused on those details, but aimed at identifying a common API we can use in both sync and concurrent mode, one which in the case of useFormStateSlice discussed on the issue above, would use different underlying implementations of subscriptions to that state depending on sync or concurrent.
I am actively advocating avoiding "drinking the kool-aid" like we did for v2 where React came out with Context and we said "React says it's OK so let's go all in!" and it resulted in a less performant Formik experience in v2. I don't want to over-prepare for concurrent mode at the cost of today's dev experience out of a sheer trust in React to implement it within a reasonable period of time, but I do want to be prepared enough that if they launched it tomorrow we'd be able to "fall forward" relatively easily.
To this end, I've split the bulk API of Formik into one package, and created two implementations (Jared's useContextSelector and my "reducer-refs", for lack of a better name, implementation). This change supports the creation of a useMutableSource implementation as well. There are some kinks to work out, but I think this is enough for a proof of concept.

Optimizations gained by context splitting however use an API currently available in React 17, but have no tearing issues. i.e. The same optimized code works in both stable react and experimental concurrent mode, but doesn't introduce tearing between components in concurrent mode like subscriptions do.

But these optimizations have a trade-off -- we have to maintain all of those contexts, each of those contexts has its own render pipeline, and partial use of straight context and partial use of subscriptions, those are the technical ones. However, the biggest one I see is one of dev experience -- a developer reading through their Dev Tools Components through a list of 20 Contexts per Formik instance to debug an input will be extremely frustrated by the development experience of nested Contexts.

Do you have any reason to anticipate that a setValue and a setTouched made at the same time in the same batch would result in a component receiving one but not the other? To my understanding that's not supposed to happen.

Batches are currently only automatically used in React-based event handlers and other special React functions, otherwise they must be wrapped in unstable_batchedUpdates. So it is my understanding that if you did something like:
// Formik users love async code like this
setTimeout(() => {
  formik.setIsSubmitting(true);
  formik.setValues(myNewValues);
});

Then React could commit the result of isSubmitting (the reducer state that results), and setValues at separate increments. Normally I think it would be so fast a callback as to hit in the same render, but I would be concerned that if one value is received via Context and another is a subscription (the result of an effect on the resulting FormikState), this would increase the chance that they didn't hit during the same render. I don't have anything but a gut feeling to back that up, but would love proof for or against.

I've been thinking all weekend however about what you said, and I agree that running memoizations for every single subscription that is added is a little bit overboard. That's why I'm going to take the following steps with this PR and update Formik's state in a more performant way.

For the bulk of Formik's users, we're going to recommend using micro-hooks, like useIsSubmitting, useField, etc.
As an advanced topic, I still think we should expose the underlying State Slice mechanism, but it will be a little bit more complicated to use.
Formik's hooks will use this State Slice mechanism internally in a highly optimized fashion.

Formik's context will keep track of listeners on a per-update-callback basis, in a shape that looks like this:
// note, this will start off an empty object with no updates, and each call to useFormikX will add listeners here, and the first addition of each one will create the prevSliceRef.
const formikListeners = {
  // all references to `useIsSubmitting` are here. this is a VERY fast function, using ===
  memoizedUseIsSubmittingUpdaterSymbol: {
    selector: selectIsSubmitting,
    updater: updateIfNotReferenceEquals,
    listeners: [],
    prevSliceRef: {
      current: selectIsSubmitting(state),
    }
  },
  // all listeners for  `useField("myField")` are here. All references to `useField("myOtherField")` would be in another context.
  // this is relatively slow, but as optimized as possible
  memoizedUseFieldUpdaterSymbol: {
    updater: updateIfNotDeepEquals,
    selector: selectGetFieldMeta,
    listeners: [],
    prevSliceRef: {
      current: selectIsSubmitting(state),
    }
  }
}

Now instead of a flat list of listeners that apply to every update, We can first diff state, and if the state differs for a given set of listeners, we can apply them all at once. This is the theoretical equivalent of how nested Contexts would work, but centralized within Formik.
I'm gonna prototype this up and see how it works. I'm going to create a new page in the dev app that is 500 inputs of the SAME FIELD. It should currently be pretty slow, and implementing this should make it lightning.

RE: https://github.com/formium/formik/issues/2433#issuecomment-761273638 @dantman

I'm not concerned about tearing in legacy mode.

I will be advocating using a different version of Formik for concurrent mode, and with the way things are looking the underlying implementation will be with useMutableSource. Jared and I discussed using Feature Flags in webpack or some other method of opting into concurrent mode. I like the feature flag method because it doesn't require understanding the underlying implementation or changing code, but the API is yet to be finalized. My PR here isn't focused on those details, but aimed at identifying a common API we can use in both sync and concurrent mode, one which in the case of useFormStateSlice discussed on the issue above, would use different underlying implementations of subscriptions to that state depending on sync or concurrent.
I am actively advocating avoiding "drinking the kool-aid" like we did for v2 where React came out with Context and we said "React says it's OK so let's go all in!" and it resulted in a less performant Formik experience in v2. I don't want to over-prepare for concurrent mode at the cost of today's dev experience out of a sheer trust in React to implement it within a reasonable period of time, but I do want to be prepared enough that if they launched it tomorrow we'd be able to "fall forward" relatively easily.
To this end, I've split the bulk API of Formik into one package, and created two implementations (Jared's useContextSelector and my "reducer-refs", for lack of a better name, implementation). This change supports the creation of a useMutableSource implementation as well. There are some kinks to work out, but I think this is enough for a proof of concept.

Optimizations gained by context splitting however use an API currently available in React 17, but have no tearing issues. i.e. The same optimized code works in both stable react and experimental concurrent mode, but doesn't introduce tearing between components in concurrent mode like subscriptions do.

But these optimizations have a trade-off -- we have to maintain all of those contexts, each of those contexts has its own render pipeline, and partial use of straight context and partial use of subscriptions, those are the technical ones. However, the biggest one I see is one of dev experience -- a developer reading through their Dev Tools Components through a list of 20 Contexts per Formik instance to debug an input will be extremely frustrated by the development experience of nested Contexts.

Do you have any reason to anticipate that a setValue and a setTouched made at the same time in the same batch would result in a component receiving one but not the other? To my understanding that's not supposed to happen.

Batches are currently only automatically used in React-based event handlers and other special React functions, otherwise they must be wrapped in unstable_batchedUpdates. So it is my understanding that if you did something like:
// Formik users love async code like this
setTimeout(() => {
  formik.setIsSubmitting(true);
  formik.setValues(myNewValues);
});

Then React could commit the result of isSubmitting (the reducer state that results), and setValues at separate increments. Normally I think it would be so fast a callback as to hit in the same render, but I would be concerned that if one value is received via Context and another is a subscription (the result of an effect on the resulting FormikState), this would increase the chance that they didn't hit during the same render. I don't have anything but a gut feeling to back that up, but would love proof for or against.

I've been thinking all weekend however about what you said, and I agree that running memoizations for every single subscription that is added is a little bit overboard. That's why I'm going to take the following steps with this PR and update Formik's state in a more performant way.

For the bulk of Formik's users, we're going to recommend using micro-hooks, like useIsSubmitting, useField, etc.
As an advanced topic, I still think we should expose the underlying State Slice mechanism, but it will be a little bit more complicated to use.
Formik's hooks will use this State Slice mechanism internally in a highly optimized fashion.

Formik's context will keep track of listeners on a per-update-callback basis, in a shape that looks like this:
// note, this will start off an empty object with no updates, and each call to useFormikX will add listeners here, and the first addition of each one will create the prevSliceRef.
const formikListeners = {
  // all references to `useIsSubmitting` are here. this is a VERY fast function, using ===
  memoizedUseIsSubmittingUpdaterSymbol: {
    selector: selectIsSubmitting,
    updater: updateIfNotReferenceEquals,
    listeners: [],
    prevSliceRef: {
      current: selectIsSubmitting(state),
    }
  },
  // all listeners for  `useField("myField")` are here. All references to `useField("myOtherField")` would be in another context.
  // this is relatively slow, but as optimized as possible
  memoizedUseFieldUpdaterSymbol: {
    updater: updateIfNotDeepEquals,
    selector: selectGetFieldMeta,
    listeners: [],
    prevSliceRef: {
      current: selectIsSubmitting(state),
    }
  }
}

Now instead of a flat list of listeners that apply to every update, We can first diff state, and if the state differs for a given set of listeners, we can apply them all at once. This is the theoretical equivalent of how nested Contexts would work, but centralized within Formik.
I'm gonna prototype this up and see how it works. I'm going to create a new page in the dev app that is 500 inputs of the SAME FIELD. It should currently be pretty slow, and implementing this should make it lightning.

Created a dev app page with 500 of the same input. It's pretty slow.

Created a dev app page with 500 of the same input. It's pretty slow.

However, the biggest one I see is one of dev experience -- when debugging in Dev Tools through a list of 20 Contexts per Formik instance I think nested Contexts would be borderline unusable.

This should NEVER be a factor considered. Use as many contexts as makes sense. The react team has made it clear you shouldn't be minimizing contexts expecting to optimize things in a different way if you find that more contexts is the more optimal. React's DevTools have an option for hiding contexts precisely because of this.

For the bulk of Formik's users, we're going to recommend using micro-hooks, like useIsSubmitting, useField, etc.

👍

Formik's hooks will use this State Slice mechanism internally in a highly optimized fashion.

Was a bit strange to wrap my head around the example. But looks good. Separate subscription listener systems (which are effectively just an array of functions to call) definitely seem cheaper than running object memoization on everything.
Instead of having useFormikX dynamically append a listener. How about creating something based on the create* pattern React uses. e.g. createFormikListener. This could offer guarantees that all listeners of the same type use the same config and there are no name collisions. Perhaps it could also optimize the testing of whether a type of listener already exists. e.g. Maybe it could reduce the formikListeners list to a Set (actually, maybe Map) that you only need to run a super fast .has on to know if the listener is already available on that formik instance.
e.g. Something like:
const isSubmittingSelector = createFormikSelector({
	selector: selectIsSubmitting,
	updater: updateIfNotReferenceEquals,
});

function useIsSubmitting() {
	return useFormikState(isSubmittingSelector)
}

// somewhere in <Formik>, probably an addFormikSelector
if (!formikSelectorListeners.has(selector)) formikSelectorListeners.set(selector, new Set());
const listeners = listeners.get(selector);

listeners.add(listenerHandler)
const unsubscribe = () => listeners.delete(listenerHandler);

const updateIfNotReferenceEquals = (selector, listeners, prevSliceRef, newState) => {
  const newSlice = selector(newState);
  const prevSlice = prevSliceRef.current;
  if (prevSlice !== newSlice) {
    prevSliceRef.current = newSlice;
    listeners.forEach(listener => listener(newSlice));
  }
}

I'm not sure the updater should be responsible for actually executing listener handlers. What if a formik listener from the author's perspective was made up of just a selector function to get the slice and a fast equality function to test if listeners should be called:
const selectIsSubmitting = state => state.isSubmitting;
const referenceEquality = (prevSlice, nextSlice) => prevSlice === nextSlice;

const isSubmittingSelector = createFormikSelector({
	selector: selectIsSubmitting,
	equals: referenceEquality,
});

Then the majority of that update function isn't needed since it's boilerplate that applies to all formik listeners and can just be in formik somewhere as this:
// S=The createFormikSelector result,
// or this could be part of createFormikSelector and {prevSliceRef, newState} are passed in
const nextSlice = S.selector(newState);
const prevSlice = prevSliceRef.current;
if (!S.equality(prevSlice, nextSlice)) {
  prevSliceRef.current = nextSlice;
  listeners.forEach(listener => listener(nextSlice));
}

However, the biggest one I see is one of dev experience -- when debugging in Dev Tools through a list of 20 Contexts per Formik instance I think nested Contexts would be borderline unusable.

This should NEVER be a factor considered. Use as many contexts as makes sense. The react team has made it clear you shouldn't be minimizing contexts expecting to optimize things in a different way if you find that more contexts is the more optimal. React's DevTools have an option for hiding contexts precisely because of this.

For the bulk of Formik's users, we're going to recommend using micro-hooks, like useIsSubmitting, useField, etc.

👍

Formik's hooks will use this State Slice mechanism internally in a highly optimized fashion.

Was a bit strange to wrap my head around the example. But looks good. Separate subscription listener systems (which are effectively just an array of functions to call) definitely seem cheaper than running object memoization on everything.
Instead of having useFormikX dynamically append a listener. How about creating something based on the create* pattern React uses. e.g. createFormikListener. This could offer guarantees that all listeners of the same type use the same config and there are no name collisions. Perhaps it could also optimize the testing of whether a type of listener already exists. e.g. Maybe it could reduce the formikListeners list to a Set (actually, maybe Map) that you only need to run a super fast .has on to know if the listener is already available on that formik instance.
e.g. Something like:
const isSubmittingSelector = createFormikSelector({
	selector: selectIsSubmitting,
	updater: updateIfNotReferenceEquals,
});

function useIsSubmitting() {
	return useFormikState(isSubmittingSelector)
}

// somewhere in <Formik>, probably an addFormikSelector
if (!formikSelectorListeners.has(selector)) formikSelectorListeners.set(selector, new Set());
const listeners = listeners.get(selector);

listeners.add(listenerHandler)
const unsubscribe = () => listeners.delete(listenerHandler);

const updateIfNotReferenceEquals = (selector, listeners, prevSliceRef, newState) => {
  const newSlice = selector(newState);
  const prevSlice = prevSliceRef.current;
  if (prevSlice !== newSlice) {
    prevSliceRef.current = newSlice;
    listeners.forEach(listener => listener(newSlice));
  }
}

I'm not sure the updater should be responsible for actually executing listener handlers. What if a formik listener from the author's perspective was made up of just a selector function to get the slice and a fast equality function to test if listeners should be called:
const selectIsSubmitting = state => state.isSubmitting;
const referenceEquality = (prevSlice, nextSlice) => prevSlice === nextSlice;

const isSubmittingSelector = createFormikSelector({
	selector: selectIsSubmitting,
	equals: referenceEquality,
});

Then the majority of that update function isn't needed since it's boilerplate that applies to all formik listeners and can just be in formik somewhere as this:
// S=The createFormikSelector result,
// or this could be part of createFormikSelector and {prevSliceRef, newState} are passed in
const nextSlice = S.selector(newState);
const prevSlice = prevSliceRef.current;
if (!S.equality(prevSlice, nextSlice)) {
  prevSliceRef.current = nextSlice;
  listeners.forEach(listener => listener(nextSlice));
}

This should NEVER be a factor considered. Use as many contexts as makes sense. The react team has made it clear you shouldn't be minimizing contexts expecting to optimize things in a different way if you find that more contexts is the more optimal.

But what if a dev needs to debug Formik's context? Still seems very weird to me. I haven't read anything from the React team specifically about using dozens of contexts but if it's not in the docs I probably haven't read it.
I still have a concern about subscriptions + raw contexts being mixed together, but I'd be really interested to compare performance between these two methods.

How about creating something based on the create* pattern React uses. e.g. createFormikListener.

YES. I really like the idea of createFormikSelector. The reason I split args into its own separate dependency hook is because when you using something like, the following, you're not actually using a constant value function, but a dynamic one.
const [field] = useField("myField");

Here, the underlying mechanism you're actually using would be something like:
// selectGetFieldMeta is a global constant, but the return value isn't
const selector = selectGetFieldMeta(name);

So we'd have to separate args in order to create a single instance across components. There are a few methods I have in mind:
1.
// the identity is now selector+[...args]
const selector = api.createSelector(selectGetFieldMeta, [name]);
// both args must be optimized
const fieldMeta = useFormikState(selector, _.equals);

2.
// the identity is now selector+comparer+[...args]
const selector = api.createSelector({
  selector: selectGetFieldMeta,
  comparer: _.equals,
  args: [name],
});
const fieldMeta = useFormikState(selector);

3.
// the identity is now selector+comparer, but selector can be optimized separately
const subscriber = api.createSubscriber({
  // selector can still be cleaned up because it is scoped to API.
  // additionally, this could just be a constant function like selectIsSubmitting
  selector: api.createSelector(selectGetFieldMeta, [name]),
  comparer: _.equals,
});
const fieldMeta = useFormikState(subscriber);

I guess the final thing I'm concerned about is that we've moved some implementation details out from behind useFormikStateSlice(), which are currently nicely tucked away in this PR.

This should NEVER be a factor considered. Use as many contexts as makes sense. The react team has made it clear you shouldn't be minimizing contexts expecting to optimize things in a different way if you find that more contexts is the more optimal.

But what if a dev needs to debug Formik's context? Still seems very weird to me. I haven't read anything from the React team specifically about using dozens of contexts but if it's not in the docs I probably haven't read it.
I still have a concern about subscriptions + raw contexts being mixed together, but I'd be really interested to compare performance between these two methods.

How about creating something based on the create* pattern React uses. e.g. createFormikListener.

YES. I really like the idea of createFormikSelector. The reason I split args into its own separate dependency hook is because when you using something like, the following, you're not actually using a constant value function, but a dynamic one.
const [field] = useField("myField");

Here, the underlying mechanism you're actually using would be something like:
// selectGetFieldMeta is a global constant, but the return value isn't
const selector = selectGetFieldMeta(name);

So we'd have to separate args in order to create a single instance across components. There are a few methods I have in mind:
1.
// the identity is now selector+[...args]
const selector = api.createSelector(selectGetFieldMeta, [name]);
// both args must be optimized
const fieldMeta = useFormikState(selector, _.equals);

2.
// the identity is now selector+comparer+[...args]
const selector = api.createSelector({
  selector: selectGetFieldMeta,
  comparer: _.equals,
  args: [name],
});
const fieldMeta = useFormikState(selector);

3.
// the identity is now selector+comparer, but selector can be optimized separately
const subscriber = api.createSubscriber({
  // selector can still be cleaned up because it is scoped to API.
  // additionally, this could just be a constant function like selectIsSubmitting
  selector: api.createSelector(selectGetFieldMeta, [name]),
  comparer: _.equals,
});
const fieldMeta = useFormikState(subscriber);

I guess the final thing I'm concerned about is that we've moved some implementation details out from behind useFormikStateSlice(), which are currently nicely tucked away in this PR.

Looks like they basically document optimizing selectors here: https://github.com/reactjs/rfcs/blob/master/text/0147-use-mutable-source.md#redux-stores
They don't really give a concrete example across Components, but inferring from their examples, it looks like createSelector will still be useful for establishing identity. It also doesn't seem like there is a way to configure whether to re-render when the result of getSnapshot has a certain type of equality, so we'll have to thoroughly test performance when moving to useMutableSource. getSnapshot doesn't get passed a previous value to check against, and I don't believe refs will be safe in that context.

Looks like they basically document optimizing selectors here: https://github.com/reactjs/rfcs/blob/master/text/0147-use-mutable-source.md#redux-stores
They don't really give a concrete example across Components, but inferring from their examples, it looks like createSelector will still be useful for establishing identity. It also doesn't seem like there is a way to configure whether to re-render when the result of getSnapshot has a certain type of equality, so we'll have to thoroughly test performance when moving to useMutableSource. getSnapshot doesn't get passed a previous value to check against, and I don't believe refs will be safe in that context.

It was challenging to get TypeScript to play nicely with this system, BUT! Alas, it is done. I've simplified the Subscriptions API in to more manageable chunks, using the useSubscriptions API.
The new API is like so:
import { isEqual } from 'lodash';

const MySubscriber = () => {
  const { createSubscriber, createSelector } = useFormikApi<FormValues>();

  /**
   * Create a subscriber. Memoizing it is the most important thing you can do.
   * I think if I can memoize the
   */
  const subscriber = React.useMemo(
    () =>
      createSubscriber(
        createSelector(selectFieldMetaByName, [fieldName]),
        isEqual
      ),
    [createSelector, createSubscriber, fieldName]
  );

  // GEE it was hard to get `fieldMeta` automatically typed.
  const fieldMeta = useFormikStateSubscription(subscriber);
}

I think the footprint can get even smaller, but I'm pretty tired of battling typescript at this point, lol. Similar to what is discussed, batched updates just do this:
    unstable_batchedUpdates(() => {
      subscriptionsRef.current.forEach(subscription => {
        const prevState = subscription.prevStateRef.current;
        const newState = subscription.selector(state);

        if (!subscription.subscriber.comparer(prevState, newState)) {
          subscription.prevStateRef.current = newState;
          subscription.listeners.forEach(listener => listener(newState));
        }
      });
    });

It was challenging to get TypeScript to play nicely with this system, BUT! Alas, it is done. I've simplified the Subscriptions API in to more manageable chunks, using the useSubscriptions API.
The new API is like so:
import { isEqual } from 'lodash';

const MySubscriber = () => {
  const { createSubscriber, createSelector } = useFormikApi<FormValues>();

  /**
   * Create a subscriber. Memoizing it is the most important thing you can do.
   * I think if I can memoize the
   */
  const subscriber = React.useMemo(
    () =>
      createSubscriber(
        createSelector(selectFieldMetaByName, [fieldName]),
        isEqual
      ),
    [createSelector, createSubscriber, fieldName]
  );

  // GEE it was hard to get `fieldMeta` automatically typed.
  const fieldMeta = useFormikStateSubscription(subscriber);
}

I think the footprint can get even smaller, but I'm pretty tired of battling typescript at this point, lol. Similar to what is discussed, batched updates just do this:
    unstable_batchedUpdates(() => {
      subscriptionsRef.current.forEach(subscription => {
        const prevState = subscription.prevStateRef.current;
        const newState = subscription.selector(state);

        if (!subscription.subscriber.comparer(prevState, newState)) {
          subscription.prevStateRef.current = newState;
          subscription.listeners.forEach(listener => listener(newState));
        }
      });
    });

The other alternative I can think of to find existing Subscriptions is the following. Not sure exactly how performance would differ without testing.
// as exists in the PR
const subscriptions: SubscriptionsRef = useRef([]);
// complex mapping object to keep track of what selectors / comparers / args map to which subscriptions
const subscriptionMap = new Map();
subscriptionMap.push(
    selectIsSubmitting, // selector
    new Map(
      Object.is, // comparer
      {
        subscription: subscriptions[0] // for example
        nextArgs: undefined,
      }
   )
);
subscriptionMap.push(
    selectFieldMetaByName, // selector
    new Map(
      _.isEqual, // comparer
      {
        subscription: undefined, // there should be no version of this without args
        nextArg: new Map(
          "firstName", // first arg
          {
            subscription: subscriptions[1],
            nextArg: undefined, // unless there are more args passed in createSelector
          }
        )
      }
   )
);

The other alternative I can think of to find existing Subscriptions is the following. Not sure exactly how performance would differ without testing.
// as exists in the PR
const subscriptions: SubscriptionsRef = useRef([]);
// complex mapping object to keep track of what selectors / comparers / args map to which subscriptions
const subscriptionMap = new Map();
subscriptionMap.push(
    selectIsSubmitting, // selector
    new Map(
      Object.is, // comparer
      {
        subscription: subscriptions[0] // for example
        nextArgs: undefined,
      }
   )
);
subscriptionMap.push(
    selectFieldMetaByName, // selector
    new Map(
      _.isEqual, // comparer
      {
        subscription: undefined, // there should be no version of this without args
        nextArg: new Map(
          "firstName", // first arg
          {
            subscription: subscriptions[1],
            nextArg: undefined, // unless there are more args passed in createSelector
          }
        )
      }
   )
);

I've simplified the API to look like this:
useFormikState(selectIsSubmitting);
useFormikState([selectFieldMetaByName, "firstName"], compareFieldMeta);

I've simplified the API to look like this:
useFormikState(selectIsSubmitting);
useFormikState([selectFieldMetaByName, "firstName"], compareFieldMeta);

The reducer-refs API enables easy optional subscriptions, such as the <Form /> subscribing to values only when onChange={values => dependents(values)} is passed to it.

The reducer-refs API enables easy optional subscriptions, such as the <Form /> subscribing to values only when onChange={values => dependents(values)} is passed to it.

closed in favor of #3089


Added timestamp support

Nice project, I was working on adding timestamps into the python side of whisper and thought I'd add it in here for fun. It worked on my computer, but I didn't test it too much so it might still be buggy. Thanks

Hi! Thank you for doing that! When I have time, I will test it and merge it. Thank you again for contributing to this repo!


no-object-mutation rule, allow class member mutation in constructor

Fixes #59

Coverage decreased (-0.4%) to 98.582% when pulling fd6541f44779b2d14789e348a098449464e6e46f on feature/class-member-init-constructor into fc0f554e04674fa9dceb29f4b1d2060d9bf45670 on master.

Released in 4.5.4


Floating windows position isn't updated when the monitor layout changes

Hyprland Version
0.35.0
Bug or Regression?
Bug
Description
When the monitor layout using wlr-randr:
Everything is updated to fit the new layout so there are no visible changes, but floating windows are not.
There is a chance to completely lose floating windows this way (when changing the monitor layout).
How to reproduce

Get a monitor at 0.0, eg: wlr-randr --output HDMI-A-1 --pos 0,0
make some window floating
Change to another position, eg: wlr-randr --output HDMI-A-1 --pos 400,0
see workspaces being updated, tiled windows are preserved, but floating windows are shifted horizontally (in the example)

Crash reports, logs, images, videos
No response

I don't think this is enough, also it's hard to operate on things you don't see, meaning you have to use such hacks/workarounds: https://github.com/hyprland-community/pyprland/wiki/lost_windows
or identify the client using hyprctl and then move it to the workspace of your choice using the command line... not very friendly


Proposal: verbose errors

In many cases when we're generating an error we know that the particular error, if it happens, is indicative of a bug. In those cases, it's very useful if the error message contains more information (like file:line).
Errors might be handled at a different layer (e.g. sent out to a client using %s) where the original context of the error is lost.
The proposal is to add a version of Errorf which results in a "verbose" error which automatically includes the file:line where it was generated as part of the error message.

Hello,
Thank you for raising this issue. I believe with version 0.7.0 this is already supported via the %+v formatting verb.

Hi Dave,
The layer that is formatting the error in general doesn't know the context of the error anymore - it doesn't know which errors it should format using %+v and which using %s.
The key part of the proposal is having the error itself internally keep track of this "verbosity" indicator.

I'm not sure know how to satisfy this request, once an error value is turned into a string, obviously any other information is lost.
Are you suggesting a new helper, something like errors.ErrorfWithStacktrace that will force the file:line information into the .Error() string output when printed ?

If this is what you are asking for I can see two possibilities:

A new pair (quad) of top level functions, ie, we'd have New and NewWithFileAndLine, and so on.
A wrapper function, errors.WithFileAndLine (terrible name) that would "convert" an errors's .Error() format from just returning the message to returning something like file:line: message

Neither of these is particularly appealing.

Oh, im.sorry I think understand what you mean, you want
 errors.Errorf("...", arg)

Where the elided part is some formatting verb that adds the file and line
of the call to Errorf.
Is that correct?
On Fri, 24 Jun 2016, 08:27 RaduBerinde<EMAIL_ADDRESS>wrote:

Hi Dave,
The layer that is formatting the error in general doesn't know the context
of the error anymore - it doesn't know which errors it should format using
%+v and which using %s.
The key part of the proposal is having the error itself internally keep
track of this "verbosity" indicator.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/pkg/errors/issues/59#issuecomment-228204628, or mute
the thread
https://github.com/notifications/unsubscribe/AAAcAw0nriVMlGbSRlAw4AQD-TsgUlA6ks5qOwhMgaJpZM4I9Sli
.

I was suggestion a new helper (e.g. errors.Verbosef or whatever). It can also be a verb to errors.Errorf.

Thanks for your reply. I can think of three ways to do this, none of them
are without (serious) drawbacks.
The first would be something like
errors.Error("%+v", arg).Error()
To say we want the "verbose" output when Error is called. This is
problematic because there is an ambiguity over does the %+v get applied to
the argument arg, or consumed to signal Error() should modify its
behaviour. Maybe this is solvable with documentation, but it still leaves
New and Wrap. Where could we put the flag to modify their return value's
.Error() method?
I don't think this is a good solution.
Adding new methods like errors.Verbosef solves that first problem, but
you'd have to do it for all four of New, Errorf, Wrap, and Wrapf. I'm sorry
but four additional helpers is not something I'm prepared to do.
Adding some kind of modified function like
func Verbose(err error) error
Which took an error and returned an error with the "verbose details" bit
set is a possibility. But both this and the previous method suffer from the
issue that if the original called did not use the verbose form, or wrapper,
then when you pass that error to fmt.Printf, the chance to turn on the
verbose bit is long gone and not in code you control.
This leaves printing this error. Ideally we would have three verbs
available, %s, %v and %+v which would print the message, a slightly more
verbose version (such as you suggested) and the full stack trace of the
error as it does in 0.7.0.
Unfortunately in my research %s and %v are used interchangeably (as they
have the same behavior with the srdlib's built in errors package) with a
strong preference to using %v more often than %s.
There are two practical solutions in can see. The first is to add something
like errors.Verbose which takes an error and returns an error with the
message modified. This feels like a minefield of bikes shedding about the
exact format of the information added (file and line, what about the
function name? What about the package name? etc)
The second choice would be to try to reclaim %v and have it print the file
and line. Leaving %s for printing just the message, and %+v for the full
stack trace.
The second is my preferred option as it leaves the control in the code
doing the printing, not the code that generated the error.
On Fri, 24 Jun 2016, 09:05 RaduBerinde<EMAIL_ADDRESS>wrote:

I was suggestion a new helper (e.g. errors.Verbosef or whatever). It can
also be a verb to errors.Errorf.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/pkg/errors/issues/59#issuecomment-228211793, or mute
the thread
https://github.com/notifications/unsubscribe/AAAcA2_Hykze_5oEyW2D53dlGnV0AWsuks5qOxFHgaJpZM4I9Sli
.

@davecheney I believe the specific desire here is indeed for the code that generates the error to be able to indicate that the error needs to be verbose. In particular we often generate errors in CockroachDB that are indicative of bugs - those comments are not for end-user consumption, and so we know we always want them to print with higher verbosity, regardless of the code that prints them.
.Verbose() seems like the most practical option to me.

I'm concerned that will lead to copy pasta
err := errors.New("oops")
err = errors.Verbose(err) //because reasons
On Fri, 24 Jun 2016, 09:38 Tamir Duberstein<EMAIL_ADDRESS>wrote:

@davecheney https://github.com/davecheney I believe the specific desire
here is indeed for the code that generates the error to be able to indicate
that the error needs to be verbose. In particular we often generate errors
in CockroachDB that are indicative of bugs - those comments are not for
end-user consumption, and so we know we always want them to print with
higher verbosity, regardless of the code that prints them.
.Verbose() seems like the most practical option to me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pkg/errors/issues/59#issuecomment-228217211, or mute
the thread
https://github.com/notifications/unsubscribe/AAAcA1Df2Fc7gGSaEwcGeYKrpEZuOjmwks5qOxkCgaJpZM4I9Sli
.

Tamir, with reference to your point about your usage in cockroachdb, can
you tell me if the %+v feature added in 0.7.0 is useful. And if not, How
could it be changed.
If you could give this feedback on a new issue that would be strongly
preferred.
Thanks
On Fri, 24 Jun 2016, 09:44 Dave Cheney<EMAIL_ADDRESS>wrote:

I'm concerned that will lead to copy pasta
err := errors.New("oops")
err = errors.Verbose(err) //because reasons
On Fri, 24 Jun 2016, 09:38 Tamir Duberstein<EMAIL_ADDRESS>wrote:

@davecheney https://github.com/davecheney I believe the specific
desire here is indeed for the code that generates the error to be able to
indicate that the error needs to be verbose. In particular we often
generate errors in CockroachDB that are indicative of bugs - those comments
are not for end-user consumption, and so we know we always want them to
print with higher verbosity, regardless of the code that prints them.
.Verbose() seems like the most practical option to me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pkg/errors/issues/59#issuecomment-228217211, or mute
the thread
https://github.com/notifications/unsubscribe/AAAcA1Df2Fc7gGSaEwcGeYKrpEZuOjmwks5qOxkCgaJpZM4I9Sli
.

Tamir and I are referring to the exact same issue. We want to control the verbosity at the point where the error is generated, not at the point where we are printing the error.
The proposed Verbose works though I agree errors.Verobse(error.Errorf(..)) is a little clunky.. We could provide a helper just for this one Verbosef but not for the other three (Verbose can still be used specifically if needed).

Here is a high level illustration of why this is useful. Say our program logic is something like this:
1:  for {
2:    receive user request
3:    call into module X to satisfy request
4:      -> module X calls into module Y
5:         ..
6:            -> somewhere deep in the bowels of a submodule, an error is generated and bubbles up
7:
8:    send error to user
9:  }

Some errors are expected to be seen by a user (e.g. "no more space"); other errors are caused by some internal inconsistency and indicate a bug. We want the latter to print more verbosely. We know the difference when we generate the error (line 6) but the "send error to client" code in line 8 does not know - all it has is the error. So the "verbosity" needs to be stored inside the error.

@RaduBerinde thank you for your explanation. In your example it does not look like there are any calls to fmt.Sprintf or anything that would convert the error value into a string. That is, the original error arrives at the top of the call stack, possibly wrapped, but otherwise intact.
Is that correct ?

I saw you edit your original comment. That's hard to keep track of, could you please answer any followup questions in a new comment. Thanks.

I had edited it immediately after writing it to make it more clear (way before your followup question)..

Thanks for confirming. Could you please respond to my question in https://github.com/pkg/errors/issues/59#issuecomment-228231951

The conversion to string would happen in step 8 "send error message to user".

Thank you for confirming. Why won't %+v work for you then. Is the problem that given an arbitrary error value, you cannot decide if it's important enough to give the user all the information, or just some of it ?

Exactly. Like I said above:

Some errors are expected to be seen by a user (e.g. "no more space"); other errors are caused by some internal inconsistency and indicate a bug. We want the latter to print more verbosely

Real talk, what you're asking for is going to make the surface area of this package larger and certainly more complex to use. This is in conflict with the goal of this package to be a proof of concept for improving the errors package in the standard library in Go 1.8.
If you have a certain class of errors that you know are more serious, or verbose, then you can define your own error type that adds any detail you want. Even something as simple as this
_, file, line, _ := runtime.Callers(1)
return errors.Errorf("%s:%d: %s", file, line, "critical error happened here")

Should give you what you want.
Can I ask why you do not want to always use %+v when printing the error back to the user. What about it is not acceptable? Is there a way we can define an intermediate format, somewhere between printing just the error's message with %s, and the full stack dump that %+v.

It's your call, but I don't see how it makes the package more complex to use. Anybody who doesn't care about this would continue using it just like today. It does make the exposed interface more complex (in that it has a couple more functions), sure.

Can I ask why you do not want to always use %+v when printing the error back to the user. What about it is not acceptable?

Because the messages for "normal" errors would be less user-friendly and harder for the user to understand. In our case these are errors returned in a SQL session so it's not really feasible to dump a lot of obscure information. It only makes sense for errors that weren't intended to be ever seen by a user.

It does make the exposed interface more complex (in that it has a couple more functions), sure.

The type returned from error.{New,Wrap,Errorf,Wrapf} has to be error otherwise this breaks
err := fn() // something that returns a type from this errors package
if err != nil {
       return err
}
err = fn2() // something that returns an error generated from fmt.Errorf

This has come up a few times in other issues on this repo, the short version is the type return from this packages' methods must be error, not something like errors.Error.

Because the messages for "normal" errors would be less user-friendly and harder for the user to understand. In our case these are errors returned in a SQL session so it's not really feasible to dump a lot of obscure information. It only makes sense for errors that weren't intended to be ever seen by a user.

ok, I can see that you don't want to always return a multiline stacktrace, but would you be ok with always returning to the caller say
 driver.go:9999: out of space

The solution you proposed (func Verbose(err error) error) doesn't need to do that - it would be very close to how Wrap works. In fact, it could even use Wrap and use the file:line as the extra message.

ok, I can see that you don't want to always return a multiline stacktrace, but would you be ok with always returning to the caller say [..]

No - we want the "normal" errors to not have any filenames and line numbers in them; one big reason is that we don't want the error messages to vary depending on the build..

Of course - I do understand the hesitation to add random stuff to the package, so feel free to close this.
A generalization of this concept to maybe consider in the future is allowing "tagging" of errors with arbitrary information (e.g. setting key/values with string keys and interface{} values). In my experience this functionality can be very useful - similar to how Wrap adds a message to the error, an intermediate layer can set an ID or a flag, and that could be used in an upper layer to make a decision when handling the error.

@RaduBerinde as to your last point, please see #34, which is regrettably, closed.

The solution you proposed (func Verbose(err error) error) doesn't need to do that - it would be very close to how Wrap works. In fact, it could even use Wrap and use the file:line as the extra message.

I don't think I understand. Can you please explain in more detail how this would work.

E.g.:
func Verbose(err error) error {
  _, file, line, _ := runtime.Caller(1)
  return errors.Wrap(err, fmt.Sprintf("%s:%d", file, line))
}

I'm sorry but I do not plan to add this helper. I understand your use case but am not sure that it common enough to increase the surface area of this package. I'm almost certain that this helper would not make the cut if this package was accepted (in part or in piece) into the standard library so I recommend that you write this helper in you own codebase.


Fix displaying commits and files of PR created from now deleted fork

If PR was made from forked repository and later fork was deleted Gitea was failing with panic. Fixed displaying commits and changed files tabs.

LGTM

LGTM

LGTM


python311Packages.cython: restrict patch to python versions where the API exists

This doesn't actually cause python311Packages.Cython to fail it's build but python311Packages.skia-pathops
Description of changes
Cython used internal python APIs for a while, but that was removed at some point. We added a patch to add that back in in e69d0a0aa3bf but since the API was removed in python3.11 we cannot use the patch anymore.
I can't confidently say I understand why the patch was added so I don't want to speak on whether it is still needed, but since it doesn't work on python3.11 we should probably merge this?
Pinging

@collares Since you added the patch
@FRidh as Cython maintainer
@barinov274 as skia-pathops maintainer

Things done
Only use the patch on python version <=3.11

Built on platform(s)

[x] x86_64-linux (Cython and skia-pathops)
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Can you apply https://github.com/cython/cython/commit/e337825cdcf5e94d38ba06a0cb0188e99ce0cc92 atop the present patch instead of removing it? It effectively reverts the changes in Cython/Utility/ExtensionTypes.c (because they were upstreamed) but does not revert the Cython/Compiler/* changes, meaning that Cython will now still use trashcan support (but the upstream version instead).

For reference, the original patch (the one that would be removed if this PR were merged right now) was committed as https://github.com/cython/cython/commit/f781880b6780117660b2026caadf4a6d7905722f. I'm pointing this out because the patch is currently fetched from Sage's repository, which might make code archaeology unnecessarily hard.

You'll probably want to target staging (or python-updates, if there's an open Python Updates PR, but I couldn't find one at a quick glance), because Cython is a transitive dependency of many many packages.

I thought it was uppercase Cython for some reason, maybe we need to trigger a rebuild? I'm not sure how ofborg works.

ofBorg looks at the commit title, not at the PR title. It will automatically trigger a new build on push (even force pushes).

Added the second patch as you suggested. I'm also pulling in both of them from the official repo, let me know/revert the lines if you'd prefer to leave the old one as it is.
@ofborg build python311Packages.skia-pathops

Done and done :)

Great, many thanks for updating the patches! And thanks for pinging me in the first place, I probably would have missed it. Let's wait for the Cython maintainer's approval, but please ping me if that hasn't happened in a reasonable timeframe (a week, say).

fails to build:
gcc -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -I/nix/store/jwg037i9jji90ap1112wd5hb5f4lg9iy-libxcrypt-4.4.28/include -fPIC -I./cypari2 -I/nix/store/rhqyzfxyk43gmr4yz1w9b7b8h2mz4r4m-python3.11-cysignals-1.11.2/lib/python3.11/site-packages/cysignals -I/nix/store/zy158n41isy1l8asc4q6kgz4bj255py8-pari-2.13.4/include -I/nix/store/s2q0x350276vgsqls8ws317kcrdii2xk-python3-3.11.0/include/python3.11 -c cypari2/convert.c -o build/temp.linux-x86_64-cpython-311/cypari2/convert.o
cypari2/convert.c: In function ‘__pyx_f_7cypari2_7convert_PyLong_FromINT’:
cypari2/convert.c:3395:21: error: lvalue required as unary ‘&’ operand
 3395 |   __pyx_v_sizeptr = &Py_SIZE(((PyObject *)__pyx_v_x));
      |                     ^
error: command '/nix/store/mjfccdxzpb87wa4pz56fkv6l63pw9in4-gcc-wrapper-11.3.0/bin/gcc' failed with exit code 1
error: builder for '/nix/store/g5ibxzw5d297q3n36qrvgv2n5zw1lsff-python3.11-cypari2-2.1.2.drv' failed with exit code 1;

@SuperSandro2000 Thanks for the heads up! I tested cypari2 out of an abundance of caution, but it turns out to be incompatible with Python 3.11 for reasons unrelated to this PR (https://github.com/sagemath/cypari2/issues/114). It was fixed upstream (https://github.com/sagemath/cypari2/pull/120), but I think we can afford to wait for a new cypari2 release since Python 3.11 is opt-in in Nixpkgs for now. Either way, the compilation problem is caused solely by Python 3.11 and not by this PR.

@ofborg build python311Packages.cython


No /COMMUNICATION.md

Many documentation links point to /COMMUNICATION.md.

COMMUNICATION.md links have been fixed - thanks @mmlb for fixing and @guilhem for reporting this.


Refactor Environment

This brings a number of improvements:

I introduced LedgerEnv which has both the configuration and the stateful part. Most calls in LedgerState are now done with this LedgerEnv and don't require the user to keep track of the ledger directory, network, var or to read the state in order to take the Configuration. This makes the api clearer.
The DbSyncEnv wraps this LedgerEnv. Calls which need to access both the ledger and the DB, are done via this DbSyncEnv
Genesis ledger state is no longer saved to disk. It can be recreated from the configuration if necessary. The filename of genesis used the hash of "genesis" at the place of block hash, so it caused confusion.
Used Point instead of Slot in more places.
Using mostly Point fixed an issue which occurred if we saved an EBB state.

this should be ready to review

Rebased, moved the PR message to the commit and did some minor tweaks.

Will merge this as soon as I have verified that there is no performance regression.


Cannot delete repositories after restore

Hi,
I restored a redmine installation, now when I try to delete a repository the page just says:

Internal error
An error occurred on the page you were trying to access.
If you continue to experience problems please contact your Redmine administrator for assistance.
If you are the Redmine administrator, check your log files for details about the error.
Back

What can I check?
Thanks

The errore message from production.log
Started DELETE "/repositories/27" for <IP_ADDRESS> at 2016-03-31 09:33:16 +0200 Processing by RepositoriesController#destroy as HTML   Parameters: {"authenticity_token"=>"nqhXQoGZrBmoHKr4BkoR16nntgFCesMnrwZkNcECH2M7Y244QoFqnGrlaWWME3fWr1JoUhldVvMRKI8LYbX0tA==", "id"=>"27"}   Current user: antonio (id=5) Completed 500 Internal Server Error in 54ms (ActiveRecord: 40.3ms)

Here after other tries `Started DELETE "/repositories/26" for <IP_ADDRESS> at 2016-03-31 10:49:55 +0200
Processing by RepositoriesController#destroy as HTML
Parameters: {"authenticity_token"=>"9L+F5ICGgKi4XEPbCLGYmUmhcU2LnyLIjVb43sSq11fbPpsWw9IbJvTgfacy9maMVElJGcOgOCOJBJbuEJ7BGQ==", "id"=>"26"}
Current user: admin (id=1)
Completed 500 Internal Server Error in 35ms (ActiveRecord: 18.5ms)
ActiveRecord::StatementInvalid (Mysql2::Error: Table 'redmine.repository_git_notifications' doesn't exist: SHOW FULL FIELDS FROM repository_git_notif ications):
app/controllers/repositories_controller.rb:109:in destroy'   lib/redmine/sudo_mode.rb:63:in sudo_mode'
`
Anyone knows what I did wrong? Thanks..

When I try to clone a repository this error comes up:
`Cloning into 'testrepodel'...
FATAL: R any redmine/redmine/testrepodel id_rsa DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
`

Hi @ioiobzit,
We had the same problem, this table was not in our database. We don't know why.
I hope you found a solution. If not and for others, please find the solution we came up with.
Create file create_repository_git_notifications.sql with this content :
---
-- Table structure for table `repository_git_notifications`
--

DROP TABLE IF EXISTS `repository_git_notifications`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `repository_git_notifications` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `repository_id` int(11) DEFAULT NULL,
  `include_list` text,
  `exclude_list` text,
  `prefix` varchar(255) DEFAULT NULL,
  `sender_address` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

Add this table to your MySQL database :
redmine$ mysql -u redmine -p redmine < create_repository_git_notifications.sql
Apply plugin migration command:
redmine$ bundle exec rake redmine:plugins:migrate RAILS_ENV=production NAME=redmine_git_hosting

We had the same problem, this table was not in our database. We don't know why.

Because you're on devel branch...

Yes, we were.
But we migrated to the v1.2.1 and this table still absent.

This is normal, this table has been removed in devel branch.

OK.
Thank you for your reactivity and your work.

I have the same problem, table does not exist, deleting repo results in error 500.
I dont fully get what being on devel means? I checked out version 1.2.2


UX/ UI- Disbursements

Disbursements to Students
Disbursements to Institutions on behalf of Students

[ ] Workflow
[ ] Wireframe

Display disbursements made on a few key areas in the student app.
Pages effected:
App pain dashboard?
App Summary
App Details
Communications/Notifications as needed.


Editable Text

Requires design for Figma Component.

Component design
https://www.figma.com/file/sz08OJt2VrEgxQ8eToFIqG/ADS2.0---Components?type=design&node-id=4759-9475&mode=design&t=uR1DQcnLsYedXQgz-4

Pending: To Provide the screens for the usage.


MATLAB parser cleanup & fix for parsing 1./x

1st commit: Clarify recognition of "command form" by MATLAB parser.
Expand a bit the explanation; remove an unnecessary non-capturing group,
replace \s+ by \s at the end (we just need to check for the presence of
a space).
2nd commit: MATLAB: Correctly parse 1./x as (1)(./)(x).

There have been quite a bunch of changes in the Matlab lexer. Could you please take a look and rebase to the latest version?

rebased

Perfect, thanks a lot!


feature: migrate to clap (CLI arg parser)

Hi,
First of all, great project!
I'm curious to hear your thoughts on migrating to clap - A full featured, fast Command Line Argument Parser for Rust
I've used this crate in the past before and it has been pretty helpful. If you're interested in migrating to it, I think that I can create a PR implementing these changes however I wanted to run this by you first.

Thank you for your suggestion.
While clap is amazing, I don't see the need to incorporate it into this project. With only two options (-h and -l), I think using std::env::args to parse arguments is sufficient.
If you have specific reasons why clap would be a better choice in this code, I'm open to hearing them.


proxy.config.http.cache.open_read_retry_time default value impractical

The default value for proxy.config.http.cache.open_read_retry_time is 10ms.
While running synthetic load testing simulating a thundering herd against a rotating manifest file I added debug into HttpCacheSM to printout time when read retries occurred.  On a broadwell xeon with nvme drives I was consistently seeing more than 900ms between these calls.  However under these conditions I was seeing at most 2-3 calls being made before the read lock was acquired.

We need more information to determine what we should do here.  @traeak will investigate  more.

I agree with this: 10ms default is at odds with other ATS defaults, and have seen this behaviour also.
Hypothesis:

Tightly time coupled thundering herd will naturally cause read lock failures
ATS read lock failures will reschedule (10ms default)
I suspect 10ms + (reschedule delay) will have 'expected' effect


Support for using Rollbar.js as an ES2015 module

This builds upon the work done in #58, #59, #60 and #61
Rather than consuming apps needing to have globals all over the place, this PR now publishes the window.Rollbar global as an ES2015 module
import rollbar from 'rollbar';

...

rollbar.critical("Connection error from remote Payments API");

...

Nice addition 👍


"Error: options.uri is a required argument" when trying to use setValue

var write_sheet = function(col , row , value){
        //convert col and row to single array value
        var sheet_row_length = sheet_info.worksheets[0].colCount;
        var row_value = (row - 1) * sheet_row_length;
        var index = row_value + col;
        spreadsheet.getCells(1, function(err , cell_array){
            cell_array[index].setValue(value, function(err){
                if(err){
                    console.log(err);
                    console.trace();
                }else{
                    console.log("success!");
                }
            })
        });
    };

Is the code I'm using when getting this. The stack trace is as follows
at /Users/joshmcgrath/Documents/Git/spellingbee/app.js:94:29
    at Request._callback (/Users/joshmcgrath/Documents/Git/spellingbee/node_modules/google-spreadsheet/index.js:129:20)
    at self.callback (/Users/joshmcgrath/Documents/Git/spellingbee/node_modules/google-spreadsheet/node_modules/request/request.js:123:22)
    at Request.emit (events.js:95:17)
    at Request.init (/Users/joshmcgrath/Documents/Git/spellingbee/node_modules/google-spreadsheet/node_modules/request/request.js:137:17)
    at new Request (/Users/joshmcgrath/Documents/Git/spellingbee/node_modules/google-spreadsheet/node_modules/request/request.js:99:8)
    at request (/Users/joshmcgrath/Documents/Git/spellingbee/node_modules/google-spreadsheet/node_modules/request/index.js:54:11)
    at async.series.request (/Users/joshmcgrath/Documents/Git/spellingbee/node_modules/google-spreadsheet/index.js:122:9)
    at /Users/joshmcgrath/Documents/Git/spellingbee/node_modules/google-spreadsheet/node_modules/async/lib/async.js:735:13
    at iterate (/Users/joshmcgrath/Documents/Git/spellingbee/node_modules/google-spreadsheet/node_modules/async/lib/async.js:253:13)

Willing to help if you can point me in the right direction.

Did you find a solution for this? I'm having the same problem with an extremely simple use case where I just set a value and then .save(callback). Any ideas?

Hi @josmcg , I think we moved to https://github.com/theoephraim/node-google-spreadsheet/issues/90 ;)


Guidance on how to create IconVG file

Thanks for you efforts.
Really looking forward to official Flutter support!
Just out of curiosity how would those files be created?
Are all files at this point handcrafted or is there some library already to generate those from SVGs?

The old Go library has an Encoder, although it's fairly low level and makes more sense if you've already read the IconVG spec.
https://github.com/golang/exp/blob/b47a03e3048a16e5877dea02cf86e143e549fc46/shiny/iconvg/encode_test.go has some examples.
Please also note that the file format may change soon (issue #4).

I think the underlying question here is how would you go from a deisgner's drawing to IconVG?
Is there/are there canonical tools for doing this? Are certain formats supported or not?
I imagine, for example, it would be interesting to convert SVGs (or some subset of SVGs) to IconVG. It would also be interesting to export IconVG from Adobe Illustrator or Inkscape. However, there are a significant number of things the SVG spec supports that IconVG doesn't, and it grows further when you add features/extensions from Inkscape or Illustrator or whatever other graphic design tools might exist.
@IchordeDionysos - it would probably be interesting to know what icons you want to encode as IconVG and what format(s) they currently exist in.
It might also be interesting to take an existing SVG renderer and adding an IconVG backend to it, although it might get confusing/frustrating for people who find that it doesn't support particular things.

Is there/are there canonical tools for doing this?

Today? No. Only ad-hoc programs like https://github.com/golang/exp/blob/master/shiny/materialdesign/icons/gen.go to turn the 2016-era Material Design icons from SVG to IconVG. But that only needed to parse a very, very small subset of SVG. (That a very, very small subset is still useful is kind of the point of IconVG, and I'd expect some SVG features like embedding a <foreignObject> video to simply be unrepresentable in any current or future version of IconVG).
In the future, I'd certainly like Illustrator and Inkscape to both have a one-click "Export to IconVG" the same way they currently have "Export to PNG", but somebody's got to create the tools first...

An inkscape extension must first have something written in python. I haven't seen an code here in python, so that makes such a process harder. Though inkscape has many export formats, so there are many examples of how to achieve the extension.
Once one is made there is a process by which it can be accepted into the inkscape package itself, if the project wants this format supported by default.  Further advice can be found at https://chat.inkscape.org/channel/inkscape_extensions and examples at https://gitlab.com/inkscape/extensions/-/tree/master


experiment.stats() error

My experiment instances do not have a stats() method so I cannot access the stats engine results

Any update on this please?

@HarrietMuncey -- apologies for the delay. The stats() method should be available on the Experiment object... if you uninstall the optimizely module, then reinstall it fresh, are you still unable to use the stats() method? If so, can you share a stack trace?

@jgaul I have uninstalled and reinstalled several times but it doesn't fix it. Please see below:
AttributeError                            Traceback (most recent call last)
 in ()
1 import optimizely
2 client = optimizely.Client(optimizely_api_token)
----> 3 client.Experiments.get(4883971194).stats()
AttributeError: 'Experiment' object has no attribute 'stats'

@HarrietMuncey I double-checked this, and I'm confident this would work with the latest version of the library. perhaps you're installing the latest version to a different Python environment then the one you're actually running your code from. can you capture the optimizely.__file__ for the imported optimizely module, then zip up the `optimizely

optimizely.zip

thanks @HarrietMuncey! so i used the version of the library that you provided, which does look like the latest version, and i didn't have any issues... is there a chat client you use that i could chat with you live over?

I just tried it again and it seems to work! Very bizarre.

@HarrietMuncey -- ah, i'd guess somehow you were using an older/cached version of the lib. good to hear you're in business!

Thanks for your help anyway!

sure thing!


Added default icon for links

Closes #549
Added default icon if the icon not found in PrimeReact
Before:

After:

If any suggestions for the default icon plz comment down

Hey there @Kunal0007 👋 Just checking in, do you need any help?

Hey there @Kunal0007 👋 Just checking in, do you need any help?

Hello 👋, As I told in the above comments this issue can't be solved https://github.com/EddieHubCommunity/LinkFree/pull/579#issuecomment-951792586.
We have to change the icon library. So, I think I should close this PR. Should I close it?

Yeah sure :D

Yes, i think we should close the PR and make changes in a newer PR, with an icon library/set of our choice.
Thanks for contributing to LInkFree!


Datafit v1.0.0

First full release of datafit
Includes all relevant documentation
Should be bug free!

Closes #36


Amend Roles Page

We should amend the roles page to include the ability to edit the values for

session_timeout
password_mandatory
password_lifetime

8bf9c4c10cb98e834ba3e96da038db9b1be7bbf2


Doesn't seem to work in console

Hi,
I'm trying to download some files by running the script from the console on a server without GUI (via ssh). I can't pass the google authentication: it opens the text-based console browser, and asks for email & password, and then fails due to JavaScript not being supported.
Could you tell me whether it is possible to use the script without GUI?
[I've enabled Google Drive API; copied credentials.json to the working directory; installed all the packages]

Hi,
I only test it under the GUI environment, but I guess it could work if you first run the script on your host machine that has GUI (and do the authentication with your browser), and copy the token.pickle file, which is the authentication file, to remote server.
See if it works, thanks!

It worked perfectly, thank you!


Feature: Don't care/anonymous parameter

Many functional languages have a don't care parameter/variable that holds values not used by programs.
For example, a function like Array.prototype.forEach supplies three arguments to the callback. If the code only needs the second argument (index), it will still have to supply a name for the first one. The programmer can use a don't care parameter as the name of the first argument instead. This improves readability and avoids problem of accidentally shadowing.
An additional keyword/comment may have to be introduced to define which string is used for this purpose as the traditional "_" happens to be used by the popular underscore library.
This can also be extended to destructuring code.

Just thinking aloud -- would arr.forEach(( , index) => console.log(index)); look too much like a typo?

I think so. Also, when commas stack up they get hard to count.

I agree with @sandersn. How about arr.forEach((void, index) => console.log(index));?
Just the first thing that came to mind. Correct me if I'm wrong, but I think this doesn't lead to a conflict with the ES spec as it would be a part of the type system.

Does the already-supported workaround of _, __, __, ... suffice?

Maybe _ could be special cased, so that you can use it multiple times, then __ and ___ wouldn't be needed.
(_, __, x, ____) => x + 1

Would become
(_, _, x, _) => x + 1

How about ??  For example: (?, x, ?) => x + 1.
Given that _ is a valid identifier name, I don't believe it is appropriate to use here.

You could just use an empty binding pattern like[] or {}.
arr.forEach(({}, index) => console.log(index));

arr.forEach(([], index) => console.log(index));

@DanielRosenwasser nice :+1:

@DanielRosenwasser Sounds perfect. Would be nice if this special use case is documented though.

@DanielRosenwasser Great, thanks.


Windows support

My current understanding of Windows support for this tool is:

developers on Windows would need to have Cygwin or MinGW + autotools installed
users on Windows would need to have Cygwin or MinGW without autotools installed

Is this correct?

cc @texhex
Thoughts?

Correct.  This will also be supported on the Linux subsystem for Windows.
As a Cygwin user myself, I'll be targeting that most closely because I think it presents the easiest option for users and developers alike.  It has a simple GUI installer that takes just a couple of clicks to select git, make, automake, autoconf, python, gcc, etc. packages.  Couple clicks later and you're in a shell where you can 'git clone; ./configure; make; etc.'.

Couple clicks later and you're in a shell where you can 'git clone; ./configure; make; etc.'.

👍


DivineMC rework

So, I've started to rework DivineMC because old patches may be broken and needed to be updated.
I want to make server more optimised and have functions to configure it. Also I will add non-vanilla functions and it can be disabled/enabled in divinemc.yml.
Release ETA: 10-16 April
Stay tuned!

Will be merged soon


[feature]hive sql support

is there any plan to support hive sql

I don't have immediate plans to implement Hive SQL support, but I would welcome the contribution.
The first step would be to add Hive SQL support to modeldba/antlr4ts-sql, there is a grammar available here if you or anyone else is interested in adding it. More details on building grammars is available in the documentation.


Nested routes doesn't mounting after router push named-routes

Version
2.6.0
Reproduction link
https://codepen.io/shubich/pen/MGWoMR
Steps to reproduce
click button "work" and "doesn't work"
What is expected?
Nested routes mounting after router push named-routes
What is actually happening?
Nested routes doesn't mounting after router push named-routes

You have to name the child route

@posva how?

add a name in the child route as well and use that one in the push 🙂

Please, next time consider using the forum, the Discord server or StackOverflow for questions first


showSpinner dinamically

Bug description:
i was looking on the code and detect that the attribute showSpinners, only work when load the directive, and is unable to trigger dinamically with click from a button or else, i do some hack
and put this code
$scope.showSpinners = timepickerConfig.showSpinners;
if ($attrs.showSpinners) {
watchers.push($scope.$parent.$watch($parse($attrs.showSpinners), function(value) {
$scope.showSpinners = !!value;
    updateTemplate();

}));

}
/$scope.showSpinners = angular.isDefined($attrs.showSpinners) ?
$scope.$parent.$eval($attrs.showSpinners) : timepickerConfig.showSpinners;/
and work like a charm.
i know this is not the best solution, i hope theres is a better one that can use provider from this comunity. Greetings.

Hi, there's a pull request that solves this in a more elegant way. check it out: https://github.com/sykes10/bootstrap/commit/6a9c72a6a194d58d3d2850c2cefa0f4c839f9f1c

lol i suggested that solution in stackoverflow for the user who post the issue .lol but great if fixed.

It's me. 😁😁😁
On Fri, 28 Jul 2017 at 20:00, wkJesus<EMAIL_ADDRESS>wrote:

lol i suggested that solution in stackoverflow for the user who post the
issue .lol but great if fixed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/angular-ui/bootstrap/issues/6605#issuecomment-318722366,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKFp2BRNznFxIDhybYHNHKx2LlKgoZeeks5sSiG6gaJpZM4OllpH
.


x509 certificates that could be read in 1.8.1 can no longer be read by 1.8.3

I'm having some difficulty with certain x.509 certificates, when reading with version 1.8.3 - manifesting in an Exception that was introduced as part of an 'extra data' check.
I believe the change the effects us is https://github.com/bcgit/bc-csharp/commit/374564ba8b2b385c90633679aae9cca27d0bb069
It appears to be related to a version number and a subsequent check for 'extra data' - which fails.
Here is a typical stack trace of 1.8.3 during certificate read:
Org.BouncyCastle.Security.Certificates.CertificateException: Failed to read certificate ---> System.ArgumentException: version 1 certificate contains extra data
at Org.BouncyCastle.Asn1.X509.TbsCertificateStructure..ctor(Asn1Sequence seq)
at Org.BouncyCastle.Asn1.X509.TbsCertificateStructure.GetInstance(Object obj)
at Org.BouncyCastle.Asn1.X509.X509CertificateStructure..ctor(Asn1Sequence seq)
at Org.BouncyCastle.Asn1.X509.X509CertificateStructure.GetInstance(Object obj)
at Org.BouncyCastle.X509.X509CertificateParser.ReadDerCertificate(Asn1InputStream dIn)
at Org.BouncyCastle.X509.X509CertificateParser.ReadCertificate(Stream inStream)
--- End of inner exception stack trace ---
at Org.BouncyCastle.X509.X509CertificateParser.ReadCertificate(Stream inStream)
at Org.BouncyCastle.OpenSsl.PemReader.ReadCertificate(PemObject pemObject)

Here is an example of a certificate that causes the exception:
-----BEGIN CERTIFICATE-----
MIIDAjCCAeoCFB+M5Oi9qfGrPikV/d44DfLCVMDuMA0GCSqGSIb3DQEBCwUAMC4x
CzAJBgNVBAYTAlVTMQwwCgYDVQQKDANYWFgxETAPBgNVBAMMCE15IENBIFYzMB4X
DTE4MTAyMzA4MjQzOFoXDTI4MTAyMDA4MjQzOFowLjELMAkGA1UEBhMCVVMxDDAK
BgNVBAoMA1hYWDERMA8GA1UEAwwITXkgQ0EgVjMwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC2ATfFRW9oM3Yz10EEIVcRlOnfPsQQBT9Z7GKuP5MKZAI1
CHX9ujf1A/EeKBHtCTU5q7TLtRIpAfFVJj7KynSqcN9SzXBvvyIX82VienV4S4XK
ywiY0yfmeVFZy2IQz2o5vm+Al+jzBm200rwPtadHy0z4xsLy7ly1K1fd828Ui9pB
nCaeuoih4n2GSpqgNIHnlkHGwmWYeryveXpSsWJYodQroNl89usHqRXlH0alVpQs
Tfk+LNoiDGwTdRZFeLYo/Rqw0iSvCNgSULrK2TpT4ZNHe6HIr9I2t9fNUvf0J9bG
EJrL1K7Gh2V85dcYBs/0Nh+eFs7Hp5Ua0JlxCufjAgMBAAGjHTAbMAwGA1UdEwQF
MAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBCwUAA4IBAQASQ6195ALx1Mfs
ZXF5OqBKC6DR0d4UC/pxth5xpl5wM5FpiH/bMUIqzKLEvyV3ZMZ4UyPC+tn5k+gs
HAwUJpZDKKmzhgZbmeuwNbRk3H5NRjQ3do2jwneDdIGAI8DtjOlEOtbkfO0xDxP/
UM7EUt3/Lk6SxPhoDep7MdkWzJkpjzPzz3UO/nGNTfGOJza2pTIV+h7oKGpnxkdX
4oJOLBa1C4ONDQQOCYpC2O+66p/j5YGIY/ifuxviPItYk8DZR2YgNC7vRuVMBXAz
wY48OlOW+ybmolmMO4Hg19BT45zJLEqF/Sju+e+QZHMHTe5jen76cA3RZxdQ656w
wj47Z+DO
-----END CERTIFICATE-----

I can share some code that was used to generate this certificate if that aids tracking down the issue.
This certificate can be read in 1.8.1:

The windows certificate store and openssl seem to be OK with this certificate, so I'm hoping that I could get some advice on whether there is something wrong with this certificate, or if there is an issue in these new checks that needs further thought?
Thanks!

The issue is that the (absent because == default) version indicates a V1 certificate, but there are extensions present (the "extra data") in the ASN.1 sequence, which is a feature added for V3. Given that the purported issuer is "My CA V3" I would guess the certificate creator was trying to create a V3 CA cert, but the version was not set correctly.

Thanks @peterdettman I can confirm that by explicitly setting a version number using the code sample I have, it now passes the validation check and correctly identifies the certificate as a V3 certificate.

Hi @peterdettman I'm a software developer for a consulting company. We are currently building a medical system for the Red Cross Blood Service in Australia that manages organ transplants. We rely on on software that @jburger produces to deploy our application. When our application goes into production next year, it could result in life or death if it does not function correctly or we are blocked from deploying critical fixes.
For this issue, I consider it irresponsible to deploy a breaking change for a minor release from 1.8.1 to 1.8.3 that could have potential downstream effects. We're lucky in this instance that the affected certificate (which does have a configuration error) is currently not in use and that our system is not in production yet.
If a breaking change like this is implemented, there should be the option to revert to the old behaviour with some flags in the method calls in order to support existing artefacts. Environment such as ours could require advanced warning and time to sort this out and regenerate certificates.
Our client is very sensitive to any defects, especially those that could bring our software "assembly line" to a halt.
Hoping this can be addressed soon!
Thanks!

Hi Larry, I've no doubt @jburger will be able to fix his software. We're happy to hear that this change has avoided invalid certificates from being deployed to production. I would stress that we are not the only people who have been tightening up validation on these.


Implement API to communicate with Twitch extension

Implements API that allows displaying PowerTips on Twitch for streamers using SlayTheRelics Twitch extension

The TwitchExtension allows to display the actual PowerTips of Memories and the Snap Counter on stream

The data is shared through two static ArrayLists: slayTheRelicsHitboxes, slayTheRelicsPowerTips

The specific properties are looked up (by name) by the SlayTheRelicsExporter mod (in all classes that have @SpireInitializer), if they are found, they are checked frequently and their contents are sent over to a server that communicates with Twitch

Here, during every update of the Wanderer both ArrayLists are cleared and refilled. This is perhaps not the most optimal approach but probably the simplest with the smallest footprint. Impact on performance should be negligable.

Documentation for the API will be available soon (tm), the extension is expected to be released within 1-3 weeks (2020/4/5 - 2020/4/19)

The changes have been tested reasonably with mentioned mod and extension directly on Twitch.

Please hang on. This works fine when one has loaded only the Wanderer mod, problem arised when I loaded Poker Player as well and tried to play it. The problem is that MemoryManager constructor and update calls are patched directly into AbstractPlayer. This means that when the PokerPlayer instance is created, it contains MemoryManager and in each update step it adds its memories to the TwitchExtensionAPI. The shared list gets emptied at the beginning of each update in the Wanderer class but it doesn't get emptied every update in the PokerPlayer class, that's why it grew indefinitely. But in other characters this code should not even be called at all. This would probably be the same case even with the base game characters, they will have the MemoryManager patched in as well, I believe.
Do you have suggestions on how to fix this behavior easily?
My idea is to make all the used properties public (MemoryManager.memories, SnapCounter.tips, SnapCounter.hitbox) and do the whole TwitchExtensionAPI update in a single place - in the Wanderer update() function instead of it being delegated to multiple places.

I would recommend doing it in the other direction and avoiding having Wanderer be responsible for any aspect of managing the memory hitbox/tip lists; MemoryManager is patched into AbstractPlayer rather than being a member of Wanderer intentionally because it is possible for non-Wanderer classes to be rendering memories (in particular, CULL always renders one memory, and any class which somehow gains access to a Wanderer card via Prismatic-Shard-like shenanigans will start rendering those memories which are currently active).
I do think it makes sense for the individual things with hitboxes/tips to be responsible for making the decisions about whether they should be rendered or not, same as they're responsible for determining whether they should be rendered on screen or not. Personally, I would probably lean towards something like:
@SpireInitializer
public class SlayTheRelicsIntegration {
    public static ArrayList<Hitbox> slayTheRelicsHitboxes = new ArrayList<>();
    public static ArrayList<ArrayList<PowerTip>> slayTheRelicsPowerTips = new ArrayList<>();

    public static void initialize() {
        BaseMod.subscribe((PreRenderSubscriber) () -> SlayTheRelicsIntegration.clear());
    }

    public static void clear() {
        slayTheRelicsHitboxes.clear();
        slayTheRelicsPowerTips.clear();
    }

    public static void renderTipHitbox(Hitbox hb, ArrayList<PowerTip> tips) {
        slayTheRelicsHitboxes.add(hb);
        slayTheRelicsPowerTips.add(tips);
    }
}

...and then have AbstractMemory::renderTip and SnapCounter::render be responsible for calling SlayTheRelicsIntegration.renderTipHitbox appropriately.

What you suggest seems like a good approach. It lead to a lot less code than in my original implementation and is more general - works even on other characters using jorbs-mod cards.
New iteration of changes discussed in #485
Closing this PR.


Add word-break modifier for table cells

This adds a nhsuk-table__cell--break-word modifier which can be used on table cells where there is a risk that they contain such long content that the table might otherwise overflow its container and cause horizontal scrolling.
This is particularly possible for email addresses, as the full stop character in email addresses is not a break point.
The modifier is opt-in though, as in other scenarios where the content is more predictable, you likely wouldn’t want table cells to break mid-word.
In order to enable this I’ve added support for classes on table cells. There is an existing format option used for nhsuk-table__cell--numeric, but classes is more flexible (for example allowing custom modifiers and more than one class), and this doesn’t feel like a "format".
I’ve also refactored the Table nunjucks macro to reduce duplication.
Screenshots

Before
After

The GOV.UK Design System, has govuk-!-text-break-word, a general utility class that can be applied anywhere. Can we not do the same here?
(Agree to allowing classes on table cells, been hacking my way around this for a while)

@paulrobertlloyd that class uses overflow-wrap: break-word (and the non-standard word-wrap: break-word for older browsers) which doesn’t seem to work for table cells unless they’ve been given a fixed width.
Both word-break: break-all and overflow-wrap: break-word seem to have the same definition, so why they behave differently is a bit of mystery - I guess something down to the box model calculations for flexible tables? 🤷

@frankieroberto could it be a more generic modifier as @paulrobertlloyd suggests, but use a different method when inside a table cell?

I like @edwardhorsford's suggestion.
On service manual website we have added these locally:
// Helper to break long words/URLs in tables
.nhsuk-table__cell--break-all {
  word-break: break-all;
}
.nhsuk-table__cell--break-all--tablet {
  @include mq($until: tablet) {
    word-break: break-all;
  }
}
.nhsuk-table__cell--break-all--desktop {
  @include mq($until: large-desktop) {
    word-break: break-all;
  }
}

But a more generalised class would be even better.

@anandamaryon1 @edwardhorsford @paulrobertlloyd I've updated this PR to change the modifier class from the a table cell modifier to add 2 generic modifiers:

.nhsuk-u-word-break-all - uses word-break: break-all;
.nhsuk-u-word-break-word - overflow-wrap: break-word;

The difference is subtle but crucial. word-break: break-all will only break the word if it absolutely has to, whereas overflow-wrap: break-word will break the word as soon as the word overflows its container and won’t try to avoid it by moving the word onto its own line.
The MDN word-break article has good explanation and examples:

The only reason to use the word-break: break-all over the other one is where the container doesn’t have a defined width (or something) - ie it doesn't work in tables unless the table column widths are defined.

I think I’ve got this right but happy to be corrected if I'm wrong! 🤯

Would it be grotesque to have just .nhsuk-u-word-break and style it so that when used within a table, it switches to use break-all?

Would it be grotesque to have just .nhsuk-u-word-break and style it so that when used within a table, it switches to use break-all?

I considered that, but potentially there are other use-cases for .nhsuk-u-word-break-all (eg a custom component with flexible widths?), and also you might still want to use nhsuk-u-word-break-word in a table if your table is using fixed (or percentage-based) widths?
That said, explaining the difference between the 2 options is really tricky and it took me ages to get my head around it...

Ok thats fair @frankieroberto . I'll approve once tests are successful.

I wonder also about having the single, simpler form, and then if teams need something more specific they could just use their own css?


Fixes to the Abortable fetch article

What's changed, or what was fixed?
In the Abortable fetch article,

Replaced "that" with "what" in "[...] do that the user asked".
Added white space in a code snippet to improve readability.
Added a missing comma.

CC: @petele

:tada: This has been pushed live to https://developers.google.com/web/


[DOC SUGGESTION] Example Suggestion

Doc Page Links
https://cs.spatial.io/api/SpatialSys.UnitySDK.SpatialBridge.html
Explain Suggestion
Show an example of using the bridge
Code Suggestion
void Start()
{
    SpatialBridge.coreGUIService.DisplayToastMessage("Hello World");
}

Contribution Credit
alanSherba

closed


Update sbt-typelevel, ... to 0.5.2

About this PR
📦 Updates

org.typelevel:sbt-typelevel
org.typelevel:sbt-typelevel-ci-release
org.typelevel:sbt-typelevel-github-actions

from 0.5.0 to 0.5.2
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.typelevel" }
}]

labels: sbt-plugin-update, early-semver-minor, semver-spec-patch, version-scheme:early-semver, commit-count:n:2

Superseded by #22.


rebase

fixing issues with sync between fork and upstream

changes needed for the update are already applied to the master branch. the update branch will now be deleted


Sources are lists of Components

This PR simplifies the counting of components in Blend and allows grouping multiple Components into Sources. This encodes our existing terminology of sources as collections of components.
Formally:

All content (sed, morphology, center) as well as the constraints (including fix_...) are held exclusively by Component.
On the other hand, Sources can then implement additional operations to update the component centers, seds, and morphs after each iteration.

The advantage is that we can now build flexible multi-component sources that are aware of the state of all components in a source.
See also #49.

Because this branch is forked off from matrix_adapter, it's easiest to merge PR 52 first.

Components can now be grouped hierarchically into a tree. Then it hit me: Blend doesn't just have such a tree, it is such a tree (with additional methods). Commit forthcoming.

I discovered a bug in the source creation code, which I would like to iron out. Now that we separated Component from Source, we can break the interdependence we had in Source.__init__, which will make it much less confusing to make custom sources. Hold off the merge until I get that commit in.

Everything looks good. But do we have enough users that we should start a changelog.rst file to keep them informed of changes in each sub version?

not a bad idea. for sphinx?

I was thinking of something like astropy and photutils use, for example this changelog.


[🔥AUDIT🔥] Update to latest octokit API

🖍 This is an audit! 🖍
Summary:
The Octokit API has changed, so things are now off a rest endpoint. I must admit, I gave up on the flow types management and just installed the latest version from flow-typed which is next to useless. TypeScript upgrade would be nice right now.
I went in favour of getting things working instead. I can reinstate better typing at a later date if folks think I should.
Issue: FEI-4813
Test plan:
yarn test (but these don't really test what we need to here so got to release it to main to find out).

Hello, was just stalking around flow-typed usage and came across this PR. I'm a flow-typed maintainer and I'm sorry the rest types weren't up to standards 😢 I added them myself and added just enough type definitions for my own needs.
My hope was that people who needed more than my initial use case would contribute back but I understand that it's sometimes a large ask considering how easy it is on the Typescript side.
I'll try look into further improving these types over the next couple weeks, hopefully that helps 🙏

Hello, was just stalking around flow-typed usage and came across this PR. I'm a flow-typed maintainer and I'm sorry the rest types weren't up to standards 😢 I added them myself and added just enough type definitions for my own needs.
My hope was that people who needed more than my initial use case would contribute back but I understand that it's sometimes a large ask considering how easy it is on the Typescript side.
I'll try look into further improving these types over the next couple weeks, hopefully that helps 🙏

Thanks for the work, @Brianzchen. I did not intend to be dismissive of your effort; I am sorry for doing that. My frustration was showing. 🙏🏻