New component: Toast

See https://github.com/radix-ui/primitives/discussions/375

Some preliminary research on the Toast:

Google's proposed <std-toast> element is the most comprehensive existing overview of popular Toast implementations in the wild I could find.
Lots of discussion on <std-toast> exists, with many noting accessibility issues in the concept itself. There are many potential problems we can attempt to mitigate, but the fact is that the very nature of messages that disappear after a set amount of time ensures that some users will likely miss those messages. This is a good overview of the potential WCAG issues and mitigation strategies by Adrian Roselli.
Based on Adrian's article and pattern's that exist in native environments, I believe the best thing we can do for a generic toast package is to provide not only the Toast message and its top-level container (ToastEmitter?), but also a separate container that contains all toasts that haven't been manually dismissed by the user. This is similar to the MacOS notification center.

I really like some of the implementations in react-hot-toast. I'd like to take some heavy inspiration from there and build on it to design our API.
Here's an initial rough sketch of what I'm envisioning as far as the API goes:
function App() {
  // expose ToastProvider to manage all global toast state
  return (
    <ToastProvider>
      <AppInner />
    </ToastProvider>
  );
}

function AppInner() {
  const [notificationsVisible, setNotificationsVisible] = React.useState(false);
  return (

        <MainNav />
        <button onClick={() => setNotificationsVisible(!notificationsVisible)}>
          Notifications
        </button>
        {notificationsVisible ? (

            {/* Space for all active toasts to appear until user dismisses */}
            <ToastCenter>{({ toasts }) => toasts.map((toast) => <Toast {...toast} />)}</ToastCenter>

        ) : null}

        <Content />

        <Sidebar />

      {/* Space for current active toasts to appear */}
      <ToastEmitter>{({ toasts }) => toasts.map((toast) => <Toast {...toast} />)}</ToastEmitter>

  );
}

Similar to Announce, messages are read globally from an aria-live container. A key difference for Toast I think is that we will actually need to do some global state management, as we'll have at least a few key pieces of stateful global data to deal with:

Current active toasts (toasts that appear until either the user dismisses them or their timer runs out)
All active toasts (all toasts that haven't been dismissed manually by the user)
A timer for each toast, as well as the ability to pause/resume the timer based on a user's interaction with it

More reading:

https://www.scottohara.me/blog/2019/07/08/a-toast-to-a11y-toasts.html

Some preliminary research on the Toast:

Google's proposed <std-toast> element is the most comprehensive existing overview of popular Toast implementations in the wild I could find.
Lots of discussion on <std-toast> exists, with many noting accessibility issues in the concept itself. There are many potential problems we can attempt to mitigate, but the fact is that the very nature of messages that disappear after a set amount of time ensures that some users will likely miss those messages. This is a good overview of the potential WCAG issues and mitigation strategies by Adrian Roselli.
Based on Adrian's article and pattern's that exist in native environments, I believe the best thing we can do for a generic toast package is to provide not only the Toast message and its top-level container (ToastEmitter?), but also a separate container that contains all toasts that haven't been manually dismissed by the user. This is similar to the MacOS notification center.

I really like some of the implementations in react-hot-toast. I'd like to take some heavy inspiration from there and build on it to design our API.
Here's an initial rough sketch of what I'm envisioning as far as the API goes:
function App() {
  // expose ToastProvider to manage all global toast state
  return (
    <ToastProvider>
      <AppInner />
    </ToastProvider>
  );
}

function AppInner() {
  const [notificationsVisible, setNotificationsVisible] = React.useState(false);
  return (

        <MainNav />
        <button onClick={() => setNotificationsVisible(!notificationsVisible)}>
          Notifications
        </button>
        {notificationsVisible ? (

            {/* Space for all active toasts to appear until user dismisses */}
            <ToastCenter>{({ toasts }) => toasts.map((toast) => <Toast {...toast} />)}</ToastCenter>

        ) : null}

        <Content />

        <Sidebar />

      {/* Space for current active toasts to appear */}
      <ToastEmitter>{({ toasts }) => toasts.map((toast) => <Toast {...toast} />)}</ToastEmitter>

  );
}

Similar to Announce, messages are read globally from an aria-live container. A key difference for Toast I think is that we will actually need to do some global state management, as we'll have at least a few key pieces of stateful global data to deal with:

Current active toasts (toasts that appear until either the user dismisses them or their timer runs out)
All active toasts (all toasts that haven't been dismissed manually by the user)
A timer for each toast, as well as the ability to pause/resume the timer based on a user's interaction with it

More reading:

https://www.scottohara.me/blog/2019/07/08/a-toast-to-a11y-toasts.html

Oooo, I like the notification center idea. I'm not sure about the "emit" proposal though. That's all starting to feel a bit like we're supplying imperative application code. I would favour a more declarative component-based approach with the help of portals. Plus, I would expect that when a Toast is rendered, that would implicitly be the emitter.
Something along the lines of:
function App() {
	return (
		<ToastProvider>

				<button>Notifications</button>
				{isNotificationCenterOpen && <ToastCenter />}

				<Profile />
				<ToastPortal />

		</ToastProvider>
	);
}

function Profile() {
	// whatever declarative data management thing consumer uses (or just state)
	const [{ error, success }, saveProfile] = useSaveProfile();

	return (
		<form>
			{/* ... */}
			<button onClick={() => saveProfile()}>Save</button>
			{success && <Toast message="Whoop! It worked!" />}
		</form>
	);
}

My thinking here is that:

ToastProvider provides the necessary context.
ToastCenter renders a container that Toasts get copied into.
ToastPortal (not sure on name here) renders a container that timed Toasts get portalled into.
Toast portals into ToastPortal and gets cloned into ToastCenter.

I like this approach because:

The Toast can be consumed where it is needed alongside the code that triggers it and its styles/events/props will apply in both contexts (center and portal).
It will work completely uncontrolled without the consumer needing to map out the toasts in two separate contexts manually.

Since I'm so terrible at explaining things, I've thrown together a quick sandbox to demonstrate my thinking for further discussion. There may be issues with this approach that we would need to flesh out, I've literally just built it on the spot so wouldn't know unless we investigated it further https://codesandbox.io/s/relaxed-worker-6m27d?file=/src/App.js

Oooo, I like the notification center idea. I'm not sure about the "emit" proposal though. That's all starting to feel a bit like we're supplying imperative application code. I would favour a more declarative component-based approach with the help of portals. Plus, I would expect that when a Toast is rendered, that would implicitly be the emitter.
Something along the lines of:
function App() {
	return (
		<ToastProvider>

				<button>Notifications</button>
				{isNotificationCenterOpen && <ToastCenter />}

				<Profile />
				<ToastPortal />

		</ToastProvider>
	);
}

function Profile() {
	// whatever declarative data management thing consumer uses (or just state)
	const [{ error, success }, saveProfile] = useSaveProfile();

	return (
		<form>
			{/* ... */}
			<button onClick={() => saveProfile()}>Save</button>
			{success && <Toast message="Whoop! It worked!" />}
		</form>
	);
}

My thinking here is that:

ToastProvider provides the necessary context.
ToastCenter renders a container that Toasts get copied into.
ToastPortal (not sure on name here) renders a container that timed Toasts get portalled into.
Toast portals into ToastPortal and gets cloned into ToastCenter.

I like this approach because:

The Toast can be consumed where it is needed alongside the code that triggers it and its styles/events/props will apply in both contexts (center and portal).
It will work completely uncontrolled without the consumer needing to map out the toasts in two separate contexts manually.

Since I'm so terrible at explaining things, I've thrown together a quick sandbox to demonstrate my thinking for further discussion. There may be issues with this approach that we would need to flesh out, I've literally just built it on the spot so wouldn't know unless we investigated it further https://codesandbox.io/s/relaxed-worker-6m27d?file=/src/App.js

@jjenzz appreciate the example, I quite like that approach as well! I'm going to start by mapping out a state chart and then start working on the API with your alternative as a starting point 👍

@jjenzz appreciate the example, I quite like that approach as well! I'm going to start by mapping out a state chart and then start working on the API with your alternative as a starting point 👍

@jjenzz I can't seem to be able to load that sandbox, is it just me?

@jjenzz I can't seem to be able to load that sandbox, is it just me?

@benoitgrelard I must have broken the link by mistake, sorry. Edited and it's working now

@benoitgrelard I must have broken the link by mistake, sorry. Edited and it's working now

Expanding on the API design a bit. @colmtuite would love your input here as well!
This is intended to showcase different possible APIs I'm imagining. Real implementation would probably be a lot simpler in practice, but a few thoughts to explain what I'm thinking here:

An individual Toast will be rendered alongside the component that triggers it, which is far away from the portal where they appear. This raises the question: which component is responsible for composing the various parts?

In my mind, it generally makes sense for toasts to be composed where they show up visually, which is either in the ToastCenter (all toasts) or the ToastWarmer (visually active toasts). This is because they generally appear differently in these contexts, and all toasts within each contexts generally share similar style attributes.
That said, in some cases it may be desirable to compose a toast where it is rendered. In those cases, the API below uses children as a render prop that would be used in lieu of the composition dictated in the ToastWarmer. This would be entirely left up to the consumer to decide how to deal with this, but this exposes a mechanism for overriding any rendering done in either visual container.

As we will need to manage some state for this component, we also need to expose it to the various parts. I like to expose it via hooks and render props and let consumers decide which works best in a given context, but we can stick with just hooks for simplicity if everyone else prefers. Examples below show both.
Potential names for the area where toasts show up visually as they are triggered:

ToastWarmer (kind of silly, but so is the name Toast so 🤷♂)
ToastPortal (more technically accurate but not really reflective of the fact that we're only rendering the ephemeral toasts vs. all toasts like in ToastCenter, which could also be a portal!
ToastActivePortal (longer names are blah but it's a bit more specific?)
[your brilliant idea here!]

function App() {
  // expose ToastProvider to manage all global toast state
  return (
    <ToastProvider>
      <AppInner />
    </ToastProvider>
  );
}

function NotificationCenter() {
  // all toasts manageged by the state machine in ToastProvider
  // so they could be accessible here via a hook, or...
  const { allToasts, dismiss } = useToasts();

  // Not doing anything magic! Lets consumers build the notification
  // center however they'd like.
  const toastsByDate = allToasts.reduce(someCoolReducer);

  <ToastCenter>
    {({ toasts: allToasts, dismiss }) => {
      // ...as a render children prop
      const toastsByDate = allToasts.reduce(someCoolReducer);

      return toastsByDate.map(({ date, toasts }) => (
        <Box>
          <Flex>
            <Title>{date.fullDateText}</Title>
            {/* Toasts can be dismissed imperatively by id or array of ids */}
            <Button onClick={() => dismiss(toasts.reduce(getToastIds))}>
              Dismiss All
            </Button>
          </Flex>
          {toasts.map((toast) => (
            <ToastCenterItem id={toast.id} as="div" type={toast.type}>
              {/* Toasts can be dismissed declaratively */}
              <ToastDismiss aria-label="Dismiss notification" />
              <Box>
                <Heading>{toast.label}</Heading>
                <Text>{toast.message}</Text>
              </Box>
            </ToastCenterItem>
          ))}
        </Box>
      ));
    }}
  </ToastCenter>;
}

function NotificationArea() {
  const { activeToasts, dissmiss } = useToasts();
  return (
    <ToastWarmer
      duration={5000} // Duration for all toasts to show unless overridden
      as="div"
    >
      {/* render props API here too? maybe? */}
      {({ activeToasts }) => {
        return activeToasts.map((toast, i, arr) => (
          <>
            <ToastWarmerItem
              id={toast.id}
              as="div"
              // Declarative type prop for common toast types for better
              // internal aria-live handling. "error" or "success" might be
              // "assertive", whereas "loading" or "basic" might be polite.
              type={toast.type} // "loading" | "success" | "error" | "basic"
              // Aria can be overridden as well
              role={toast.role}
              role="alert"
              aria-live={toast["aria-live"]}
              aria-live="off"
              // Individual toast duration could override ToastWarmer duration
              duration={toast.duration} // number
              // This could be set on individual toasts as they are rendered, or
              // in ToastWarmerItem for general overrides
              duration={toast.type === "error" && 10000} // number
              // For some active toasts, maybe the duration is dictated by state
              // somewhere, and we can control it with a progress prop.
              progress={toast.progress} // number
              // This could be set on individual toasts as they are rendered, or
              // in ToastWarmerItem for general overrides
              progress={toast.type === "loading" && getProgress(toast.id)} // number
            >
              {toast.children ? toast.children(toast) : (
                <>
                  <ToastDismiss aria-label="Dismiss notification" />
                  <Box>
                    <Heading>{toast.label}</Heading>
                    <Text>{toast.message}</Text>
                  </Box>
                </>
              )}
            </ToastWarmerItem>
            {i !== arr.length - 1 ? <Spacer /> : null}
          </>
        ));
      }}
    </ToastWarmer>
  );
}

function SaveButton() {
  // whatever declarative data management thing consumer uses (or just state)
  const [state, saveProfile] = useSaveProfile();

  let toast = null;

  if (state.value === "loading") {
    toast = (
      <Toast
        label="Saving"
        message={`File is saving, currently at ${Math.round(
          state.context.progress * 100
        )}%`}
        progress={state.context.progress}
        type="loading"
      />
    );
  }

  if (state.value === "error") {
    return (
      <Toast
        label="Save error"
        message={state.context.error.message}
        progress={state.context.progress}
        type="error"
      />
    );
  }

  if (state.value === "success") {
    return (
      <Toast
        label="File saved"
        message="Yay, your file has been saved!"
        type="success"
      >
        {({ label, message }) => (
          <>
            <ToastDismiss aria-label="Dismiss notification" />
            <Box>
              <Heading>{toast.label}</Heading>
              <Text>{toast.message}</Text>
              <SuccessAnimationIcon />
            </Box>
          </>
        )}
      </Toast>
    );
  }

  return (
    <>
      <Button onClick={() => saveProfile()}>
        <Text>Save</Text>
      </Button>
      {toast}
    </>
  );
}

Expanding on the API design a bit. @colmtuite would love your input here as well!
This is intended to showcase different possible APIs I'm imagining. Real implementation would probably be a lot simpler in practice, but a few thoughts to explain what I'm thinking here:

An individual Toast will be rendered alongside the component that triggers it, which is far away from the portal where they appear. This raises the question: which component is responsible for composing the various parts?

In my mind, it generally makes sense for toasts to be composed where they show up visually, which is either in the ToastCenter (all toasts) or the ToastWarmer (visually active toasts). This is because they generally appear differently in these contexts, and all toasts within each contexts generally share similar style attributes.
That said, in some cases it may be desirable to compose a toast where it is rendered. In those cases, the API below uses children as a render prop that would be used in lieu of the composition dictated in the ToastWarmer. This would be entirely left up to the consumer to decide how to deal with this, but this exposes a mechanism for overriding any rendering done in either visual container.

As we will need to manage some state for this component, we also need to expose it to the various parts. I like to expose it via hooks and render props and let consumers decide which works best in a given context, but we can stick with just hooks for simplicity if everyone else prefers. Examples below show both.
Potential names for the area where toasts show up visually as they are triggered:

ToastWarmer (kind of silly, but so is the name Toast so 🤷♂)
ToastPortal (more technically accurate but not really reflective of the fact that we're only rendering the ephemeral toasts vs. all toasts like in ToastCenter, which could also be a portal!
ToastActivePortal (longer names are blah but it's a bit more specific?)
[your brilliant idea here!]

function App() {
  // expose ToastProvider to manage all global toast state
  return (
    <ToastProvider>
      <AppInner />
    </ToastProvider>
  );
}

function NotificationCenter() {
  // all toasts manageged by the state machine in ToastProvider
  // so they could be accessible here via a hook, or...
  const { allToasts, dismiss } = useToasts();

  // Not doing anything magic! Lets consumers build the notification
  // center however they'd like.
  const toastsByDate = allToasts.reduce(someCoolReducer);

  <ToastCenter>
    {({ toasts: allToasts, dismiss }) => {
      // ...as a render children prop
      const toastsByDate = allToasts.reduce(someCoolReducer);

      return toastsByDate.map(({ date, toasts }) => (
        <Box>
          <Flex>
            <Title>{date.fullDateText}</Title>
            {/* Toasts can be dismissed imperatively by id or array of ids */}
            <Button onClick={() => dismiss(toasts.reduce(getToastIds))}>
              Dismiss All
            </Button>
          </Flex>
          {toasts.map((toast) => (
            <ToastCenterItem id={toast.id} as="div" type={toast.type}>
              {/* Toasts can be dismissed declaratively */}
              <ToastDismiss aria-label="Dismiss notification" />
              <Box>
                <Heading>{toast.label}</Heading>
                <Text>{toast.message}</Text>
              </Box>
            </ToastCenterItem>
          ))}
        </Box>
      ));
    }}
  </ToastCenter>;
}

function NotificationArea() {
  const { activeToasts, dissmiss } = useToasts();
  return (
    <ToastWarmer
      duration={5000} // Duration for all toasts to show unless overridden
      as="div"
    >
      {/* render props API here too? maybe? */}
      {({ activeToasts }) => {
        return activeToasts.map((toast, i, arr) => (
          <>
            <ToastWarmerItem
              id={toast.id}
              as="div"
              // Declarative type prop for common toast types for better
              // internal aria-live handling. "error" or "success" might be
              // "assertive", whereas "loading" or "basic" might be polite.
              type={toast.type} // "loading" | "success" | "error" | "basic"
              // Aria can be overridden as well
              role={toast.role}
              role="alert"
              aria-live={toast["aria-live"]}
              aria-live="off"
              // Individual toast duration could override ToastWarmer duration
              duration={toast.duration} // number
              // This could be set on individual toasts as they are rendered, or
              // in ToastWarmerItem for general overrides
              duration={toast.type === "error" && 10000} // number
              // For some active toasts, maybe the duration is dictated by state
              // somewhere, and we can control it with a progress prop.
              progress={toast.progress} // number
              // This could be set on individual toasts as they are rendered, or
              // in ToastWarmerItem for general overrides
              progress={toast.type === "loading" && getProgress(toast.id)} // number
            >
              {toast.children ? toast.children(toast) : (
                <>
                  <ToastDismiss aria-label="Dismiss notification" />
                  <Box>
                    <Heading>{toast.label}</Heading>
                    <Text>{toast.message}</Text>
                  </Box>
                </>
              )}
            </ToastWarmerItem>
            {i !== arr.length - 1 ? <Spacer /> : null}
          </>
        ));
      }}
    </ToastWarmer>
  );
}

function SaveButton() {
  // whatever declarative data management thing consumer uses (or just state)
  const [state, saveProfile] = useSaveProfile();

  let toast = null;

  if (state.value === "loading") {
    toast = (
      <Toast
        label="Saving"
        message={`File is saving, currently at ${Math.round(
          state.context.progress * 100
        )}%`}
        progress={state.context.progress}
        type="loading"
      />
    );
  }

  if (state.value === "error") {
    return (
      <Toast
        label="Save error"
        message={state.context.error.message}
        progress={state.context.progress}
        type="error"
      />
    );
  }

  if (state.value === "success") {
    return (
      <Toast
        label="File saved"
        message="Yay, your file has been saved!"
        type="success"
      >
        {({ label, message }) => (
          <>
            <ToastDismiss aria-label="Dismiss notification" />
            <Box>
              <Heading>{toast.label}</Heading>
              <Text>{toast.message}</Text>
              <SuccessAnimationIcon />
            </Box>
          </>
        )}
      </Toast>
    );
  }

  return (
    <>
      <Button onClick={() => saveProfile()}>
        <Text>Save</Text>
      </Button>
      {toast}
    </>
  );
}

This is cool!
A few questions/suggestions:

re. the notifications center idea thing. Is this something that users "have" to do, ie. for accessibility reasons, or is it just us proposing that it might be useful? Seems quite prescriptive to me for now.
will this use our Announce component somehow under the hood?
re. ToastWarmer, ToastPortal, ToastActivePortal naming. How about just ActiveToasts?
there are quite a few concepts in the Toast, like label, message, type, etc. Are these standardised? It feels again quite prescriptive to me for now. Ie. what if someone needs the message to be formatted somehow and therefore needs JSX, can't be just a string, etc.
if we're going to do declarative Toast at the point of render to raise them, how are we ensuring that they don't re-trigger if the parent re-renders? I can't see the id so I'm assuming we generate it, in which case how do we distinguish already raised toasts?

Not a huge fan of the render prop for the Toast but again, this comes as an issue we have because we have this notifications center thing, so will depend on that I guess.

This is cool!
A few questions/suggestions:

re. the notifications center idea thing. Is this something that users "have" to do, ie. for accessibility reasons, or is it just us proposing that it might be useful? Seems quite prescriptive to me for now.
will this use our Announce component somehow under the hood?
re. ToastWarmer, ToastPortal, ToastActivePortal naming. How about just ActiveToasts?
there are quite a few concepts in the Toast, like label, message, type, etc. Are these standardised? It feels again quite prescriptive to me for now. Ie. what if someone needs the message to be formatted somehow and therefore needs JSX, can't be just a string, etc.
if we're going to do declarative Toast at the point of render to raise them, how are we ensuring that they don't re-trigger if the parent re-renders? I can't see the id so I'm assuming we generate it, in which case how do we distinguish already raised toasts?

Not a huge fan of the render prop for the Toast but again, this comes as an issue we have because we have this notifications center thing, so will depend on that I guess.

re. the notifications center idea thing. Is this something that users "have" to do, ie. for accessibility reasons, or is it just us proposing that it might be useful? Seems quite prescriptive to me for now.

It certainly is prescriptive, but the problem is that without it or something like it, it's essentially impossible to make a toast that doesn't violate WCAG. This article outlines several problems with the core design of the toast that I'm not sure can be overcome without it.

will this use our Announce component somehow under the hood?

I believe so, but that will require some screen reader testing to be sure. The potential concern is timing -- you need to ensure a toast is visible long enough for both a user and a screen reader to read it, which is ultimately something consumers will have to consider in their designs. This could be particularly tricky when aria-live is set to "polite", as the SR may be reading something else that eats into the Toast's time on screen.

there are quite a few concepts in the Toast, like label, message, type, etc. Are these standardised? It feels again quite prescriptive to me for now. Ie. what if someone needs the message to be formatted somehow and therefore needs JSX, can't be just a string, etc.

label I'm not 100% sure we will need. message would be the simplest interface because the SR announcement should always be test. We should support any kind of composition in Toast and use element.innerTextif there is no message, but that's potentially troublesome if the inner HTML has a composition that doesn't make sense when read as a single sentence. I envision message could be used in lieu of composition if the toast is simple, or alongside composition as a simplified supplement for better SR support.
Consider:
<Toast>

    <Heading>Warning: Error</Heading>
    <ToastDismiss>
      <VisuallyHidden>Dismiss error</VisuallyHidden>
      <CloseIcon />
    </ToastDismiss>

    <Text>Oh no! You have a major problem!</Text>
    <ToastDismiss>Dismiss error</ToastDismiss>

</Toast>

Using the HTML inner text here would be needlessly verbose, repetitive, and would read like a run-on sentence. The way Announce works is that it needs to mirror some text into a visually hidden live-region. It's quite a bit different than aria-describedby or aria-label, so this is what I imagine the message prop can solve.
<Toast message="Oh no! You have a major problem!">
  {/* compose whatever you'd like */}
</Toast>

As for type, this too is probably a bit prescriptive, but I think it can be helpful for users for a few reasons.

I think the vast majority of needs will fit into one of these categories, so for most people they don't need to think about anything else other than whether or not a toast is an error message, success message, etc.
We can use this type to handle ARIA for them. For example, an error or success message probably make the most sense with role="alert" aria-live="assertive", while other types of messages probably shouldn't interrupt the user, so we'd use role="status" aria-live="polite" (or possibly role="log").

if we're going to do declarative Toast at the point of render to raise them, how are we ensuring that they don't re-trigger if the parent re-renders? I can't see the id so I'm assuming we generate it, in which case how do we distinguish already raised toasts?

No differently really than rendering anything else, really. They should always be conditionally rendered by the consumer based on some state, but we'll also be managing them internally via context where we will need to generate IDs for those. This does raise an interesting question though.
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {status === 'success' && <Toast message="Whoop! It worked!" />}
    </form>
  );
}

In Jenna's example above, Toast renders when status is success, but of course when it times out in our app-level toast context status may still be success, so we'd just return null internally if the timer for that toast ID has run its course or if the user has dismissed that message.
Now, what happens when the user clicks the Save button again? status presumably changes to loading or something, but when it returns back to success we are still rendering the same toast based on the generated id, so presumably it wouldn't appear for the second save action 🧐
The consumer could do something like...
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  const [toastId, setToastId] = React.useState(1);
  React.useEffect(() => {
    if (status === 'success') {
      setToastId(i => i++)
    }
  }, [status]);
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {status === 'success' && <Toast id={`save-${toastId}`} message="Whoop! It worked!" />}
    </form>
  );
}

The consumer uses their own ID to signal that the toast is new on each success status. But now we have a new problem -- what if the previous toast is still on screen when this happens? It would go away because the ID of the toast we're rendering in this component has changed. Now it might get a little funkier.
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  const [toastIds, setToastIds] = React.useState([]);
  React.useEffect(() => {
    if (status === 'success') {
      setToastIds(t => [...t, t[t.length - 1] + 1])
    }
  }, [status]);
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {toastIds.map((id) => <Toast key={id} id={`save-${id}`} message="Whoop! It worked!" />)}
    </form>
  );
}

This probably works a little better but feels awkward that we're kind of offloading React complexity to work around what is probably unexpected behavior, but I think this ends up being a potentially common scenario. Kind of wondering if the originally proposed "imperative" API doesn't actually become a bit simpler here.
import { emitToast, Toast } from '@radix-ui/react-toast';

function Profile() {
  const [status, saveProfile] = useSaveProfile();
  React.useEffect(() => {
    if (status === 'success') {
      emitToast(() => (
        <Toast message="Whoop! It worked!" />
      ))
    }
  }, [status]);
  return (
    <form>
      <button onClick={() => saveProfile()}>Save</button>
    </form>
  );
}

We could provide a hook to simplify this somewhat:
import { useToastEmit, Toast } from '@radix-ui/react-toast';

function Profile() {
  const [status, saveProfile] = useSaveProfile();
  useToastEmit(
    // condition
    status === 'success',
    // callback to render the toast
    () => <Toast message="Whoop! It worked!" />
  );
  return (
    <form>
      <button onClick={() => saveProfile()}>Save</button>
    </form>
  );
}

re. the notifications center idea thing. Is this something that users "have" to do, ie. for accessibility reasons, or is it just us proposing that it might be useful? Seems quite prescriptive to me for now.

It certainly is prescriptive, but the problem is that without it or something like it, it's essentially impossible to make a toast that doesn't violate WCAG. This article outlines several problems with the core design of the toast that I'm not sure can be overcome without it.

will this use our Announce component somehow under the hood?

I believe so, but that will require some screen reader testing to be sure. The potential concern is timing -- you need to ensure a toast is visible long enough for both a user and a screen reader to read it, which is ultimately something consumers will have to consider in their designs. This could be particularly tricky when aria-live is set to "polite", as the SR may be reading something else that eats into the Toast's time on screen.

there are quite a few concepts in the Toast, like label, message, type, etc. Are these standardised? It feels again quite prescriptive to me for now. Ie. what if someone needs the message to be formatted somehow and therefore needs JSX, can't be just a string, etc.

label I'm not 100% sure we will need. message would be the simplest interface because the SR announcement should always be test. We should support any kind of composition in Toast and use element.innerTextif there is no message, but that's potentially troublesome if the inner HTML has a composition that doesn't make sense when read as a single sentence. I envision message could be used in lieu of composition if the toast is simple, or alongside composition as a simplified supplement for better SR support.
Consider:
<Toast>

    <Heading>Warning: Error</Heading>
    <ToastDismiss>
      <VisuallyHidden>Dismiss error</VisuallyHidden>
      <CloseIcon />
    </ToastDismiss>

    <Text>Oh no! You have a major problem!</Text>
    <ToastDismiss>Dismiss error</ToastDismiss>

</Toast>

Using the HTML inner text here would be needlessly verbose, repetitive, and would read like a run-on sentence. The way Announce works is that it needs to mirror some text into a visually hidden live-region. It's quite a bit different than aria-describedby or aria-label, so this is what I imagine the message prop can solve.
<Toast message="Oh no! You have a major problem!">
  {/* compose whatever you'd like */}
</Toast>

As for type, this too is probably a bit prescriptive, but I think it can be helpful for users for a few reasons.

I think the vast majority of needs will fit into one of these categories, so for most people they don't need to think about anything else other than whether or not a toast is an error message, success message, etc.
We can use this type to handle ARIA for them. For example, an error or success message probably make the most sense with role="alert" aria-live="assertive", while other types of messages probably shouldn't interrupt the user, so we'd use role="status" aria-live="polite" (or possibly role="log").

if we're going to do declarative Toast at the point of render to raise them, how are we ensuring that they don't re-trigger if the parent re-renders? I can't see the id so I'm assuming we generate it, in which case how do we distinguish already raised toasts?

No differently really than rendering anything else, really. They should always be conditionally rendered by the consumer based on some state, but we'll also be managing them internally via context where we will need to generate IDs for those. This does raise an interesting question though.
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {status === 'success' && <Toast message="Whoop! It worked!" />}
    </form>
  );
}

In Jenna's example above, Toast renders when status is success, but of course when it times out in our app-level toast context status may still be success, so we'd just return null internally if the timer for that toast ID has run its course or if the user has dismissed that message.
Now, what happens when the user clicks the Save button again? status presumably changes to loading or something, but when it returns back to success we are still rendering the same toast based on the generated id, so presumably it wouldn't appear for the second save action 🧐
The consumer could do something like...
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  const [toastId, setToastId] = React.useState(1);
  React.useEffect(() => {
    if (status === 'success') {
      setToastId(i => i++)
    }
  }, [status]);
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {status === 'success' && <Toast id={`save-${toastId}`} message="Whoop! It worked!" />}
    </form>
  );
}

The consumer uses their own ID to signal that the toast is new on each success status. But now we have a new problem -- what if the previous toast is still on screen when this happens? It would go away because the ID of the toast we're rendering in this component has changed. Now it might get a little funkier.
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  const [toastIds, setToastIds] = React.useState([]);
  React.useEffect(() => {
    if (status === 'success') {
      setToastIds(t => [...t, t[t.length - 1] + 1])
    }
  }, [status]);
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {toastIds.map((id) => <Toast key={id} id={`save-${id}`} message="Whoop! It worked!" />)}
    </form>
  );
}

This probably works a little better but feels awkward that we're kind of offloading React complexity to work around what is probably unexpected behavior, but I think this ends up being a potentially common scenario. Kind of wondering if the originally proposed "imperative" API doesn't actually become a bit simpler here.
import { emitToast, Toast } from '@radix-ui/react-toast';

function Profile() {
  const [status, saveProfile] = useSaveProfile();
  React.useEffect(() => {
    if (status === 'success') {
      emitToast(() => (
        <Toast message="Whoop! It worked!" />
      ))
    }
  }, [status]);
  return (
    <form>
      <button onClick={() => saveProfile()}>Save</button>
    </form>
  );
}

We could provide a hook to simplify this somewhat:
import { useToastEmit, Toast } from '@radix-ui/react-toast';

function Profile() {
  const [status, saveProfile] = useSaveProfile();
  useToastEmit(
    // condition
    status === 'success',
    // callback to render the toast
    () => <Toast message="Whoop! It worked!" />
  );
  return (
    <form>
      <button onClick={() => saveProfile()}>Save</button>
    </form>
  );
}

re. the notifications center idea thing. Is this something that users "have" to do, ie. for accessibility reasons, or is it just us proposing that it might be useful? Seems quite prescriptive to me for now.

It certainly is prescriptive, but the problem is that without it or something like it, it's essentially impossible to make a toast that doesn't violate WCAG. This article outlines several problems with the core design of the toast that I'm not sure can be overcome without it.

I see. Does that mean if someone doesn't include a notification center in their app, they won't be accessible then?

will this use our Announce component somehow under the hood?

I believe so, but that will require some screen reader testing to be sure. The potential concern is timing -- you need to ensure a toast is visible long enough for both a user and a screen reader to read it, which is ultimately something consumers will have to consider in their designs. This could be particularly tricky when aria-live is set to "polite", as the SR may be reading something else that eats into the Toast's time on screen.

Yeah, tricky for sure…

there are quite a few concepts in the Toast, like label, message, type, etc. Are these standardised? It feels again quite prescriptive to me for now. Ie. what if someone needs the message to be formatted somehow and therefore needs JSX, can't be just a string, etc.

label I'm not 100% sure we will need. message would be the simplest interface because the SR announcement should always be test. We should support any kind of composition in Toast and use element.innerTextif there is no message, but that's potentially troublesome if the inner HTML has a composition that doesn't make sense when read as a single sentence. I envision message could be used in lieu of composition if the toast is simple, or alongside composition as a simplified supplement for better SR support.
Consider:
<Toast>

    <Heading>Warning: Error</Heading>
    <ToastDismiss>
      <VisuallyHidden>Dismiss error</VisuallyHidden>
      <CloseIcon />
    </ToastDismiss>

    <Text>Oh no! You have a major problem!</Text>
    <ToastDismiss>Dismiss error</ToastDismiss>

</Toast>

Using the HTML inner text here would be needlessly verbose, repetitive, and would read like a run-on sentence. The way Announce works is that it needs to mirror some text into a visually hidden live-region. It's quite a bit different than aria-describedby or aria-label, so this is what I imagine the message prop can solve.
<Toast message="Oh no! You have a major problem!">
  {/* compose whatever you'd like */}
</Toast>

I see, yeah makes sense to at least have a way to provide an override text to announce.

As for type, this too is probably a bit prescriptive, but I think it can be helpful for users for a few reasons.

I think the vast majority of needs will fit into one of these categories, so for most people they don't need to think about anything else other than whether or not a toast is an error message, success message, etc.
We can use this type to handle ARIA for them. For example, an error or success message probably make the most sense with role="alert" aria-live="assertive", while other types of messages probably shouldn't interrupt the user, so we'd use role="status" aria-live="polite" (or possibly role="log").

Ah yes that makes a lot of sense.

if we're going to do declarative Toast at the point of render to raise them, how are we ensuring that they don't re-trigger if the parent re-renders? I can't see the id so I'm assuming we generate it, in which case how do we distinguish already raised toasts?

No differently really than rendering anything else, really. They should always be conditionally rendered by the consumer based on some state, but we'll also be managing them internally via context where we will need to generate IDs for those. This does raise an interesting question though.
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {status === 'success' && <Toast message="Whoop! It worked!" />}
    </form>
  );
}

In Jenna's example above, Toast renders when status is success, but of course when it times out in our app-level toast context status may still be success, so we'd just return null internally if the timer for that toast ID has run its course or if the user has dismissed that message.

Ohhh that's the bit I wasn't sure about how we would do it. That makes sense, we would have an id internally in a ref so we'd know if it's the same or not, and we'd know if it's done or not.

Now, what happens when the user clicks the Save button again? status presumably changes to loading or something, but when it returns back to success we are still rendering the same toast based on the generated id, so presumably it wouldn't appear for the second save action 🧐
The consumer could do something like...
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  const [toastId, setToastId] = React.useState(1);
  React.useEffect(() => {
    if (status === 'success') {
      setToastId(i => i++)
    }
  }, [status]);
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {status === 'success' && <Toast id={`save-${toastId}`} message="Whoop! It worked!" />}
    </form>
  );
}

The consumer uses their own ID to signal that the toast is new on each success status. But now we have a new problem -- what if the previous toast is still on screen when this happens? It would go away because the ID of the toast we're rendering in this component has changed. Now it might get a little funkier.
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  const [toastIds, setToastIds] = React.useState([]);
  React.useEffect(() => {
    if (status === 'success') {
      setToastIds(t => [...t, t[t.length - 1] + 1])
    }
  }, [status]);
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {toastIds.map((id) => <Toast key={id} id={`save-${id}`} message="Whoop! It worked!" />)}
    </form>
  );
}

This probably works a little better but feels awkward that we're kind of offloading React complexity to work around what is probably unexpected behavior, but I think this ends up being a potentially common scenario. Kind of wondering if the originally proposed "imperative" API doesn't actually become a bit simpler here.
import { emitToast, Toast } from '@radix-ui/react-toast';

function Profile() {
  const [status, saveProfile] = useSaveProfile();
  React.useEffect(() => {
    if (status === 'success') {
      emitToast(() => (
        <Toast message="Whoop! It worked!" />
      ))
    }
  }, [status]);
  return (
    <form>
      <button onClick={() => saveProfile()}>Save</button>
    </form>
  );
}

We could provide a hook to simplify this somewhat:
import { useToastEmit, Toast } from '@radix-ui/react-toast';

function Profile() {
  const [status, saveProfile] = useSaveProfile();
  useToastEmit(
    // condition
    status === 'success',
    // callback to render the toast
    () => <Toast message="Whoop! It worked!" />
  );
  return (
    <form>
      <button onClick={() => saveProfile()}>Save</button>
    </form>
  );
}

For all this, it seems to me we don't need to do anything specific, just use react and pass a different key to the Toast when it needs to be a new one.

re. the notifications center idea thing. Is this something that users "have" to do, ie. for accessibility reasons, or is it just us proposing that it might be useful? Seems quite prescriptive to me for now.

It certainly is prescriptive, but the problem is that without it or something like it, it's essentially impossible to make a toast that doesn't violate WCAG. This article outlines several problems with the core design of the toast that I'm not sure can be overcome without it.

I see. Does that mean if someone doesn't include a notification center in their app, they won't be accessible then?

will this use our Announce component somehow under the hood?

I believe so, but that will require some screen reader testing to be sure. The potential concern is timing -- you need to ensure a toast is visible long enough for both a user and a screen reader to read it, which is ultimately something consumers will have to consider in their designs. This could be particularly tricky when aria-live is set to "polite", as the SR may be reading something else that eats into the Toast's time on screen.

Yeah, tricky for sure…

there are quite a few concepts in the Toast, like label, message, type, etc. Are these standardised? It feels again quite prescriptive to me for now. Ie. what if someone needs the message to be formatted somehow and therefore needs JSX, can't be just a string, etc.

label I'm not 100% sure we will need. message would be the simplest interface because the SR announcement should always be test. We should support any kind of composition in Toast and use element.innerTextif there is no message, but that's potentially troublesome if the inner HTML has a composition that doesn't make sense when read as a single sentence. I envision message could be used in lieu of composition if the toast is simple, or alongside composition as a simplified supplement for better SR support.
Consider:
<Toast>

    <Heading>Warning: Error</Heading>
    <ToastDismiss>
      <VisuallyHidden>Dismiss error</VisuallyHidden>
      <CloseIcon />
    </ToastDismiss>

    <Text>Oh no! You have a major problem!</Text>
    <ToastDismiss>Dismiss error</ToastDismiss>

</Toast>

Using the HTML inner text here would be needlessly verbose, repetitive, and would read like a run-on sentence. The way Announce works is that it needs to mirror some text into a visually hidden live-region. It's quite a bit different than aria-describedby or aria-label, so this is what I imagine the message prop can solve.
<Toast message="Oh no! You have a major problem!">
  {/* compose whatever you'd like */}
</Toast>

I see, yeah makes sense to at least have a way to provide an override text to announce.

As for type, this too is probably a bit prescriptive, but I think it can be helpful for users for a few reasons.

I think the vast majority of needs will fit into one of these categories, so for most people they don't need to think about anything else other than whether or not a toast is an error message, success message, etc.
We can use this type to handle ARIA for them. For example, an error or success message probably make the most sense with role="alert" aria-live="assertive", while other types of messages probably shouldn't interrupt the user, so we'd use role="status" aria-live="polite" (or possibly role="log").

Ah yes that makes a lot of sense.

if we're going to do declarative Toast at the point of render to raise them, how are we ensuring that they don't re-trigger if the parent re-renders? I can't see the id so I'm assuming we generate it, in which case how do we distinguish already raised toasts?

No differently really than rendering anything else, really. They should always be conditionally rendered by the consumer based on some state, but we'll also be managing them internally via context where we will need to generate IDs for those. This does raise an interesting question though.
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {status === 'success' && <Toast message="Whoop! It worked!" />}
    </form>
  );
}

In Jenna's example above, Toast renders when status is success, but of course when it times out in our app-level toast context status may still be success, so we'd just return null internally if the timer for that toast ID has run its course or if the user has dismissed that message.

Ohhh that's the bit I wasn't sure about how we would do it. That makes sense, we would have an id internally in a ref so we'd know if it's the same or not, and we'd know if it's done or not.

Now, what happens when the user clicks the Save button again? status presumably changes to loading or something, but when it returns back to success we are still rendering the same toast based on the generated id, so presumably it wouldn't appear for the second save action 🧐
The consumer could do something like...
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  const [toastId, setToastId] = React.useState(1);
  React.useEffect(() => {
    if (status === 'success') {
      setToastId(i => i++)
    }
  }, [status]);
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {status === 'success' && <Toast id={`save-${toastId}`} message="Whoop! It worked!" />}
    </form>
  );
}

The consumer uses their own ID to signal that the toast is new on each success status. But now we have a new problem -- what if the previous toast is still on screen when this happens? It would go away because the ID of the toast we're rendering in this component has changed. Now it might get a little funkier.
function Profile() {
  const [status, saveProfile] = useSaveProfile();
  const [toastIds, setToastIds] = React.useState([]);
  React.useEffect(() => {
    if (status === 'success') {
      setToastIds(t => [...t, t[t.length - 1] + 1])
    }
  }, [status]);
  return (
    <form>
      {/* ... */}
      <button onClick={() => saveProfile()}>Save</button>
      {toastIds.map((id) => <Toast key={id} id={`save-${id}`} message="Whoop! It worked!" />)}
    </form>
  );
}

This probably works a little better but feels awkward that we're kind of offloading React complexity to work around what is probably unexpected behavior, but I think this ends up being a potentially common scenario. Kind of wondering if the originally proposed "imperative" API doesn't actually become a bit simpler here.
import { emitToast, Toast } from '@radix-ui/react-toast';

function Profile() {
  const [status, saveProfile] = useSaveProfile();
  React.useEffect(() => {
    if (status === 'success') {
      emitToast(() => (
        <Toast message="Whoop! It worked!" />
      ))
    }
  }, [status]);
  return (
    <form>
      <button onClick={() => saveProfile()}>Save</button>
    </form>
  );
}

We could provide a hook to simplify this somewhat:
import { useToastEmit, Toast } from '@radix-ui/react-toast';

function Profile() {
  const [status, saveProfile] = useSaveProfile();
  useToastEmit(
    // condition
    status === 'success',
    // callback to render the toast
    () => <Toast message="Whoop! It worked!" />
  );
  return (
    <form>
      <button onClick={() => saveProfile()}>Save</button>
    </form>
  );
}

For all this, it seems to me we don't need to do anything specific, just use react and pass a different key to the Toast when it needs to be a new one.

I see. Does that mean if someone doesn't include a notification center in their app, they won't be accessible then?

Yes, unless they design some other interface to satisfy WCAG criteria where the toasts fail.

For all this, it seems to me we don't need to do anything specific, just use react and pass a different key to the Toast when it needs to be a new one.

Yeah good point on key, we might be able to make that work. I'm not abandoning Jenna's API idea just yet, just wanted to note some cases where it might present a challenge. We should test these out for sure, but it might not be a problem.

I see. Does that mean if someone doesn't include a notification center in their app, they won't be accessible then?

Yes, unless they design some other interface to satisfy WCAG criteria where the toasts fail.

For all this, it seems to me we don't need to do anything specific, just use react and pass a different key to the Toast when it needs to be a new one.

Yeah good point on key, we might be able to make that work. I'm not abandoning Jenna's API idea just yet, just wanted to note some cases where it might present a challenge. We should test these out for sure, but it might not be a problem.

I think that's what I would expect to have to do from React's standpoint at least.

I think that's what I would expect to have to do from React's standpoint at least.

Just wanted to chime in that I'd love a hooks api for this one but see that it's already being discussed. So +1 for that 👍
Thanks for all your work!

Since it is a common occurrence (In my opinion... 😉 ) to have dialog (modals) open and toasts providing information at the same time. It would be nice if there was a very easy to implement way to not have the dialog close when dismissing the toast. Preferably as an option for all toasts, not one toast at a time.
But that might be outside the scope of this project.

@DanielBailey-web Thanks for raising that, it's highlighted an issue with our current implementation that I'm looking into now 🙂

@jjenzz  Not sure if this is the right place to ask this - Is there a suggested way to prevent modal closing if we are using 3rd party toast implementations? (e.stopPropagation()  on toast dismiss event doesn't help)

@jjenzz Not sure if this is the right place to ask this - Is there a suggested way to prevent modal closing if we are using 3rd party toast implementations? (e.stopPropagation() on toast dismiss event doesn't help)
@sikanhe
You need to do this:

const reference = useRef<HTMLDivElement>(null);
useEffect(() => {
    function mousedown(e: Event) {
      e.stopImmediatePropagation();
      e.stopPropagation();
      e.preventDefault();
    }
    if (reference.current) {
      reference.current.addEventListener("pointerdown", mousedown);
    }
    return () => {
      if (reference.current) {
        reference.current.removeEventListener("pointerdown", mousedown);
      }
    };
  }, []);

and the reference needs to be on an html element surrounding your toast container.

Forgot to say this: @jjenzz  @DanielBailey-web  thank you both so much for helping!. Also can't wait to see how the Toast component come out

was released


android: Add support to set volume

Signed-off-by: Joel Fernandes<EMAIL_ADDRESS>

There is a way to use 'service call audio', but looks like it requires codes that are android version specific. I am more comfortable with key events, which also seems to be the most widely used method.

Fair enough, It's just a shame to have something unnecessarily stateful. Other than that this looks fine to me.

Is the amount of key presses to go from e.g. lowest volume to highest volume somewhat standard ? It would be nice if we could have a proper mute() function that uses that bounded amount of presses instead of an arbitrarily large value.

Yes that would be nice but in a separate patch.
This is just for volume change.
On May 17, 2017 9:47 AM, "Valentin Schneider"<EMAIL_ADDRESS>wrote:
Is the amount of key presses to go from e.g. lowest volume to highest
volume somewhat standard ? It would be nice if we could have a proper
mute() function that uses that bounded amount of presses instead of an
arbitrarily large value.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ARM-software/lisa/pull/398#issuecomment-302150451, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACSVNMfc4F2R-CBtBzMdxQQv9S7cwlOks5r6ySIgaJpZM4NdZct
.

Also I don't think the number of key presses is standard or we want to rely
on.
On May 17, 2017 4:08 PM, wrote:
Yes that would be nice but in a separate patch.
This is just for volume change.
On May 17, 2017 9:47 AM, "Valentin Schneider"<EMAIL_ADDRESS>wrote:
Is the amount of key presses to go from e.g. lowest volume to highest
volume somewhat standard ? It would be nice if we could have a proper
mute() function that uses that bounded amount of presses instead of an
arbitrarily large value.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ARM-software/lisa/pull/398#issuecomment-302150451, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACSVNMfc4F2R-CBtBzMdxQQv9S7cwlOks5r6ySIgaJpZM4NdZct
.

Right, it's mostly something that would have been nice to have. The use cases for that will mostly be setting the volume to min or max, but that'll imply arbitrary press counts.

If this API is stateless, and we don't know how many key-press you need to get to max/min volume, how do you plan to use it?

I suppose press enough number of keys to get to the Min or max and take it
from there.

That was actually what I was thinking me too.
Initially I was thinking about a couple of methods to set just the max or min volume.
Indeed, I don't think we are interested in not well defined mid volume levels since tests needs to be reproducible... and I guess the volume level can have some noticeable impact on energy consumption.
Than I've noticed a couple of things:

If I use input keyevent KEYCODE_VOLUME_UP on a just rebooted device... Android update the ring volume, while I guess that in most of the cases we are interested in updating the media volume
the dumpsys audio command seems to return many interesting info about audio channels, including the a STREAM_MUSIC along with Min and Max supported values.

I think that by reading/parsing that output of we can know exactly which volume we have on the speaker... still we need to find a suitable way to change the Music volume instead of the Ring one.

Hi Patrick, you are right. But what you said sounds like a more context-aware volume change which can be an additional feature on top of this patch. Do you think we can just include this in, and add the advanced feature as a #issue ? I think its better than having nothing.

So current versions of android can do this but support was just added to control volume on channels over adb. Which means older android will not be able to. Is that a problem?

The main issue now is that, by default it seems we control the ring volume instead of the media volume.
I'm assuming we want to tune the volume for media playback... maybe if we press the volume button while Youtube is in foreground we actually change the media volume?

Yes... it seems so... ok for merge and opening an issue to improve that.

Yes you are right about that. However it is possible to start an app. Change the volume. And then do the activity through intent, like playing a video. But it is an issue as you pointed


Problems running latest version on specific devices

I used the previous version (4140a53447b0b7f419bacbe0ff1dfa53ff1c08f8) of this demo on Samsung Note 1 (GT-N7000), everything worked fine.
After pulling the latest version (5a80ac6a14fe5a0b493ac8e20137c7bd14710f36) the app crashes while starting up.
What's more interesting is that the new version works fine on other devices (LG G3, Samsung S4)
Do you have any idea what changed between these commits that might have suce an affect?
Thanks

What's the android version on your Samsung Note 1 (GT-N7000)?

Android version is 4.0.4,
The problem is probably related to the JNI libs, app crashes when calling loadModel

Did you update the models in your Samsung Note 1 as well?

Yes, I ran adb push again after switching

Sorry, can you provide more details about the error? Or, does your phone have enough memory for loading a CaffeNet (probably needs 500mb or even more available RAM) ?

The demo app just crash after loadModel, on the older version it worked fine (with initTest) so I guess my phone should be able to support it, at least the older version.
Is there any way to output the internal caffe log from the app?

Alright, I use a naive way to redirect native logs to android logcat. You now can see what happen in loadModel(). ;p

OK, I ran the new version on both phones again,
Please take a look at the logs at:

Samsung Note (Fails) - https://gist.github.com/mtngld/fc36f60b7dc8e8b43a39
LG G3 (works) - https://gist.github.com/mtngld/9ee26edc94e7599d3d08

This is the same version (latest commit) and I pushed all model files again, just to be sure.
Looks to me like the problem is related to loading weights and upgradeing

Sorry, I just checked the 2 log files. It seemed that after the network initialization was done, the model loading stopped abruptly on your Samsung Note.
Please refer to this and this. The behaviours are coherent till the point which is highlighted. And actually, the Errors are actually not vital , while Caffe core use ERROR level to report (should be warnings).
I really have no idea what happened to your phone after the network initialization was done. All I can guess is that your phone ran out of  RAM at that time.

Sorry, I have no idea about the changes in the underlying implementation of the memory management in Caffe core, as I focus on the high level features (e.g., layers) only.

Thanks,
I guess it is related to some lower layer caffe memory issue,
Thanks for your help, closing this issue


Release version 0.0.3

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (72e5751) to head (16e67b3).

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #365   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          100       100
  Lines         3172      3172
  Branches       267       267
=========================================
  Hits          3172      3172

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


extend #5024 for SCshadowreg

https://github.com/D-Programming-Language/dmd/pull/5024

std.net.curl fails again. What a surprise, but it has nothing to with this PR.

If only there was a way to make the autotester re-run on that platform...

It's passing now.

Auto-merge toggled on

Hmm. This always fails on Win64, and shadowreg is only for Win64. Looks like there's some problem with it. I'm going to abandon this for now.


Proposal: remove background-color from .mat-drawer-container

Bug, feature request, or proposal:
Proposal: remove background-color from .mat-drawer-container
What is the expected behavior?
The common background that I've set in my app appears on a page with a drawer
What is the current behavior?
Putting a drawer on a page requires putting the page contents inside md-drawer-container which comes with background-color set that overrides any app background that's been set.
What are the steps to reproduce?
Add a drawer to a page with a non-standard background
What is the use-case or motivation for changing an existing behavior?
Overlays for drawers and sliders are typically supposed to block the majority of the UI. IMHO material shouldn't be providing a background-color for this majority.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
2.0.0-beta.10
Is there anything else we should know?

I agree with @adamdport I have to override this background color every time.

You might as well add .color to that as well as it overrides both

PLease do it.

thats what is there currently , why ?
background-color: #fafafa;
color: rgba(0,0,0,.87);

This mat-drawer css is broken. It even overwrites my "routerLinkActive" color.

A fix would be really appreciated. You cant offer theming and say that the components support it and then you have to set the background color of some components manually

I asked this question on stackoverflow, maybe it can help..
<mat-drawer-container class="red-container">
...
</mat-drawer-container>

.red-container {
  background-color: red;
}

These seems like a trivial fix. Has there been any movement on this?

This can cause very slight visual regressions in existing projects where background colors are just #FFF white, and makes it so that a first experience of implementing an Angular Material component requires a style FIX, as opposed to a style customization. Which in turn does not provide a good first experience, which is a bummer. Why is it there?

This is still open right? Not the first time I end up in this issue. I would like to also suggest to add the possibility of setting the color of the drawer using the app theme e.j. (color="primary")


created local storage to parse data and display on page load

created local storage to parse data and display on page load

Changes look good, approved


[Backport 2.6] HARVESTER: Validate ccm & csi maximum version

Backport PR https://github.com/rancher/dashboard/pull/8504
issue: - https://github.com/harvester/harvester/issues/4401

Note - there's no 2.6.x ui release at the moment. If there's not a specific need then i don't think we need this backported

I think this needs to be merged into a future 2.6. x release, as this issue can be very annoying for users.
In the future, we will make an enhancement to this issue in 2.8.x, and the enhancement will not be merged into 2.6.x.

There are no more currently scheduled releases in 2.6.x at this time, so I'm closing this and the milestone.


[Bug] README workflow testing samples are not running the worker

Describe the bug
README samples in the workflow testing area are not actually running the worker

Same, I faced the same issue, the test environmentt Client just keeps running, eventually timing out the test.
I copied and pasted the example under Workflow testing.
I am using XUnit, Windows OS (x64).
MockWaitADayWorkflow.cs
[Workflow]
public class MockWaitADayWorkflow {
    [WorkflowRun]
    public async Task<string> RunAsync() {
        await Workflow.DelayAsync(TimeSpan.FromSeconds(1));
        return "all done";
    }
}

TestTemporalWorkflow .cs
using NanoidDotNet;

public class TestTemporalWorkflow {
    [Fact(Timeout = 5_000)]
    public async Task SimpleMockedWorkflow() {
        await using var env = await WorkflowEnvironment.StartTimeSkippingAsync();
        using var worker = new TemporalWorker(
          env.Client,
          new TemporalWorkerOptions($"task-queue-{Nanoid.Generate()}").
              AddWorkflow<MockWaitADayWorkflow>());
        var result = await env.Client.ExecuteWorkflowAsync(
            (MockWaitADayWorkflow wf) => wf.RunAsync(),
            new(id: $"wf-{Nanoid.Generate()}", taskQueue: worker.Options.TaskQueue!));
        Assert.Equal("all done", result);
    }
}

Also, I added breakpoints within the RunAsync method of the MockWaitADayWorkflow class and the break point is never reached.

Similar to https://github.com/temporalio/sdk-dotnet/issues/179#issue-2092746994

In your sample code I am not seeing where you actually run/execute the worker


Windows install instructions are incomplete when node.js was installed via chocolatey

I installed nodejs via chocolatey, and then followed the instructions in npm's README to install npm. When I was done, the npm files were there, but typing npm at a command prompt gave me a 'npm' is not recognized as an internal or external command, operable program or batch file error -- even though I am successfully able to run node from the command line.
It looks like the problem is the strange way that Chocolatey set up directories and updated the PATH when it installed node. npm's README assumes that, if node is on the path, then it can drop npm.cmd into the same directory as node.exe and everything will work (seems reasonable enough!). But chocolatey installed node.exe into C:\NuGet\lib\nodejs.0.5.9\tools, and didn't add that directory to the PATH. Instead, it added C:\NuGet\bin to the PATH, and in that directory is a node.bat containing the following batch script:
@echo off
"C:\NuGet\lib\nodejs.0.5.9\tools\node.exe" %*

I was able to get npm to work by making an npm.bat in the same directory, that does the same thing but references npm.cmd instead of node.exe.
Until there's a chocolatey package for npm that does this automatically, it would be nice if the README included this detail. Chocolatey is a "recommended" way to install node on Windows, so this issue will probably come up again.

I'm not familiar with this chocolatey, but if it's a package manager for windows, then the project owners have my sincerest condolences and respect.
The issue is that chocolatey is doing the same sort of thing that npm is doing.  Once we get npm bundled in the node MSI installer, I think this will be much better.
Thanks for bringing up the issue, but I really don't see a way around it at this time.  If anyone is interested in writing a chocolatey package for npm, I'll do my best to help them with it, but I don't have time to take that on right now.

Yes, chocolatey is a (fairly new) Windows package manager. It's based on NuGet, which is basically .NET's version of npm (without -g). Chocolatey is a bit like npm -g, but since .NET doesn't have global libraries the way node does, it's generally just for the part about installing apps and their dependencies.
When I first wrote this up, I thought it was just an issue with installing npm itself; but then I learned a bit more about node package management, and I realized that npm's installer is probably pretty much just bootstrapping and doing an npm -g on itself, which would mean that this is a general problem with anything installed via npm -g after installing node via chocolatey. I've been pondering this, and it seems to me that the right thing is to either:

Change the node chocolatey installer to actually add node.exe's directory to the PATH, instead of putting it somewhere else and redirecting individual commands via batch files. Then npm would Just Work. But I don't know if this would run contrary to chocolatey/NuGet's design / philosophy. Or,

Make some way for npm to know that it was installed via chocolatey (perhaps by making a special chocolatey version of npm and making a chocolatey installer for it), so it can do things the chocolatey/NuGet way by adding batch files (as its way of "setting the executable bit").

I don't actually know which is the better option -- I don't know much about chocolatey/NuGet yet (or node/npm, for that matter). I may poke around and see if I can learn more, and perhaps try to tackle this at some point.
Just as a point of curiosity, is there a reason why npm isn't just included with node? Maybe it would make sense for the chocolatey node package to include npm too, which could be a good way to just hand off the issue to the people who are better able to do something about it.

Oh, "chocolatey nuget", I get it.  Very clever ;)

Just as a point of curiosity, is there a reason why npm isn't just included with node?

As of 0.6.3, it is bundled in the msi, and as of 0.6.4, it should actually work ;)
The correct thing to do would be for the chocolatey recipe for node (or for npm) set a builtin config file telling npm how to behave.  Basically, this is a file named npmrc that lives in the root of the npm source code, and has ini-formatted config options.  Then, it can set the paths however Chocolatey would like them to be.


Add Startup Check for Popper Installations < 1.5

Otherwise the errors are simply logged and the user does not recognize these errors.

Added with 2.14.0


Orderbook not coherent

I am having problems maintaining a coherent orderbook on the V3 socket API.
I have tried filtering updates using the "offsets" field and disregarding the "offsets" field. I can maintain a good book for about 3-10 seconds then either a bid or ask price will get "stuck" - I have traced through the Websocket updates and confirmed that the message stream does NOT contain any updates (or removals) for the prices[s] that get stuck
This happens on EVERY attempt i have made, not just occasionally. There looks to be relevant activity at where the top of book seems to be moving but unless i implement a "cancel on overlap" mechanism the book will always end up overlapping
Is there an implied "cancel on overlap" assumption ? (e.g. where all asks are removed when a bid is higher .. and vice versa)  - if so then the official GUI shows "backwardation" of proces (overlap) by 1 or 2 spread sometimes so i require guidance . If that is not the problem then why am i losing updates
I can provide examples easily if you require tham

did you manage to get the orderbook state going?


application test cases for postgresql

Describe the feature request
Describe alternatives you've considered
Additional context

we have bigger fish to fry.


Clean up vote and timeout message construction for broadcast

Current dependencies on/for this PR:

feature/pos-networking-and-syncing

PR #815   👈

This stack of pull requests is managed by Graphite.


Remove fail_on_warning from readthedocs.yml

Thanks! So the good news is it fixed the docs build, but I just saw I wrote it in markdown instead of reStructuredText :| I'll fix that with a future change.


Sequence annotation

Definition of FeatureSet and Feature records, together with get and search endpoints for each.

+1  .. while the query methods will most likely need to evolve some, it's important to get the data model out there so the methods can evolves through real use cases

For the CI failure: https://github.com/ga4gh/schemas/pull/592

@dzerbino @sarahhunt
I created this  issue to thinking about fusions and rearrangements per your comments above.
https://github.com/ga4gh/schemas/issues/594

Please check suggested fixes in #596

+1
looks good from our perspective - couple of minor issues raised can be taken to follow up issues for discussion

+1.  This code seems completely appropriate for advancing development.


unread_count_badge: Clear out all TODO(#95)s

For the user-facing change in this commit:
unread_count_badge: Clear out a TODO by following Vlad's design

The difference (in the text color of the unread-count badges on the streams/topics) really is tiny. I used Mac's Digital Color Meter to see that there was in fact a difference, though.

Before
After

Resolved the test failure.

Wow, indeed, that sure is a subtle color difference.
All looks good, thanks — merging.


Import PropTypes from prop-types package

Resolves a deprecation warning due to PropTypes being removed from the main react package in the next upcoming major release.
https://facebook.github.io/react/blog/2017/04/07/react-v15.5.0.html#migrating-from-react.proptypes

I've added the need for react >= 0.14.9 as mentioned on the prop-types README.
Thanks for that PR 👍

Thanks for the speedy merge! 😄


Disable aliasing on rename

Given code like this
const person = { hgt: 180 }
const { hgt } = person;
console.log(hgt)

Using <Plug>(coc-rename) hgt ~> height
Results in this;
const person = { hgt: 180 }
const { height: hgt } = person;
console.log(hgt)

Whereas
const person = { hgt: 180 }
const { height } = person;
console.log(height)

would be much preferable.
This has been implemented in Microsofts ts server and vscode. Link -
https://github.com/Microsoft/TypeScript/issues/29238#issuecomment-494866713
Is there any chance of having this implemented?

Set typescript.preferences.useAliasesForRenames to false in your coc-settings.json.

Set typescript.preferences.useAliasesForRenames to false in your coc-settings.json, javascript.preferences.useAliasesForRenames if you're using JS.

Thank you. This doesn't seem to catch object property shorthands. IE
Before
type Params = {
  arg: string;
};

function doAThing({ arg }: Params) {
  const t = { arg };
}

<Plug>(coc-rename) arg ~> newArgName (while cursor is over arg in the type definition)
Results in;
type Params = {
  newArgName: string;
};

function doAThing({ newArgName }: Params) {
  const t = { arg };
}

Which results in a "no value exists" error. Perhaps the reason why aliasing is the default. Anyway that is another issue, thank you for the answer.

@JakeElder tested your code with VSCode + https://github.com/microsoft/TypeScript/issues/29238#issuecomment-494866713 settings, same issue. It's related to coc or coc-tsserver.

Thanks @fannheyward, closing. Would it be useful for me to create a PR that adds this setting to the documentation?


Remove command's knowledge of its keys

Summary of the Pull Request
Targets #17162
With the move to Action IDs, it doesn't quite make sense anymore for a Command to know which keys map to it. This PR removes all Keys from Command, and any callers to that now instead query the ActionMap for that Command's keys.
PR Checklist

[x] Closes #17160
[ ] Tests added/passed
[ ] Documentation updated

If checked, please file a pull request on our docs repo and link it here: #xxx

[ ] Schema updated (if necessary)

I'm a bit confused if we're showing the key chord in the suggestions UI. I see that we make space for it in the XAML but it looks like we never populate it.

The KeyChordText was never supposed to be in the sxnui! @zadjii-msft can confirm

Yea that was accidental copypasta from the Command Palette


fixed_new_capacity sets CAP_NEW but not CAP

If we set fixed_new_capacity to a certain value, the model reacts by setting the CAP_NEW parameter to the desired value. The CAP however seems to be unaffected by this, thus, remains zero. Any ideas on why this is happening / is this the desired behaviour?

This behaviour actually makes sense - currently, there is no mechanism forcing the newly installed capacity to be maintained in the first period, i.e. CAP_NEW(node, tec, vintage) does not have to equal CAP(node, tec, vintage, vintage). In an optimization problem, the model wouldn't build new capacity that it doesn't maintain.
In this particular case, I guess that the model just doesn't need the capacity, so it builds it (as defined) and immediately throws it away.
@ClaraLuisa, can you confirm?
More generally, one could add a new constraint like
CAPACITY_MAINTENANCE(node,inv_tec,vintage,vintage)$( map_tec_lifetime(node,inv_tec,vintage, vintage) AND NOT historical(vintage) )..
    CAP(node,inv_tec,vintage,vintage) =E=
    remaining_capacity(node,inv_tec,vintage, vintage) * (
* new capacity built in the current period (vintage == year)
        + ( duration_period(vintage) * CAP_NEW(node,inv_tec,vintage) )
    ) ;

It does seem like @danielhuppmann  is right on that the model just doesn't really need it and thus "throws it away". However, i would very much appreciate an extension to the maintenance equation as suggested by @danielhuppmann  as this would be more realistic (also in the cost accounting).

@danielhuppmann are you going to, or should I try to implement the equation suggested by you into the gams code.

@ClaraLuisa it would be great if you could give it a try!
Thinking about it, you most likely wouldn't even need a new equation, just refine the existing CAPACITY_MAINTENANCE to apply only if vintage < year (removing the section with CAP_NEW) and then adding the blurb I suggested earlier.
And you don't even need a new test for it, the 'Westeros' and 'Austria' tutorials should catch it if anything goes awry...


Scrolling Background by Lua

Describe your problem here.
Is there a way to make scrolling background(Like Danger and Nightmare Run stuff) using Lua?
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No response

This thingie

you could do it using runhaxecode() as i think its easier in haxe but idk how to make it in lua, ill update you if i figure out how

You could either have an animated background or use a Tween.
If you know how to make animated sprites in Lua, then just do that for the background.
For tweens, you'll first have to remove the close() in your stage script. Then, align the image correctly and have a forever-looping tween, which looks something like this.
function onCreate()
	makeLuaSprite('bg', 'background', 0, 0);
	setScrollFactor('bg', 1, 1);

	addLuaSprite('bg', false);
    doTweenX('bgMove', 'bgClouds', -4500, 3, 'linear')
end

function onTweenCompleted(tag)
	if tag == 'bgReset' then
		setProperty('bgClouds.visible', false)
		doTweenX('bgMove', 'bg', 1500, 1, 'linear')
	end
	if tag == 'bgMove' then
		setProperty('bgClouds.visible', true)
		doTweenX('bgReset', 'bg', -4500, 15, 'linear')
	end
end

You can tinker with the code to your needs, such as the name of the image, how far you need the image to move, how fast you want it to move, etc.

You could either have an animated background or use a Tween.
If you know how to make animated sprites in Lua, then just do that for the background.
For tweens, you'll first have to remove the close() in your stage script. Then, align the image correctly and have a forever-looping tween, which looks something like this.
function onCreate()
	makeLuaSprite('bg', 'background', 0, 0);
	setScrollFactor('bg', 1, 1);

	addLuaSprite('bg', false);
        doTweenX('bgMove', 'bgClouds', -4500, 3, 'linear')
end

function onTweenCompleted(tag)
	if tag == 'bgReset' then
		setProperty('bgClouds.visible', false)
		doTweenX('bgMove', 'bg', 1500, 1, 'linear')
	end
	if tag == 'bgMove' then
		setProperty('bgClouds.visible', true)
		doTweenX('bgReset', 'bg', -4500, 15, 'linear')
	end
end

You can tinker with the code to your needs, such as the name of the image, how far you need the image to move, how fast you want it to move, etc.

Thanks!

If you want it to be truly seamless, it might work to have two of the same sprite scrolling with the same method I just method, and then when the first one gets off-screen, reset it, etc. etc.

If you want it to be truly seamless, it might work to have two of the same sprite scrolling with the same method I just method, and then when the first one gets off-screen, reset it, etc. etc.

Tried to do so, but i suck at codding, that's it lmao

Still does stop moving after first tweening, for some reason

oh, nvm!
i messed up with other code and it worked perfectly!


[Package Request]: Plazma Burst 2 official launcher

How can we help?
I would like someone else to build the manifest.
Please read and ensure the following

[X] The installer meets the above requirements

Please provide the following information
Download Page Url: https://plazmaburst2.com/?s=2&a=
Publisher: Eric Gurt , Lin
Package Name: Plazma Burst 2 launcher
Description: Official launcher for the game Plazma Burst 2
Package Version: <IP_ADDRESS>   OR   0.1.0 (see picture below)

Installer URL: https://plazmaburst2.com/pb2/Plazma Burst 2 installer by Lin.msi

Thank you!


Add Turkish language

I want to translate Turkish language but there's no Turkish in POEditor. Could you add that language?

Done.

Done.

Also, can you accept my join request?

Done.

I translated 94.29% of it.

It's done, you can find apk from the link to test it out.
https://github.com/rev0lgenX/AniLib-Snapshot/releases/tag/S-753


WIP: Enhance kernel monitor

This PR enhances various features within kernel monitor, which were proposed in #1514.
What I'm trying to do

[x] Beautify monitor pane using react-table
[x] Allow user to click on a filename to activate the editor

[x] Not create link to unsaved editors because there is no URI for them

[x] Add a column for execution_count

[x] Implement execution_count watcher both for ZMQ/WS kernel

[ ] Add a column for kernel spec
[ ] Update usage/style customization documentation
Idea: Add a column for last execution time

What I've done so far
Looks like this:

Remaining work
Want to hear general feedbacks and your ideas about the topics below:

What/how to show kernel specs:

I think opening the kernel.json file is more useful for users than showing the current kernel spec (, which easily can be obtained from kernel.kernelSpec).

The last execution time info:

I could implement a watcher for the last execution time as I did so for execution count, but I'm not so sure that this is useful or just verbose that I've not included this enhancement in this PR yet.

This is looking great @aviatesk! I'll look closer into this after you remove WIP from the title. Here are just a couple thoughts for now:

For the kernelspec/execution time questions, would you want to split those changes into a separate PR (or discuss in an  issue) after this one is merged rather than holding up the rest of your work?

For unsaved editors, we may be able to use the editor id. Though I am curious if you think this would be more difficult than imagine off the top of my head. (possibly another PR anyway)

Thanks for your feedback, @BenRussert !
My thoughts for your comments are below:

For the kernelspec/execution time questions, would you want to split those changes into a separate PR (or discuss in an issue) after this one is merged rather than holding up the rest of your work?

The information of kernel specs which are currently stored within Hydrogen's kernel representation is like:
{argv: Array(5), display_name: "Python 3", language: "python", name: "python3"}argv: (5) ["C:\Users\aviat\Anaconda3\python.exe", "-m", "ipykernel_launcher", "-f", "{connection_file}"]display_name: "Python 3"language: "python"name: "python3"__proto__: Object

and we can easily show kernel spec information using this which would look like:

But I think those information is less useful than jumping to the original kernel.json file since those kernel specs are read from the file.
Then the problem here is that we've not stored the files information within kernel object and it needs some refactoring in a package in node_modules...
So in conclusion, I think this enhancement should be in another PR if you go with my idea, otherwise it can be easily included in this PR .

For unsaved editors, we may be able to use the editor id. Though I am curious if you think this would be more difficult than imagine off the top of my head. (possibly another PR anyway)

Actually I implemented "jumping to file" feature just using kernel.getFilesForKernel() and atom.workspace.open(filePath) and it totally doesn't work for unsaved editors.
I don't have any idea to get unsaved texteditor's URI and thus I left it unjumpable.
Do you know me a way to get an URI for them ?

And I've included last execution time enhancement within the last commit.
Now the monitor looks like:

Do you think this information is verbose or useful ??

I'm welcome to write tests ! even though it takes some time to finish because I'm an just newbie to JavaScript & unfamiliar with Jusmine.
First I will try to write and I get stuck I will reach you out.
I may strip WIP before I write all the tests up.

First I will try to write and I get stuck I will reach you out.
I may strip WIP before I write all the tests up.

Sounds good! Tests can be hard to write here at first because of the need to mock atom and kernel related stuff. I wrote a simple one for this last night, so we can think about tests in another PR after merging this.

Okay, I've almost done what I wanted to do in my first mind !
Thanks so much for your help @BenRussert !
Throughout the implementation, I did many (of course biased 🤣) manual tests and I want to strip WIP for now.
Of course I know writing tests would be much valuable & important, so I will write them in another PR or include them in this PR if I have time before merging !

Ah, I will update the corresponding documentation first !

@BenRussert
Thanks for merging !
I will join to write tests with you in that PR as well !


Windows wheels

Add build and release setup for Windows compatible wheels.

Doesn't seem like building cross platform wheels with all the nuances regarding available platform extensions makes sense, let's instead figure out how to ship source so that pip install can build APSI as required on each target system.


Update IO.hs

On line 437, the value for numAcks (which is supposed to tell how many elements should be read from the array pointed to by acksPtr) is read from the array at acksPtr instead of numAcksPtr. This patch fixes it.

Thanks -- sorry it sat for so long!

Uploaded as version 0.0.2


add podmaster support for etcd tls

add support for podmaster to consume tls secured etcd.
cc. @brendandburns (since you are listed as the maintainer in the dockerfile for podmaster)

Thanks for the PR!  small comments.

thanks for the comments @brendandburns, everything should be addressed.

WDYT about using etcd-config in order to be aligned with the apiserver?

/ref https://github.com/kubernetes/contrib/pull/143.

yeah, i think thats a better idea. good call.

yep.
It seems like kubernetes core is going to use the new etcd client github.com/coreos/etcd/client (not the deprecated one: github.com/coreos/go-etcd) which doesn't support reading config from a custom formatted file. Although, in order to be backward compatible maybe that parsing should be made by kubernetes itself...
/ref kubernetes/kubernetes#11962

This PR appears to address Issue https://github.com/kubernetes/contrib/issues/133. Just wanted to make someone reference between the two in case someone (like me) comes across the issue but somehow fails to find the this PR quickly.
I'm looking forward to using this when merged. thanks!

@rwehner @roboll until this is merged and available for all, i created a public image which uses etcd-config parameter as kube-apiserver does: `quay.io/saltosystems/podmaster.

I had to do etcd-config file version for my own use, so if anybody wants to use etcd-config from a file, there is a version of pod-master here: https://github.com/biwwy/contrib/commit/79664e46d38cb03d38ca6425e7cc57c0bd2b38e0

revisiting this, i poked around all the relevant issues and didn't find any details leading me to believe this was going down the wrong path.
updating podmaster to use the new etcd config is a little more intense, and probably not as high a priority as this.
@brendandburns is this good for merge?

going to close this per https://github.com/kubernetes/contrib/issues/133#issuecomment-163371391


problem with setting mqtt server to localhost

Hi
I'm using the Mosquitto broker in HA. When I set the mqtt server to localhost or <IP_ADDRESS> i can't get a connection to the mqtt server from the script. When adding the actual IP adress or "homeassistant" it is working.
This is useful when you want the script run while you disconnect the ethernet.
I'm not sure if this is a problem of bluetti2mqtt but of Mosquitto broker but I'm not good enough to find out.

I guess the answer is here:
"That’s not going to work. Your mqtt container has a different ip address since its a container.
And if you’re running ha also in a container, <IP_ADDRESS> would be the internal ip address of the container. You’ll need the ip address of your server and make sure ports are correctly open (seems to be the case from your docker command)"
see https://community.home-assistant.io/t/connect-to-local-mqtt/150018
any good ideas?

Please upgrade to version 1.2.0.  In the addon configuration page, leave all the MQTT settings blank.  This will force the addon to "auto-configure" MQTT and pull the necessary settings from Home Assistant.
I haven't tested it for your particular use case (disconnected from LAN).  If it still doesn't work, we can run the addon with the host_network config variable set to true.  That will dock the addon some security points so I wouldn't necessarily release that version to the public.

I checked it over night, when ethernet is removed from my Pi the data still gets collected. Thank you.


docs: remove interledger-payment-request doc since it is outdated

Changes proposed in this pull request

the doc is very outdated and needs to be completely redone using the new Open Payments
I don't think this repo is the right place for it
It should be discussed on a forum

Context

fixes #551

Checklist

[x] Related issues linked using fixes #number
[ ] Tests added/updated
[ ] Documentation added
[ ] Make sure that all checks pass

saved to docs?

I put them in a google doc and will put them in the Interledger notion once I have access.


Handle nil / 503 response from TangoCard API

TangoCard API went down today:
> Tangocard::Raas.rewards_index
=> #<Tangocard::Response:0x007f9c70db2338 @parsed_response=nil, @code=503>

Let's write some specs to make sure this is handled gracefully by the gem.

Fixed.


:fire: Chore(actions): Delete dead code

Description
Concise description of proposed changes
Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

#1451  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @roninjin10 and the rest of your teammates on  Graphite


add /usr/sbin to PATH in chroot-host-wrapper.sh

Would you add /usr/sbin to PATH in chroot-wrapper.sh. In debian based distributions xfs_growfs is located there and by default it will fail. I know it is not officially supported distribution, but it would be better for compatibility,
Thanks

Fןסקג


chore: release main

:robot: I have created a release beep boop
auto-instrumentations-node: 0.33.0
0.33.0 (2022-09-27)
Features

add dataloader instrumentation (#1171) (3898b11)
add mongoose instrumentation (#1131) (b35277b)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/instrumentation-aws-sdk bumped from ^0.9.1 to ^0.9.2
@opentelemetry/instrumentation-dataloader bumped from ^0.1.0 to ^0.2.0
@opentelemetry/instrumentation-fastify bumped from ^0.29.0 to ^0.30.0
@opentelemetry/instrumentation-mongodb bumped from ^0.32.0 to ^0.32.1
@opentelemetry/instrumentation-mongoose bumped from ^0.30.0 to ^0.31.0

host-metrics: 0.30.1
0.30.1 (2022-09-27)
Bug Fixes

readme snippet (#1182) (35d1e45)

instrumentation-aws-sdk: 0.9.2
0.9.2 (2022-09-27)
Bug Fixes

aws-sdk: set spanKind to CLIENT by default in v3 (#1177) (d463695)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/propagation-utils bumped from ^0.28.0 to ^0.29.0

instrumentation-dataloader: 0.2.0
0.2.0 (2022-09-27)
Features

add dataloader instrumentation (#1171) (3898b11)
upstream mocha instrumentation testing plugin from ext-js #621 (#669) (a5170c4)

instrumentation-fastify: 0.30.0
0.30.0 (2022-09-27)
Features

opentelemetry-instrumentation-fastify: Support Fastify V4 also (#1164) (d932d3e)

instrumentation-mongodb: 0.32.1
0.32.1 (2022-09-27)
Bug Fixes

remove unneeded type exports in mongodb instrumentation (#1194) (6920a55)

instrumentation-mongoose: 0.31.0
0.31.0 (2022-09-27)
Features

add mongoose instrumentation (#1131) (b35277b)
upstream mocha instrumentation testing plugin from ext-js #621 (#669) (a5170c4)

propagation-utils: 0.29.0
0.29.0 (2022-09-27)
Features

propagation-utils: end pub-sub process span on promise settled (#1055) (cb83d30)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/auto-instrumentations-node-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/host-metrics-v0.30.1 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/propagation-utils-v0.29.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mongoose-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-dataloader-v0.2.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-aws-sdk-v0.9.2 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-fastify-v0.30.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mongodb-v0.32.1 :sunflower:

seems nothing was published to NPM once again. Did the release please job ever succeed on a release here?