BREAKING CHANGE: useMutation returns tuple with result

Closes #90
Just a draft, for now, to gather some opinions before I dive into fixing tests and documentation. There are probably some mistakes, but I don't want to invest too much time in it before other people chime in.
The whole thing is sort of ripoff from Apollo's Mutation component converted to the Hooks. I've omitted a couple of things from there as those can be added later without breaking anything.

ignoreResults prop
onComplete & onError callbacks

I was thinking about this a lot. A major concern is how it fits into a whole Suspense & Error Boundaries (#28) paradigm. I mean it would be kinda nice to utilize that and have the same approach. However, mutation use cases are different than queries.
Considering simplest one...
const MutantComponent = () => {
  const [mutateMe, { error, loading }] = useMutation(MUTANT)
  return (

    <button disabled={loading} onClick={mutateMe}>I want to be a mutant</button>
    <ErrorDisplay error={error} />

}

Since Suspense is not really ready, let's not worry about that (although it's a similar problem). But could we utilize Error Boundaries here? The error would be thrown within a onClick event handler and error boundary would do what? Throw away the component and replace it with some "there was error" and "retry" button? Doesn't feel like good UX. So I am kinda convinced that we need to be handling it on more granular level like I've drafted above.
@gaearon Would be lovely to get your opinion here if you can.

I just realized, since mutations are async, a thrown error cannot be caught by error boundaries 😢
One of the actual use cases where propagating error toward closest error boundary is displaying such error as a toast or even sending a report to some service. Such scenarios can be nicely generalized and component code gets a bit cleaner.
So I've decided to implement an experimental approach which would throw the error synchronously by default. If anything, it gives much better error stack instead of just "unhandled rejection". And it can be switched off by throwAsync option if a need for a more granular error handling arises. Let me know what you think.
I've tested it by hand and it works nicely. Even without error boundary the error is thrown by React, it doesn't get lost anywhere. Only caveat is that whole component tree is thrown away in that case, but error clearly states to use error boundary, so I wouldn't be too worried about it.

@trojanowski I would love to hear an opinion from you if I should continue with adding tests/docs or it's something you don't want to merge at all.

@FredyC the current form of useMutation was enough for me - I have usually used it in conjunction with Formik, where the loading and error state was stored. But I agree that there are many use cases where the implementation suggested by you makes perfect sense (maybe with the exception of the error handling). It would also make it easier to port code which used the <Mutation /> component from react-apollo. Few comments:

Since Suspense is not really ready, let's not worry about that (although it's a similar problem).

Actually, I can't see how Suspense would be helpful here.

But could we utilize Error Boundaries here?

So I've decided to implement an experimental approach which would throw the error synchronously by default. If anything, it gives much better error stack instead of just "unhandled rejection" inside of Apollo. And it can be switched off by throwAsync option if a need for a more granular error handling arises. Let me know what you think.

I don't think an error should be thrown at all by default. In my use cases, I needed access to the error as a part of the response, so I'd always had to disable this behavior. E.g., please look at the following code:
<Formik
  onSubmit={async (values, { setErrors, setSubmitting, setValues }) => {
    let response;
    try {
      response = await performMutation({ variables: { input: values }});
    } catch (error) {
      setErrors(getValidationErrors(error));
      NotificationManager.error('Cannot perform mutation');
      return;
    } finally {
      setSubmitting(false);
    }

    setValues(mapResponseToFormValues(response.data.myMutation));
    NotificationManager.success('Mutation completed');
  }
/>

Actually, I don't see a scenario where throwing them would be helpful. For cases where I think the rest of this PR would be useful (e. g. an easy possibility of re-running a failed mutation) it'd be better to not lost the state of the component which error boundaries would cause.

Actually, I can't see how Suspense would be helpful here.

Yea, without a full picture how Suspense for data fetching will look like, I cannot imagine it either :) It pretty much boils down to eg. disable submit button which is very similar operation to showing spinner on data fetching.

Actually, I don't see a scenario where throwing them would be helpful.

One of the actual use cases where propagating error toward closest error boundary is displaying such error as a toast or even sending a report to some service. Such scenarios can be nicely generalized and component code gets a bit cleaner.

Error boundary does not always mean you have to render some placeholder UI, it can be really just to collect errors and do something different with those. The challenge could be that the error boundary does not give much of context if it was thrown from mutation or a failed query which might require a different approach.
Anyway, if you look closer at Mutation component, it already does throw by default, but since it's async code, it ends up as unhandledRejection which is not really helpful. I only turned it around so it throws synchronously, but can be turned off.
I guess Formik is not ready for this hooked world with such imperative API. If something like this would work, it would certainly clean up a lot of things. It's fairly contrived, but you get the gist :)
const [performMutation, { data, loading, error }] = useMutation(...)
<Formik
  isSubmitting={loading}
  errors={getValidationErrors(error)}
  values={mapResponseToFormValues(data)}
  onSubmit={async (values) => {
    await performMutation({ variables: { input: values }});
    NotificationManager.success('Mutation completed');
  }}
/>

@FredyC thanks for your work. When are you going to release this ? :)

@lotsoftick I am kinda waiting for more opinions. There are still no tests and docs and I don't want to put an extra effort into before it's clear that it's wanted change.

@FredyC i think this is crucial, and must be done.
const [mutateMe, { error, loading, data }] = useMutation(MUTANT)

Ok, I agree with that, but what about error handling part? Should it throw by default? The current behavior means you have to explicitly do this for every mutation call.
const MutantComponent = () => {
  // using the new option here which represents current behavior
  const [mutateMe, { error }] = useMutation(MUTANT, { throwAsync: true })
  const mutateMeSafely = (...args) => {
    mutateMe(...args).catch(handleError)
    // or use async with try/catch which would way more verbose
  }
  return (

    <button disabled={loading} onClick={mutateMeSafely}>I want to be a mutant</button>
    <ErrorDisplay error={error} />

}

Compared to new default behavior from this PR the error is thrown synchronously which means it can be caught by error boundaries and sent to reporting service in a universal way without doing it every time the mutation is called. But it's still possible to grab the error from result and render it if that's what's required.
const MutantComponent = () => {
  const [mutateMe, { error, loading }] = useMutation(MUTANT)
  return (

    <button disabled={loading} onClick={mutateMe}>I want to be a mutant</button>
    <ErrorDisplay error={error} />

}

Personally, I don't really mind which behavior goes by default as it's easy to wrap it into a custom hook. But I am trying to provide a best default experience.

The error boundaries still need a class component, but it's easy to have a single one like this sitting on top of the tree.
class ErrorBoundary extends React.Component {
  componentDidCatch(error, info) {
    // Report error, show the toast, whatever you like...
    logErrorToMyService(error, info);
  }

  render() {
    return this.props.children;
  }
}

By directly rendering the children, no UI gets lots or remounted. It really just to catch that error in universal way. And best part is that you can make different customized error boundary, use it lower in the rendering tree to customize experience for a specific part of the app.

i prefer the first option, without Error Boundary

@lotsoftick Do you care to elaborate why? I am wondering if you are seeing some benefit there that I am missing.

mutation request may fail because of validation, let's say with error status 422 and with error messages  for each field in the body. I understand that this is can be done using ErrorBoundary as well, but basically my components look like this:
const RoutComponent = ({ params, history }) => {
  const { loading, error, data } = useQuery(GET_LIST);

  return (
    <Fragment>
      {params.id &&
        <EditModal id={params.id} closeModal={() => history.goBack()} />
        /* show modal form over the table   */
      }
      {error &&
{error.message}
}

        ...
        {data.map( /* render data */)}
        ...

    </Fragment>
  )
}

const EditModal = ({ id, closeModal }) => {
  const { loading, error, data } = useQuery(GET_ITEM, { variables: { id }}); // getting item data
  const [mutator, { loading: updating, error: updateError }] = useMutation(MUTANT);

  const submit = async (e) => {
    await mutator(formData);
    closeModal();
  }

  return (
    <Modal>
      {error &&
{error.message}
} {/* show error if can't fetch item data */}
      {updateError && updateError.status !== 422 &&
{updateError.message}
} {/* show error if something went wrong during update. But error is not validation */}
      <ValidForm
        className={classnames({ loading: loading || updating })}
        onSubmit={submit}
        showValidationError={updateError.status === 422 ? updateError : null} {/* in case if data vas invalid show validation errors for each filed */}
      >
        {/* ... render inputs */}
      </ValidForm>
    </Modal>
  )
}

I see that I still haven't explained it well enough. You can do exactly that with this PR and default sync throw.
You will always get the error as the result from useMutation, that's for the fact and you cannot prevent that behavior.
Think of that sync throw as a bonus. A unified way of catching all mutation errors at one place (error boundary) and ideally reporting them to some service so nothing is going to escape your attention. Without it, you will only get unhandledRejection which you would need to catch manually for every single mutation call.
Is it better like this or am I really bad at explaining it? :)

@FredyC thanks, it's clear. Both will work for me, so, just use second one (
sync throw) as default :)

This is amazing, when are you able to merge @FredyC 	? 🚀

@guilhermedecampo Would love to get it out soon as well, but I am kinda fighting with tests.
Also @trojanowski doesn't seem to be convinced about it, so I hope he won't reject it later :)

@FredyC

Error boundary does not always mean you have to render some placeholder UI, it can be really just to collect errors and do something different with those.

About collecting errors and sending them e.g. to Sentry - I don't think I'd like to send there any of errors being a result of invoking a mutation. They can belong to one of these groups

network connection errors, e.g. if the user is online
server-side resolver errors - they will be sent by a server Sentry integration
predefined Apollo errors - they are like 4xx HTTP errors

The challenge could be that the error boundary does not give much of context if it was thrown from mutation or a failed query which might require a different approach.

I can see that you already tried to solve it in https://github.com/trojanowski/react-apollo-hooks/pull/93/commits/cf7b8b310af182fee37f52af3bb6ad5ad5058ed2. One suggestion - you can use an internal Symbol here as a marker.

Anyway, if you look closer at Mutation component, it already does throw by default, but since it's async code, it ends up as unhandledRejection which is not really helpful.

It just simulates the behavior of apolloClient.mutate(). It's just like:
try {
  const result = await client.mutate(...);
  doSomethingWithResult(result);
} catch(error) {
  throw error;
}

unhandledRejection can also be sent to an error collecting service, but as I said above, I don't think it's a good idea. In my opinion async errors works best if you try/catch them manually, like in the Formik example in my previous comment.
My idea is to replace throwAsync option with something like throwMode. It could have 3 possible values:

sync - the behavior in the current version of react-apollo-hooks. It works well in almost all cases for me. I think it should be the default value.
none - don't throw errors at all, just set the value of the error state. That way we'd have something like an "internal" error boundary. We could check the presence of the error and, e.g. show "Try again" button.
async - the default behavior in the current version of this PR. I actually don't see too much use cases for it (which wouldn't be solved by the none throw mode).

@trojanowski doesn't seem to be convinced about it, so I hope he won't reject it later :)

I like the API. I'm just not sure about the error handling part.
@umidbekkarimov @rosskevin what's your opinion about it?

About collecting errors and sending them e.g. to Sentry - I don't think I'd like to send there any of errors being a result of invoking a mutation. They can belong to one of these groups

server-side resolver errors - they will be sent by a server Sentry integration

Yea, I do care about those errors and I want them in client-side Sentry simply because there might some relevant app state that can help figure out an issue. Perhaps I've sent wrong variables and I would like to know why and how it happened.

I can see that you already tried to solve it in cf7b8b3. One suggestion - you can use an internal Symbol here as a marker.

I am not sure if there some real benefit to it. I got inspired by ApolloError and how is the isApolloError implemented :)
The throwMode.none feels pretty much useless because you cannot render any UI from the hook. Someone might misunderstand, use it and the errors would be suddenly lost unless they manually check the error in every mutation call. It's fairly dangerous mode to have there. I would rather not.

I have a slightly different idea. We can have sync mode by default, but we can export something like this from the package.
const throwModeContext = React.createContext()

class ErrorBoundary extends React.Component {
  componentDidCatch(error, info) {
    console.error(error)
  }

  render() {
    return <throwModeContext.Provider value="async">{this.props.children}</throwModeContext.Provider>;
  }
}

This way it's possible switch the mode not globally, but for that part of tree where we actually know there is an error boundary to catch them. It's much safer. The context Provider itself could be exported as well for a customized error boundaries.
This gives a great power as you can keep part of the tree to handles sync errors and other part would be throwing async and catching with boundary. Most importantly, you don't need to think about it. Just drop boudary where you want and rest of the app will be safe.

@umidbekkarimov @rosskevin what's your opinion about it?

@trojanowski I'm good with this proposal as long as we keep current hook functionality (e.g: as  useMutationFn).
TBH I'm not using useMutation directly in my project, I merged it with react-final-form-hooks as useMutationForm so final-form deals with all state management for me.

But I'm not sure about using context to manage hook options, It makes it counter intuitive. It's still better to wrap with custom hook to keep it straightforward.

But I'm not sure about using context to manage hook options, It makes it counter intuitive. It's still better to wrap with custom hook to keep it straightforward.

It's not meant like that. You would still be able to override that throwMode per useMutation meaning you can surely wrap it into a custom hook. The idea is merely to have an easy escape route with a primitive error boundary to never lose any error and have useful information about it. The sync mode which yields unhandledRejection gives absolutely no clue of where the error happened and that's the major reason why I don't like it.

this looks 😍merge merge! 😁

I’m just wondering what the appropriate way to handle these errors in the error boundaries would be. Right now I use error boundaries to crash my application by throwing errors I can’t recover from. With this change I would need to know that the error is from a mutation (for example a form) and we can safely render the children and display the error with some sort of an alert in the form.

@rovansteen Yea, I haven't mentioned it here just yet, but the last commit contains some utility for that. I am planning to add the same thing for queries, later on, to be able to define opposite logic if necessary.
import { isMutationError } from 'react-apollo-hooks'
class ErrorBoundary extends React.Component {
  state = { bailout: false }
  componentDidCatch(error, info) {
    if (!isMutationError(error)) {
      this.setState({ bailout: true })
    }
    console.error(error)
  }

  render() {
    if (this.state.bailout) {
      return
It has crashed

    }
    return this.props.children
  }
}

I'm good with this proposal as long as we keep current hook functionality (e.g: as useMutationFn).

@umidbekkarimov actually you could quite easily get the current functionality. It would be enough to replace the following invocation:
const mutate = useMutation(MY_MUTATION);

with that one:
const [mutate] = useMutation(MY_MUTATION);

Would it work for you? I'd prefer not to add a separate hook just for that. @leonardfactory @DAB0mB @Urigo Is that change OK for you? Would it be problematic for graphql-code-generator?

TBH I'm not using useMutation directly in my project, I merged it with react-final-form-hooks as useMutationForm so final-form deals with all state management for me.

Good to know it's not only me using mutations with a form library. :)

The throwMode.none feels pretty much useless because you cannot render any UI from the hook. Someone might misunderstand, use it and the errors would be suddenly lost unless they manually check the error in every mutation call. It's fairly dangerous mode to have there. I would rather not.

I thought it's the biggest benefit of this PR. :) You cannot render any UI from the hook, but you can use the presence of an error to decide what to render in your component. So if you wanted such behavior and didn't want to send those errors to a collecting service you would have to use the hook that way:
const [mutateBase, { error }] = useMutation(MY_MUTATION);

async function mutate(options) {
  try {
    await mutateBase(options);
  } catch (errorToIgnore) {
    // ignore the thrown error to prevent `unhandledRejection` event
    // we use `error` returned by `useMutation` to decide what to render
  }
}

Anyway, I have an alternative suggestion. Let's forget about throwMode and introduce a different option - errorHandler. It would be a function run when an error happened. The default implementation would be:
const defaultErrorHandler = error => { throw error; }

So it would work the same as the current version of useMutation. But you can replace it e.g. with noop (a more explicit version of the none throw mode), or a handler sending an error to Sentry:
function useSetryFriendlyMutation(mutation, options) {
  return useMutation(mutation, {
    ...options,
    errorHandler: error => {
      Sentry.captureException(error);
    }
  );
}

That way you don't need to use isApolloError or isMutationError. But if you still prefer to use error boundaries you can easily create a custom hook for that:
function useMutationWithErrorBoundariesAnyway(mutation, options) {
  const [mutate, result] = useMutation(mutation, options);
  if (result.error) {
    throw result.error;
  }
  return [mutate, result];
}

But I'm not sure about using context to manage hook options, It makes it counter intuitive. It's still better to wrap with custom hook to keep it straightforward.

I agree. But if still prefer such behavior you can do it easily with a custom hook and a context provider.

But if you still prefer to use error boundaries you can easily create a custom hook for that:

Error boundaries are becoming fairly common practice. I don't like that you would not have an option to use them directly and everyone would have to enable it with a custom hook. I would be really careful about building library in a way that needs custom hooks to work properly.

Let's forget about throwMode and introduce a different option - errorHandler. It would be a function run when an error happened. The default implementation would be:

I don't follow how is that good thing. In most cases handling an error does mean you want to log/report it somewhere. It would be super annoying to need to do it everywhere. I like my DRY code :)
I am starting to like throwMode. And I don't mind having the none option after all (it already helped with tests). It can come in handy in scenarios where you really do want to just render error in some way (eg. icon), but you don't want to report it anywhere. It just needs proper warning in the documentation. I am thinking about a separate document about error handling in general.
And I made a wrong statement above. I've meant to keep async mode as default. I am perfectly fine with that. Then the error boundary can automatically switch it to sync for a given subtree so those errors can actually bubble up.

@trojanowski

Would it work for you? I'd prefer not to add a separate hook just for that. @leonardfactory @DAB0mB @Urigo Is that change OK for you? Would it be problematic for graphql-code-generator?

Seems like it would be supported by default. Since we just return ReactApolloHooks.useMutate(...) result entirely, it should work by default! I'll make sure however anything plays well if and when this will be released

Good to know it's not only me using mutations with a form library. :)

+1 here 😄 Furthermore, Formik is currently working on v2 version based on hooks

Alright, it's time ❗ I am opening PR for a review as I have finally managed to figure tests. I will work on the documentation in the meantime.

Great guys! I didn't start using this library because of this missing feature. I'm excited about this PR! Thank you so much.

@trojanowski Just tried to actually build this and it's failing because of class properties used in those Error classes. Would you be against adding https://babeljs.io/docs/en/babel-plugin-proposal-class-properties?

Amazing job

So I am trying to implement this change into our production app and I am having some second thoughts about error handling.
First and foremost, error boundaries for mutations are a bad idea. See my post at Spectrum for details. This is something I haven't realized before so I am going to drop the throwMode from the PR after all.
Also the none for the throwMode does make sense now. Consider use case like following (we have bunch of those).
const [zoneUpdate, { called, data, error }] = useMZoneUpdate({ throwMode: 'none' })

if (called) {
  if (data) {
    routeToZoneList()
    enqueueSuccess(`Zone has been updated`) // show the toast
  }
  if (error) {
    enqueueError(`Zone failed to update`) // simplified
  }
}

const onSubmit = values => {
  zoneUpdate(zoneModel.getZoneVariables(zoneId, values))
}

I kinda like this more instead of try-catch and awaiting in every single case. That error handling can be unified with a custom hook and basically send it to the Context to show the relevant toast with errors from the backend server.
If there would be an error thrown in this use case, it ends up as unhandledRejection. And I don't want to try/catch it in every single component. So the option for not throwing at all definitely makes sense.

Stay tuned for more discoveries, but this PR is far from ready. Feel free to use this in your project as well to figure out some best practices. It's pretty much just copy & paste one file, you don't need to wait for official release.

Right now I'm using this library for queries and 'react-apollo' for mutations. I'd love to see this pr merged soon.
Also, regarding Error boundary I think it's a bad idea. I'd like it work exactly like how 'react-apollo' works. If there is an error I'll show another div based on it
@FredyC can I expect it soon?

@FredyC

First and foremost, error boundaries for mutations are a bad idea. See my post at Spectrum for details. This is something I haven't realized before so I am going to drop the throwMode from the PR after all.

👍. BTW I did some testing and I think that the unhandled rejections are not so bad for error reporting - you can read a meaningful stack trace from the unhandledrejection event, and sentry supports it, but unfortunately, it requires polyfills on Firefox/Edge and is not supported on IE.

First and foremost, error boundaries for mutations are a bad idea. See my post at Spectrum for details. This is something I haven't realized before so I am going to drop the throwMode from the PR after all.
Also the none for the throwMode does make sense now.

So we could abandon the throwMode option and introduce an alternative one, e.g. rethrow which would control that behavior (true would mean the async throw mode described in https://github.com/trojanowski/react-apollo-hooks/pull/93#issuecomment-468671007 would be used, false would enable the none mode, sync wouldn't be implemented at all). I prefer it to be true by default.

Stay tuned for more discoveries, but this PR is far from ready.

What other changes are you considering?

@trojanowski I've just pushed an update. Documentation is still lacking in my opinion, but otherwise it seems to be working. I've included rethrow the way you said, agree on that. I've also made ApolloOperationError which is universal for all three types of operation and comes handy when recognizing errors in some unified error handler.

What other changes are you considering?

I am not sure yet. Trying to use this in as many cases as I can, but I am also a bit swamped with some tasks.

but unfortunately, it requires polyfills on Firefox/Edge and is not supported on IE.

Yea, one of the reasons why I wouldn't use it. Also, catching it is feels rather hacky.

For my own use I've figured out a nice way with Context as a universal error handler. It basically looks like this and it seems to be working quite nicely so far.
export const DefaultErrorHandler: React.FC = ({ children }) => {
  const onRetry = React.useCallback(() => {
    // reset error state
  }, [])

  const onUnhandledError = React.useCallback((error: Error) => {
  }, [])

  const onNetworkError = React.useCallback((error: Error) => {
  ), [])

  const onOperationError = React.useCallback(() => {
  }, [])

  const onUserErrors = React.useCallback((messages: ReadonlyArray<string>) => {
  }, [])

  const render = () => {
     // render fallback UI based on kind of error
     // or keep the current one - without remounting!
     return children
  }

  return (
    <ApolloDefender
      onNetworkError={onNetworkError}
      onUserErrors={onUserErrors}
      onOperationError={onOperationError}
    >
      <SillyErrorBoundary onError={onUnhandledError}>
        {render()}
      </SillyErrorBoundary>
    </ApolloDefender>
  )
}

The SillyErrorBoundary is just a componentDidCatch passing error in here (it's included in the PR). The ApolloDefender is my opinionated Sentry centered component which exposes onError through the Context which can be used for passing any caught errors (queries, mutations, subscriptions).

Tests look good. Are we good to merge this?

Tests look good. Are we good to merge this?

I think the docs really need more information, but I am a bit swamped this week. Could use some help with that really. Or we can merge this now and leave docs for a separate PR so someone else can do that. What do you think @trojanowski?

I see that basic doc is already done. It would be if you guys can merge this asap and create a separate PR for docs later. I can also help with the docs

@trojanowski So can you actually merge it? I don't think there is going to be any other breaking change addition right now.

@FredyC I'd prefer to reduce this PR and remove SillyErrorBoundary and ApolloOperationError. I think SillyErrorBoundary in the current form is not very useful -  a better idea is to document error handling. Also, ApolloError seems enough for me (instead of ApolloOperationError) - in your onError handler you know that the error was thrown by a mutation (and you can determine by which one).

I think SillyErrorBoundary in the current form is not very useful

That depends, in React Hooks world it's very useful as you don't have a hook variant (yet). It's a useful workaround so you don't need to copy-paste it in your code. I agree it doesn't really fit well in the package, but I have to keep in the code for the tests. So why not reexport when it's already there? :)

Also, ApolloError seems enough for me (instead of ApolloOperationError) - in your onError handler you know that the error was thrown by a mutation (and you can determine by which one).

How can you know which mutation has thrown in a universal error boundary? Or if it was a mutation at all. That's kinda point of that Error class so you can unify your error handling into a single point and do a decision what to do based on the operation failing.

Getting up to speed on this and I've picked up a couple nice patterns from the comments that beat the fully imperative routine of try/catch/handle I usually do, so thank you.  I think this reduces the code needed around calling a mutation - considerably if you only need to display the loading/data/error declaratively.  In my case I usually need to do something with the response imperatively, but even then this still reduces loading and error and the need to catch.  I think I like it!

Looks like official react-apollo is getting ready for hooks! https://github.com/apollographql/react-apollo/pull/2892

@gijo-varghese That won't be ready for some time yet, there was a word they want to wait for Suspense for data fetching which might be by the end of the year.

@FredyC can you merge this soon?

@gijo-varghese Well, it's not up to me really, @trojanowski had some objections, I've responded. If you are impatient, just grab the Yalc and you can roll without waiting. That's what I do.

I think SillyErrorBoundary in the current form is not very useful

That depends, in React Hooks world it's very useful as you don't have a hook variant (yet). It's a useful workaround so you don't need to copy-paste it in your code. I agree it doesn't really fit well in the package, but I have to keep in the code for the tests. So why not export when it's already there? :)

Because it would be a part of the public API and we'd have to support it. Also, I'd instead prefer to recommend a specialized library for that, like react-error-boundary. Moreover, I don't think SillyErrorBoundary is even useful for tests in this PR - you use it to check if no errors were throws while rendering the React tree. However, you don't need an error boundary for that - tests throws by default in that case.

Also, ApolloError seems enough for me (instead of ApolloOperationError) - in your onError handler you know that the error was thrown by a mutation (and you can determine by which one).

How can you know which mutation has thrown in a universal error boundary? Or if it was a mutation at all? That's kinda point of that ApolloOperationError so you can unify your error handling into a single point and do a decision what to do based on the operation failing. When this is merged, I would like to introduce the same thing into useQuery and useSubscription.

But we decided that we won't support the synchronous error throwing, so in order to use error boundaries (or sending it to the context like in your comment) you'd need a custom hook - you could convert it to a "higher order error" there. We could continue the discussion about ApolloOperationError, but I'd prefer to do that in a separate issue or PR - if we'd merge this PR in the current form, some public API functions would behave incorrectly (isQueryError, isSubscriptionError).

But we decided that we won't support the synchronous error throwing, so in order to use error boundaries (or sending it to the context like in your comment) you'd need a custom hook

It has nothing to do with the synchronous throw. It's about an error object in general which should carry that information to improve debugging. I have this in my wrapper which allows me to pass an error to closest Context (ApolloDefender) which can decide what to do based on information in that error. If it's just regular ApolloError, that information is lost.
  const { onError } = useApolloDefender()
  React.useEffect(
    () => {
      if (result.called && result.error) {
        onError(result.error)
      }
    },
    [result.called, result.error],
  )

I think I am going to hand this over to you and do changes you deem necessary. We obviously have different opinions about it and nobody else seem to care enough. I am already using my custom fork of this library so I don't really care that much to get this merged.

When is this getting merged? I need error checking for a crucial part in my application flow. Is any workaround for this?

@charlie632 http://bfy.tw/N54W

Hi folks, just checking if this is close to being merged? really looking forward to it!

Perhaps, instead of asking for a merge to be done soon could actually contribute with an opinion on standing questions. It would ultimately help much more than poking and prodding like impatient nerds. 🙊

Next week I'm going to try to add changes I requested in https://github.com/trojanowski/react-apollo-hooks/pull/93#issuecomment-479462989 and merge after that.

@trojanowski thanks for the insightful response.

@FredyC, I appreciate your efforts

Edit: I am currently working on an article showing that error boundary is fairly useless in its current form and Context has surpassed it.

@FredyC I'm super curious on this topic and was wondering how this article is coming along? Would love to see your implementation of a context based error handler :)

I added an alternative PR with changes I requested in my previous comment: #135. @FredyC please let me know what do you think about it.

@trojanowski Well, you know my opinion. I could live with the removal of SIllyErrorBoundary, but those errors wrapped are essential. I am already using those in production and it has proven very valuable in automated bug reports. Shame nobody else sees it. So be it, I will stick to my version.

Finally! npm install @apollo/react-hooks@beta --save
Soon I'll run npm r react-apollo-hooks
https://twitter.com/peggyrayzis/status/1128280687470100480

I understand you are excited about this feature @gijo-varghese - but responding like this sounds quite insensitive to the fact that a lot of people donated their time and effort to make this library freely available to you. Fair enough if there is an alternative but please show some a moderate amount of appreciation for what has been gifted.

This library has been incredibly helpful and well done. To give @gijo-varghese the benefit of the doubt, I hope they just thought that it was a transition to Apollo ownership / maintenance and they were genuinely excited for the library.


wasmparser: Validation of function references can take ~infinite time

This module:
(module
  (type $t1 (func))
  (type $t2 (func
    (param (ref $t1) (ref $t1) (ref $t1) (ref $t1) (ref $t1) (ref $t1) (ref $t1) (ref $t1) (ref $t1) (ref $t1))
  ))
  (type $t3 (func
    (param (ref $t2) (ref $t2) (ref $t2) (ref $t2) (ref $t2) (ref $t2) (ref $t2) (ref $t2) (ref $t2) (ref $t2))
  ))
  (type $t4 (func
    (param (ref $t3) (ref $t3) (ref $t3) (ref $t3) (ref $t3) (ref $t3) (ref $t3) (ref $t3) (ref $t3) (ref $t3))
  ))
  (type $t5 (func
    (param (ref $t4) (ref $t4) (ref $t4) (ref $t4) (ref $t4) (ref $t4) (ref $t4) (ref $t4) (ref $t4) (ref $t4))
  ))
  (type $t6 (func
    (param (ref $t5) (ref $t5) (ref $t5) (ref $t5) (ref $t5) (ref $t5) (ref $t5) (ref $t5) (ref $t5) (ref $t5))
  ))
  (type $t7 (func
    (param (ref $t6) (ref $t6) (ref $t6) (ref $t6) (ref $t6) (ref $t6) (ref $t6) (ref $t6) (ref $t6) (ref $t6))
  ))
  (type $t8 (func
    (param (ref $t7) (ref $t7) (ref $t7) (ref $t7) (ref $t7) (ref $t7) (ref $t7) (ref $t7) (ref $t7) (ref $t7))
  ))
  (type $t9 (func
    (param (ref $t8) (ref $t8) (ref $t8) (ref $t8) (ref $t8) (ref $t8) (ref $t8) (ref $t8) (ref $t8) (ref $t8))
  ))
  (type $t10 (func
    (param (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9))
  ))
  (type $t11 (func
    (param (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9) (ref $t9))
  ))

  (table 1 1 (ref null $t10))

  (func (param (ref null $t11))
      i32.const 0
      local.get 0
      table.set)

)

Currently takes ~infinite time to validate with the function-references proposal, but it shouldn't

Ah I think that's a bug then or a regression since I first opened this. If after fixing that this still doesn't work I can work on making another repro.

 We need to do it for the gc proposal anyways.


CI failures for master

See https://github.com/gap-packages/francy/actions?query=branch%3Amaster

This is already fixed, just not merged into master.
Will make it available once I sort out the use of ReleaseTools.


Feature/user manager

Adds user manager test library
Facilitates test user creation and tests user creation

Not sure why this isn't syncing with last commit, investigating...

replacing with new one


(HTTP code 401) unexpected - {"message":"Get https://registry-1.docker.io/v2/library/ubuntu/manifests/latest: unauthorized: incorrect username or password"}

Expected behavior
Actual behavior
Information about the Issue
Steps to reproduce the behavior

...
...

#2996 this issue works for me

Please try to login using your Docker ID (hub username) instead of your email. This should fix the issue.


Relayout on after-attach event

Should fix #1055

This is not ideal. Because, as you can see in the GIF, the figure is displayed a first time with a size of 0, and due to the margins it actually gets a size of -20 x -20.
@maartenbreddels I know you did not agree with this last time we talked about it, but I really think that when the Figure has no available space, it should not be displayed at all. This would fix this glitch.

This is now also fixed, by making the whole element invisible (so it takes up DOM space if needed).


Update to latest CoffeeNet parent version 0.31.0

New CoffeeNet parent version 0.31.0 was released! Please check https://github.com/coffeenet/coffeenet-starter/blob/master/CHANGELOG.md for more information

Pull Request Test Coverage Report for Build 36

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 73.913%

Totals

Change from base Build 35:
0.0%

Covered Lines:
17

Relevant Lines:
23

💛  - Coveralls


worker-loader seems to inject web assembly binary contents directly into JavaScript output bundle

wasm-loader-problem.tar.gz
Attached an example project. You can run it using npm install followed by npm build or npm start. The web assembly is pre-built for you, but if you want to build it yourself using a rust toolchain, you can do so using the included Makefile.
I can load and execute a simple web assembly function (add two numbers and return the result) using webpack, which works (commented out in the example project). However, if I do the same thing in a web worker created using worker-loader, the web worker experiences a syntax error.
On further examination of the worker's JavaScript output bundle, I find something like this:
/***/ "./rust-wasm-package/pkg/rust_wasm_package_bg.wasm":
/*!*********************************************************!*\
  !*** ./rust-wasm-package/pkg/rust_wasm_package_bg.wasm ***!
  \*********************************************************/
/*! exports provided: memory, add, __wbindgen_malloc */
/***/ (function(module, exports, __webpack_require__) {

eval("\u0000asm\u0001\u0000\u0000\u0000\u0001}\u0012`\u0001...

Which I assume is not correct.
I'm not sure what to make of this. It seems that WebPack, once invoked within the worker-loader, can't recognize wasm resources or doesn't care and treats it as JavaScript.

+1, same problem

@cars10 I dealt with it by using a separate entry point for the for the web-worker. Webpack can load wasm correctly, just not via worker-loader.

@clanehin - do you mind sharing how you've done multiple entry points for workers, in webpack4 ?
I've posted a similar question to Stackoverflow here: https://stackoverflow.com/questions/52437858/multiple-targets-per-entry-in-webpack-4

@dakom after playing around with the issue i created an example repo showing how to use wasm + workers + webpack together, maybe that will help you.
https://github.com/cars10/rust-wasm-webworker-example

thanks! though I see you're loading the wasm directly... I believe wasm-bindgen requires using its own generated js?

I am not sure TBH - though the example in this project works if you try it out.

Why is the binary inject into the ouput JS? Our implementation of WebAssembly in Webpack uses WebAssembly.instantiateStreaming, I guess we could have the same support here?

Is it though? I also use instantiateStreaming, see https://github.com/cars10/rust-wasm-webworker-example/blob/master/src/js/worker.js#L3 .

@dakom, I'm using webpack 4 with wasm-bindgen, and it goes just fine day-to-day even though it was time consuming to figure out the first time due to poor error messages. You can provide an array of configurations. However, a critical insight for me was that the different configurations in the array can stomp on each other's output, and this will result in extremely difficult-to-diagnose errors. You must provide an output: { filename: "[name].unique-pattern.js" } as part of each entry point to ensure that this does not happen.
Webpack could make this a lot easier by checksumming or UUID-ing module loads so you get immediate feedback if you unexpectedly load a weird module.

Close in favor https://github.com/webpack-contrib/worker-loader/issues/251


Remove "granularity" from IngestSegmentFirehose.

It wasn't doing anything useful (the sequences were being concatted, and
cursor.getTime() wasn't being called) and it defaulted to Granularities.NONE.
Changing it to Granularities.ALL gave me a 700x+ performance boost on a
small dataset I was reindexing (2m27s to 365ms). Most of that was from avoiding
making a lot of unnecessary column selectors.

@gianm it appears that this breaks re-indexing which expects IngestSegmentFireHose to give individual rows from the segment without any truncation.
how about making ALL default granularity but still providing the option for caller to change the granularity so that re-indexing path can stay same ?
I wonder if this impacts re-indexing done via local index task too.

@himanshug What specifically has broken? IIRC the rows still do have their original, unchanged timestamps -- the only difference is that the cursor timestamps are truncated. But reindexing shouldn't be using the cursor timestamps anyway.

ok, I assumed CursorFactory.makeCursor(..) could truncate timestamps based on provided granularity. its fine if it returns rows without truncation. thanks.

IIRC what happens is the cursor.getTime() is truncated, but the timestamp on the actual rows (row.getTimestampFromEpoch()) is not truncated, since it comes from the time column, not from the cursor. So I think it should be ok. If you notice anything different please raise it…


Fixes #28

Small changelog:

Replaced char, int, text with pretty
Doc with Doc ann
Removed Pretty class; prettyprinter has already one.
One must take care of the use of prettyList since the default implementations are differs from the one used in out Pretty class.
Incorporated BashDoc from #24. I also added two tests for it and some Haddock documentation.

Uses  prettyprinter>=1.4.0.
I'm really looking forward to see this merged.

Ok, Travis loves us! And if your review is positive as well I'd say: Let's merge!

Okay, I played around with it a little. Other than the missing newline issue, it looks good to go :) thanks again!

Ok, I addressed your concerns.
It passes all tests in #30. (Note: I updated this PR, too.)
The reason for the CI failure is #17.


Fix #173: Add flag to make application path group-writable

Introducing BP_APP_PATH_GROUP_WRITABLE, defaults to false

Use Cases
> pack build -p ~/Downloads/apache-activemq-dist.zip dist --env BP_APP_PATH_GROUP_WRITABLE=true -e BP_APPLICATION_SCRIPT=apache-activemq-dist/bin/activemq -b paketo-buildpacks/syft \
-b paketo-buildpacks/bellsoft-liberica \
-b . \
 --builder paketobuildpacks/builder:base --verbose --clear-cache
[...]
Paketo Buildpack for DistZip {{.version}}
  https://github.com/paketo-buildpacks/dist-zip
  Build Configuration:
    $BP_APPLICATION_SCRIPT       apache-activemq-dist/bin/activemq  the application start script
    $BP_APP_PATH_GROUP_WRITABLE  true                               make the application path group-writable
    $BP_LIVE_RELOAD_ENABLED      false                              enable live process reload in the image
  Successfully marked applicationPath, /workspace, as group-writable
  Process types:
    dist-zip: /workspace/apache-activemq-dist/bin/activemq
    task:     /workspace/apache-activemq-dist/bin/activemq
    web:      /workspace/apache-activemq-dist/bin/activemq
[...]
> docker run -it --entrypoint=ls dist -al /workspace
total 12
drwxr-xr-x  3 cnb  cnb  4096 Jan  1  1980 .
drwxr-xr-x  1 root root 4096 May  3 13:45 ..
drwxrwxr-x 10 cnb  cnb  4096 Jan  1  1980 apache-activemq-dist

Checklist

[X] I have viewed, signed, and submitted the Contributor License Agreement.
[X] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[X] I have added an integration test, if necessary.
[X] I have reviewed the styleguide for guidance on my code quality.
[X] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

hello all!
If that's okay with you (react with a 👍 ) I'll close this issue in favor of the chmod-buildpack RFC and POC.


Emptyish lines have misaligned indentation markers

Lines that are empty or only contain whitespace have indentation markers that appear a few units to the left of lines that have content:

Live repro: https://repro-codemirror-indentation-markers-7.glitch.me

This should be fixed in the latest updates as we are now relying on a brand new reimplementation but please let me know if you're still experiencing this


Capture return status in the function call inline to fix the issue with vulnerability scanners

From the logs of a latest run. Instead of the value of res being 0 or 1, the script exits prematurely causing the value to be set to some string. This PR fixes this issue.
Run res= Check the full report here: https://quay.io/repository/redhat-pipeline-service/vulnerability-scan/manifest/sha256:92f5cf046[1](https://github.com/openshift-pipelines/pipeline-service/actions/runs/3389846804/jobs/5633369718#step:9:1)bdedb54e66bf2e6a489b16f67ef941aad27cf62f1f25976c29736f?tab=vulnerabilities
/home/runner/work/_temp/00184d58-34aa-45fb-90ff-56d51ab33496.sh: line 1: Check: command not found
Error: Process completed with exit code [12](https://github.com/openshift-pipelines/pipeline-service/actions/runs/3389846804/jobs/5633369718#step:9:13)7.

/retest


Floats in Bridge have more precision than in .Net

Expected
1.701412E+38
Actual
1.701411735e+38
Steps To Reproduce
public class App
{
    [Ready]
    public static void Main()
    {
        float maxFloat = float.MaxValue;
	Console.WriteLine(maxFloat  / 2);
    }
}

Hi @michaelcheers,
Yes, the underlying type for .Net float is JavaScript's number:
namespace System
{
    [Constructor("Number")]
    [External]
    [Name("Bridge.Single")]
    public struct Single : IComparable, IBridgeClass, IComparable<Single>, IEquatable<Single>, IFormattable
    {
    }
}

At the moment we do not consider changing this implementation by introducing a wrapper type to reduce precision and introducing additonal complexity.

There are other details about the problem stated in this comment of a related Issue.

At some point this has been fixed. The test sample now returns the expected results.
http://deck.net/8c32f5a4e1585804456002f973793579
Please let us know if there's still a problem and we will re-open the issue.


Error: Start tag expected, '<' not found

I've recently wrote a utility bot that repeatedly crashes at random when people run something through wolfram alpha.
I'm getting the following error when that happens:
`/home/thomas/paper_bot/node_modules/libxmljs/lib/document.js:168
return bindings.fromXml(string, options || {});
^
Error: Start tag expected, '<' not found
at Error (native)
at Object.module.exports.fromXml (/home/thomas/paper_bot/node_modules/libxmljs/lib/document.js:168:21)
at Request._callback (/home/thomas/paper_bot/node_modules/wolfram-alpha/wolfram.js:58:19)
at Request.self.callback (/home/thomas/paper_bot/node_modules/request/request.js:188:22)
at emitTwo (events.js:106:13)
at Request.emit (events.js:191:7)
at Request.<anonymous> (/home/thomas/paper_bot/node_modules/request/request.js:1171:10)
at emitOne (events.js:96:13)
at Request.emit (events.js:188:7)
at IncomingMessage.<anonymous> (/home/thomas/paper_bot/node_modules/request/request.js:1091:12)
at IncomingMessage.g (events.js:291:16)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)
at endReadableNT (_stream_readable.js:974:12)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickCallback (internal/process/next_tick.js:98:9)`

Any ideas on what is wrong?

Hey, thanks for the report. I haven't used this module in a while, CI does appear to fail now: https://travis-ci.org/clux/wolfram-alpha/jobs/132341822 - so it's likely some problem in here. Maybe schemas from wolfram alpha have changed or something :/

No problem :)
I do appear to get slightly different errors each time, generaly related to parsing.
Even stuff such as getting a null result and no error.

Whoops auto-close. At any rate, I've bumped all the dependencies and fixed up tests. If you upgrade to<EMAIL_ADDRESS>you may find it works, if not please report back :)
I did change the main interface to be promise based in the process though, if you don't want to deal with that right now, you can change your calls to client.query to client.queryCb.

Many thanks!
I've updated to latest and it appears to be running fine.
I'll update this issue or create a new one if I have any issues :)


Redirect Manager - AEM SPA not working

Required Information

[ ] AEM Version, including Service Packs, Cumulative Fix Packs, etc: 6.0.4
[ ] ACS AEM Commons Version:6.0.4
[ ] Reproducible on Latest? yes

Expected Behavior
While setting up the redirect via the Redirect Manager,I need to add a redirect and after publish can redirect to the source page. We are using AEM SPA based implementation
Actual Behavior
When I add a redirect, the page goes blank.
Steps to Reproduce

Install the ACS Commons on AEM cloud service
Create a redirect from a source "/test/" to destination - "https://www.google.com"
Publish the redirect
Try to access the redirect via publisher (http://localhost:4503/test/)

I get the blank page rather than it navigates to the destination page
Links
Links to related assets, e.g. content packages containing test components
redirect.zip

Do you have Sling Mappings to resolve /test/  to a full path , e.g. /content/my-site/en/test ?
If not, use the full JCR path, e.g. instead of /test/ the source should be /content/my-site/en/test

The use case is that there is no physical page in AEM with a full path that resolves to /test/, In the e-commerce application, we need to apply the rules to /test/ category which is coming from the commerce engine and then re-direct it to a place in AEM. So I can put a destination to a full path like /content/my-site/en/new-landing but the source will not be a page/location within AEM.
Hope this make sense

by default the Redirect Filter listens to /content/* requests:

change it to an empty string to listen from the root.

(the value "/" won't work, it's a bug which I'm going to fix)
with these settings it worked to me:

curl -I  http://localhost:4503/test
HTTP/1.1 302 Found
Date: Wed, 17 May 2023 08:31:33 GMT
Location: https://www.google.com
Content-Length: 0

Thanks for the prompt reply and are you planning to release the fix for "/" soon or is there a roadmap for the same.

Thanks, I will keep an eye and update it. Thanks for the help

https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/3105


Hint vararg

Improve the error message so that user that try to pass an array as is instead of elements is hinted about the ... reverse-vararg operator.
fun foo(xs: Int...) do end
foo(1,2,3) # OK
foo([1,2,3]) # Error, expected `Int`; got `Array[Int]`. Is `...` missing?
foo([1,2,3]...) # OK

close #98 (quite old bug)

Super ! Another proof that Nit is not Java...

+1

:shipit:

In the d2dcd1f8 commit message: "but*"

foo([1,2,3]...)

Am I the only one who find this quite ugly ?

What about Is an ellipsis ... missing on the argument? a bit long but more informative. And by giving the name of the operator a search in the doc could be easier.

Yeah, I like it


[AUTOPATCHER] Patches CVE-2021-21334 for moby-containerd

        Patches CVE-2021-21334 for moby-containerd.
        This patch and PR was automatically generated and needs human verification before merging.

This autopatch applies to the wrong version of containerd.  The actual CVE is not for version 1.4.4.  Closing issue.


Null background activity can not draw action bar items properly with invalidateOptionsMenu()

I found a drawing bug  on the API 9 phone with ABS v4.0, beta 5.
Action bar Items are not  drawn properly  by calling the invalidateOptionsMenu().
This bug does not occur on the API 15 emulator without ABS.
Sample code is like this.
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

    // Set activity background to null
    getWindow().setBackgroundDrawable(null);

    Button button = (Button)findViewById(R.id.button);
    button.setOnClickListener(new OnClickListener() {
        @Override
        public void onClick(View v) {
        	mItems++;
        	if (mItems>= 8) {
        		mItems = 0;
        	}
            invalidateOptionsMenu();
        }
    });
}

public boolean onCreateOptionsMenu(Menu menu) {
    for (int i = 0; i < mItems; i++) {
    	String title = String.format("Item: %d", i);
    	int iconId = (i % 2 == 0) ? R.drawable.ic_search : R.drawable.ic_refresh;
    	menu.add(title)
    		.setIcon(iconId)
            .setShowAsAction(MenuItem.SHOW_AS_ACTION_IF_ROOM | MenuItem.SHOW_AS_ACTION_WITH_TEXT);
    }
    return super.onCreateOptionsMenu(menu);
}

This is occurring because the ActionBar doesn't use a solid color background (it's transparent right now) and the DecorView appears to be caching the drawing which is leading to weird results.  I would suggest either using a completely opaque background drawable in the ActionBar or the applications window background.  If you just trying to remove the window background (performance maybe?) you can use a new ColorDrawable() and you won't see this behavior http://developer.android.com/reference/android/view/Window.html#setBackgroundDrawable(android.graphics.drawable.Drawable)

Completely works well!
Thank you, Chris.


Clean up tools/run_tests directory

Only keep useful user-runnable scripts in tools/run_tests, move helpers to subdirectories.
Fixes #8748

All tests are passing, will rebase/squash and merge.


loader needs to be verified for no memory leaks

Well, I'm using the loader in my app and ran valgrind on it. Here's one I found and fixed. Other than that (so far -- limited testing) the loader is clean.
loader_destroy_layer_list() memory leak:
Run valgrind --leak_check=full on a this test file:
#include "vulkan/vulkan.h"
#include "stdio.h"

int main() {
  uint32_t layerCount = 0;
  vkEnumerateInstanceLayerProperties(&layerCount, nullptr);
  printf("layerCount=%u\n", layerCount);
  return 0;
}

valgrind output will look like:
==PID==
==PID== 49,920 bytes in 6 blocks are definitely lost in loss record 57 of 58
==PID==    at 0x40307C4: malloc (vg_replace_malloc.c:270)
==PID==    by 0x4A2B5F3: loader_instance_heap_alloc (loader/loader.c:178)
==PID==    by 0x4A2CB0D: loader_init_generic_list (loader/loader.c:858)
==PID==    by 0x4A2CBDE: loader_add_to_ext_list (loader/loader.c:889)
==PID==    by 0x4A30A32: loader_read_json_layer (loader/loader.c:2311)
==PID==    by 0x4A31373: loader_add_layer_properties (loader/loader.c:2509)
==PID==    by 0x4A3286F: loader_layer_scan (loader/loader.c:3032)
==PID==    by 0x4A38DFC: vkEnumerateInstanceLayerProperties (loader/trampoline.c:239)
==PID==

The issue is that most of the body of loader_delete_layer_properties() is not done by loader_destroy_layer_list(). Which probably means that the two functions should be merged somehow.

The patch above causes some of the demo programs to segfault.

I saw a follow on to this thread that said you were seeing segfaults with this patch.  Is it still true?  If so, what applications see the segfault?  With our without validation enabled?

Hi Mark,
I added that comment and then deleted it. I saw segfaults in the
'vulkaninfo' tool, caused by a previous iteration of the patch.
The previous iteration patch copied lines of code from
loader_delete_layer_properties() into loader_destroy_layer_list(). That was
incorrect, leading to segfaults, because loader_destroy_layer_list() is
used to destroy layer lists when the list items themselves have already
been cleaned up. Yes, that's probably immediately obvious to an experienced
Vulkan Loader dev...it took me a few more days to sort it out.
The current form of the patch no longer segfaults in vulkaninfo, because it
calls the correct cleanup (loader_delete_layer_properties()). I tested the
patch on linux using valgrind, then repeated the test by compiling with
-fsanitize=address.
Both tests were done with validation enabled by: export
VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_standard_validation
Best,
David
On Fri, Jul 29, 2016 at 9:20 AM, Mark Young<EMAIL_ADDRESS>wrote:

I saw a follow on to this thread that said you were seeing segfaults with
this patch. Is it still true? If so, what applications see the segfault?
With our without validation enabled?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/571#issuecomment-236225453,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEArpIwxY5DGkqqe38X2yjcq2yFRFemiks5qaihMgaJpZM4Ijd1z
.

Ok.  I tested out your changes on the various demos and tests in LVL and I hadn't seen any segfault, which is why I was asking.    If that works, I'll likely get this in some time this week.

Changes pushed up in commit 8304a3146414ae4f43fb0e110f27c4b16c9eab52.

Changes still caused a segfault on VulkanInfo.  Reverted the first change to hte local_list and VulkanInfo no longer segaults.

I've traced the segfault to vkEnumerateInstanceLayerProperties.
Pull request #803 incorrectly only changed vkEnumerateInstanceExtensionProperties.
I have tested vulkaninfo with no layers enabled and standard_validation enabled. No segfaults, and valgrind says the loader is clean. (Errm, I did spot some leaks in the main app of vulkaninfo, but I'll look at those later.)
I also ran all tests. I can't get vk_layer_validation_tests to work at all, but vk_loader_validation_tests are all behaving the same before/after this patch:
[  FAILED  ] 2 tests, listed below:
[  FAILED  ] CreateInstance.LayerPresent
[  FAILED  ] EnumerateDeviceLayerProperties.PropertyCountLessThanAvailable

David, I just noticed you haven't signed the CLA yet.  We're supposed to require any users submitting code changes to confirm the CLA.  Can you make sure you do that?  I'll start looking into this.
Thanks

Bad news, these changes are causing the alloc tests in Conformance to fail.  I'll have to do some more investigation into this.

Ok, thanks for helping me work through the CLA setup. I'll take a look at running Vulkan-CTS tomorrow.

Here's my reduced subset of the mustpass tests that should show failures.
vk-alloc.zip

I'm closing this issue because the remaining problem was in a call that shouldn't be used by desktop applications.  It should probably be cleaned up at some point, but the primary memory leaks mentioned in this original issue have been resolved.


Update with the finalized EMG tutorial additions

This pull request will merge in all of the changes added to the tutorial docs pages to include a walkthrough of applying AutoLFADS to EMG data.

@fzhu23 will also make final changes to tutorial-dev branch to fix tutorial dataset section then merge to tutorial branch, so closing pull request.


Umami on AWS

Hello, Thank you for Umami.
Do you know if it's possible to deploy umami on AWS Amplify ?
For now, i use heroku but i have other apps on aws. I don't want to use an EC2 instance that seems to overkill.
So i successfully deploy the front end but there is issue with backend database.
Is there someone that successfully deploy umami on AWS ?

Yes i know it's possible to use a database exposed to the public but the purpose was to have some kind of "localhost" database on aws that is linked to umami/prisma

You can install umami on the same server as the database, if you're hosting the database yourself. Otherwise, I think AWS allows local IP addresses, assuming your servers are in the same region.


Fixing #1950 and whitespace issues.


Inconsistent escaping of directory names

This is similar to https://github.com/japaric/criterion.rs/issues/182, but I've noticed few more issues when running benchmarks. Here is a simple reproducible example:
fn bench(c: &mut Criterion) {
    c.bench_function_over_inputs("t{e.s/t", |b, i| b.iter(|| i), &[
        "a/b",
        "c{d"
    ]);
}

This creates following directory structure:
target/criterion/
├── report
├── t{e.s
│   └── t
│       └── report
└── t{e_s_t
    ├── _a_b_
    │   ├── base
    │   ├── new
    │   └── report
    └── _c{d_
        ├── base
        ├── new
        └── report

Why top-level directories for general report and parametrised reports are escaped differently? Which one is correct - is / supposed to be treated as subdirectory in benchmark names or should it be escaped? Note that it's not escaped with non-parametrised benchmark_function as well.

Same for group names:
fn bench(c: &mut Criterion) {
    c.bench("g.r{ou/p", ParameterizedBenchmark::new("t{e.s/t", |b, i| b.iter(|| i), &[
        "a/b",
        "c{d"
    ]));
}

target/criterion/
├── g.r{ou
│   └── p
│       ├── report
│       └── t{e.s
│           └── t
│               └── report
├── g_r{ou_p
│   └── t{e_s_t
│       ├── _a_b_
│       │   ├── base
│       │   ├── new
│       │   └── report
│       └── _c{d_
│           ├── base
│           ├── new
│           └── report
└── report


Update version to 0.3.0 for release

Codecov Report

Merging #133 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #133   +/-   ##
=======================================
  Coverage   95.21%   95.21%
=======================================
  Files          34       34
  Lines        1191     1191
=======================================
  Hits         1134     1134
  Misses         57       57

Impacted Files
Coverage Δ

response_operations_ui/views/info.py
100% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d1b7d15...55c83b6. Read the comment docs.


Badge Position - Bottomleft

I would like to know how to place the bagde on the bottom left of the screen. Using the data-badge="bottomleft"
Tried something like:
Vue.use(VueReCaptcha, { siteKey: '', loaderOptions: { renderParameters: { badge: 'bottomleft' } } })
https://developers.google.com/recaptcha/docs/invisible#render_param
https://github.com/AurityLab/vue-recaptcha-v3/issues/143

Hey, sorry for the delayed response.
I've addressed this issue in #172. The implemented functionallity in the PR will allow you pass the render parameters to the load(...) function.
The PR will be merged into the master within the next hours and a new version will also be released (I'll also update vue-recaptcha-v3).

Hey,
I've just published v1.8.0 which includes the the fix to set the badge property.


Thoughts on suture pkg

I am wondering what your thoughts are on https://github.com/thejerf/suture are and whether there are any major design differences between the two packages?

I looked at it a long time ago and had difference of opinion, but can't instantly recall all of them and didn't keep good notes :thinking:
I think it came down to that I'm a bit dubious of the type Service interface { Serve(); Stop(); } core.  That mental model is based on actors; and I wanted to build supervision... without the innate belief in actor models.
(Mind, I still like actor models.  I build them all the time.  But I think we can make supervision orthagonal to that.)
Another probably significant difference is that this go-sup package uses standard library's context.Context heavily, both for passing any metadata (e.g. task tree names) around transparently, and for the obviously important cancellation and halting purpose.  I've actually (re)written something "like" this library several times, and the first ones didn't lean on context; this one does, and it's come out the nicest so far (IMO) and also integrates easily with other parts of the Go ecosystem which are now all standardizing around context.
Also, if suture is considered matured and unlikely to change, that's definitely a difference :)  I definitely expect to make at least one more significant change to this go-sup package (mostly having to do with stream supervisors, though; forkjoin style probably won't change much).

That was an off-the-cuff answer, but I think it mostly checks out.  I'll leave this issue open to remind myself to write better docs about this, though.  This sort of stuff should probably be boiled down into the readme or some other docs in-repo.

@warpfork Thanks for the response.
The use of context.Context, though I wish it wasn't the case, is necessary for any sort of tracing and metrics collection framework these days in Go, so yeah that is a deal break for suture, for me at least.


Addressing misplaced <html> tag in swagger template (#660)

Addressing https://github.com/poem-web/poem/issues/660

thank you


Remove waiter.sh script from coreos master.yaml

The waiter.sh script can be implemented as a oneliner within the etcd-waiter.service file. This is much simpler than create the script and ensuring that it has the correct permissions before running it.

The chances of me going through the process of being able to sign off on the CLA is pretty low, so if that is what is required, then this pull request may as well be close.
There is nothing novel or new is this patch though, so I imagine it would be pretty simple for someone else to re-implement a similar change without any issue if it was so desired.

Is this PR active? If not please close it according to https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/devel/pull-requests.md

Original author said it could be closed.


Facebook: Unable to extract single video id

Checklist

[x ] I'm reporting a broken site support issue
[x ] I've verified that I'm running youtube-dl version 2020.09.20
[x ] I've checked that all provided URLs are alive and playable in a browser
[x ] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[ ] I've searched the bugtracker for similar bug reports including closed ones
[ ] I've read bugs section in FAQ

Verbose log

PASTE VERBOSE LOG HERE

$ youtube-dl -v https://web.facebook.com/DonaldTrump/posts/10165632688355725
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'https://web.facebook.com/DonaldTrump/posts/10165632688355725']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2020.09.20
[debug] Python version 3.5.3 (CPython) - Linux-4.9.0-3-amd64-x86_64-with-debian-9.4
[debug] exe versions: avconv 3.3.4, avprobe 3.3.4, ffmpeg 3.3.4, ffprobe 3.3.4, phantomjs 2.1.1, rtmpdump 2.4
[debug] Proxy map: {}
[facebook]<PHONE_NUMBER>8355725: Downloading webpage
ERROR: Unable to extract single video id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 797, in extract_info
ie_result = ie.extract(url)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py", line 532, in extract
ie_result = self._real_extract(url)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/facebook.py", line 479, in _real_extract
video_id = self._search_regex(r'video_id:\s*"([0-9]+)"', webpage, 'single video id')
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py", line 1010, in _search_regex
raise RegexNotFoundError('Unable to extract %s' % _name)
youtube_dl.utils.RegexNotFoundError: Unable to extract single video id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Description

WRITE DESCRIPTION HERE
I have downloaded many videos from Facebook with youtube-dl. Today, it failed with the error message provided in the output above.

play the video and click the three dots ... above right of the video  and click "copy link"
and then paste into youtube-dl to download the video

Issue SOLVED.

Yes, that approach works for me too. Thank you.


Issue With Router firmware's for all versions of launchpad

I have a 3 SONOFF Zigbee 3.0 USB Dongle Plus ZBDongle-P (2 with board v1.3 2021-07-29 and 1 with board v1.4 2021-10-20)
All three flash both the most recent as of this message Router and coordinator firmware with no issues with cc2538-bsl.py
When they are flashed with the coordinator launchpad firmware for CC1352P2_CC2652P they perform as expected, but when flashed with any of the router firmware they become soft-bricked and appear to not even try to start the pairing process biased on power consumption.
When you use TI's Z-Tool 2.0 to connect to the dongles, in coordinator firmware they are detected and can be managed, but with router firmware they do not show up at all, the software can not recognize there is even a device there even with the same settings as when it was connected to the coordinator firmware.
I have attempted to follow the instructions on compiling the firmware myself using TI's software using the versions provided at the top of the doc but the menu "power management" does not show up in the software nor is it searchable, i also tried the latest version of both files and there was no luck there.
so i have not been able to create any of my own router firmware files.
Any help with this would be welcome.

please disregard, on the offhanded i had a corrupted install, i re-installed z2mqtt and that resolved the issue


Python select interpreter shows up when settings.json is open

I guess it's handled specially as I don't see it for regular json files but it seems odd that it would show up here since it's not a Python file. The impact on the user here is if Python is installed and synced, there's extra noise that draws the eye even if they have no desire to setup Python on this machine.

The reason this is done is so that users see the active interpreter change when changing the value of python.defaultInterpreterPath setting in the file, otherwise it's difficult to work with the setting. We're eventually moving it inside the language status API anyways so this won't be an issue. Closing it as it's intentional.


Sorting Code not included in the output of getEnvelopeAddress method

Using the android java library, the FormatInterpreter class contains a method getEnvelopeAddress(AddressData address) used to get the formatted address. This method does not include the sorting code that may have been set in the AddressData object.
For example French addresses may include a CEDEX. The widget successfully stores the CEDEX value in the sorting code field within AddressData, but the field is not included when using getEnvelopeAddress() producing an incorrect output.

Thanks for reporting this :)


NodeDataType subtypes

Hello, i'm trying to use nodeeditor for a image processing flow. i have processing blocks that can work on both color images and grayscale images, but also image processing blocks that can only work on grayscale images.
So i'd like to have some kind of subtyping in NodeDataType. i guess implementing would be doable, any hints ? (i'd think changing the sameType function to a isAssignableFrom function, but not sure where to put the logic then)
Thanks,
Frank

Hi Frank,
maybe you'd like to use converters?
Take a look at the examples/calculator. In this example some nodes are able to work with two data types: DecimalData and IntegerData.
We register two converters that are able to change the data type "on the fly".
Consider a graph:

Let me know what you think.
Best,
Dmitry

Hi,
thanks for the reply! i'll try with converters and come back if i have a usecase for subtyping. The example i gave can indeed be solved with converters, there might be cases that are suboptimal with converters but i'll come back when i stumble upon one.
closing this for now.
Frank

Hi,
thanks for the reply! i'll try with converters and come back if i have a usecase for subtyping. The example i gave can indeed be solved with converters, there might be cases that are suboptimal with converters but i'll come back when i stumble upon one.
closing this for now.
Frank

Just check the image channels in setInData and set to error state if you don't want to use converters (since using converter for images means splitting ImageData in multiple types with potentially a lot of implicit conversion)

Hi @Daguerreo , thanks for the hint (I saw "Azul" on your github account which might be related to what i'm trying to do, but i guess its a bit old)


[PE-D][Tester C] NRIC could be inserted as upper case

Labels: severity.VeryLow type.FunctionalityBug
original: ghos7ie/ped#13

Duplicate of #204


all: (mostly) automated clean up

Unset any user-defined Go environment variables devbox.json to make builds more reproducible. Clean up some of the build scripts.
Remove exp/slices and exp/maps now that they're in the Go 1.21 stdlib.
Run find . -name '*.go' -exec gofumpt -extra -w {} \+ to format Go files.
Upgrade dependencies that don't have any backwards incompatible changes.
Organize direct vs. indirect modules and run go mod tidy.

Tests fails just look like timeouts. Probably the dependency changes caused longer build times.

Merging because the CI error was due to a GitHub API rate limit (presumably due to force-pushing debug commits).


FormInput: An aria attribute has been given an invalid value

Describe the bug
Component: FormInput
An invalid aria attribute value was found through running an accessibility test. This instance
can be found with a <div> element being provided with a ‘role’ attribute and an ‘error’
value.
Expected behavior
Ensure that the appropriate roles are used to allow all information to be adequately
conveyed and announced to users of screen reading assistive technologies. The role should
not be set to ‘error’.
Consider changing these to have a role of ‘alert’ if the intention is to have them announce to
screen reader users.
Please conditionally add the element when an error message is to be displayed
Screenshots

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

closed by https://github.com/Capgemini/dcx-react-library/pull/632


resolve paths relative to '~', reduce code duplication with absPath

fix https://github.com/docker/compose-cli/issues/1584

yes indeed, so https://github.com/docker/compose-cli/pull/1585


Images for real example auto saved

Will clean first before merge

Please rebase this on top of the latest master changes, otherwise we'll be merging all the commits from the last PR again (I assume this is what you meant by "clean first")


Fixed type

the word "for" was repeated twice

@piyushmutha : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks good. Thanks @piyushmutha


unable to reproduce the MME result

I cannot find the scrip get_images.py proposed in https://github.com/InternLM/InternLM-XComposer/blob/main/evaluation/mme/MME_Bench.md.

@vanpersie32 We have released the InternLM-XComposer2-VL-7B, which is much more powerful. Please check the evaluation code here https://github.com/InternLM/InternLM-XComposer/tree/main/evaluation


Error

Uncaught InvalidArgumentException: file does not exist in /var/www/html/solveapi/google-drive/vendor/google/apiclient/src/Google/Client.php:859

This error indicates that it can't find the credentials.json file, did you move it into the same directory as your PHP script?

@erickoledadevrel i have this problem too. I dont touch any files inside vendor

In Step 1 the instructions include:

Download the configuration file.
Move the downloaded file to your working directory.

Did you do that?

@erickoledadevrel oh, sorry its my fault! Now i did it but become a new error... missing the required redirect URI. I trying to use it on my local machine with OpenServer

My server work in Ukraine. Maybe time not correctly. Bad i changed to NY. Result is bad.
If run programm with shs "php quickstart.php":
Warning: date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /home/tviyuspi/vesilla.com.ua/test/quickstart.php on line 4
2018-08-05T19:41:25+00:00
Warning: date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /home/tviyuspi/vesilla.com.ua/test/quickstart.php on line 69
Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in /home/tviyuspi/vesilla.com.ua/test/vendor/google/auth/src/Cache/Item.php:129
Stack trace:
#0 /home/tviyuspi/vesilla.com.ua/test/vendor/google/auth/src/Cache/Item.php(129): DateTime->__construct('now + 1500 seco...')
#1 /home/tviyuspi/vesilla.com.ua/test/vendor/google/auth/src/CacheTrait.php(61): Google\Auth\Cache\Item->expiresAfter(1500)
#2 /home/tviyuspi/vesilla.com.ua/test/vendor/google/auth/src/Middleware/ScopedAccessTokenMiddleware.php(171): Google\Auth\Middleware\ScopedAccessTokenMiddleware->setCachedValue('https://www.goo...', 'ya29.GlsOBmddDA...')
#3 /home/t in /home/tviyuspi/vesilla.com.ua/test/vendor/google/auth/src/Cache/Item.php on line 129
If run other programm for Web+php (Google API Client Libraries PHP (Beta)):
Fatal error: Uncaught exception 'Google_Service_Exception' with message '{ "error": { "errors": [ { "domain": "global", "reason": "required", "message": "Login Required", "locationType": "header", "location": "Authorization" } ], "code": 401, "message": "Login Required" } } ' in /home/tviyuspi/vesilla.com.ua/test/vendor/google/apiclient/src/Google/Http/REST.php:131 Stack trace: #0 /home/tviyuspi/vesilla.com.ua/test/vendor/google/apiclient/src/Google/Http/REST.php(107): Google_Http_REST::decodeHttpResponse(Object(GuzzleHttp\Psr7\Response), Object(GuzzleHttp\Psr7\Request), 'Google_Service_...') #1 [internal function]: Google_Http_REST::doExecute(Object(GuzzleHttp\Client), Object(GuzzleHttp\Psr7\Request), 'Google_Service_...') #2 /home/tviyuspi/vesilla.com.ua/test/vendor/google/apiclient/src/Google/Task/Runner.php(176): call_user_func_array(Array, Array) #3 /home/tviyuspi/vesilla.com.ua/test/vendor/google/apiclient/src/Google/Http/REST.php(58): Google_Task_Runner->run() #4 /home/tviyuspi/v in /home/tviyuspi/vesilla.com.ua/test/vendor/google/apiclient/src/Google/Http/REST.php on line 131

I'm not sure where that error is coming from, as I don't see it in the source code. Did you download the credentials.json file from the button in the quickstart instructions?

Closing due to inactivity.


500 Server Error on account creation

Sending the form gives the 500 Server Error

Reloading:

Trying to login:

Trying to recover the password seems to work, but no email arrives:

@jayoshih @aronasorman

Working OK on https://develop.contentworkshop.learningequality.org, closing!


Build failure: biber

Steps To Reproduce
Steps to reproduce the behavior:

nix-build -A biber

Build log
https://hydra.nixos.org/build/222252165/nixlog/1
Additional context
https://hydra.nixos.org/build/222252165
Notify maintainers
@tteggel
Metadata
Confirmed locally against recent master (ddb3455e152edb633e171d51a5c1f12ae8d22641)

system: "x86_64-linux"
host os: Linux 6.1.30, NixOS, 23.11 (Tapir), 23.11.20230528.4e37b4e
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.13.3
nixpkgs: /nix/store/39fplqnf7hlw1gpcnq9zfp4bhlrhxqgs-source

There's already a PR fixing this build failure: https://github.com/NixOS/nixpkgs/pull/235347

looks like this is being addressed in #235347

Can confirm, fixes build-issues on unstable :)

Fix has been merged. Feel free to reopen if the issue persists after the next channel bump


feat: Windows Updates For Integration Tests

Part 1 of the fixes for integration tests.
Binary updates.
Test Plan

How do we know the code works?
Again it doesn't. This just allows swift-demangle and nm.exe to be available to be used.

@flank-it

@flank-it

@flank-it


cmake: python packages now install to the cannonical directory

Addresses issue #1676
Now when make install is run, the caffe2 (and caffe) python modules will be installed into the correct site-packages directory (relative to the prefix) instead of directly in the prefix.

@caffe2bot test this please

@caffe2bot test this please

@caffe2bot test this please

@caffe2bot test this please

@caffe2bot retest this please

@Erotemic Thanks for your contribution :-)

@bddppq Was this merged? It looks like it was simply closed?

Hi @Erotemic - it was committed through our internal system, which might have required a few tweaks to get it landed and so might not match your branch 100%. However, it was definitely committed at
https://github.com/caffe2/caffe2/commit/c20584e07c4a75d27f829fd60bf7a37c97c01523
Again, thank you, and I've verified those changes are in master.

Ah, make sense. Thanks for letting me know. Glad to have helped.


Add e2e tests for Authz v2 (#12271)

Cherry-pick from #12271
Add e2e tests for additional fields in ServiceRole and ServiceRoleBinding.
Add e2e tests for workload selector.
Add e2e tests for new CRD AuthorizationPolicy.
For #12394

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: pitlv2109
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

tests/e2e/tests/pilot/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@pitlv2109: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
f9f51ab94fd1bd2ce8bc802a19ec8f51bc7e9f66
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@pitlv2109: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
f9f51ab94fd1bd2ce8bc802a19ec8f51bc7e9f66
link
/test istio-pilot-multicluster-e2e

prow/istio-integ-k8s-tests.sh
f9f51ab94fd1bd2ce8bc802a19ec8f51bc7e9f66
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: pitlv2109, yangminzhu
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

tests/e2e/tests/pilot/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: diemtvu, pitlv2109, yangminzhu
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

tests/e2e/tests/pilot/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: diemtvu, pitlv2109, yangminzhu
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

tests/e2e/tests/pilot/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/cc @andraxylia @costinm @GregHanson @kyessenov @ijsnellf @nmittler @rshriram @vadimeisenbergibm @zackbutcher for owner approval.
This is the e2e test file for RBAC v2.

I know that this is a cherry-pick, but we should probably be using the new test framework for new tests.

Close this one and will create a new PR using the new testing framework + more tests.
/close

@pitlv2109: Closed this PR.

In response to this:

Close this one and will create a new PR using the new testing framework + more tests.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Add Macau as Region

Hello @tommylung,
Thanks for your contribution.
I just had a look on your GeoJSON file and it seems "strange".

Is that correct ?
And if not, what procedure did you follow to generate that GeoJSON file ?

@jbelien
I updated the GeoJSON file. Could you please check it again? Thanks.

🇲🇴 Beautiful!

I'll take care of the next steps ASAP.

🚀 Deployed: https://welcome.osm.be/macao/list


Router for human handoff

Inspiration from https://github.com/MissionMarsFourthHorizon/operation-max for handoff to human routing

Looks good - little light on comments :P


Vault - Chat#getPlayerInfoInteger - Returns always the default value

the method Chat#getPlayerInfoInteger from Vault does always return the default value with LuckPerms.

Can you show me the code you're using?

MyPlugin.getChat().getPlayerInfoInteger(player, "myplugin.daily", 0);

Is player online?

offline

You cannot use Vault for offline player lookups. Use the native API.

So I need to use the API instead of using Vault to make the plugin useable for multiple permission plugins?

Yes, as I just said, you cannot use Vault for offline player lookups.
The Vault Permission API is not written in a way which allows for i/o in the background. When it was written, it was the norm that permission plugins would store all of their data in memory.
For offline players, I have to perform i/o in order to retrieve data. The majority of plugins which use Vault do so on the main thread (since the majority of permission plugins are not thread safe). Put those two things together and you have a problem.
I cannot block the main thread with i/o calls, or your server will pause for a few seconds every time a plugin performs a Vault operation.

Actually I'm wrong, sorry. I'm using it while the player is online.
Few seconds after the player logged in.

That's how I want to use it atm:

Thanks, that fixed it.


Python: provide guidance on ARM compatibility for binary extensions

Which operating systems/versions of ARM should we include? ARMv6,v7,v8?

This is the guidance I heard. Noting it here and closing:
•	SDK teams provide wheels (pre compiled binaries) for ARM64 (aka ARMv8).
•	Everything below, compile it yourself


Building C# code requires a project or solution file, but VS code won't create project files.

We have written the needed data into your clipboard because it was too large to send. Please paste.
Issue Type: Bug
Installed VS code and then the C# extension and the .Net SDK as per the workflow. When building, I get:
Microsoft (R) Build Engine version 16.0.450+ga8dc7f1d34 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file.
The terminal process terminated with exit code: 1
Terminal will be reused by tasks, press any key to close it.
I tried using View/Palette... to create .Net build artifacts, but that failed with:
Could not locate .NET Core project. Assets were not generated.
Not a great User experience :(.
 You should be creating a project file using the command dotnet new <project type>


Coin-toss Game

Coin-toss Game
This is a coin toss apllication created using HTML, CSS, Javascript.
A coin toss is a luck game in which user chooses an option(heads or tails) and the coin starts flipping. This can be used to decide the winner of a draw match, used in cricket to decide who should bat or bowl first and has many more apllications.
In this super simple game, you just flip a coin for it!
Additionally, you can choose to bet an amount on your coin flip. Now, how confident are you that luck will favour you?
How to play this game?

First the user is asked to choose an option(heads or tails) and computer also chooses an option.
If the coin flips and shows the selected option, your score increases by one.
If the coin flips and shows the other option, nothing happens.
The first player to score 5 wins the game.
The scores are shown on the screen.

I have contributed to this issue under Hacktoberfest'2021. Kindly review my code, accept the pr and add the hacktoberfest tag

Great work
do give a star to the repo 👍


CPU instructions AVX and AVX2 not supported on a windows machine

Hi,
Thanks for such great package!
I have a windows 64 machine with Python 3.6.5 and nmslib 2.1.1
The nmslib package was installed using "pip install nmslib" without issues. When, I use another package that makes use of nmslib, I get the message below:
Your CPU supports instructions that this binary was not compiled to use: AVX AVX2
For maximum performance, you can install NMSLIB from sources
pip install --no-binary :all: nmslib
So, I decided to uninstall nmslib and re-install it using the command mentioned above. Then, I ran the other package that makes use of nmslib, and I still get the same message below.
What is the meaning of this message?
Ivan

Hi @ivan-marroquin it just doesn't use these instructions, sorry. We have binaries for Windows, which are somewhat less efficient. Hopefully, we will be able to select an instruction subset dynamically one day (though it's tricky).


Text Gizmos

What problem does this solve or what need does it fill?
Gizmos are mainly used (atleast from my experience) to quickly add information vizualization without much effort
They fill this work great, but sometimes we want to gizmo more complex data visible than shapes can handle.
Things like names, lengths, values etc...
What solution would you like
gizmos.text(position, size, "text");
gizmos.text_2d(position, size, "text");

Would draw text always upright always facing the camera.
The size given would be in world space, so the text would be sized according to distance like any other object.
The 3d/2d variants simply change the position to be Vec2 vs Vec3
What alternative(s) have you considered?
Logging is not as indicative, I can't thing of any thing that could get the diversity of information like a text gizmo would.
Additional context
The simplest way to get something like it working would be to encode every alpha-numeric character as a shape (a-z A-Z 0.9 and maybe some symbols). Then only allow these characters to be displayed.
Fonts are kind of a pain to implement, though bevy already has abstractions around them but I don't know enough to know if it's a viable approach.
If the manual symbol approach is chosen then I could probably implement it and open a PR for it.

Was just googling for this feature and found this issue. I would really love this!