text:
[Autocomplete] On mobile selecting option keeps keyboard open

When using the autocomplete input on mobile the keyboard doesn't disappear after selecting an item from the dropdown list. Even when selecting an item and seeing it populate the input then clicking the enter key on the keyboard is still there.

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
Keyboard doesn't disappear on mobile when selecting something from the autocomplete input.

Expected Behavior 🤔
After typing and selecting a match in the list the keyboard should disappear.

Steps to Reproduce 🕹

Steps:

Go to material-ui.com on mobile
Select an autocomplete input and start typing
Click item from list of matches

Context 🔦

I'm making a progressive web app and would like to stay within the material ui component library instead of moving to use react-select or downshift for autocomplete search
Your Environment 🌎

Tech
Version

Material-UI (lab)
v4.0.0-alpha.35

Browser
Chrome 78.0.3904.108

OS
Android 9

@oliviertassinari On desktop as well as mobile, the underlying <TextField /> keeps focused after an option is selected. Is this not the normal behaviour?

@scott-mcnulty I have wondered about this point during the initial implementation of the component. Keeping the focus was done on purpose to be closer to a regular input experience and not to interrupt the experience when working on a multi-select input.

downshift

I believe you would have to implement the logic on your own going with this solution. The solution would be almost identical to what you would need to write to add such support to the Autocomplete.

react-select

If you have a desktop with a touch screen, it will blur the input, even if you have used your mouse or keyboard to select the value ❌.

I think that we can add an opt-in prop for such behavior: blurOnSelect? false | true | 'touch' | 'pointer'.
diff --git a/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js b/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
index 38f9ee430..6722376bd 100644
--- a/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
+++ b/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
@@ -71,6 +71,7 @@ export default function useAutocomplete(props) {
     autoComplete = false,
     autoHighlight = false,
     autoSelect = false,
+    blurOnSelect = 'touch',
     clearOnEscape = false,
     debug = false,
     defaultValue,
@@ -91,8 +92,8 @@ export default function useAutocomplete(props) {
     multiple = false,
     onChange,
     onClose,
-    onOpen,
     onInputChange,
+    onOpen,
     open: openProp,
     options = [],
     value: valueProp,
@@ -666,9 +667,25 @@ export default function useAutocomplete(props) {
     setHighlightedIndex(index, 'mouse');
   };

+  const isTouch = React.useRef(false);
+
+  const handleOptionTouchStart = () => {
+    isTouch.current = true;
+  };
+
   const handleOptionClick = event => {
     const index = Number(event.currentTarget.getAttribute('data-option-index'));
     selectNewValue(event, filteredOptions[index]);
+
+    if (
+      blurOnSelect === true ||
+      (blurOnSelect === 'touch' && isTouch.current) ||
+      (blurOnSelect === 'pointer' && !isTouch.current)
+    ) {
+      inputRef.current.blur();
+    }
+
+    isTouch.current = false;
   };

   const handleTagDelete = index => event => {
@@ -814,6 +831,7 @@ export default function useAutocomplete(props) {
         id: `${id}-option-${index}`,
         onMouseOver: handleOptionMouseOver,
         onClick: handleOptionClick,
+        onTouchStart: handleOptionTouchStart,
         'data-option-index': index,
         'aria-disabled': disabled,
         'aria-selected': selected,

What do you think of this diff? Do you want to work on a pull request?

@scott-mcnulty If you don't mind I could work on this issue.

@m4theushw Ok, this sounds good, but let's way @scott-mcnulty perspective on the matter first :).

I like the idea of the blurOnSelect prop you suggested @oliviertassinari -- seems like a good way to go
@m4theushw If you'd like to work on this be my guest :slightly_smiling_face:
Thank you guys for your help!


text:
input type number reset incorrect value

I have controlled component with material-ui  with type='number' and want to clear it by button.
steps:

typing something like '---8' or another incorrect number value with many plus or minus,
clear input by button.

Expected: input is clear
Real:  nothing happens
demo here: https://codesandbox.io/s/material-demo-p0kio?file=/demo.js

Duplicate of #10582

source: gharchive/issue

authors: madcher oliviertassinari

repo: mui-org/material-ui

license: MIT

license_type: permissive

license_source: github-api


text:
[test] Fix prettier ci task with multiple changed files

Fixes various issues in #12564:

no changes caused grep to match everything (this is a non-issue because why would this trigger a CI build?)
more than one changed file broke the if statement (I'm concerned that an error in a bash command does not cause the CI task to fail)
passing more than one file arg to the cli was considered on file

Sorry about the inconvenience. I should've been more careful with languages that I'm not that familiar with.
The build should be considered broken. Once this is confirmed I will retrigger with only one file changed and the remove the broken format completely. Only if all those builds return as expected should this be merged.

This does work locally git diff --name-only master... returns different results in CI. I'm going to investigate how I can diff against master in CircleCI.

The current approach relies on CIRCLE_COMPARE_URL which is empty at the moment. No idea why (it was set on previous builds).
I have no idea how to get a commit range from master to branch in CircleCI otherwise. #12564 should be reverted if no one else has solution.

I have no idea how to get a commit range from master to branch in CircleCI

The test_material-ui-x test can help.

Thanks. I wish we had a detailed diff of what's wrong (like beforeà rather than just the files that need to be fixed, but it's not that important. Let's try that out.

While this is useful for linting since most of those issues need to be resolved manually formatting should not be done manually. That should either be handled by the IDE or via yarn prettier.

source: gharchive/pull-request


text:
@material-ui/styles

This is a proof of concept. I have taken many shortcuts to make everything works together. This pull request is introducing:

An isolated @material-ui/styles package. I think that we can start with a v3.0.0-alpha.0 release.
Official support for the hook API.
a CSS = f(props) feature like all the major CSS-in-JS solutions have.
Use the new context API.
Upgrade to React v16.7.0-alpha.0.
Official support for the styled-components API
Official support for the render prop API

Closes #7633
Help with #13465
Merging this pull request will take some time. @mui-org/core-contributors early feedback is welcomed :)

@ConneXNL It's not about using styled-components under the hood, it's about publishing this documented API in a mldule: https://material-ui.com/customization/css-in-js/#styled-components-api---15-lines-

"Official support for the styled-components API".
Would love to see an example of this!

Sorry for this ot question question:

It's not about using styled-components under the hood (we will see later for that)

@oliviertassinari Is this an ongoing discussion somewhere? I'd love to read the arguments for both sides

Is this an ongoing discussion somewhere? I'd love to read the arguments for both sides

@sakulstra The styled components API implementation is less than 20 lines of codes with the withStyles higher-order components. It's the simplest solution.

Isn't have the ternary conditional (const theme = listenToTheme ? React.useContext(ThemeContext) : noopTheme;) in makeStyles bad? I thought you couldn't have hooks in conditionals?
const themeContext = React.useContext(ThemeContext);
const theme = listenToTheme ? themeContext : noopTheme;

Or is it OK because listenToTheme a constant for the life of the function?

@nicholas-l Yes, it's fine. It will never change between two renders.

What about type definition updates? :-D

@franklixuefei Need to finish up the context API rewrite for FormControl today and then I'll take a look.

// index.tsx
import { install } from '@material-ui/styles';

install();

// Ensures install is called before anything else.
// We can remove this once Material-UI v4 is released
require('./init.tsx') // Standard Index.tsx code

I'm doing this to ensure install is called first and to therefore avoid conflicting jss class names when building for production. Is there a recommended cleaner approach for now?

@XHMM It hasn't been translated yet. You can change the language:

It doesn't really solve the problem doesn't it? What if I need to change not root styles?

@yhaiovyi What do you mean?

Every example operates with { root: ... } styles only, and you inject it in element through className, which is confusing the least to say.

Btw, thanks that quick response.
But speaking of the real world example. I need to be able to set offsets for Tooltip based on component's props. If I wanted them static, I'd do something like withStyles({ tooltip: { margin: '10px' }})(Tooltip), but what should I do, if I need to set that margin with property?
And the last question is that possible to have that feature with mui stable, or alpha is the only option?

@yhaiovyi You can use the prop in the style: https://next.material-ui.com/css-in-js/basics/#adapting-based-on-props.

Doesn't explain styling of nested elements, none of examples covers that topic.

@yhaiovyi Something like this?
withStyles({
  tooltip: {
    margin: props => prop.size === 'large' ? 20 : 10,
  },
})(({ size, ...props }) => <Tooltip {...props} />)

Damn, I may be doing something wrong, I was sure I've tried that way. But hold on, so should it work with 3.9.2 ?

@yhaiovyi No, v4.

And can you think about any ETA for at least beta? Thanks.

@yhaiovyi We will have beta once #13663 is closed.

authors: ConneXNL eps1lon franklixuefei jrestall nicholas-l oliviertassinari sakulstra yhaiovyi


text:
[lab] Incomplete peerDependencies break usage with yarn pnp

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
Yarn PnP (Plug'n'Play) is more strict when it comes to specifying a library's peerDependencies correctly.
Currently, @mui/lab is missing the following entries in peerDependencies as they are peerDependencies of @mui/x-date-pickers:

@emotion/react
@emotion/styled

This causes errors like this one:
ERROR in resolving fallback for shared module @emotion/styled
Module not found: Error: @mui/styled-engine tried to access @emotion/styled (a peer dependency) but it isn't provided by its ancestors; this makes the require call ambiguous and unsound.

Required package: @emotion/styled
Required by: @mui/styled-engine@virtual:7a413bb353e548319c90adb82631b0c089acd1a802fdcf34c7a70f0d92986c9f29874633545bb7dc3d02df8b9ae9870617074e94e1a662f0e58596867aac2836#npm:5.6.1 (via /workspace-root/.yarn/__virtual__/@mui-styled-engine-virtual-d4f5f5ea46/0/cache/@mui-styled-engine-npm-5.6.1-06c551ec66-cd17d05902.zip/node_modules/@mui/styled-engine/)

Ancestor breaking the chain: @mui/lab@virtual:be640854c908ca72c5c45d17e3a5d76a2c579538ed551547b39edc486c90638abf94c25a34fa05a0a9167f796b8fb98e280e0bad9b44c61172fe75f4bcf39869#npm:5.0.0-alpha.80

Expected behavior 🤔
If the mentioned packages were added to peerDependencies, these errors would not occur with yarn pnp.
It would maybe also make sense to add them as optional peer dependencies because mui can also be used with styled-components instead of emotion.
Steps to reproduce 🕹
This bug is connected to https://github.com/mui/mui-x/issues/4761. I created a PR to fix the issue on @mui/x-date-pickers but after that, this library depending on @mui/x-date-pickers will have the same problem as it also doesn't declare these peer deps. So reproduction for this issue would be the same (also after mui-x is fixed):

Set up a new react app (i.e. via CRA) npx create-react-app mui-x-date-pickers
Make sure you have yarn installed
run yarn set version berry in order to get the latest yarn version with pnp
run yarn add @mui/lab @mui/material @mui/system
Implement usage of one of these date pickers:

import {CalendarPicker} from '@mui/lab';

function App() {
  const handleDateChange = () => {
  };

  return (
    <CalendarPicker
      date={null}
      onChange={handleDateChange}
    />
  );
}

export default App;

start the app --> errors appear.

Context 🔦
I'm in an environment where I rely heavily upon yarn functionalities (yarn workspaces, pnp, etc.). This issue is a major blocker for me.
Your environment 🌎

`npx @mui/envinfo`
  System:
    OS: macOS 12.3.1
  Binaries:
    Node: 16.11.1 - /opt/javascript/ncanode/16.11.1/node/bin/node
    Yarn: 3.2.0 - /opt/javascript/ncayarn/1.22.4/bin/yarn
    npm: 8.0.0 - /opt/javascript/ncanode/16.11.1/node/bin/npm
  Browsers:
    Chrome: 101.0.4951.54
    Edge: Not Found
    Firefox: 99.0.1
    Safari: 15.4
  Browser used: Brave [Version 1.37.116 Chromium: 100.0.4896.127 (Official Build)]

@oliviertassinari @nate-summercook maybe it's caused by the -alpha.0 dependency (instead of `-alpha.2) here: https://github.com/mui/material-ui/blob/master/packages/mui-lab/package.json#L75
If you are on react v18 the current versions are unresolvable (as -alpha.0 had only react v17 peer dependency)

@oliviertassinari @nate-summercook maybe it's caused by the -alpha.0 dependency (instead of -alpha.2) here: https://github.com/mui/material-ui/blob/master/packages/mui-lab/package.json#L75

No, I did try with -alpha.2 (through resolutions. Didn't fix the problem.

@nate-summercook Please provide a minimal reproduction. @mui/x-date-pickers is not part of @mui/lab. You also need to install @emotion/react and @emotion/styled in your project.

repo: mui/material-ui


text:
[system] Add spacing theme token to be used in theme.spacing()

part of https://github.com/mui/material-ui/issues/40225
closes #37911
// before
theme.spacing(1) // 8px

// after
theme.spacing(1) // calc(1 * var(--mui-spacing))

Changes
When using extendTheme({ spacing: string | number }), a new token (--mui-spacing) is created for use with CSS calc function.
https://github.com/mui/material-ui/assets/18292247/de00d90e-9daa-47c7-a074-780e5ab398d5

[x] I have followed (at least) the PR section of the contributing guide.

@DiegoAndai This is not a breaking change but do you think it should a part of v5 or v6?

Moved to v6.

@DiegoAndai This is not a breaking change but do you think it should a part of v5 or v6?

Being so close to v5 freezing, I agree with you to not merge it to master and wait for v6.

@siriwatknp let me know when this is ready for review 😊

@siriwatknp let me know when this is ready for review 😊

It's ready!

There is a regression visible in the video description of these changes:

I opened to try to fix it #42574.

authors: DiegoAndai oliviertassinari siriwatknp


text:
Make fetch available as a global in server side code

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
fetch is not available as a global in serverside code. Let’s use this kind of polyfill?
Examples 🌈
No response
Motivation 🔦
No response

Added in https://github.com/mui/mui-toolpad/pull/1651

repo: mui/mui-toolpad


text:
Applications cards overflow badly

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯

Expected behavior 🤔
Proper overflow behavior. Ellipses maybe? Or should this UI be a table rather than cards?
Steps to reproduce 🕹
Steps:

Context 🔦
No response
Your environment 🌎
No response

i think ellipses would solve it, but the title text should be small enough so that titles that aren't too long are always fully readable

authors: Janpot apedroferreira


text:
Avoid restarting vite devserver when env file changes

Currently when the application env file changes, the vite devserver restarts on another port. Not sure why it uses another port but we don't want it to restart anyway, we want to maintain control over env vars for this application.
To do:

[x] Add test

@apedroferreira There's a minor issue in the test that I've seen before in other tests, is that queries don't reload when the env file changes. With the current functionality this is not a huge problem because to change the env file you'd have to blur the window and window focus causes a revalidation for all queries. This currently doesn't happen in playwright and they don't support hiding/showing the tab yet. We'll have to fix this issue at some point when we start altering .env files from the UI.
second to note is that the env file gets loaded from disk on every query call, this is wasteful and I'd like to centralize all env file logic for functions and rest queries so that it loads only once and notifies on changes. Will look into this after merging https://github.com/mui/mui-toolpad/pull/2062

@apedroferreira There's a minor issue in the test that I've seen before in other tests, is that queries in the canvas don't reload when the env file changes. With the current functionality this is not a huge problem because to change the env file you'd have to open your code editor and browser window focus causes a revalidation for all queries. Playwright doesn't support an API to simulate hiding/showing the browser tab yet. We'll have to fix this issue at some point though when we start altering .env files from the UI. second to note is that the env file gets loaded from disk on every query call, this is wasteful and I'd like to centralize all env file logic for functions and rest queries so that it loads only once and notifies on changes. Will look into this after merging #2062

Ok, we should look into loading the env data from memory and also making sure it's always up to date in queries no matter what. Thanks for looking into it, but let me know if I should create an issue for this / look into it instead if it helps!

Playwright doesn't support an API to simulate hiding/showing the browser tab yet.

I have this in the rest-basic tests:
 // Make sure switching tabs does not close query editor
  const newTab = await context.newPage();
  await newTab.bringToFront();
  await page.bringToFront();
  await expect(newQueryEditor).toBeVisible();

It might not do exactly what a real browser does though, if I remember correctly.


text:
[system] Remove createUseThemeProps, RtlProvider, and DefaultPropsProvider API

Summary
From https://github.com/mui/material-ui/pull/40648#issuecomment-1961591574

This PR aims to remove the usage of React context to make some components RSC compatible while having backward compatible with emotion.

What's the use case to have RSC compatible components? We use the Badge in the PR, but I guess it's not the objective (I don't see why a developer would want this with his component, there would be no state change animations, the onClick listener wouldn't works, etc.), but I guess the Badge is meant as a supplement for layout components. For instance, it makes a lot of sense to me with a <Container> with a different default layout mode propagated with the context or for a static content: https://github.com/mui/mui-x/issues/12180).
Now, I don't think this change is needed, we can have context (maybe with nesting support but not sure) https://github.com/emotion-js/emotion/issues/2978#issuecomment-1935131675.

Trade-off

But them, how can we support theme nesting? I don't see this mentioned, but I think it matters. For example, how is the documentation of Material UI supposed to be able to show components in their default form while the docs has a MUI branded theme?
At first sight, I would recommend:

We revert this PR.
We introduce a server side theme, to live in the server bundle, alongside the a client bundle theme. We need this anyway to get RSC support with Emotion.
We update the theme provider and theme customer to support both theme locations.

This way, we get:

No theme propagation feature regression on the client bundle, theme nesting continues to work. On the server bundle, the theme nesting mighty not work, it depends on how React calls the cache API, but I wouldn't expect it to be achievable. Maybe one-day if React introduce a true context RSC API.
The foundations for Emotion with RSC.

Opportunity moved to https://github.com/mui/pigment-css/issues/129
Search keywords:

I'm extending the scope of this issue to <DefaultPropsProvider>, https://github.com/mui/material-ui/issues/42635. This feature means that we don't support default prop value configuration for RSC. If we solve https://github.com/mui/material-ui/pull/42476#discussion_r1632325822, we would be able to support it.
Now, the only concern for me is the support of theme nesting on RSC and client-side components. This looks more important to support theme nesting than the default prop on RSC. The React.cache() or window.__theme solution doesn't support theme nesting. As I understand it, today, Pigment CSS doesn't support it either. So I would only explore how to support theme nesting before removing all of these APIs (createUseThemeProps, RtlProvider, and DefaultPropsProvider)

repo: mui/pigment-css


text:
Reconnection doesn't work

The call for a reconnect doesnt work properly. Probably a restart of the reactor is needed, which needs a restart of the worker loop.

With v.0.2.0 twisted will be removed anyway from the client. Therefore this won't be fixed.


text:
invisible ties

How could I encode "invisible" ties?
Here is some example music from JRP (http://josquin.stanford.edu/cgi-bin/jrp?a=notationEditText&f=Jos0602d):

The last notes in each part are "terminal longs" which function similar to fermatas in Renaissance-era music.   Behind these longs, the encoding in the musical data looks like this:

In particular I convert the two gestural tied breves into a single visual long.  How can I do that in MEI?
note@visible="false" can be used to hide the second breve in the tied group, but how to not display the tie as well, since it does not have a visual attribute?
Here is a sample encoding, which has (1) the second note invisible, (2) the barline invisible, and (3) the breve visually rendered as a long:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="4.0.0">
    <meiHead>
        <fileDesc>
            <titleStmt>
                <title />
            </titleStmt>
            <pubStmt />
        </fileDesc>
        <encodingDesc>
            <appInfo>
                <application isodate="2017-10-10T21:50:27" version="2.0.0-dev-7f71266">
                    <name>Verovio</name>

Transcoded from Humdrum

                </application>
            </appInfo>
        </encodingDesc>
        <workDesc>
            <work>
                <titleStmt>
                    <title />
                </titleStmt>
            </work>
        </workDesc>
    </meiHead>
    <music>

            <mdiv>
                <score>
                    <scoreDef xml:id="scoredef-0000001705520885" midi.bpm="400">
                        <staffGrp xml:id="staffgrp-0000001762618526">
                            <staffDef xml:id="staffdef-0000001940139764" clef.shape="G" clef.line="2" n="1" lines="5" />
                        </staffGrp>
                    </scoreDef>

                        <measure xml:id="measure-L2" right="invis" n="1">
                            <staff xml:id="staff-L2F1N1" n="1">
                                <layer xml:id="layer-L2F1N1" n="1">
                                    <note xml:id="note-L4F1" dur.ges="breve" dur="long" oct="4" pname="b" accid.ges="n" />
                                </layer>
                            </staff>
                            <tie xml:id="tie-L4F1-L6F1" startid="#note-L4F1" endid="#note-L6F1" />
                        </measure>
                        <measure xml:id="measure-L5" right="end">
                            <staff xml:id="staff-L5F1N1" n="1">
                                <layer xml:id="layer-L5F1N1" n="1">
                                    <note xml:id="note-L6F1" dur="breve" oct="4" pname="b" visible="false" accid.ges="n" />
                                </layer>
                            </staff>
                        </measure>

                </score>
            </mdiv>

    </music>
</mei>

I could not encode the tie if necessary, but then the MIDI output from verovio would be incorrect and it would re-attack the invisible breve...

So in the gestural domain you need a breve tied to a breve, but in the logical (and visual) domain you need only a long.  Right?  It doesn't look like we have a way to encode a tie as purely gestural yet.  Perhaps that should be added.

Yes, although I would say that the gestural and logical domain are the same in this case, and this is how the original data is encoded for analytic purposes.  For printing, I want to transform the tied group of notes into a visual representation as found in the original edition by converting the first notehead to a long, and hiding all notes tied to that note (including the ties of course).
For now I will cheat and remove the tie when converting to MEI.  Here is what the example looks like in rendered with verovio at the moment:
http://verovio.humdrum.org/?k=e&file=jrp:Jos0602d&filter=myank -m85-93

(barline after long in bottom staff I will also have to figure out how to get rid of)
And here is how the data is otherwise encoded without showing the terminal longs:

I could not encode the tie if necessary, but then the MIDI output from verovio would be incorrect and it would re-attack the invisible breve...

This sounds like a MIDI conversion problem to me.  Invisible notes should be ignored, shouldn't they?

For now I will cheat and remove the tie when converting to MEI. Here is what the example looks like in rendered with verovio at the moment:

It's not "cheating" to remove the tie.  In fact, it's anything but cheating.  It's being faithful to the different notational styles  -- ties exist in CMN, but not in mensural notation.  I say it's cheating to "warp" CMN into mensural by manipulating its visual characteristics.  That's the thing we're trying to avoid by encoding both styles.
It would be more honest to provide both encoding styles (via <choice>) and switch between them.

It would be more honest to provide both encoding styles (via ) and switch between them.

That is probably good, although the musical content is basically the same so a bit redundant.   So more expensive in terms of encoding as well as maintenance :-)
The terminal long has a variable duration: when a singer comes to the long note at the end of their part, then keep holding it until all other singers are holding their terminal long.  It functions similar to a fermata in CMN.  I am displaying a terminal long in full-score format which was never done in mensural music, since the music was always written out by part (when generating a part, aligning the terminal long with other parts is not a problem).
In Humdrum, I encode the score as it would be done in Finale, as that is where the scores are initially entered.  When converting them to Humdrum, I add a "terminal long" marker to the note attack of the last note for each part in the piece (and before any double barline which demarks a major section boundary).  For analysis (logical form) I use the Finale-style encoding, as well as for the gestural form (MIDI). for the visual form, I generate the visual long in the process of converting the Humdrum data to the music typesetting format (MuseData for this example):

Here is the Humdrum data for this excerpt:
**kern	**kern	**kern	**kern
*clefF4	*clefGv2	*clefGv2	*clefG2
=249	=249	=249	=249
2C	2A	2E	0r
2D	2F	2F	.
2BB-	1G	2D	.
2C	.	2E	.
=250	=250	=250	=250
1AA	2r	2r	1c
.	1A	1E	.
1BB-	.	.	1d
.	2G	2D	.
=251	=251	=251	=251
2AA	2A	1E	2.c
2.C	2G	.	.
.	.	.	4B-
.	2A	2r	2c
4AA	.	.	.
2BB-	2G	2D	2d
=252	=252	=252	=252
2C	2A	2E	2c
2D	2F	2F	1f
2BB-	1G	2D	.
2C	.	2E	2e
=253	=253	=253	=253
2AA	[0Fl	2C	[0fl
2BB-	.	2D	.
2AA	.	2C	.
[2BB-	.	[2D	.
=254	=254	=254	=254
2BB-]	0F_	4D]	0f_
.	.	4BB-	.
2AA	.	2C	.
2.BB-	.	1D	.
4AA	.	.	.
=255	=255	=255	=255
0FFl	0F]	0Cl	0f]
==	==	==	==
*-	*-	*-	*-
!!!RDF**kern: l=terminal long

If I remove the RDF line, then the music will be printed in a more conventional modern style, which is the only format that verovio can currently handle properly:

probably adding fermatas to the notes in the last measure since the original last notes were longs and not breves as in two parts.  MIDI playback is correct since this is conventional CMN.
Verovio is getting close to what I want.  Here is what happens when I add the definition of the "l" marker back into the data:

Playing the music, you will hear the invisible notes being re-struck since I removed the ties.  These invisible notes could be converted to invisible rests (a.k.a. space elements) and a @dur.ges added to the terminal longs, which verovio does not support (yet)).  So either MEI should add an invisible attribute to ties, which would allow verovio to generate MIDI properly from the visual form of the score in verovio as is; or verovio should add support for note@dur.ges.  Or both should be done, of course.
If the music is encoded with invisible notes/ties, then it would be easier to switch between the two visual formats programmatically in MEI: to convert to standard CMN, make all of the invisible notes and ties attached to the terminal long visible.  Using the note@dur.ges/space method would require swapping out the spaces for notes and adding ties, which would be a much more difficult process (and be better suited to storing both forms in <choice> if that is the encoding method).
Checking the MuseData conversion of this score:
http://josquin.stanford.edu/data?a=musedata&f=Jos0602c
I see that I remove the visual ties, but I partially keep the gestural ties, the "-" after 48-, I don't make the MIDI file from the MuseData conversion; otherwise I would fix that.  And I make the tied notes invisible (P  C1:p1 is equivalent to note@invis="true" in MEI).
measure 249
rest  48      1
measure 250
C4    24      1 w
D4    24      1 w
measure 251
C4    18      1 h.    u
Bf3    6      1 q     u
C4    12      1 h     u
D4    12      1 h     u
measure 252
C4    12      1 h     u
F4    24      1 w
E4    12      1 h     u
measure 253
F4    48      1 L
msilent 254
F4    48-     1 B
P  C1:p1
msilent 255
F4    48      1 B
P  C1:p1
mheavy2

We can make more elements be members of att.visibility.  But how does this compare with using @type (e.g., @type="invis") to hide these items during rendition?

We can make more elements be members of att.visibility. But how does this compare with using @type (e.g., @type="invis") to hide these items during rendition?

Doing that should work for webpage interfaces.
It would not be as easy for static SVG use -- probably accomplished by adding a style element to the SVGs after they have been generated by verovio (or other renderer).

There's a fairly lengthy list of elements whose visual domain attributes doesn't include @visible.  As I recall these were removed at the point at which the possibility of a style language was introduced.  I have no objection to adding them back, but I think we need to determine exactly what we mean when we say something is "invisible".  Does it mean --

space for the item is preserved in the layout but the item just isn't shown, or
no space is retained for the item and the layout is "collapsed" as though the item never existed?

I've been assuming option 1 since it would provide a way to "de-clutter" a complex rendering. (I imagine Finale-like "handles" being displayed for invisible/hidden elements.) Option 2, on the other hand, leads to more fundamental philosophical questions along the lines of "If a tie falls in the woods ...".
One way forward might be to add @visible to more elements now (assuming option 1), and address option 2 in a style language later.  Alternatively, we could modify @visible to take 3 values: show, hide, ignore, where "show" and "hide" address option 1 and "ignore" addresses option 2.

space for the item is preserved in the layout but the item just isn't shown, or
no space is retained for the item and the layout is "collapsed" as though the item never existed?

In CSS, (1) is the equivalent of visibility:hidden, and (2) is display:none, so the best behavior would be (1) for an invis attribute to match the behavior of CSS.  Technically I would want (2) for invisible ties, but (1) should always work just as well.
Using ignore for (2) sounds good.  This would make a <note> behave like a <space>, for example.  Potentially this could be useful for controlling slurs that go off to nowhere: they could be attached to an "ignored" note that otherwise would not take up any space by itself.
@invis could also be used to control the visibility of things such as a "gestural" slur, or other gestural feature in the music.  Gestural items could have the default behavior @visible="hide", but they could be forced visible by setting @visibile="show" explicitly.  Conversely, fermatas could be switched from visible to purely gestural by setting @visible="hide".

Using ignore for (2) sounds good. This would make a <note> behave like a <space>, for example.

I think not, because a <space> occupies time and therefore has dimensions.  An ignored note (that is, taking away its dimensions) can't be equivalent to a space (which has dimensions).  Perhaps you meant to say that a slur could be attached to an invisible note (not an ignored one).

@invis could also be used to control the visibility of things such as a "gestural" slur, or other gestural feature in the music.

I don't think we should equate invisibility with gestural-ness or vice versa.  These qualities should be independent of each other.

I think not, because a  occupies time and therefore has dimensions. An ignored note (that is, taking away its dimensions) can't be equivalent to a space (which has dimensions). Perhaps you meant to say that a slur could be attached to an invisible note (not an ignored one).

Yes.  I was thinking in terms of a full score where the duration is still needed, but just for alignment.

@craigsapp, So,

@visible="show" means the entity should be rendered. This is the default for any "render-able" elements. Non-render-able elements wouldn't carry @visible anyway.
@visible="hide" means the entity should not be rendered, but should affect performance,
@visible="ignore" means the item should not be rendered, and should not affect performance.  In practical terms, it is simply "gone".

But, I'm still not sure how this would help deal with the Josquin example, because the possible alternatives -- one mensural, one CMN -- still have to be encoded somehow.  Even with the possibilities described above, a note, fermata, etc. can't be visible and invisible simultaneously.  The mechanism for switching between (or at least identifying) alternatives is still <choice>.

@visible="show" means the entity should be rendered. This is the default for any "render-able" elements. Non-render-able elements wouldn't carry @visible anyway.
@visible="hide" means the entity should not be rendered, but should affect performance,
@visible="ignore" means the item should not be rendered, and should not affect performance. In practical terms, it is simply "gone".

Yes, there would be no effect on performance, only on visual rendering.   You were suggesting that the difference between @visible="hide" and @visible="ignore" would be similar to @visibility="hidden" and @display="none" in CSS.  Visibility hidden in CSS means to make them invisible, but preserve the layout as if the object were still there.  Display none in CSS means to make them invisible and do not preserve the space that the take up  (i.e., remove them from the display).
Strictly speaking I would want to say that the invisible notes and ties that form the end of a terminal long are @display="none" which would map to @visible="ignore".  For single-staff music, the objects could be removed.  For multi-staff music, the notes would have to be converted internally into spaces before rendering.
In Humdrum data, I would say that I am adding a "functional attribute" to the first note in the terminal long group.  I encoded in modern notation, and use modern notation for analysis, but when converting to a notation format (MuseData usually), I "compile" the data according to the functional attribute.  This would be somewhat equivalent to embedding an attribute on a note (such as with note@type="terminal_long") which would then trigger an XSLT script to process the data into the visually desired form.
Fermatas are the modern equivalent of terminal longs.  Here are the two visual syntaxes:

In the Josquin Research Project encodings, which come from Finale, the data is encoded purely in CMN.  Jesse wants to use a somewhat hybrid mensural/CMN representation that reflects the original mensural notation.  For example, the original note values are used in the notation, and in this case terminal longs are used instead of a long series of tied notes ending with a fermata sign.  When converting into MEI, I would want to keep the CMN syntax, at least for analysis and performance, but be able to adjust the visual look to do something which is not CMN.  Karen and other Renaissance/Medieval scholars would also want this sort of capability: rendering the notation in explicit rhythms and adding barlines as in CMN, but preserving other aspects of mensural music such as the mensural signs and terminal longs.  The mensural signs are important to display since they encode both meter and tempo, but the terminal long are "visual sugar".

I basically see one point of discussion with the approach to mensuralish CMN
shouldn't mensuralish CMN rather rely on <staffLine> than measure?
This would:

resolve the problem of meter conformity (as none can ever exist)
make it unnecessary to have multiple "empty" measure after the terminal longs
render the problem to a mere synchronisation problem with no differences between logical, gestural and visual durations, which brings me to the second point

Consequently

This sounds like a MIDI conversion problem to me[, too!]

N.B. The MIDI rendition by means of certain converter should not serve as model for encoding. Instead the converter should cover the logical aspects of the ›mensuralish MEI‹ (which I like, though ;-)

Has this been implemented yet?   Invisible ties are a required feature of MEI.

authors: bwbohl craigsapp pe-ro siennamw

repo: music-encoding/music-encoding


text:
Pluggable layout engines, such as jade

Riot is awesome project for me. But to write html is feel awful...
I want to write html by Jade. So I created experiment implementation -> https://github.com/e-jigsaw/roister
Roister can write in Jade and CoffeeScript. CoffeeScript is now officially support. Remain only Jade. I want to support Jade too. Example:
riot --type coffeescript --template jade source.tag

Is this good?

Impressive.
I like the idea. Makes sense to have layout pre-processors similar to what we do with logic (js) now.
Maybe you can extend Riot this way and make a pull request?

@tipiirai thanks! I will try.

This would be pretty neat.

I wonder whether this is something that should be implemented in Riot. For one explicit dependancies on external tempting frameworks seems like a bad idea, not to mention a management nightmare moving forward...

That being said Jade is a much nicer syntax for writing HTML. Would something like this be better implemented in user land, via a browserify transform. or similar?

@joshgillies I understand your opinion. I thought same, so I created another compiler(https://github.com/e-jigsaw/roister). But riot began to support CoffeeScript, es6 and TypeScript. For now it is reasonable to support template language. isn't it?

@e-jigsaw I've been inspecting the setup since posting my thoughts above; and must admit with further examination I note that Riot doesn't explicitly depend on anything for the compiler. Rather it's on the user to ensure they have the dependancy met for coffeescript, typescript, et al.
I guess given the current trend it's not unreasonable to go with adding in support for further compile to JS or compile to HTML technologies. I just worry about bloat moving forward.

@joshgillies On the implementation:
https://github.com/muut/riotjs/blob/master/package.json#L34:
  "dependencies": {
    "chokidar": "~1.0.0-rc2",
    "minimist": "~1.1.0",
    "shelljs": "~0.3.0"
  },

Riot depends on just above. If user want to CoffeeScript, es6..., user have to install that module by own. (https://muut.com/riotjs/compiler.html) So your concern is no problem.

Check :+1:

Thanks :satisfied:

#239 merged!
Close this issue.

authors: aurri e-jigsaw joshgillies tipiirai

repo: muut/riotjs

license: mit

license_source: bigquery


text:
for loop and "this" does not work in recent version.

This feature used to work (it is still in the docs):
<todo-item each="{ items }" data="{ this }"></todo-item>

data = { this } used to bind the item in the forEach loop.
But now it stops working, see this example: http://jsfiddle.net/dz9h6v4d/1/

Just tried again, and seems the behavior is not changed.
Maybe it was because it was due to firebase data object.
Anyway, the fiddle here does not show the issue correctly. Close this issue.


text:
fix: Account for cases where the media-controller instance is part of…

… a custom element's shadow DOM in fullscreen mode.

Latest not released. False alarm. Nothing to see here.

repo: muxinc/media-chrome


text:
Player resolution not being properly reported

Our team has recently migrated to the media3 version of ExoPlayer.  As such, we have started using the com.mux.stats.sdk.muxstats:data-media3-at_1_1:1.2.2 version of Mux.  Since switching to this version of Mux, we have observed that our player resolution is constantly reported as 1048576 x 1048576.
We have manually tried supplying the player and screen sizes as recommended in this guide, but have not had any luck.
playerView?.let { view ->
    val width = Resources.getSystem().displayMetrics.widthPixels
    val height = Resources.getSystem().displayMetrics.heightPixels

    muxStats?.setPlayerSize(view.width, view.height)
    muxStats?.setScreenSize(width, height)
}

Due to the extremely large player resolution, our upscale percentage is astronomically high, resulting in us always getting a 0/100 score for video quality.
I can't determine if this is a setup issue or a library issue, but this all seemed to work find before migrating to media3.

From the Zendesk Ticket:
Hey David & team!
So it's my understanding that you shouldn't need to set all three of these—only a subset of them.
If you're passing the SDK a playerView during initialization, the resolution tracking is automatic, and you shouldn't need to manually set the others. If you don't have a playerView at first, you can use setPlayerView to pass the SDK one later on during the session.
In the case where you're not using a playerView, you have to use setPlayerSize, along with presentationChange & setScreenSize for fullscreen tracking & VQ metrics. This turns off auto-tracking and requires you to manually update the resolutions as things change. Here's the guide for manual fullscreen tracking.
The preferred path is to use the playerView way since it's automatic, but if you want to go the manual route, you can use those other methods I shared above.
The dev who built this is on PTO right now, but I'll make sure to flag this to them when they return in case something is off.
Hope this helps!
-Edwin

Hey Vinnie just closing the loop here from the ZD ticket!
I spoke to our Android dev about this and they're making an internal ticket to double check the behavior around setting a playerView on initialization & using setPlayerView later on.
This was resolved using setPlayerView instead of using non-null values for both.

authors: edwin-mejia vfutia


text:
Update main.py

torch.cuda.amp suites

it's mistake

repo: muzairkhattak/ViFi-CLIP


text:
Cannot Set Brightness via Script/Automation

Describe the bug
Setting the brightness via the included service fails.
To Reproduce
Steps to reproduce the behavior:

Create a script or automation
Add "Call Service" action
Select "Philips Hue Play HDMI Sync Box: Set brightness"
Select brightness in UI or set via YAML

Only 0 and 1 can be selected as values and setting values via YAML does not work either.
Expected behavior
Brightness value of Hue Sync Box updated.
Environment

Home Assistant Core version: core-2021.11.0
Home Assistant operating environment (OS/Container/Supervised/Core): OS
Huesyncbox integration version: 1.14.0

Should be fixed in v1.15.0.

Confirmed. Fixed!
Thank you!!!

authors: brodkin mvdwetering

repo: mvdwetering/huesyncbox


text:
Run with --gpu option and fail to get a clx context

I am trying to follow an example found here: https://github.com/mviereck/x11docker/issues/198
I ran this:
x11docker --gpu x11docker/check glxinfo | grep renderer

And I have nvidia drivers installed on my host. I get the following error:
docker.io/x11docker/check:latest
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  149 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  26
  Current serial number in output stream:  25

Am I missing something? I was hoping the --gpu option would suffice for passing the GPU through to my x11docker container and I'm not seeing that is the case. So I ran the test above, and I can see the same error that I was getting in the context of another container (x11docker/lxde-wine) when trying to run an openGL application.

FYI, my NVIDIA Driver version:
$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  460.67  Thu Mar 11 00:11:45 UTC 2021
GCC version:  gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)

With option --gpu and a proprietary NVIDIA driver x11docker should show you some messages how to set up the driver.
Can you show me the output of x11docker?
Possibilities to use an NVIDIA GPU are described also in https://github.com/mviereck/x11docker/wiki/NVIDIA-driver-support-for-docker-container

x11docker note: Installing NVIDIA driver 460.67 in container.

That looks good so far.

OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits)

So it shows that it is installing the driver, however, still isn't using Nvidia for Open GL. I also ran this just to see, and I can see it is running on my CPU:

Indeed, it runs on CPU. llvmpipe also indicates software rendering.
I am not sure what is going wrong. I wonder if here is an x11docker bug or if glxinfo and glxgears just do not work with NVIDIA at all.
Try:   x11docker --gpu x11docker/check glxspheres64
This is similar to glxgears,  but more up to date.

I am running an x11docker on screen 30 right now, but it was just me testing something. Do I need to close all instances of x11docker?

No, that is not needed.
$ echo $DISPLAY
localhost:11.0
$ ls /tmp/.X11-unix
X30

It seems display :11 is running over tcp instead over a unix socket. That is a quite unusual setup. Is that a custom setup of you?

As for the echo $DISPLAY, I don't believe I did anything intentional to customize that setup. Do you know how to get it to run the more conventional way, over a unix socket instead of tcp?
Here is the output of x11docker --gpu x11docker/check glxspheres64
x11docker note: Installing NVIDIA driver 460.67 in container.

Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
Visual ID of window: 0xab
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  149 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  27
  Current serial number in output stream:  28

When I add the --xorg flag, I get this instead:
$ x11docker --gpu --xorg x11docker/check glxspheres64
x11docker note: Installing NVIDIA driver 460.67 in container.

Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
Visual ID of window: 0x3d1
Context is Direct
OpenGL Renderer: llvmpipe (LLVM 7.0, 256 bits)

Which looks like it's still running on CPU.

As for the echo $DISPLAY, I don't believe I did anything intentional to customize that setup. Do you know how to get it to run the more conventional way, over a unix socket instead of tcp?

What system do you run? Which desktop? Which display manager?

When I add the --xorg flag, I get this instead:

For further test runs it makes sense to always use --xorg to exclude possible issues by the tcp setup of your regular display.

Which looks like it's still running on CPU.

Yes. Can you show me ~/.cache/x11docker/x11docker.log at www.pastebin.com after terminating x11docker --gpu --xorg x11docker/check glxspheres64?
Maybe I find a hint in the log.

I'm running Ubuntu 20.04. Originally installed the Server Edition. I used the apt package manager to install Ubuntu-Desktop and various other packages to get a desktop running on it. Originally it had no video output, but I acquired a GPU recently so I wanted to be able to output a desktop. The display manager is the default one that comes with Ubuntu-Desktop, GDM3.
I am gathering the logs and will send you the link to them, thank you.

@mviereck Here you go: https://pastebin.com/NFwQ6Xzm

Some points I found so far, will look further tomorrow:
Xorg seems to load the NVIDIA driver fom host (lines 1647-1652), but unloads it later for unknown reasons (lines 2081-2088):
(II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
(II) Module nvidia: vendor="NVIDIA Corporation"
	compiled for 1.6.99.901, module version = 1.0.0
(II) NVIDIA dlloader X Driver  460.67  Thu Mar 11 00:09:07 UTC 2021
(II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
(EE) No devices detected.
[...]
(II) Loading /usr/lib/xorg/modules/libfb.so
(II) Module fb: vendor="X.Org Foundation"
	compiled for 1.20.9, module version = 1.0.0
(II) Unloading nvidia
(II) Unloading modesetting
(II) Unloading fbdev
(II) Unloading fbdevhw
(II) Unloading vesa

Can you successfully use the NVIDIA GPU with host applications?

I found this warning,missed it above:
x11docker WARNING: x11docker can run Xorg on another tty (option --xorg),
  but you won't see it in your SSH session.
  Rather install e.g. Xephyr on ssh server and use option --xephyr.

Did you run all the commands over SSH?
That also explains the tcp setup.
Using headless NVIDIA GPU over SSH is a quite special task. I wasn't aware that this is the situation we are speaking of. Somewhere is a ticket with a successful setup, will look for it tomorrow.

Have a look at https://github.com/mviereck/x11docker/issues/199

@mviereck 😮
So I made some progress thanks to what you mentioned here (https://github.com/mviereck/x11docker/issues/199#issuecomment-557927571). I needed to add a virtual display to my Xorg.conf file.
SubSection     "Display"
        Virtual     1920 1080
EndSubSection

Now, from within the container, I'm able to run glxinfo | grep renderer
john@99687caaec6d:~$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Quadro P4000/PCIe/SSE2
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
    GL_NVX_conditional_render, GL_NVX_gpu_memory_info, GL_NVX_nvenc_interop,
    GL_NV_command_list, GL_NV_compute_program5, GL_NV_conditional_render,
    GL_NV_parameter_buffer_object2, GL_NV_path_rendering,
    GL_NV_path_rendering_shared_edge, GL_NV_pixel_data_range,
    GL_NV_stereo_view_rendering, GL_NV_texgen_reflection,
    GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted,
    GL_NVX_conditional_render, GL_NVX_gpu_memory_info, GL_NVX_nvenc_interop,
    GL_NV_command_list, GL_NV_compute_program5, GL_NV_conditional_render,
    GL_NV_parameter_buffer_object2, GL_NV_path_rendering,
    GL_NV_path_rendering_shared_edge, GL_NV_pixel_data_range,
    GL_NV_stereo_view_rendering, GL_NV_texgen_reflection,
    GL_EXT_multisample_compatibility, GL_EXT_multisampled_render_to_texture,
    GL_EXT_multisampled_render_to_texture2,
    GL_EXT_raster_multisample, GL_EXT_render_snorm, GL_EXT_robustness,
    GL_NV_clip_space_w_scaling, GL_NV_conditional_render,
    GL_NV_packed_float_linear, GL_NV_path_rendering,
    GL_NV_path_rendering_shared_edge, GL_NV_pixel_buffer_object,
    GL_NV_shadow_samplers_cube, GL_NV_stereo_view_rendering,
    GL_OES_fbo_render_mipmap, GL_OES_geometry_point_size,
    GL_OVR_multiview_multisampled_render_to_texture

And when I run glxgears I get about 75fps, which I'm assuming is because it caps it when on the GPU. I also ran nvidia-smi and I can see the program running:
Tue Mar 30 18:44:41 2021
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.67       Driver Version: 460.67       CUDA Version: 11.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  Quadro P4000        Off  | 00000000:42:00.0  On |                  N/A |
| 49%   45C    P8    10W / 105W |     83MiB /  8119MiB |     17%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A   2383792      G   /usr/lib/xorg/Xorg                 77MiB |
|    0   N/A  N/A   2387054      G   glxgears                            2MiB |
+-----------------------------------------------------------------------------+

If I wanted to document this for others, where should I add this to the wiki? Really appreciate your help on this, so it'd be great if I could contribute as well.

So I'll pick this up again tomorrow, but I wanted to say, when I run this x11docker --gpu --xorg x11docker/check glxinfo | grep renderer I still get this as a result, even after adding the virtual display:
x11docker note: Installing NVIDIA driver 460.67 in container.

    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
    GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits)

So there is a difference between running the line above and running this script below that I want to nail down so I can fully understand it:
#! /bin/bash
read Xenv < <(x11docker --display=30 --desktop --size 1920x1080 --pulseaudio --gpu --xorg --xtest --showenv --sudouser x11docker/lxde-wine)
env $Xenv xpra start-desktop :30 --use-display --start-via-proxy=no --daemon=no --bandwidth-limit=0 --system-tray=no --speaker=disabled --microphone=disabled

And when I run glxgears I get about 75fps, which I'm assuming is because it caps it when on the GPU. I also ran nvidia-smi from the host and I can see the program running:

Great! Success so far.

So there is a difference between running the line above and running this script below that I want to nail down so I can fully understand it:

Surprising. Good that you found this!
I can only imagine that --sudouser makes a difference also it should not.  --xtest should be enabled by default.
Please try:
x11docker --gpu --xorg --sudouser x11docker/check glxinfo | grep renderer

If that works, please try:
x11docker --gpu --xorg --cap-default x11docker/check glxinfo | grep renderer

x11docker --gpu --xorg --newprivileges=yes x11docker/check glxinfo | grep renderer

If I wanted to document this for others, where should I add this to the wiki? Really appreciate your help on this, so it'd be great if I could contribute as well.

That would be nice!
I'd say this should be an article on its own. Linked with https://github.com/mviereck/x11docker/wiki/NVIDIA-driver-support-for-docker-container and shown in the overview/home as a subarticle of this.

Thanks for all the help!
At the end of this, I'll take a look at the wiki and run by you the various pages I think could be updated about it. And I'll draft up an article dedicated to this special setup, with specifics on xorg.conf and NVIDIA GPUs.
This is pretty great progress, but here's the issue I'm running into. I'm actually able to get it to report the GPU with this command x11docker --gpu --xorg x11docker/check glxinfo | grep renderer and having no sudouser or special access. I realized that earlier, it wasn't working because my script was running.
#! /bin/bash
read Xenv < <(x11docker --display=30 --desktop --size 1920x1080 --pulseaudio --gpu --xorg --xtest --showenv --sudouser x11docker/lxde-wine)
env $Xenv xpra start-desktop :30 --use-display --start-via-proxy=no --daemon=no --bandwidth-limit=0 --system-tray=no --speaker=disabled --microphone=disabled

If I'm running the above script, then I can't get glxinfo in a separate container to report the GPU. Even when adding --sudouser or ``--cap-defaultor--newprivileges=yes`. None of those options will report the GPU. However, if I end the script, then I get glxinfo with the vanilla command, no special sudo user or privileges needed. So, I guess my issue here is I hoped I could have multiple containers running with access to the GPU and OpenGL drivers, but right now I am limited to having at most 1.
Still, this is pretty great progress. Any ideas on how I can get multiple containers with GPU access going?

Oh, and I tried running glxgears with vblank_mode=0 as an env variable and it did not work. I found an answer here that states with the closed-source driver, you have to run this instead:
$ __GL_SYNC_TO_VBLANK=0 glxgears
62543 frames in 5.0 seconds = 12508.548 FPS
63985 frames in 5.0 seconds = 12796.983 FPS

And I can see the FPS go to the full capacity of the GPU.

Also, I'm not sure how this happened, but the size is not being set when I'm running the script again. I thought it might be due to the changed xorg.conf settings, so I went and commented out the lines I added for the virtual display, and I still get this:
x11docker note: Will try to set native resolution 1920x1080.
  If that looks ugly, use --scale=1 to enforce a fake scaled resolution.

x11docker note: Resolution 1920x1080 not found in xrandr.

x11docker note: Panning 1920x1080. If virtual screen is greater than
  maximal screen size, you can move virtual screen with mouse at screen edges.
  You can force the virtual screen to match your monitor with option --scale=1

x11docker note: Panning failed, trying to scale instead.

x11docker note: Setting desired resolution 1920x1080 failed.
  Fallback: Will use detected (normalx(normal instead.

None of those options will report the GPU. However, if I end the script, then I get glxinfo with the vanilla command, no special sudo user or privileges needed. So, I guess my issue here is I hoped I could have multiple containers running with access to the GPU and OpenGL drivers, but right now I am limited to having at most 1.

Oh, now I see the reason: Only one Xorg at a time can use the GPU. Additional Xorg sessions can only use software rendering or have to wait for the GPU to be released.
If I run multiple Xorg wih glxgears on a headfull system, i.e. with a monitor, and switch between the ttys, only the currently visible Xorg gets GPU access. On the other Xorgs glxgears is frozen until I switch back to its tty.
So with this core setup only one container can use the GPU.

Still, this is pretty great progress. Any ideas on how I can get multiple containers with GPU access going?

One possibility: Run an Xorg with --gpu --xonly and wihou a container. On this xorg session you can run multiple containers with --hostdisplay. Drawback: The containers can see and access each other over the X11 protocol, i.e. several X security leaks can be abused.
With MESA drivers we would have more secure possible setups. The closed source NVIDIA driver restricts x11docker to --hostdisplay and --xorg. With  nouveau driver we could set up isolated accelerated X servers.
Another possibility I am not familiar with: docker provides an option --gpus that works for NVIDIA only and allows some special setup to split GPU resources. That might allow multiple accelerated Xorg. Though, I am not sure if that works and how to set this up correctly.

Also, I'm not sure how this happened, but the size is not being set when I'm running the script again. I thought it might be due to the changed xorg.conf settings, so I went and commented out the lines I added for the virtual display, and I still get this:

Not sure what happened here.
Maybe you ran multiple Xorg and only one can use the one virtual display? Maybe you need to specify more then one virtual display for more than one Xorg.

I ran some tests with a remote headless server with an intel GPU.
GPU acceleration works well with the fallback framebuffer setup.
Additional experiments with intel virtual heads and also with evdi-dkms did not gather any advantage.
I wonder if NVIDIA really needs the Virtual entry in xorg.conf or if it can be omitted. If it would work with the framebuffer setup, less user setup would be needed.

I tried the iglx option and I can confirm that it works. In fact, it sped up my client's rendering on xpra, which was unexpected. I thought it might've been a fluke, so I undid the option and tried it without it to confirm it would slow down, and that was the case. What does it do? Is there any reason why the client side rendering would be different with that option?
Also, I experimented with another container image and I was able to get multiple containers spun up, each with their own xorg servers running on the GPU. I don't know if any of what's being done in there can apply here, but thought I'd link it to you: https://github.com/ehfd/docker-nvidia-glx-desktop
I will try omitting the Virtual option again and see if I can get it to work. It would be great to be able to do a remote headless server with my setup (like many people, I am unfortunately locked into the closed-source NVIDIA drivers, and as much as I hate it and as big of a headache as it gives me, I don't have the option of switching out of them with my current setup). I'm wondering if I can achieve the same setup you have with the Intel GPU but with my GPU.

Just FYI, to show the multiple Xorgs running concurrently with the container referenced above:
nvidia-smi
Mon Apr  5 14:52:36 2021
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.67       Driver Version: 460.67       CUDA Version: 11.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  Quadro P4000        Off  | 00000000:42:00.0 Off |                  N/A |
| 51%   52C    P0    30W / 105W |    362MiB /  8119MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A   1545030      G   /usr/lib/xorg/Xorg                127MiB |
|    0   N/A  N/A   1545222      G   /usr/lib/xorg/Xorg                127MiB |
|    0   N/A  N/A   2645579      G   /usr/lib/xorg/Xorg                103MiB |
+-----------------------------------------------------------------------------+

Also, the Fallback: Will use detected (normalx(normal instead. bug has gone away. I'm assuming it had to do with a misconfiguration on my part, because this disappeared after reinstalling xorg.

I tried the iglx option and I can confirm that it works.

Great!

In fact, it rendered more smoothly on the client's rendering in xpra, which was unexpected. I thought it might've been a fluke, so I undid the option and tried it without it to confirm it would render less smoothly without iglx, and that was the case.

That is surprising. I'd expect it to be rather less performant.

What does it do? Is there any reason why the client side rendering would be different with that option?

By default applications use direct rendering, i.e. they directly communicate with the GPU.
With x11docker option --iglx (in Xorg: +iglx and environment variable LIBGL_ALWAYS_INDIRECT=1)
indirect rendering is enabled. The application does not talk to the GPU but sends its GLX rendering requests to the X server that forwards them to the GPU.
This can be of interest in setups where X is not accessed directly over a unix socket but over TCP. (x11docker option --xoverip).
For x11docker this is of interest in some special use cases. For example, with --runtime=kata-runtime, where the container runs in QEMU with a virtual kernel, x11docker sets up a TCP connection for X access. Direct rendering does not work in this case.
In a nutshell:

--xoverip allows to run the X server and the X client on different machines.
--iglx allows the X client to access the GPU on the machine where the X server is running.

Also, I experimented with another container image and I was able to get multiple containers spun up, each with their own xorg servers running on the GPU. I don't know if any of what's being done in there can apply here, but thought I'd link it to you: https://github.com/ehfd/docker-nvidia-glx-desktop

That sounds interesting. I had a look and did not understand the full setup so far. From what I see:

Xorg runs within the container
Different parts of the GPU can be specified.

Just FYI, to show the multiple Xorgs running concurrently with the container referenced above:

Can you confirm that acceleration works on all of them simultaneously, not only on one of them at a time?
I could imagine that this works if each Xorg uses a different part of the GPU.

Thanks for the info about iglx. That's quite interesting. I'll do some more testing to confirm that behavior.
I'll also confirm that acceleration works on all of the Xorgs simultaneously.
I wanted to let you know that I saw this in the news today, might be interesting to test within x11docker: Xwayland: Support hardware accelerated rendering with the proprietary NVIDIA driver

I'll also confirm that acceleration works on all of the Xorgs simultaneously.

I might have to dig deeper how his is possible. Currently I don't find the mind for investigation. If you find out more about this, please tell me!

I wanted to let you know that I saw this in the news today, might be interesting to test within x11docker: Xwayland: Support hardware accelerated rendering with the proprietary NVIDIA driver

Those are good news! So this might works within this year once NVIDIA catches up. Thank you for telling me.

@mviereck FYI according to the author,
https://github.com/ehfd/docker-nvidia-glx-desktop/issues/8#issuecomment-819957414
when all containers are privileged mode AND shares the same TTY multiple Xorg instances work.

when all containers are privileged mode AND shares the same TTY multiple Xorg instances work.

That is quite interesting, thank you for the investigation!
x11docker should not need the privileged mode. The essential key is to share the same TTY.
x11docker normally avoids this, because with real monitors multiple Xorg on the same TTY do not make sense and would disturb each other.
You can specify the TTY with x11docker option --vt N with N being a number.
Try to run multiply x11docker instances with same e.g. --vt 20 and check if GPU acceleration works on all of them.
One possible issue comes to mind: If one Xorg is terminates, it might release the TTY and thus crash the other Xorg instances.

I experimented in dind without privileged but it Xorg doesn't manage to start with the error you just got.

Do you know if TTY is required for EGLStreams on Wayland compositors?

I am not sure, but I assume yes.
However, it is possible to run multiple Xwayland instances on one Wayland compositor.
Also it is  possible to run nested Wayland compositors in Xorg or in Wayland.
This would allow segregated accelerated X sessions for different containers.

Do you know if TTY is required for EGLStreams on Wayland compositors?

I am not sure, but I assume yes.
However, it is possible to run multiple Xwayland instances on one Wayland compositor.
Also it is possible to run nested Wayland compositors in Xorg or in Wayland.
This would allow segregated accelerated X sessions for different containers.

This would surely mean a more plausible solution than now.
https://github.com/ehfd/docker-nvidia-egl-desktop
We have this now but this only supports OpenGL acceleration. Vulkan doesn't run at all.
https://github.com/ehfd/docker-nvidia-glx-desktop
This is very hacky and has to be replaced with XWayland.

Your setups look interesting. Though, I cannot test them myself because I don't have NVIDIA hardware.

This would surely mean a more plausible solution than now.

With open source MESA drivers this already works well.

authors: ehfd johncadengo mviereck


text:
Use bag split as signal from recorder in rosbag tests

The rosbag tests are flaky, because it can happen that the recorder is
stopped before it has the required number of messages received. This is
because the process that contains the recorder has a second subscriber
that keeps track of the number of messages published. However, the
recorder's subscriber and that counting subscriber are not synchronized.
Even if the message counting subscriber has received some number of
messages, this doesn't mean that the recorder's subscriber has received
even a single message.
We fix the issue by replacing the message counting subscriber by one
that listens for bag split events. We also configure the recorder to
split bags once some number of bytes has been recorded. Once the bag
split event is received, we can be certain that the recorder has
received that amount of bytes.
Fixes #82.

Thank! I had briefly looked into using managed nodes and lifecycle_msgs, but it seemed quite complex, so this seems like a good way to fix the issue :sweat_smile:

@lalten Not sure how managed nodes would help here. After all, we need some signal from the recorder that it has received some number of messages. The current API doesn't seem to offer anything like that. However, I implemented something else now where I use the bag splitting event as a proxy. When the bag split happens, we know the recorder has received and written some amount of data. What's not so great about this is that the minimum size of a bag split depends on the storage plugin and the relation between a message and its size on disk is not entirely clear. I went with numbers now that seem to work well. So for the purpose of this test, I think this is good enough, plus much more reliable than just sending more slowly. @mvukov Please let me know which approach you prefer. I would go with the latter, but before merging I would want to squash and most importantly update the commit message.

I think https://github.com/mvukov/rules_ros2/pull/84/commits/ea1d6c6da29e1ba4f005220d20049df02380d9cd is just fine. It's async processing and such e2e tests can just be flaky (we can have flaky = True for those tests). I don't think we need large artifacts with the second approach. If you're really up to the second approach, then change TEST_UNDECLARED_OUTPUTS_DIR -> TEST_TMPDIR. We don't need those large artifacts uploaded to the cache. Thinking about it now again, I should've used TEST_TMPDIR from the beginning... Anyway, I don't have a very strong opinion about this.
Just for the record: I've never seen those tests to be flaky locally :).

Thanks for fixing and documenting this! :)

Thanks for fixing and documenting this! :)

Sure, and sorry for ignoring the style guide. Will try to leave less cleanup work for you next time!

authors: ahans lalten mvukov


text:
generate pid files for vmx vm's

generate uniq pid files for the VM based on macaddr1. this allows
specific vms to be killed in the off chance that there are other qemu
invocations on the host as well.

Great solution. Merge into master. Thanks!

authors: mwiget sulrich

repo: mwiget/vmxdocker


text:
How to run a saga for a container that does not use react-router ?

I am a bit stuck in plugging in a saga that was required for a container component that does NOT need react-router. It seems to me that the saga for a container that uses react-router is taken care of automatically in this react-boilerplate code, because I don't need to do anything other than run the built-in generator for a router.
I find the following code in store.js:
  store.runSaga = sagaMiddleware.run;

and I tried to run my custom saga this way, but it does not work:
store.runSaga = sagaMiddleware.run(mySaga); // note: mySaga

Could someone help me understand how to plugin a saga to the store for a container component that does not require react-router?

You were close, but changing the store.runSaga reference will break all other sagas, since they call store.runSaga to point to sagaMiddleware.run.
Can you try adding that line above the assignment? That should work!
sagaMiddleware.run(yourSaga);
store.runSaga = sagaMiddleware.run;

I came here this morning to ask the same question. Last week I've been struggling a bit with the following structure:

I have a "routed" HomePage that includes several containers
each container will independently run their own sagas (like, one container is an Alerts list that will handle the display, closing, etc., of alerts while the other container is an Items list that will also handle display, ordering, etc. of items)

I am not sure how to do that, and sure wouldn't mind a piece of doc explaining how to "plug in" the relevant saga files.
Full disclosure: I'm a React/Redux newb and am relying heavily on this most magnificent boilerplate to help me put into action the stuff I've learnt about those technos. Some technical-magical things you do in the boilerplate is a bit confusing sometimes (the automatic injection in app.js for example) and it would definitely help people like me if there was some doc explaining why the magic is done and what it is exactly that it saves me from having to do.

Yeah, I think having that doc sounds good – just need somebody to get around to actually writing it. :wink:
Since the question seems to be answered, I'll close this issue for now – feel free to continue discussing though!

Having the "nested" container have its Saga's loaded by it's parent container couples it to the parent though, no?
To take @Augustin82's example, you can't just throw in a <AlertsList /> component anywhere, unless you first go adn explicitly put a reference to it's Saga(s) in the parent container. Likewise, you've now also got to remember to remove the Alerts Sagas from the parent container if you remove the Alert component from the parent container.
Not the end of the world by any means, but definitely something that could bite you given a large enough project.

Yeah, you could also create a global saga.js file that re-exports all of them, but it's not optimal – there isn't really a better way to do it that I can think of.

I want to run a saga in the container/App level, and I landed on this question thread, which at first seemed to solve my problem. But the saga never gets invoked. I created a container/App/saga.js file and hook it up as mentioned above sagaMiddleware.run(yourSaga);. I've verified the saga gets included. But when I try to dispatch an action from App/index.js, and though the state does get changed in redux, the listening saga doesn't seem to 'hear' the dispatch. Is this the correct way to go about this? My motivation is that I want a saga that is globally triggered once, regardless of the route the user lands on.

@garajo I ran into this same issue today. And I fixed it by removing below code from the generator function in sagas.js as it suspends its execution. Hope it helps you also.
// Suspend execution until location changes
yield take(LOCATION_CHANGE);
yield cancel(watcher);

I think there's a slightly more elegant way to do global sagas, though not different in principle than some of the answers already mentioned here.  I thought I'd mention my approach in case anyone finds it helpful.
app/store.js, at the end of the import statements
// ...
import { getAsyncInjectors } from 'utils/asyncInjectors';

// Global sagas
import yourSagas from 'containers/YourContainer/sagas';
import yourOtherSagas from 'containers/YourOtherContainer/sagas';
// ...

app/store.js, right after the store.runSaga = sagaMiddleware.run; line
// Run any global sagas
const { injectSagas } = getAsyncInjectors(store);

injectSagas(yourSagas);
injectSagas(yourOtherSagas);

This allows you to define sagas as you normally would, exporting an array as the output of your sagas.js file and this automatically runs all the sagas in the array.

@bobkocisko I like your approach.
I hacked together my solution, as follows:
app/sagas.js
// Export all your sagas here so the sagaMiddleware imports them
import { getUserAuthenticated } from './containers/App/sagas';
export default [
  getUserAuthenticated,
];

app/store.js
// Import global sagas
import globalSagas from './sagas';

Then inside export default function configureStore(initialState = {}, history){
// Run Global Saga automatically
sagaMiddleware.run(...globalSagas);

// Extensions
store.runSaga = sagaMiddleware.run;// (...globalSagas);

Thanks @learntoswim.  Can sagaMiddleware.run accept multiple sagas?  I was under the impression that it could only run one at a time.

@bobkocisko Good question, I believe they can run more.
I prefer your solution much better, anyway. I was merely offering some other opinion for others.

Ok sure.  In the example you linked it is running only one saga (one generator function).  Also, when I tried to pass an array to the run() method it threw an error.

@bobkocisko I never tried!

I stumbled across this thread since was figuring out how to implement global sagas as well, now that i tried your suggestions here i am asking myself were i should put the reducer for my global saga? How did you guys do that?

Is it sufficient to just put it in the createReducer() object in the main reducers.js?

Yes!

@dstuecken, great question!  I thought of updating my comment when I ran into a saga needing a companion reducer but it turned out that my solution seemed a bit too complex for a simple response.  Basically rather than what I initially suggested, I decided to maintain consistency with routes.js by using Promise.all(...), System.import(...), injectReducer(...) and injectSagas(...) to load both the sagas and their reducers.  Actually to be honest I haven't needed to load more than one saga/reducer pair yet but I wanted a solution that would support more saga/reducer pairs in the future.
However while I was happy with this approach (and still use it now), it caused additional complexity in two ways:

configureStore(...) could no longer be synchronous since the main App component relied on the presence of the global reducer.  When configureStore(...) was synchronous and the global reducer was loaded asynchronously, it caused an error because the reducer was not loaded yet when the App component needed it.  To fix this, I decided to change configureStore(...) such that it returns a Promise which is only resolved when the saga/reducer pair is fully downloaded and injected.  But then of course the configureStore(...) callee in app.js had to be changed downstream and the configureStore(...) tests had to be adjusted as well to properly deal with this change.

I also found that the hot module reloading section of configureStore(...) was failing about 50% of the time and throwing a fatal error at runtime.  Which was not acceptable of course.  So I decided to introduce a Promise chain inside of configureStore(...) which would make sure that the hot reloading section completes, and also the loading of the global sagas and reducers completes, before configureStore(...) returns.  This change restored the robustness of the app.

As a side note, my personal opinion is that configureStore(...) should return a Promise anyway because of the hot module reloading code inside of it.  It seems that as it currently is written in the base code, it is a race condition already.  If you get any surprising situations where the app completely fails to load a throws a fatal error about HMR, be suspicious of this chunk of code.
As you can see, my code changes were substantial enough to be difficult to merge into the previous comment.  I'm not sure how universal or correct my approach is, but it is working great for now.
I would say that your best bet with this is to (unfortunately) dive into configureStore(...) and its surroundings in app.js, understand it deeply and then decide how exactly you want to diverge from the base for your needs.  Good luck and Godspeed!

It seems that as it currently is written in the base code, it is a race condition already. If you get any surprising situations where the app completely fails to load a throws a fatal error about HMR, be suspicious of this chunk of code.

Could you elaborate on this? What would you do differently? We should really really fix this if there's a that grave bug in there.

I tried your suggestions but somehow my saga is not executing after dispatching the action.
It is like my registered saga is overwritten somewhere since i see that the take() function is called but it is not responding to my action dispatch. Do you think it may has something to do with the HMR?

@dstuecken, I reviewed my code this morning to see if I forgot anything.  I see that configureStore(...) doesn't actually load the saga/reducer pair but rather app.js does that in a then(...) clause after calling configureStore(...).  Also, I see that in the Promise chain inside of configureStore(...), the last then(...) clause (after the HMR section) is this:
  .then((store) => {
    // Initialize it with no other reducers or sagas
    store.asyncReducers = {}; // eslint-disable-line no-param-reassign
    store.asyncSagas = {}; // eslint-disable-line no-param-reassign
    return store;
  });

Finally, I should mention that I am working off an older version of react-boilerplate.  I cloned from https://github.com/mxstbr/react-boilerplate/commit/7c5d57ba277a286744b31ee0ae8be31c85c44d50.  I see that there have been changes since then to app.js including some global saga/reducer stuff so I can't guarantee that my suggestions are still completely valid.

Hmm i don't have any Promise chains inside my configureStore() at all. Could you give me a full example of your global saga initialization in app.js?

Newbie to this project, but I'll share my "freshie" POV. It surprised me that the default pattern expressed in generators is 1:1 mapping of containers to route. Where as my default approach is to compose route markup from multiple containers e.g. / would be:
<div>
    <AddUserForm />
    <UserList filter={e=>e.type == 'admin' || e=>e.type == 'user' }/>
</div>

And then I would reuse <UserList filter={fn} /> throughout the site.
So my instinct would be to never use the injecting in app/routes.js provided by the generator. I would always use the method expressed above. And I'd modify the generators accordingly.
Question: Does that set off alarm bells for anyone here? Or is this a completely valid approach?

I've had some trouble while implementing @bobkocisko solution and @learntoswim solution mainly because:

injectSagasis now expecting an Array
the store was not valid right after store.runSaga = sagaMiddleware.run; => asyncInjectors: Expected a valid redux store)
sagaMiddleware.run(...globalSagas); wouldn't accept more than one saga.

What I finally ended up to have multiple global sagas was to create a *sagas.js on the app folder:
import { getAsyncInjectors } from './utils/asyncInjectors';

import { loginSaga } from './containers/Login/sagas';
import { categorySelectorSaga } from './containers/CategorySelector/sagas';

export function injectGlobalSagas(store) {
  const { injectSagas } = getAsyncInjectors(store);

  injectSagas([
    loginSaga,
    categorySelectorSaga
  ]);
};

And call the injectGlobalSagas right before creating the routes on app.js:
import createRoutes from './routes';

import { injectGlobalSagas } from './sagas';
injectGlobalSagas(store);

const rootRoute = {
  component: App,
  childRoutes: createRoutes(store),
};

hello, i'm trying to inject my global saga in store.js like @learntoswim way in [comment =] (https://github.com/react-boilerplate/react-boilerplate/issues/537#issuecomment-235068751)
so the idea is, i'm trying to dispatch an action that will trigger my global saga onEnter hook in react router. but i dont know why it only run once in initial state of the apps.
so this is my routes.js
route.onEnter = function onEnter(nextState, replace, callback) {
      store.dispatch(doSomething());
      if (importSaga !== false) {
        if (this.loadedSagas) {
          callback();
        }
        const importModules = importSaga.call();
        importModules.then((sagas2) => {
          this.loadedSagas = injectSagas(sagas2.default);
          callback();
        });
        importModules.catch(errorLoading);
    };
}

so why does my global saga only run once if i try to move to another route?
ty for your attention :D

authors: AshCoolman Augustin82 bobkocisko dcarneiro dstuecken garajo learntoswim mxstbr rcholic rezadhah tayyabshabab timothyallan

repo: mxstbr/react-boilerplate


text:
Mention Babel in the README

You mention PostCSS, but not Babel. I think these days babel is to JS what postcss is to CSS so you should add minimal doc for Babel :)

:+1: its so normal to me that I totally forgot. PR anybody?

authors: MoOx mxstbr


text:
fix: fixed for the issue (#16)

1. Description

1.1. Checklist

[x] The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
[x] I have read the Contributor Guide and followed the process outlined for submitting PRs.
[x] I have updated/added tests for ALL new/updated/fixed functionality.
[x] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[x] I have updated/added relevant examples in examples.

1.2. Breaking Change

[ ] Yes, this is a breaking change.
[x] No, this is not a breaking change.

1.3. Related Issues

bors merge

Codecov Report

Merging #17 (1c59051) into main (1252fdf) will increase coverage by 6.65%.
The diff coverage is 42.10%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main      #17      +/-   ##
==========================================
+ Coverage   50.19%   56.84%   +6.65%
==========================================
  Files          57       49       -8
  Lines         520      336     -184
==========================================
- Hits          261      191      -70
+ Misses        259      145     -114

Impacted Files
Coverage Δ

packages/bluesky/lib/src/bluesky.dart
0.00% <0.00%> (ø)

...bluesky/lib/src/service/actors/actors_service.dart
0.00% <ø> (ø)

...kages/bluesky/lib/src/service/bluesky_service.dart
0.00% <ø> (ø)

...y/lib/src/service/exception/bluesky_exception.dart
0.00% <ø> (ø)

...s/bluesky/lib/src/service/feeds/feeds_service.dart
53.84% <ø> (ø)

...c/service/notifications/notifications_service.dart
100.00% <ø> (ø)

packages/bluesky/lib/src/service/base_service.dart
44.23% <44.44%> (+6.52%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

authors: codecov-commenter myConsciousness


text:
🛑 Website Load Balancers is down

In ce7dae5, Website Load Balancers ($WEB_SERVER) was down:

HTTP code: 522
Response time: 15237 ms

Resolved: Website Load Balancers is back up in d89f765.

repo: myavsuper/upptime


text:
Feature request - remove datapoints from sensor data

When outliers or mistakes in sensors/sketch cause reading with gross errors it would be nice to have an option to delete them as a time interval instead of having to remove all data from the specific sensor.

https://github.com/mycontroller-org/mycontroller/commit/3c74888dee76b55c36b5f36d01377696bbddde92

authors: BSRasmussen jkandasa

repo: mycontroller-org/mycontroller


text:
Use uptime_lib for retrieving uptime

This supercedes #16 as it is a better choice to use uptime_lib instead of doing the same logic inside of systemstat.
Closes #15

No! It's not better! :P I said in #15, I'll take #16 instead. (Also, please don't auto-format code in PRs.)

Sorry, I'm still pretty new to Rust and don't understand what is doing the autoformatting in order to be able to disable it.

Wait, you made a commit called "Ran cargo fmt automatically". Did you not run cargo fmt? Did some IDE/tool run it for you?

Yes. It either ran when I ran cargo or when I was editing in vim. I
don't remember setting it up to do it automatically...

authors: colindean myfreeweb

repo: myfreeweb/systemstat

license: unlicense


text:
How to run RTE in japanese

問題点
明らかに含意しているのにrte_ja.shの出力がunknownとなってしまいます。
Coqについて勉強不足で、何が問題なのか分かりませんでした。
環境

python: 3.7.9
coq: 8.11.2
ccg2lambda: master branch (442a9ec9be7393d92c77a03856aa4a9c71c20078)
OS: WSL Ubuntu20.04

やったこと

Readmeに書いてあるセットアップをしました。
日本語のRTEを行うために、emnlp2016exp.shを参考にして以下のセットアップを行いました。cp ja/coqlib_ja.v coqlib.v
coqc coqlib.v
cp ja/tactics_coq_ja.txt tactics_coq.txt

sentence.txtに同じ文を入れました。（明らかに含意しているので）ソクラテスは人間である。
ソクラテスは人間である。

以下のスクリプトを実行しました。 ./ja/rte_ja.sh out/sentence.txt ja/semantic_templates_ja_event.yaml

Outputunknown

調べたこと

手動でCoqを動かすとnltac_set; nltac_final.のところでNo such goal.と出て止まりました。Require Export coqlib.
Parameter _ソクラテス : Entity.
Parameter _人間 : Entity -> Prop.
Theorem t1: (and True (exists x, (and (_人間 x) (exists e, (and (and ((Nom e) = x) True) ((Nom e) = _ソクラテス)))))) -> (and True (exists x, (and (_人間 x) (exists e, (and (and ((Nom e) = x) True) ((Nom e) = _ソクラテス)))))). Set Firstorder Depth 1. nltac. nltac_set; nltac_final. Set Firstorder Depth 3. nltac_final. Qed.

証明の部分をSet Firstorder Depth 1. nltac. Qed.に変えると取り敢えず正しく動くように見えます。
証明できたかどうかを判定しているのは以下の部分だと思うのですが、is defined があるかどうかを判別する理屈がよく分かりませんでした。
https://github.com/mynlp/ccg2lambda/blob/442a9ec9be7393d92c77a03856aa4a9c71c20078/scripts/theorem.py#L337-L343
これらから、私が何かCoq周りの初歩的な設定を間違えてしまっていると思うのですが、分かりませんでした。

I downgraded Coq from 8.11 to 8.3 and it worked fine.


text:
documentation on docs.rs is down

https://docs.rs/crate/bitvec/0.15.2/builds/185691

I know; I have absolutely no idea what to do about it. The docs build as part of my CI process and should build locally. I've spoken to the docs.rs team and hope to have some progress on being able to build, or tell if they'll build, when I release 0.16.

I'm personal friends with the docs.rs maintainer, so I asked her to rebuild it and she did.

authors: Escapingbug myrrlyn

repo: myrrlyn/bitvec


text:
读中文的年份的时候有错误

比如‘2018年’
生成的语音会念成er qian ling yi shi ba nian，应该是‘liang qian ling yi ba nian’ 或 ‘er ling yi ba nian’
这个要如何修正，重新用语料训练吗？

Yes, there are many issues with how years are pronounced, and the percent symbol (%) is not pronounced at all for both Chinese and English. Also, many capitalized abbreviations are not correctly pronounced, such as HBO, CCTV, XBOX, and HIV.
···
from melo.api import TTS
device = 'auto'
speed = 1.0
text = '说中文, ni3 hao3吗, BBC广播, CNN新闻, 美国HBO, NBC转播, CCTV一套, HIV病毒, 100%不合格, 列宁格勒，希特勒，P2P软件, Sony的PSP, 微软的XBOX游戏机, 2018年初，1931年, 轰炸地堡，数了数几只羊'
model_tts = TTS(language=‘ZH’, device=device)
speaker_ids = model_tts.hps.data.spk2id
model_tts.tts_to_file(translated_output_text, speaker_ids['ZH'], 1.wav, speed=speed)
···
![Demo Audio]

你的中文预训练模型在哪里下载的？

model_tts.tts_to_file(translated_output_text, speaker_ids['ZH'], 1.wav, speed=speed)
speaker_ids['ZH'] raise error AttributeError: 'HParams' object has no attribute 'ZH'
what have I missed?

中文开源生态真的道阻且长，按理说，这种开放语料就应该通过众包的方式解决，英文的开放语料库多多了

authors: MissingTwins Simon-chai gurudk jonahzheng liuxiong21

repo: myshell-ai/MeloTTS


text:
before_filter is deprecated

Required by https://github.com/mysociety/alaveteli/issues/3969
$ BUNDLE_GEMFILE="Gemfile.rails5" bundle exec rspec spec/models/
DEPRECATION WARNING: before_filter is deprecated and will be removed in Rails 5.1. Use before_action instead. (called from <class:Base> at /home/vagrant/alaveteli/lib/themes/alavetelitheme/lib/alavetelitheme.rb:12)

Ah fixed in https://github.com/mysociety/alavetelitheme/commit/5417b988e276588883fbb416614a91f1b191f6ce – needed to update locally

hi
i'm facing an issue installing alaveteli
the rails-post-deploy script fails when installing theme
it says it should use before_action instead of before_filter
but when i try to modify the theme it says I have uncommited changes
is there a way to bypass this?
I tried a lot of themes, most of them face the same issue. I even stated false to the branch it has to use so that it uses master or whatever HEAD is at.
Help I can't finish installing Alaveteli.
Thx in adv.
cheers

authors: garethrees juanmartin

repo: mysociety/alavetelitheme


text:
Support Paramiko

This should allow mysocketctl to work on systems where ssh is not available or doesn't behave as expected (I'm looking at you Windows.)
On Windows, there are a bunch of issues right now.  It works in some cert specific scenarios. First you have to install the Visual  The two that appear to work today are:

Install the Microsoft Visual C++ Build Tools this appear to be required by bcrypt which is a deep dependancy for mysocketctl
Install mysocketctl via pip
There are two working setups:

Enable OpenSSH, use the ssh-agent, load your key into the ssh agent using ssh-add, use --engine system
Use --engine paramiko with an unencrypted ssh key in your ~/.ssh/ directory.

There are still oddities, sometimes CTRL+C doesn't work.  You may end up needing to kill python/ssh from Task Manager.  Don't use Windows unless you really know what you are doing (I don't 😛 )

Thanks, tested. Lgtm!
big win

authors: atoonk tresni

repo: mysocketio/mysocketctl


text:
login issues yet again...

login issues yet again...wtf are you guys doing?! There's not even an update! That and the tags no longer display in the frontmatter and haven't since the last episode of these issues!

Please understand that the sync plugin is a different piece of code from the voicenotes.com webapp. If there is something new happening with login, it may take folks who can copy and paste developer tools errors in the logs to help us see why this may be happening.

authors: Jwminva kinabalu

repo: mysticcoders/voicenotes-sync


text:
Ability to mocking/stub/fake responses?

This has been asked before, and was originally planned to be included in v0.6.0, but never made it.
@aeirola posted a workaround to enable mocking a response, but it's a bit hacky.  It would be great if there was an easy, officially-supported way to do mocking in Axios.

Axios supports custom adapters since 0.9.0, which can be used for testing. See commit https://github.com/mzabriskie/axios/commit/b9bb6ae7aacc7ec6053ae0551be7a403a33a5b18.

I made this to enable easy mocking of requests made through axios, I thought it could be useful for others: https://www.npmjs.com/package/axios-mock-adapter

Thank you all! I am going to create a document that contains a list of axios related libraries and include axios-mock-adapter in that list.

authors: BigstickCarpet aeirola ctimmerm nickuraltsev

repo: mzabriskie/axios


text:
p2p: reliable hole punching

we have dcutr (https://github.com/libp2p/specs/blob/master/relay/DCUtR.md) as a behavior in libp2p, let's do the work to wire it up properly

:rocket: Ping me on any pull request in case you want additional eyes.

authors: mxinden ramfox


text:
chore: move some CI steps to our runners

cross builds
windows
nix builds

FYI tests intentionally left alone in this PR (but verified to work with some of the fix branches)

cli tests on linux were passing consistently, that seems to be a regression.

cli tests on linux were passing consistently, that seems to be a regression.

There are fixes from @rklaehn's work to make it all pass. It worked because the old runners were slow enough to mostly pass without issues.

authors: Arqu dignifiedquire


text:
has the project been abandoned? because there have been no updates :(

has the project been abandoned? because there have been no updates :(

Of course it has been, use chaiNNer.

Yes, this project is abandoned


text:
[HTWOO:Core] - Quicklinks - Tiles

Added in Version 2.2.0


text:
Problem with Update function

my routes:
use \Modules\Customer\Http\Controllers\CustomerController;
Route::put('customer-update/{id}', [CustomerController::class, 'update'])->name('customer-update');
Route::resource('customer',CustomerController::class);
My View:
<form  action="{{ route('customer.update', $customer->id) }}" method="POST" id="account-edit" name="account-edit">
            @csrf
            @method('PUT')
....
</form>

Target class [Modules\Customer\Http\Controllers\Modules\Customer\Http\Controllers\CustomerController] does not exist.
i have this problem with all my updates functions, it work without modules

previously I have already made an example #1245

You have made the nnamespace double, so either remove it from your routes file, or the RoutesServiceProvider.

authors: KatiaSishost nWidart wikigods

repo: nWidart/laravel-modules