text:
I have a problem with the navbar and drawer

if you try running this code there is an error I opened an issue but the owner close it  please give me an expamle please how to link properly please
import React from 'react';
import PropTypes from 'prop-types';
import { withStyles } from 'material-ui/styles';
import classNames from 'classnames';
import Drawer from 'material-ui/Drawer';
import AppBar from 'material-ui/AppBar';
import Toolbar from 'material-ui/Toolbar';
import List from 'material-ui/List';
import { MenuItem } from 'material-ui/Menu';
import Typography from 'material-ui/Typography';
import TextField from 'material-ui/TextField';
import Divider from 'material-ui/Divider';
import IconButton from 'material-ui/IconButton';
import MenuIcon from '@material-ui/icons/Menu';
import ChevronLeftIcon from '@material-ui/icons/ChevronLeft';
import ChevronRightIcon from '@material-ui/icons/ChevronRight';
import { mailFolderListItems, otherMailFolderListItems } from ;

const drawerWidth = 240;

const styles = theme => ({
  root: {
    flexGrow: 1,
  },
  appFrame: {
    height: 430,
    zIndex: 1,
    overflow: 'hidden',
    position: 'relative',
    display: 'flex',
    width: '100%',
  },
  appBar: {
    position: 'absolute',
    transition: theme.transitions.create(['margin', 'width'], {
      easing: theme.transitions.easing.sharp,
      duration: theme.transitions.duration.leavingScreen,
    }),
  },
  appBarShift: {
    width: `calc(100% - ${drawerWidth}px)`,
    transition: theme.transitions.create(['margin', 'width'], {
      easing: theme.transitions.easing.easeOut,
      duration: theme.transitions.duration.enteringScreen,
    }),
  },
  'appBarShift-left': {
    marginLeft: drawerWidth,
  },
  'appBarShift-right': {
    marginRight: drawerWidth,
  },
  menuButton: {
    marginLeft: 12,
    marginRight: 20,
  },
  hide: {
    display: 'none',
  },
  drawerPaper: {
    position: 'relative',
    width: drawerWidth,
  },
  drawerHeader: {
    display: 'flex',
    alignItems: 'center',
    justifyContent: 'flex-end',
    padding: '0 8px',
    ...theme.mixins.toolbar,
  },
  content: {
    flexGrow: 1,
    backgroundColor: theme.palette.background.default,
    padding: theme.spacing.unit * 3,
    transition: theme.transitions.create('margin', {
      easing: theme.transitions.easing.sharp,
      duration: theme.transitions.duration.leavingScreen,
    }),
  },
  'content-left': {
    marginLeft: -drawerWidth,
  },
  'content-right': {
    marginRight: -drawerWidth,
  },
  contentShift: {
    transition: theme.transitions.create('margin', {
      easing: theme.transitions.easing.easeOut,
      duration: theme.transitions.duration.enteringScreen,
    }),
  },
  'contentShift-left': {
    marginLeft: 0,
  },
  'contentShift-right': {
    marginRight: 0,
  },
});

class PersistentDrawer extends React.Component {
  state = {
    open: false,
    anchor: 'left',
  };

  handleDrawerOpen = () => {
    this.setState({ open: true });
  };

  handleDrawerClose = () => {
    this.setState({ open: false });
  };

  handleChangeAnchor = event => {
    this.setState({
      anchor: event.target.value,
    });
  };

  render() {
    const { classes, theme } = this.props;
    const { anchor, open } = this.state;

    const drawer = (
      <Drawer
        variant="persistent"
        anchor={anchor}
        open={open}
        classes={{
          paper: classes.drawerPaper,
        }}
      >

          <IconButton onClick={this.handleDrawerClose}>
            {theme.direction === 'rtl' ? <ChevronRightIcon /> : <ChevronLeftIcon />}
          </IconButton>

        <Divider />
        <List>{mailFolderListItems}</List>
        <Divider />
        <List>{otherMailFolderListItems}</List>
      </Drawer>
    );

    let before = null;
    let after = null;

    if (anchor === 'left') {
      before = drawer;
    } else {
      after = drawer;
    }

    return (

        <TextField
          id="persistent-anchor"
          select
          label="Anchor"
          value={anchor}
          onChange={this.handleChangeAnchor}
          margin="normal"
        >
          <MenuItem value="left">left</MenuItem>
          <MenuItem value="right">right</MenuItem>
        </TextField>

          <AppBar
            className={classNames(classes.appBar, {
              [classes.appBarShift]: open,
              [classes[`appBarShift-${anchor}`]]: open,
            })}
          >
            <Toolbar disableGutters={!open}>
              <IconButton
                color="inherit"
                aria-label="open drawer"
                onClick={this.handleDrawerOpen}
                className={classNames(classes.menuButton, open && classes.hide)}
              >
                <MenuIcon />
              </IconButton>
              <Typography variant="title" color="inherit" noWrap>
                Persistent drawer
              </Typography>
            </Toolbar>
          </AppBar>
          {before}
          <main
            className={classNames(classes.content, classes[`content-${anchor}`], {
              [classes.contentShift]: open,
              [classes[`contentShift-${anchor}`]]: open,
            })}
          >

            <Typography>{'You think water moves fast? You should see ice.'}</Typography>

          {after}

    );
  }
}

PersistentDrawer.propTypes = {
  classes: PropTypes.object.isRequired,
  theme: PropTypes.object.isRequired,
};

export default withStyles(styles, { withTheme: true })(PersistentDrawer);

[ ] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Current Behavior

Steps to Reproduce (for bugs)

Context

Your Environment

Tech
Version

Material-UI
1.0.0-beta.43

React
16.3.2

browser

etc

@rosselpha Your issue was closed for a reason. Please be more specific and do not expect someone could help you without any context from you. This issue should be closed.

what do you mean try running the code there is a problem with the icon folder in the last import i cant find the proper folder to point to

Also a duplicate of #11112

repo: mui-org/material-ui


text:
SSR-rendered styles are overridden by incorrect styles with JS using gatsby ssr example

[x] This is not a v0.x issue.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior
CSS renders the same both in SSR and JS modes.
Current Behavior
CSS renders correctly with JS being blocked but is overridden by incorrect one once JS loads.
Steps to Reproduce
No explicit steps to repro yet as I'm trying to make a minimal reproducible example.
The problem appears one I hook up the withRoot from the gatsby example. It fixes the SSR rendering, e.g. given the following (taken from material-ui-kit):
# assets/jss/material-kit-react.jsx
const title = {
  color: "#3C4858",
  margin: "1.75rem 0 0.875rem",
  textDecoration: "none",
  fontWeight: "700",
  fontFamily: `"Roboto Slab", "Times New Roman", serif`
};

# assets/jss/material-kit-react/views/landingPage.jsx
import { container, title } from "assets/jss/material-kit-react.jsx";

const landingPageStyle = {
  ...
  title: {
    ...title,
    display: "inline-block",
    position: "relative",
    marginTop: "30px",
    minHeight: "32px",
    color: "#FFFFFF",
    textDecoration: "none"
  }
  ...

# HeaderLayout.js
import indexPageStyle from 'assets/jss/material-kit-react/views/landingPage.jsx';
...

{title}

...
export default withRoot(withStyles(indexPageStyle)(HeaderLayout));

The title style in the SSR page would resolve to the following:
.jss2 {
  color: #FFFFFF;
  margin: 1.75rem 0 0.875rem;
  display: inline-block;
  position: relative;
  margin-top: 30px;
  min-height: 32px;
  font-weight: 700;
  font-family: "Roboto Slab", "Times New Roman", serif;
  text-decoration: none;
}

which looks like an exact representation of the original style. However the JS-injected style is incorrect:
.jss2 {
  color: #3C4858;
  margin: 1.75rem 0 0.875rem;
  margin-top: 30px;
  min-height: 32px;
  font-weight: 700;
  font-family: "Roboto Slab", "Times New Roman", serif;
  margin-bottom: 1rem;
  text-decoration: none;
}

notice how it has the color from the material-kit-react.jsx, while still including other fields, e.g. margin-top.
To make sure this isn't an off-by-one I've added borderRadius: 515 to the landingPage.jsx style and borderRadius: 909 to its parent in material-kit-react.jsx (just random numbers). As I expected, the rendered JSS page has the 515 version and the JS one has 909.
I've started tracing this bug in https://github.com/cssinjs/react-jss/issues/306 but now I'm not sure it belongs there. More so, I have no idea where to start working on a minimal reproducible version of this as it goes against my knowledge of JS. Any hints?

Tech
Version

Material-UI
v3.3.1

React
v16.6.0

... and then I carefully checked everything and found a place where a non-withRoot-decorated page was leaking.

@farcaller I'm happy you figured out the solution.

source: gharchive/issue

authors: farcaller oliviertassinari

license: MIT

license_type: permissive

license_source: github-api


text:
[docs] Optimize images

Beep boop. Your images are optimized!
Your image file size has been reduced by 13% 🎉

Details

File
Before
After
Percent reduction

/docs/static/blog/august-2019-update/material-icons.png
29.67kb
15.29kb
48.46%

/docs/static/blog/july-2019-update/skeleton.png
11.97kb
8.52kb
28.82%

/docs/static/blog/august-2019-update/typescript.png
40.58kb
38.06kb
6.21%

/docs/static/themes/onepirate/productValues1.svg
0.85kb
0.84kb
0.92%

/docs/static/images/users/uniqlo.svg
1.15kb
1.14kb
0.68%

/docs/static/themes/onepirate/producBuoy.svg
1.81kb
1.80kb
0.43%

/docs/static/themes/onepirate/productValues3.svg
3.32kb
3.31kb
0.41%

/docs/static/themes/onepirate/productHowItWorks3.svg
1.20kb
1.20kb
0.41%

/docs/static/themes/onepirate/productHowItWorks2.svg
2.09kb
2.08kb
0.37%

/docs/static/images/users/shutterstock.svg
3.84kb
3.83kb
0.28%

/docs/static/images/users/nasa.svg
6.62kb
6.60kb
0.25%

/docs/static/themes/onepirate/productHowItWorks1.svg
2.32kb
2.32kb
0.21%

/packages/material-ui-icons/fixtures/game-icons/svg/icons/delapouite/dice/svg/000000/transparent/dice-six-faces-four.svg
0.48kb
0.48kb
0.20%

/packages/material-ui-icons/fixtures/game-icons/svg/icons/john-colburn/originals/svg/000000/transparent/pistol-gun.svg
0.49kb
0.49kb
0.20%

/docs/static/themes/onepirate/productValues2.svg
3.97kb
3.96kb
0.20%

/packages/material-ui-icons/fixtures/game-icons/svg/icons/delapouite/dice/svg/000000/transparent/dice-six-faces-five.svg
0.53kb
0.53kb
0.18%

/docs/static/images/users/capgemini.svg
4.46kb
4.45kb
0.18%

/docs/static/images/users/bethesda.svg
3.18kb
3.18kb
0.15%

/docs/static/images/users/walmart-labs.svg
4.06kb
4.06kb
0.12%

/docs/static/images/grid/complex.jpg
12.18kb
12.16kb
0.10%

/docs/static/images/users/jpmorgan.svg
5.28kb
5.28kb
0.09%

/packages/material-ui-icons/fixtures/game-icons/svg/icons/lorc/originals/svg/000000/transparent/acorn.svg
1.36kb
1.36kb
0.07%

/packages/material-ui-icons/fixtures/game-icons/svg/icons/lorc/originals/svg/000000/transparent/alien-skull.svg
1.43kb
1.43kb
0.07%

/packages/material-ui-icons/fixtures/game-icons/svg/icons/lorc/originals/svg/000000/transparent/ace.svg
1.90kb
1.90kb
0.05%

/packages/material-ui-icons/fixtures/game-icons/svg/icons/lorc/originals/svg/000000/transparent/acid-blob.svg
2.37kb
2.37kb
0.04%

/packages/material-ui-icons/fixtures/game-icons/svg/icons/delapouite/dice/svg/000000/transparent/perspective-dice-six-faces-six.svg
2.55kb
2.55kb
0.04%

/packages/material-ui-icons/fixtures/game-icons/svg/icons/delapouite/dice/svg/000000/transparent/perspective-dice-six-faces-random.svg
2.84kb
2.84kb
0.03%

Total :
152.49kb
132.01kb
13.43%

📝docs | :octocat: repo | 🙋issues | 🏅swag | 🏪marketplace

If you want, you can install https://imgbot.net in this repo (or in the full organization).
It will automatically send PRs for image optimization 🙂

@oliviertassinari Maybe also add an .imgbotconfig file so the fixtures won't be optimized again? 🤔
https://imgbot.net/docs/#ignoring-files

@MichaelDeBoey Thanks for the pull request. Regarding the bot, we don't use a lot of images. I think that it's fine to compress them as they are added. I think that we should only consider investing time into the problem if we realized the our current solution doesn't match the problem. An imagine compression run once a year, seems to be enough, so far. It might change in the future.

source: gharchive/pull-request

authors: MichaelDeBoey oliviertassinari


text:
[docs] Fix DataTable.tsx demo in v4

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

Fix https://github.com/mui-org/material-ui-x/issues/2039
Preview: https://deploy-preview-27196--material-ui.netlify.app/components/tables/#data-table

Blocked by https://github.com/mui-org/material-ui-x/pull/2116 and https://github.com/mui-org/material-ui-x/pull/2108.

@oliviertassinari Do we accept fixes for the v4 docs now?

@eps1lon This is for the @material-ui/data-grid package that is developed with v4, not v5 yet.

It's not mean to fix the docs of the core.

It's opened in mui-org/material-ui targetted at master. Not sure how you mean that.

@eps1lon I meant that this PR fixes the docs of the data grid, not the docs of the core packages.

This definitely goes against existing policy. We want to avoid diverging master and next. That is the prime motivation.

Ok, a different interesting motivation. From a divergence, do you mean the change of Node.js version? Or I guess more about any changes that we might do. What would be the negative implications of a divergence?
Regarding why we might want to merge this. The demonstrated code is not working: copy and paste the source, install the latest version: 💥. In the X packages, we have optimized for the adoption of the data grid, so we picked core v4 rather than v5. In the core packages, we have optimized for the adoption of v5.
I would +1 for making an exception on this.

I actually wonder about the timing. In 2 months or so, this demo will no longer be on the TLD but on v4.material-ui.com, along with all its demo of the data grid. We will no longer have documentation of the data grid on the main domain. cc @mui-org/x We will have to migrate all the docs environments to core v5. Maybe we should work on it two weeks before the stable release date. I have added a new items in https://github.com/mui-org/material-ui-x/issues/1902.

@m4theushw I'm going to revert 2186dce. It's because we don't skip the node_modules that we could find: https://github.com/mui-org/material-ui-x/pull/1913/files#r667394689.

authors: Siv-tspab eps1lon oliviertassinari


text:
[slider] Remove data-orientation="horizontal" duplication

Summary
Open https://master--base-ui.netlify.app/components/react-slider/ see data-orientation="horizontal" 4 times in the DOM notes

I'm confused, why is this not only once on the root DOM node and people use parent CSS selectors to write the CSS?
Search keywords: -

Why would you want to have to use :has() or descendant selectors?
It's generally a bad idea to have your styles rely on DOM structure. It will of course be fine in this specific example, but it's a bad practice. :has() and descendant selectors are less ergonomic and add noise. Especially with CSS-in-JS, syntax can get a little gnarly. It's standard practice in the space to provide style hooks per component.

Why would you want to have to use :has() or descendant selectors?

@colmtuite I would imagine that we have one data-orientation="horizontal" attribute on the root. In this configuration, developers would write logic like:
.Slider {
  color: red;

  &[data-orientation="vertical"] {
    color: blue;
  }
}

[data-orientation="vertical"] .Slider-thumb {
  background-color: green;
}

I don't see how :has() applies here.

I mentioned :has() because you mentioned parent CSS selectors, and :has() is the closest thing we have to a parent selector. I mentioned descendant selectors in my reply too.

we could have one data-orientation="horizontal" attribute on the root.
But I'm wondering why we would limit devs to this, and force them to use awkward selectors and rely on DOM structure?

.SliderThumb[data-orientation="vertical"] {} is simpler and safer.

@colmtuite My bad, I fixed that issue description, from the perspective of the node that gets customized, :has() seems like a child selector and .a. .b seems like a parent selector, but it's not the official terminology, that was created purely based on the look of the CSS selector 🙃.

But I'm wondering why we would limit devs to this, and force them to use awkward selectors and rely on DOM structure? .SliderThumb[data-orientation="vertical"] {} is simpler and safer.

Today, the duplication on this component seems OK. I think that value could come in the future if we add a LOT of data attributes to the DOM, and that duplication would start to feel heavy on the HTML output and chrome devtools.
I have changed this issue description to be broader in scope. It will be interesting to see how developers approach this.

I don't anticipate a lot of attrs in the future. In fact I don't see a need for any additional attrs.
The idea is to be hands-off when it comes to styling. We don't want to say "you can't style this directly, you need to use descendant selectors". We want people to be able to style elements however they want. We want to enable devs, not restrict them.
There is also the TW experience to consider.

authors: colmtuite oliviertassinari

repo: mui/base-ui


text:
[Select] Menu item in Select Component floating top about 1 px

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
Don't float , it should be smooth for good user experience
Expected behavior 🤔
When menu item rendering or clicking select component for selecting item , menu items are floating top about 1px
https://mui.com/components/selects/#basic-select
if it doesn't, you should try another select expected native select
Steps to reproduce 🕹
Steps:
1.Click any select
2.
3.
4.
Context 🔦
No response
Your environment 🌎

`npx @mui/envinfo`
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Hey @atillaaliyev, thanks for opening this issue! Could you be more specific about what's the issue you're seeing there? Is it the fact that there's no spacing between the Menu Item and the Select, as highlighted by the green line in this screenshot?

https://user-images.githubusercontent.com/6121871/148705465-258e97d4-e6a5-4196-b41e-aab0c19b7561.mp4
https://user-images.githubusercontent.com/6121871/148705643-27b9eff9-1d41-4ff1-85bb-eec50f282a0a.mp4
Hi @danilo-leal ,
You should focus to menu items, you will see rendering problem.

Yes, it is.

By accessing the documentation on my machine, I'm not being able to reproduce. But, accessing the Codesandbox for the first Select demo (https://codesandbox.io/s/m60rm?file=/demo.js) I can see the flickering indeed. @mui-org/core any ideas?

I cannot reproduce it on my machine (documentation and codesandbox). Are you sure that you are on 100% view because if I zoom out a little bit I can see the flicker?

@siriwatknp is correct. The flicker is happening if you are not on 100% view.

@siriwatknp you are right, Actually, my view is 100% on browser, but windows display setting is %125, I suppose it is. Is it bug, I'm not sure. If you think it's not bug, you can close this issue. Thank you.

Hi guys,
Sorry to revive the thread, but how is this not a bug? 😁
It just got reported by our QA team at the company I work at, with Windows OS display settings set to 125% scale, on 1920x1080 resolution screen.
Any chance to reconsider some possible fix?

@stoberov Please provide a reproduction (exact browser version, Material UI version, etc.). It might be browser-related.

@oliviertassinari - sorry for late reply. It's tricky providing an exact reproduction via our QA setup, as I myself cannot reproduce it.
However, I am able to reproduce 2 very similar, hopefully related, scenarios. Providing details below.
Browser = Microsoft Edge, Version 119.0.2151.97 (Official build) (64-bit)
OS = Ubuntu 22.04.3 LTS
Display = for what it's worth, at the time of writing my monitor is set to 3840x2160 resolution and 175% scale
Scenario 1:

I'm using the Sandbox from an earlier comment above - https://codesandbox.io/p/sandbox/basicselect-material-demo-m60rm?file=%2Fdemo.js%3A28%2C49 - all library versions are specified in the package.json
You have to look really carefully - upon opening the dropdown, the highlighted item moves ~1px
Browser zoom is set to 90% (!). I'm only reproducing at this zoom level. There is no issue with other zooms.

Scenario 2:

I'm using our local environment at work (cannot share a link due to security), but I've made a video posted below
MUI version = @mui/material = 5.13.5
You have to look really carefully - upon opening the dropdown, only items 4444 and 9999 move ~1px downwards
Browser zoom is set to 110% (!). I'm only reproducing at this zoom level. There is no issue with other zooms.

authors: atillaaliyev danilo-leal hbjORbj oliviertassinari siriwatknp stoberov

repo: mui/material-ui


text:
404 : /joy-ui link does not exits

Description
I was on the page Get Started and when I want to go back to the parent, I found that this page does not exist.
From the UX perspective, this page should be the Home page for joy-ui or redirect to the mui home page.
Screenshot

This will be the Joy UI landing page #36829. Stay tuned!

authors: MenaiAla siriwatknp


text:
[TypeScript] getCssVar autocomplete for Material UI

Sandbox: https://codesandbox.io/s/create-react-app-with-typescript-forked-tlp4uv?file=/src/App.tsx

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

Looks great, tested here - https://codesandbox.io/s/basicbuttons-demo-material-ui-forked-u9f18y?file=/demo.tsx
Would be great if we can add a *.spec.ts where we test that we can invoke the getCssVar with valid theme value and with custom var too. We can even go one step further and test that module augmentation will be affected too.

Added! I changed my mind to make it strict first (only work with the values inside the theme).
Developers can augment by:
declare module "@mui/material/styles" {
  interface ThemeCssVarOverrides {
    customToken: true
  }
}

theme.getCssVar('customToken') // 🎉

or cast with any for unknown variable
theme.getCssVar('palette-primary-main', 'var(--custom-token)' as any)


text:
[docs][Joy] component, slots, slotProps must be visible in Prop table in API docs

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

:warning: This PR must be merged after ##36599 and #36540 are merged.

Both #36599 and #36540 are merged. This is ready for review. @siriwatknp

@siriwatknp I've already handled that in this PR and merged it!


text:
Bump typescript-eslint to ^7.16.1 (major)

Closes https://github.com/mui/material-ui/issues/42910
Not sure why renovate hasn't created a PR for it yet.
MUI X is already using this version.
Here are the major release notes: https://github.com/typescript-eslint/typescript-eslint/releases/tag/v7.0.0

@aarongarciah, there's an open issue about this, but it's only a warning for development. I'm not sure if we should cherry-pick it to master or not. What do you think?

@DiegoAndai not sure it's worth it given next will be merged into master "soon". We'd need to see if there are other deps that need to be updated after we bump typescript-eslint.

authors: DiegoAndai aarongarciah


text:
fixed tabbing direction order

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

Not sure how to add labels, I didn't see the option for it anywhere, just that none were applied.

I don't know what order #44452 is, I was fixing order #42185
https://github.com/mui/material-ui/issues/42185

@ChristopherJamesL See https://github.com/mui/material-ui/pull/44496#issuecomment-2497530832

authors: ChristopherJamesL ZeeshanTamboli


text:
Create playground

Summary
Create a Playground so developers can't play and debug the tool.
Examples

esbuild: https://esbuild.github.io/try/
prettier: https://prettier.io/playground/
yak: https://yak.js.org/playground
TypeScript: https://www.typescriptlang.org/play/
React Compiler: https://playground.react.dev/

Motivation
I suspect that for any tools like this one that perform code transformations, we need a Playground so:

Developers can quickly debug
Maintainers can have simpler reproductions

Search keywords: -

A possible use case: https://github.com/mui/pigment-css/issues/86, help people understand what's going on.

repo: mui/pigment-css


text:
Update dataweave-formats.adoc, correct JSON skipNullOn section

The skipNullOn section for JSON had a description copied from the XML section. It has been updated to match runtime behaviour and now refers to arrays, objects instead of elements, attributes.
Included is one small examples.

I signed the contributor's agreement now :-)

example exists: https://docs.mulesoft.com/mule-runtime/4.3/dataweave-cookbook-set-reader-writer-props
closing due to age and lack of sig

authors: chrysophylax dukesphere

repo: mulesoft/docs-mule-runtime


text:
Unwanted Tidal MQA playback with audio dropouts

What version of Music Assistant has the issue?
2.2.3
What version of the Home Assistant Integration have you got installed?
No response
Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

[X] Yes

The problem
MA plays back MQA versions of Tidal albums. The MQA versions don't seem to work very well, because I hear audio dropouts.
The exact same albums in the Tidal app play as FLAC with Tidal Connect and don't have these issues.
Seeing that Tidal stopped supporting MQA (not even available with Tidal Connect anymore) it would be better if MA would always revert to the best FLAC version available, and not play MQA albums.
How to reproduce
Add this album to favourites and sync to MA: https://tidal.com/album/4488861?u
It happens both with HIGH_LOSSLESS profile as well as HIGH_RES profiles
Music Providers
Tidal
Player Providers
UPnP
Full log output
No response
Additional information
No response
What version of Home Assistant Core are your running
2024.9.1
What type of installation are you running?
Home Assistant OS
On what type of hardware are you running?
Linux

I'm pretty sure the MQA tracks are not even provided anymore in the catalog so this is a bit surprising.
I'll try to reproduce

Not sure what changed in 2.2.4, but now the album continuously switches between (24 bit) FLAC and MQA.
https://github.com/user-attachments/assets/26b3a660-8a16-4a42-b223-2feda283f59b
Also happens on another album, and also happens when removing, restarting and adding Tidal again.

I have no idea what is going on but I cant reproduce any of this, not do I get an MQA stream from Tidal.
Did you try this on another player ? DLNA is famous for its flaky-ness.
Maybe also go a bit through the player settings for this player and try setting the HTTP Profile to Chunked.

@jozefKruszynski thoughts?

As @marcelveldt said this shouldn't be possible as the content should simply no longer be available on tidal.
Also switching stream type during playback is not something that should be possible.
@SirJohnDoe Did you completely remove and re-add tidal after the auth change?
The change to the pkce login type requires the complete removal before being re-added

A full reinstall of 2.2.5, but also latest dev, solved it. I only get FLAC now. Perhaps there was some remnant that linked to MQA albums or something.

@jozefKruszynski

I have no way of reproducing this as I have nothing that is capable of playing mqa.
Only thing I can think is that the player firmware is booked as Tidal do not have any mqa content anymore.

I have no way of reproducing this as I have nothing that is capable of playing mqa. Only thing I can think is that the player firmware is booked as Tidal do not have any mqa content anymore.

If I start the exact same album through Tidal (Connect) on the amp it never switches to MQA. It appears the MQA is still available in the API that MA uses, or cached somehow? When I first saved these tracks they were possibly still in MQA format. But I've done multiple full reinstalls of MA in the last few months and always did a full resync with Tidal.
Does MA tell my player that it should start a Tidal track, like a chromecast where the player makes a direct connection with the streaming provider? If that's the case, and MA is not serving the audio, I can imagine caching can be the issue on my player.

I have no way of reproducing this as I have nothing that is capable of playing mqa. Only thing I can think is that the player firmware is booked as Tidal do not have any mqa content anymore.

If I start the exact same album through Tidal (Connect) on the amp it never switches to MQA. It appears the MQA is still available in the API that MA uses, or cached somehow? When I first saved these tracks they were possibly still in MQA format. But I've done multiple full reinstalls of MA in the last few months and always did a full resync with Tidal.
Does MA tell my player that it should start a Tidal track, like a chromecast where the player makes a direct connection with the streaming provider? If that's the case, and MA is not serving the audio, I can imagine caching can be the issue on my player.

No, we grab the stream directly. It could well be the unofficial api that we use that may cause the issue.
I think there was recently an update there so I'll see if there's anything interesting happening over that way.

@jozefKruszynski Any more needed to be done here?

Let's keep it open until after the tidalapi 0.8.2 merge to see if that will help.

authors: OzGav SirJohnDoe jozefKruszynski marcelveldt

repo: music-assistant/hass-music-assistant


text:
Getting a warning on HA logs that mass is not compatible with 2022.9.1

What version of Music Assistant has the issue?
2022.8.4
The problem
Getting log warnings in HA logs:
2022-09-09 14:37:00.106 WARNING (MainThread) [custom_components.mass] This version of Music Assistant is compatible with Home Assistant version 2022.8, and you are running 2022.9.1. You may run into compatibility issues. Please check if there's a newer (beta) version available of Music Assistant.
How to reproduce
Upgrade HA to 2022.9.x
Relevant log output
No response
Additional information
No response
What version of Home Assistant Core are your running
2022.9.1
What type of installation are you running?
Home Assistant Container
On what type of hardware are you running?
Generic x86-64 (e.g. Intel NUC)

Hi, thanks for reporting. This is a known, and luckily just a  harmless warning. MA works fine with the new core 2022.9.x

ditto here
No issues with MA other than those I was aware of already.
This warning is like the HA warning about MA :
"2022-09-09 22:51:45.293 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration mass which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant"
I kind of wished these were at a different severity setting, but that is a HA design choice.

Yes that second logging is from HA and always there for all custom integrations.
The logging mentioned by @jsBlackBelt is from MA itself. Both are harmless in this case.
The reasons for these loggings is that custom integrations are not released as part of core. So library updates in core can break them. This didn't happen for 2022.9.x, but can't be predicted in advance. That is why MA explicitly warns that it was released against core 2022.8

yep I do like how it mentions the version it is tested against so you know if you need to upgrade.
I hope one day MA will become part of HA itself 👍

Will PR #908 fix this?

Maybe. It will get fixed in time. There is a significant update underway.

You can now resolve this by updating to HA 2022.11.x This issue will be closed soon.

authors: Clusters DutchJaFO OzGav erkr jsBlackBelt


text:
Unable to Reproduce Results as Stated in the Research Paper

Hello,
I have attempted to reproduce the results stated in the research paper multiple times but have been unable to achieve the same performance.

Finally I found the solution we just needed to convert the cqt to  db scale then you can produce the same resutls as described in the reserarch papper.


text:
Update formatting for consistency

Remove full stops from bullet points for document consistancy

Nice. Thank you

authors: lpww tipiirai

repo: muut/riotjs

license: mit

license_source: bigquery


text:
Releases/v1.2.2

Fixes

fix: Rendering issues on Compose UI & API 34 (upstream from media3: link)

Improvements

Update media3 to 1.4.1 + mux data to 1.6.0 (#70)

Co-authored-by: Emily Dixon edixon@mux.com
Co-authored-by: GitHub noreply@github.com

Only change has already been reviewed

repo: muxinc/mux-player-android


text:
Merge 500 images and emotions classifications (legend.csv)

William Chan
user.id = 31415

Cancelling pull request (I classified 500 images from the celebrity data set that Daniel classified completely).


text:
Strip all filename and position info when -tiny is passed

Will partially fix #127.
honnef.co/go/tools/cmd/staticcheck with and without -tiny:
normal        8167424
with -tiny    7581696

That's a ~7% decrease in size.

Not sure what to do about the tiny test, should I remove it?

repo: mvdan/garble


text:
Add a recommendations value for attributes

Add a recommendations field for each attribute

would a recommendation be related to an attribute or a rating.....or neither?
could have a separate recommendation library linked to ratings/attributes.

I think that both observations/comments and recommendations would be against particular attributes (eg, Standups, Retrospectives, etc).
I think that actions (if we implement them) will be more complicated.
Rob
From: Mike Villis [mailto:notifications@github.com]
Sent: Friday, 8 January 2016 12:24 PM
To: mvillis/measure-mate
Cc: Robert Loomans
Subject: Re: [measure-mate] Add a recommendations value for attributes (#53)
would a recommendation be related to an attribute or a rating.....or neither?
could have a separate recommendation library linked to ratings/attributes.
—
Reply to this email directly or view it on GitHubhttps://github.com/mvillis/measure-mate/issues/53#issuecomment-169869845.

This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp".
Suncorp may be contacted at Level 28, 266 George Street, Brisbane or on 13 11 55 or at suncorp.com.au.
The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.

authors: mvillis rloomans

repo: mvillis/measure-mate


text:
Document additional use-cases

Steal ideas from https://github.com/johannest/vaadin-embedded-jetty-gradle-v23/blob/main/src/main/java/com/vaadin/starter/skeleton/Main.java

Document always-on production mode
Document way to add additional servlets

Always-on production mode documented at https://github.com/mvysny/vaadin-boot#always-on-production-mode

repo: mvysny/vaadin-boot


text:
On the mobile wallet Transaction page, currently don't have the options - Validate Proof File, Refresh, Export.

Description:
On the mobile wallet Transaction page, currently don't have the following options

Validate Proof File
Export.CSV
Refresh

Expecting options in mobile wallet same as QT wallet.

@sarawut11   @vinayaga07    Export to CSV is not needed for the first version of mobile.

Moved export feature into another issue - https://github.com/mwcproject/mwc-qt-wallet/issues/833

Verified, hence closing this ticket.

repo: mwcproject/mwc-qt-wallet


text:
Support with redux-actions handleActions({})

@mweststrate - Can I use produce on my reducer with redux-action's handleActions(Object) method?
eg -
const reducer = (state = initState, action) => produce(state, draft =>
	handleActions({
			[ACTION_TYPES.FETCH_DATA]: (draft, action) => {
				draft.data = action.payload
			}
     })
)

@ronen don't comment on closed issues, chances are 50-50 that someone will see it.

@ronen anyway, check https://gist.github.com/kitze/fb65f527803a93fb2803ce79a792fff8 or some of the other stuff linked here: https://github.com/mweststrate/immer#cool-things-built-with-immer

authors: mweststrate sharmad-nachnolkar

repo: mweststrate/immer


text:
Uncaught TypeError: Cannot delete property 'find a clean mug' of #

I have greatly improved the project running at http://transcendent.ninja. The README.md is out of date, but the code can be found at https://github.com/dschalk/mobservable-monads .
Today, I have been working on a monad implementation of "Todo List". The store is a reactive object instead of an array, so instead of "splice" I used "delete" followed by the index of the embedded object to be deleted. That results error messages such as:
Uncaught TypeError: Cannot delete property 'find a clean mug' of #<Object>

Here is the constructor of the monad at issue:
let M = new MonadObject(
   {
   'find a clean mug': {
       title: 'Find a clean mug',
       completed: true,
       remove: <button onClick = {() =>  {delete(M.x['find a clean mug']) }}
         style={{fontSize: 22 }}
         >
         Remove
         </button>
    },

   'make coffee': {
       title: 'Make coffee',
       completed: false,
       remove: <button onClick = {() =>  {delete(M.x['Make coffee']) }}
         style={{fontSize: 22 }}
         >
         Remove
         </button>
    }
  }
);

Here is what appears in the console log:
var M = new MonadObject({
	  'find a clean mug': {
	    title: 'Find a clean mug',
	    completed: true,
	    remove: _react2['default'].createElement(
	      'button',
	      { onClick: function () {
	          delete M.x['find a clean mug'];
	        },
	        style: { fontSize: 22 }
	      },
	      'Remove'
	    )
	  },

Hovering the mouse pointer over the little "x" displays: "Uncaught TypeError: Cannot delete property 'find a clean mug' of #<Object>".
What I am trying to do seems quite reasonable. I am allowed to splice elements out of arrays, so it is doubly surprising to find that I can't delete properties of an object. I wonder:

Is React or Mobservable causing this?

If it is Mobservable, did you intend to include use cases such as mine in the prohibition against deleting properties of objects.

Is there a work-around that can make it possible for me to remove embedded objects from objects.

My problem has wider implications. Shopping carts are real world applications that need "remove item" buttons. So if Mobservable is responsible for this error and there is a way to remove properties from objects, I suggest that the documentation make it easy to find so developers can quickly get on with their work.

It is caused by Mobservable, currently property delete's are not allowed on objects.

So far objects are mostly considered to be structs, you want to observe the mutable properties individually in other observers. Deleting is to observers mostly the same as setting a property to undefined. However if you are looping the properties delete is quite different.

I think this is valid workaround (besides directly assigning undefined):

var prop = Object.getOwnPropertyDescriptor(x, "Find a clean mug")
prop.enumerable = false;
Object.defineProperty(x, "Find a clean mug", prop);
x["Find a clean mug"] = undefined;

I think there are three possible solutions:

Allow deleting of properties. This would leak some memory though as Mobservable cannot detect this event (until ES7 is standardized) and will leak some memory
Provide a utiity method: mobservable.deleteObservableProperty(x, "Find a clean mug") which does all the clean up
Provide an ObservableMap classes with explict set, get, delete methods and an observable key collection to express that this object is a coherent set of key / values (just like an array is a coherent set of indexes / values) instead of an uncoherent set of preoperties.

I have a version of Todo's at http://transcendent.ninja that works perfectly in Chrome and Opera in my Ubuntu 14.04 box, but not in Firefox. I uploaded the code to https://github.com/dschalk/mobservable-monads. While seeing what worked where, I discovered that the app at https://mweststrate.github.io/mobservable/getting-started.html doesn't work in any of my browsers.
The workaround you suggested didn't work, but that might have been due to my doing something wrong. I was just experimenting with storing todo's in an object.
You probably have more interesting and pressing things to think about, but for the record, here's the code that works in Chrome and Opera: First, my simple starting todo's store:
let M = new MonadArray(
   [
      [ 'find a clean mug', true ],
       [ 'make coffee', false ]
    ]
);

The display function is:
displayTodos = () => {
  let ar = [];
  let M = this.M
  let l = this.M.x.length;
  for (let k=0;k<l;k+=1) {
    ar.push(  [

 {M.x[k][0]}

 {M.fmap(this.removeTask, M.x[k][0]) }}
				style={{color: 'lightblue', fontSize: 22 }} > Remove

 {M.fmap(this.toggleComplete, M.x[k][0]) }}
				style={{color: 'lightblue', fontSize: 22 }} >
				Complented:  <input type='checkbox' checked={M.x[k][1]}
				  style={{width: 18, height: 18}} ></input>

 {M.x[k][0] = prompt('Todo:', 'Take a walk') }}
				style={{fontSize: 22, color: 'lightgreen'}}
				  >
				edit

 ]) }
    ar.push(
 {this.completed()} of {l} complete.
 )
    ar.push(
 { let t = prompt('New task: ', 'smell the roses');
                                   M.fmap(this.addTask, t) }}
        style={{fontSize: 22, color: 'orange'}}
      >
    new todo

 )
      return ar;
}

Maybe Firefox would run this if I made it into a React component. Here are the other functions:
    addTask = (mon,t) => {
      mon.x.push( [t,false])
      return mon;
    }

    removeTask = (mon,t) => {
      let l = mon.x.length;
      let k;
      for (k=0;k<l;k+=1) {
        let task = mon.x[k][0];
        if (mon.x[k][0] === t) {
          mon.x.splice(k, 1);
          console.log(mon.x);
          return mon;
        }
      }
      return mon;
    }

    toggleComplete = (mon,t) => {
      let l = mon.x.length;
      let k;
      for (k=0;k<l;k+=1) {
        if ( mon.x[k][0] === t) {
          mon.x[k][1] = !mon.x[k][1];
        }
      }
      return mon;
    }

    let completed = () => { return (M.x.filter(y => y[1]).length) }

Update: The Todo list section is a React component now. The code has expanded to include rollover buttons.

Hi David,
Some answers :)

Thanks for pointing out the issue in the todo-mvc example! Somehow I completely broke it by using the wrong api after upgrading to 1.0, without noticing. No automated tests always bites you at some point :hammer:

The loop issue is a common mistake people make when using javascrip; the k value is reused in all iterators of the loop because they are all reading the same closure. So you will end up with only the latest value everywhere. A simple work around is to store the variable in a variable in a fresh closure:

for (let k=0;k<l;k+=1) {
    () => {
        const iteratorValue = k;
       // use iteratorValue instead of k from now on.
    }()
}

I will add utilities to complete remove key/values from an object soon.

To simplify the splice, you can also use the find function, which is available in ES 7, but also on observable arrays. It takes a predicate and returns the first index that satisfies the predicate.

Whether a list is better or worse than an object to store that depends on many things. Not only the size of the collection, but also on whether the ordering of the the data set is important etc. (objects are unordered in javascript, although they often seem to be ordered). So its hard to say anything generic about that :) In performance critical applications with large datasets, and significantly more reads than writes on the data, you might even end up with a double administration of such data sets.

Thank you for graciously taking the time to comment on my Todo code. I knew there was something like 'find' out there but now I know exactly what and where it is.
"for (let k=0;k<l;k+=1) " works fine, as you can see at http://transcendent.ninja . It was when I pre-defined 'k' and ran for (k=0;k<l;k+=1) that the last value of k showed up everywhere. I want to understand this better, so I am going to try "for (var k=0;k<l;k+=1)" and see if substituting 'var' for 'let' makes a difference. I don't think it will work with 'var'.
Here's something from developer.mozilla.org:
var list = document.getElementById("list");

for (var i = 1; i <= 5; i++) {
  var item = document.createElement("LI");
  item.appendChild(document.createTextNode("Item " + i));

  let j = i;
  item.onclick = function (ev) {
    console.log("Item " + j + " is clicked.");
  };
  list.appendChild(item);
}
The example above works as intended because the five instances of the (anonymous) inner function refer to five different instances of variable j. Note that it does not work as intended if you replace let by var or if you remove the variable j and simply use the variable i in the inner function.

Congratulations on publishing version '1'.  You are making a major contribution.

P.S. As expected, the buttons generated by "for (var k=0;k<l;k+=1)" don't work at all. 'let' is what made the loop work without the additional boilerplate that 'var' would make necessary.

Just released 1.0.2, which introduces mobservable.map() can now be used to create an observable key/value maps, similar to ES6 maps (and in contrast  to objects which are expected to have more or less stable keys)

authors: dschalk mweststrate

repo: mweststrate/mobservable


text:
Camelcase operationId tags

Camelcase's operationId tags to follow the convention used in the
OpenAPI spec: https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md

Looks good :shipit:

repo: mxenabled/openapi


text:
feat(intl): Use appLocales to populate i18n toggle

use i18n.js#appLocales as source of locales, remove hard coded array

Coverage increased (+0.002%) to 98.348% when pulling 2a54a202d1cb1ba7c0efe38151fae0911333a7fe on justingreenberg:feature/use-app-locales into bfe0c201053ffe052ec2dfe010a7dd2c7f054c10 on mxstbr:master.

Have you tried adding a new language? I'm 99% sure this will throw because there is no text in messages.js for the new language.

Coverage increased (+0.002%) to 98.344% when pulling 4f3ede0be1ca1ce5584fde3d7ec7c49ab4985f54 on justingreenberg:feature/use-app-locales into c11c0ae23098a018ede1ccee85a5bb784ff3decf on mxstbr:master.

Coverage increased (+0.002%) to 98.431% when pulling 43efcdcc75ced6181433bb582448f6f5333326a3 on justingreenberg:feature/use-app-locales into 96e9441838ba2ff372e8f3ef490e7fa38d29974c on mxstbr:master.

Just tried this locally, this throws because we need add a message with the key to the LocalToggle/messages.js!

@mxstbr that makes sense... i will take a few mins tomorrow (later today for you) to see if i can find a workaround, if not will close... hard coding the locales in numerous places just feels wrong

Coverage increased (+0.002%) to 98.431% when pulling 14261cebc249adb7d553987c0a1c9a9708f9d206 on justingreenberg:feature/use-app-locales into b8ea957ed93bf6d4fe8124ba340e5b257ecf5809 on mxstbr:master.

we could populate messages.js in generator

Coverage increased (+0.002%) to 98.431% when pulling 14261cebc249adb7d553987c0a1c9a9708f9d206 on justingreenberg:feature/use-app-locales into b8ea957ed93bf6d4fe8124ba340e5b257ecf5809 on mxstbr:master.

Coverage increased (+0.007%) to 98.436% when pulling 1b8f76c54a912134834bca39bb9d72ab6f31269f on justingreenberg:feature/use-app-locales into b8ea957ed93bf6d4fe8124ba340e5b257ecf5809 on mxstbr:master.

@mxstbr threw up a super simple solution that works out of the box as you generate more languages... not priority by any means, feel free to merge or close :)

Coverage increased (+0.02%) to 98.447% when pulling 0673af6e98607c2021bc8456942e32c31bcf414c on justingreenberg:feature/use-app-locales into b8ea957ed93bf6d4fe8124ba340e5b257ecf5809 on mxstbr:master.

Coverage increased (+0.02%) to 98.447% when pulling 2c751546a5f06a509d28ddb7a5ff1ee54518590f on justingreenberg:feature/use-app-locales into b8ea957ed93bf6d4fe8124ba340e5b257ecf5809 on mxstbr:master.

Hah I love it! Great work @justingreenberg! 🔥

authors: coveralls justingreenberg mxstbr

repo: mxstbr/react-boilerplate


text:
🛑 BRICKS BETA is down

In 7903aef, BRICKS BETA (https://display-beta.bricks.tools/api/workspace-public-health-check) was down:

HTTP code: 502
Response time: 1551 ms

Resolved: BRICKS BETA is back up in 36a66ac after 9 minutes.

repo: mybigday/service-uptime-beta


text:
Running as service on a pi...

I tried to create a service on a pi...
sudo nano /lib/systemd/system/mycontroller.service
sudo chmod 644 /lib/systemd/system/mycontroller.service
sudo systemctl daemon-reload
sudo systemctl enable mycontroller.service
sudo systemctl start mycontroller.service
sudo systemctl status mycontroller.service

mycontroller.service
[Unit]
Description=mycontroller
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/java  -Xms8m -Xmx100m -Dlogback.configurationFile=/home/pi/mycontroller/conf/logback.xml -Dmc.conf.file=/home/pi/mycontroller/conf/mycontroller.properties -cp /home/pi/mycontroller/lib/* org.mycontroller.standalone.StartApp
Restart=on-abort

[Install]
WantedBy=multi-user.target

which works great for a while (at least if I disable the broker and http on my system :-),
but then something went wrong in the configuration and it broke... (with a broker)
So... i wanted to start over again so i removed the folder (which I though contains all the config and stuff), unzip it again in the same place. And as user pi this works great, grand new setup! But when I run it as service... I get the same gateways instead of beginning fresh... it seems it stores some information about gateways... somewhere else, so  so how do I completely uninstall all config/setup/db files and start again???
now I am just stuck with local user and no service.
latest jessie with java 1.8 & mosquitto server

btw the issue I was having is a subscribed to a mtqq which apparently is not a mysensor... it mtqq stil connects, but I tried to delete it, since it was wrong... I just can't...   now when it loads, almost all buttons including profile and settings are non functioning....

btw the issue I was having is a subscribed to a mtqq which apparently is not a mysensor... it mtqq stil connects, but I tried to delete it, since it was wrong... I just can't...   now when it loads, almost all buttons including profile and settings are non functioning....

ok i solved my own problem :-)
sudo find / -mtime -1 -print
it stores it in
/home/conf/
still i though i gave the arguments correctly in the service script... why does it not use that?
:-)

ok i solved my own problem :-)
sudo find / -mtime -1 -print
it stores it in
/home/conf/
still i though i gave the arguments correctly in the service script... why does it not use that?
:-)

just for the fun of it,.. i put it all the sub folders in /home
sudo /usr/bin/java -Xms8m -Xmx100m -Dlogback.configurationFile=/home/conf/logback.xml -Dmc.conf.file=/home/conf/mycontroller.properties -cp /home/lib/* org.mycontroller.standalone.StartApp
gives

if i run it without sudo it runs perfect.. so how do i run it as a service?

just for the fun of it,.. i put it all the sub folders in /home
sudo /usr/bin/java -Xms8m -Xmx100m -Dlogback.configurationFile=/home/conf/logback.xml -Dmc.conf.file=/home/conf/mycontroller.properties -cp /home/lib/* org.mycontroller.standalone.StartApp
gives

if i run it without sudo it runs perfect.. so how do i run it as a service?

@Tristan79 Create an user for mycontroller, then use "User=" and it should work, it works for me.

@Tristan79 Do you change anything here?
https://github.com/mycontroller-org/mycontroller/blob/development/dist/src/main/package/conf/mycontroller.properties#L90

seems creator not interested anymore on this issue.

authors: Avamander Tristan79 jkandasa

repo: mycontroller-org/mycontroller


text:
react-hot-loader warning in console

warning in the console
'React Hot Loader: this component is not accepted by Hot Loader. \n' + 'Please check is it extracted as a top level class, a function or a variable. \n' + 'Click below to reveal the source location: '

see react-hot-loader Troubleshooting , but the solution at bottom doesn't  work.
so currently you have to goto the <rootDir>/node_modules/react-hot-loader/lib/patch.dev.js file and comment the annoying console.error manually . like this:

function warnAboutUnnacceptedClass(typeSignature) {
  if (didUpdateProxy) {
    // console.error('React Hot Loader: this component is not accepted by Hot Loader. \n' + 'Please check is it extracted as a top level class, a function or a variable. \n' + 'Click below to reveal the source location: \n', typeSignature);
  }
}

the hot-loader function is not effected.

repo: mydearxym/mastani


text:
limesdr-usb does CW instead of tdma bursts after "lsusb -d 1d50:6108 -v" when using usb2

when running recent osmo-trx-lms with limesuite1810 and limesdr-usb forced down to usb2 by using a usb2 only cable the device stops working and starts emitting a continuous wave (cw) carrier as soon as "lsusb -d 1d50:6108 -v" is run in another terminal.
"lsusb -d 1d50:6108" does not interrupt the service.
this is not reproducible when using only usb3 cabling
see also https://osmocom.org/issues/3341

The difference between "lsusb" and "lsusb -v" is that the former just uses cached descriptors from the kernel (i.e. no transaction with the device happens), while the latter is actually using control transfers on the control endpoint to retrieve the string descriptors.
So the suspicion is that something is broken in the handling of control transfers if attached to/via USB 2.0 only.
It is perfectly normal for the OS or any other application to send USB control transfers to a device, even while the device is in use.

Can not reproduce this on Gigabyte Brix computer. Running Ubuntu 16.04 LTS. LimeSDR-USB forced to USB2 via USB hub. LimeSuiteGUI transmitting and receiving at the same time, command "lsusb -d 1d50:6108 -v" makes no impact.

The reason device stops working and starts emitting a continuous wave (cw) carrier as soon as "lsusb -d 1d50:6108 -v" is run is as follows: after command "lsusb -d 1d50:6108 -v" is run, there is a packet loss. While there is no re-synchronization (check https://osmocom.org/issues/3339#note-11), everything stops and carrier is visible only, while there are no data to send.

Thanks for your feedback. The question is: Why would a very small control endpoint transfer result in packet loss? We're talking about very small transfers fetching a couple of string descriptors.  Surely, this shouldn'r result in packet loss on the completely unrelated bulk endpoints?

@rohlan - This issue was reported for LimeSDR-USB board when it is forced to USB2 communication. From your last message I understand, that the same issue is for LimeSDR-Mini board, connected via USB3. Could you confirm please that you are talking about LimeSDR-Mini board.

authors: laf0rge rohlan ztamosevicius

repo: myriadrf/LimeSuite


text:
Handling error in interceptor without propagating to caller

Imagine a response error that needs to be handled completely in an interceptor without propagating it to the .catch on the axios.[method] caller.
axios.interceptors.response.use(response => response, (error) => {
    if (error.response) {
      if (error.response.status === 401) {
        dispatch('logOut');
        notify('Session expired');
      } else return Promise.reject(error.response);
    } else if (error.request) notify('Server down');
    else notify('Unexpected error');
  });

So the only wanted error to be propagated is when a response exists but it's status is not 401. In that case the caller of the axios.[method] function can catch the error.response directly as .catch(response).
If this cannot be achieved then the axios caller must do it's thing after it checks that error has a response and it's status is not 401. It would be checking again because the interceptor already checked and solved those cases so the caller will just ignore them. Maintenance would be a nightmare if a new check is added to the interceptor, each axios call will need to ignore that check because it was already handled.
Am I missing something on how Javascript works (sorry if this is the case) or it can be solved using the axios API?

+1 I'm thinking about this too

You can do it with Axios. When the error response interceptor returns a value or a promise, it'll use that value to resolve the returned value from Axios. If you want to re-throw the error you must throw or return Promise.reject(...).

+1 This would be really useful
@rubennorte I think that what @niklabaz wants is to use the interceptors to catch certain errors, and let the others to go to the .catch method from the axios[method] call.
The problem is that if you throw or return Promise.reject(...) after you, let's say notify the user in the interceptor, then you must catch the error again, in the .catch method, or it will break you code.
If you instead return a console.log() or a toaster for the specific errors that you cover in the interceptor, axios will consider that the response is a success and then execute the code in in the .then(response => {} method.
How can this be addressed?

@aocneanu I think that what you're suggesting is breaking the promise chain at that point, and I'm afraid promises don't support that.
You could do it returning a never resolving promise (e.g.: return new Promise(() => {});) but I'm not sure if that would cause memory leaks.
Anyway that's out of the scope of Axios and must be managed in the interceptor.

Thank you for your response.
So it seems that the only way to handle certain errors globally would be to write a handler mixin and  use it in every axios[method].catch(err => handler(error)).

authors: aocneanu ksherman niklabaz rubennorte

repo: mzabriskie/axios


text:
React Compatibility?

This more of a feature request, so feel free to close this as an issue!
But, I've been trying to get this to work with React but it's proving difficult. I think partly because the script loads on dom load rather than on each component mount. This results in the gallery working the first time it loads but fails when returning. Having the repo on NPM would also be of great help for building with webpack/browserify.
ps. Thanks for the great work!

Hey Peter!
Thanks for the feature request! I will look into it as I already had some people notifying me about the troubles when using it in connection with AJAX. I think I will do some slight refactoring so that you can either import/require it or it will automatically initialize itself when it finds any DOM elements. About the NPM part:
https://www.npmjs.com/package/fluffy.js
I know it's not in the docs, will fix that too asap.

Thanks I look forward to your future releases and can't believe I missed the NPM package!

Fixed with 42481fdfa25891904b670e4e7e4768c224fd447e

Alright @petertait, I just released v2.1.0. Give it a try and tell me if this fixes your problems with React!

Thanks @mzdr for your help, it works like a dream!

authors: mzdr petertait


text:
Chart performance

ion traces + images rendered as image in feature table

BufferedImages are first added to the FeatureTable
On click those are changed to interactive charts - faster load time
Currently they are not changed back. This mean they stay as charts

authors: SteffenHeu robinschmid


text:
blur event isn't worked properly

blur event isn't worked properly
nspanel can't be focused at runtime, blur and keydown event can't be triggered

Refer : https://github.com/electron/electron/issues/23, BrowserWindow can't be inherit because of its complexity and its wrapper which made with C++. To implement blur event, should make its own blur event in the native wrapper.

repo: mznet/electron-nspanel


text:
Remove private replays

There was a month-old comment that read Private is deprecated; it will be removed soon. I guess this was forgotten about. Therefore I removed it.

Do you need to generate migrations again? Error seems to be complaining that the models dont match the migration database state

Do you need to generate migrations again? Error seems to be complaining that the models dont match the migration database state

I guess so. How do I do that?

py manage.py makemigrations

Thank you!

repo: n-rook/thscoreboard


text:
Added a "graphFactor" parameter to a series.

Sometimes there's a need to have several series with different scales on the same y axis.
For example:
series A data is in KM
series B data is in CM
The display of this chart will be 2 lines (usually one line will look like a flat line comparing to the other one that will be more "wavy"), with a big distance between them.
The graphFactor parameter is actually a ratio factor that will help to keep the display more informative.
WIth graphFactor:

WIthout graphFactor:

Hey, thank you for the interest.
I'm sorry but I can't merge this PR. Displaying adjusted data just so that all datasets are on the same axis doesn't seem right to me. This would be a use case for a secondary y-axis.

authors: lorem--ipsum ordavidil


text:
Test assertions can't rely on object ids

Because autoincrement sequences do not rollback with a transaction, and therefore generated ids are dependent on test order and inclusion. So the best we can do is assert a number.
Right now, there are many tests that assert a specific number, which is dependent on the other tests involving that model running in a particular order and inclusion. The whole suite works stably, so this isn't catastrophically urgent, but should be addressed, probably at the same time as #55.

Resolved via #61.

repo: nafundi/jubilant-garbanzo


text:
colorschemes not working

@nagix
this is my option in data
options:{
plugins : {
colorschemes : {
scheme : 'brewer.YlGn3'
}
}
}
by default brewer.Paired12 is applied even  I change other schemes

Can you share entire js code, or more preferably, a working sample using jsfiddle, codepen or similar?

Thanks for response @nagix  , now working fine .Previously I gave the options inside data that is reason the color scheme was not changed

authors: mohamedmohsin nagix

repo: nagix/chartjs-plugin-colorschemes


text:
CNRM-email "generation" in namespace reconciler needs code cleanup

https://github.com/nais/console/blob/de70a3eeb51f9297591c88e6b7f346f3494e99db/pkg/reconcilers/nais/namespace/reconciler.go#L188-L193

https://github.com/nais/console/compare/f84e5a71c38690aa71b0ed2fbc29519b9f0db400...3218deda9bc5aaf07c7d98739f313cd27e6f13f6

repo: nais/console


text:
docker-composeでhato-botも上がるようにする

PosgresSQLの起動待機と環境整備だけ癖っぽいがあとは問題ないはず。

あくまで鳩botを常時稼働させるためのPRであって、
開発するならば従来通り pipenv install をローカルで実施する必要がある認識であってます？
(開発する際にPostgresqlのコンテナを立ち上げると、鳩botのコンテナも立ち上がるからいちいち止めるのは手間かなと思ったり。)

本音のところ環境変数で切り替えたいのと、それをやるならMakefileが欲しくなってくる。

developをマージすればCIのエラーを解消できるかと

開発用にも使えるようにした。
が、一癖あるので、必要な操作をMakefileにまとめておきたい。

developをマージしてもらえればCI通るようになると思います。

動けばOKとしたいけど動かないのでダメです。。。

なんでLintCodeBase動いてないんだろう。LintCodeBaseが入るより前にpushされたから・・・？

とりあえずReRun押してみたけど、走るかどうかはわからん

rebaseしてみる

よろです

やりました。

あざす

だめだったらLintCodeBaseをRequiredから外すわ

だめそう。。。

と゛う゛し゛て゛……

とりあえず外した

トリガーが push なのに起因している説 (他は pull_request )

別リポジトリだからかもしれない。
それが原因なら普通の外部からのPRが入れられなくなってしまう。

あーこれ別リポジトリからのPRか。そりゃ動かんわ。

どしよっかな。

一旦これはマージしてしまい、別PRとして解決する？

いいと思う

authors: Goryudyuma fono09 massongit nakkaa

repo: nakkaa/hato-bot


text:
The labels of skier and paraglider in README mix up 😂

Maybe the paraglider is skier and skier is paraglider? haha

Nice catch!

authors: ShrimpLau nalepae

repo: nalepae/bounding-box


text:
Add specialized unique() method for categorical arrays

Faster, and respects the order of levels. Use it for droplevels!() to avoid
duplication. This introduces a dependency on NullableArrays in order to return
a NulableArray rather than an Array{Nullable} from
unique(::NullableCategoricalArray).
Fix a bug in levels!() when encountering a null value (uncovered by new
tests).

Current coverage is 83.77% (diff: 95.65%)

Merging #32 into master will increase coverage by 0.53%

@@             master        #32   diff @@
==========================================
  Files             8          8
  Lines           358        376    +18
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            298        315    +17
- Misses           60         61     +1
  Partials          0          0

Powered by Codecov. Last update b6a0659...84b661e

Cc: @kleinschmidt

Current coverage is 84.04% (diff: 100%)

Merging #32 into master will increase coverage by 0.80%

@@             master        #32   diff @@
==========================================
  Files             8          8
  Lines           358        376    +18
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            298        316    +18
  Misses           60         60
  Partials          0          0

Powered by Codecov. Last update b6a0659...6e3105d

Current coverage is 84.12% (diff: 100%)

Merging #32 into master will increase coverage by 0.79%

@@             master        #32   diff @@
==========================================
  Files             8          8
  Lines           360        378    +18
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            300        318    +18
  Misses           60         60
  Partials          0          0

Powered by Codecov. Last update fea9026...88b54f4

authors: codecov-io nalimilan


text:
Update README

Bumps to major version 6 and documents the incompatibilities

Just some householding stuff :-)

Thanks!

authors: mfn odino

repo: namshi/jose


text:
🛑 vngl.ooo is down

In 2403c9d, vngl.ooo (https://vngl.ooo) was down:

HTTP code: 0
Response time: 0 ms

Resolved: vngl.ooo is back up in c7ff978.

repo: nanhosting/monitoring


text:
🛑 faki-ongd.ch is down

In 01af708, faki-ongd.ch (https://faki-ongd.ch) was down:

HTTP code: 0
Response time: 0 ms

Resolved: faki-ongd.ch is back up in e8d3fe9.


text:
Misc improvements

Hi,
Here are several changes
Misc improvements
Please be indulgent 😄, I'm a Vimscript newbie!

filename change (fzy.vim)
some refactoring / moving around of the functions (the reason why is in the notes section below)
no bind keys by default
add some API functions: quite a big name for just 2 functions 😂, namely fzy#get_status_message and fzy#get_type_message. This is for playing nice with plugins like lightline.
add some limited ability to filter only buffer names (using the config below): it is limited because despite my efforts, I could not switch between filtering buffers and filtering files. You first have to toggle a switch using <c-t> and then re-call the plugin using <c-p>. Please note that the plugins opens for buffers first. You have to toggle and re-call the plugin to filter for files. Clearly not ideal.

Config
My init.vim config for this plugin is:
nnoremap <silent> <C-p> :FuzzyOpen<cr>
let g:fuzzy_bindkeys = 1 " activate default bindkeys
let g:fuzzy_contentsearch_engine = 'ag'

Usage
<C-P> opens the plugin in buffers mode
<C-T> to toggle to files (this also kills, as <esc> does
<C-P> opens the plugin in files mode
<C-T> to toggle back to buffers

Notes

I moved around the functions because they made more sense to me. Here is my vim window with the code now (thanks to folding). I hope it is self-explanatory

Should we submit all our common work back to the original author (Alexis)? I think it sounds better for the long run.

Thanks in advance for your comments and ideas.
Best regards

Here is an terminal recording

Awesome!!

I'm not particularly experienced in vimscript either, so give me a day or two to go over it and see if I understand the changes / they make sense
I definitely think we should submit back to the original author. I think it would be better to piecemeal out the changes as much as we can for clarity... possible through multiple merge requests to him

Cool ;)
As an alternative to multiple PR, we can make one PR using our current commits (each author will still be credited for his commits). Is ok with you?

yeah, that works!

Hi David, I opened the PR in the original repo. Cheers!

cleanup!

authors: bosr nannery

repo: nannery/neovim-fuzzy


text:
Black settings ask for python 3.8 compatible syntax but enterprise supports python 3.7

pyproject.toml has a setting to determine which version of Python black should produce syntax for; this should be the oldest version on which enterprise is expected to run, but it isn't:
https://github.com/nanograv/enterprise/blob/master/pyproject.toml#L3
As result, black could reformat our code in a way that doesn't run on our test suite.

Personal opinion: it's not worth worrying about 3.7 as its end of life is in 4 months (https://endoflife.date/python). I think we should drop 3.7 in anticipation of this event and make a move to support 3.11 instead.

Personal opinion: We should drop support for Python 3.7 and move to support 3.11 instead since 3.7 reaches EoL in 4 months (https://endoflife.date/python)

We removed 3.7 with #362

authors: AaronDJohnson aarchiba vhaasteren

repo: nanograv/enterprise


text:
DO NOT MERGE Connect automatically

So I added the autoconnect back, however:

In napalm_connection we will try to get napalm_options and pass them as optional_args (we can do the same for the rest.
Instead of having connections work with either a task or a host I call the connection task from the host. For that I needed to have access to the parent brigade object from the host so tasks that are configurable could read it from there. For instance: https://github.com/napalm-automation/brigade/blob/develop/brigade/plugins/tasks/connections/paramiko_connection.py#L18
I also added available_connections so the connections that are available for the tasks can be customized

Aside from my small comment above I think it looks good.
The available_connections will need some documentation. So perhaps a few lines about that in the class.

Yeah, there are a few things that need documentation here. I was mostly waiting for agreement before doing that :P

:) I heard that Documentation Driven Development is the new black.

I didn’t say it would be a pretty way to remove connections :) Just meant that it wouldn’t be hard.
My main point is that I think my scenario is more probable to happen than the one you describe.
It could be solved with a key in Config like external_connections_policy which takes “merge” or “replace”.
Don’t know if this just makes something simple overly complex.

On 15 Dec 2017, at 16:54, David Barroso notifications@github.com wrote:
@dbarrosop commented on this pull request.
In brigade/core/init.py:

@@ -68,6 +70,10 @@ def init(self, inventory, dry_run,
level=logging.ERROR,
format=format,
)

   if available_connections is not None:

       self.available_connections = available_connections

   else:

       self.available_connections = connections.available_connections

And I agree this is going to be strange (specially disabling connections), if anything the second case and I think it's equally easy to accommodate with both yours and my solution while mine makes less assumptions of how things should work :P
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

It could be solved with a key in Config like external_connections_policy which takes “merge” or “replace”.

I'd rather not have keys to change the behavior of things if we can help it. As your proposal and mine result in almost the same convenience for the user I'd rather stick with something that is generic and does't make assumptions on how users are supposed to use things.
Also, each key we add increases the chances users might get something wrong :P

In any case, no matter what we decide we need the available_connections argument because of how the filter works so I'd suggest not getting stuck with this conversation as what you are suggesting can be an improvement later on.
@ktbyers do you have any opinion about this PR? if you are good with it let me know what you want me to add to netmiko (or push a commit yourself directly to this branch)

+1 works nicely (even if the default behaviour for available_connections is wrong :) )

Everything else looks good to me.

As people seems to agree overall I am going to merge. We can iterate if there is something to be changed.

authors: dbarrosop ktbyers ogenstad

repo: napalm-automation/brigade


text:
Try to detect npe2 plugins and warn if napari version too old to work

see https://napari.zulipchat.com/#narrow/stream/309872-plugins/topic/Minimum.20napari.20version.20for.20npe2.20plugins.3F
and https://github.com/napari/napari/issues/4287

related napari/napari#4340

repo: napari/napari-plugin-engine


text:
Behaviour of layer.corner_pixels is inconsistent

🐛 Bug
The behaviour of layer.corner_pixels is inconsistent when working with combinations of 2D, multiscale and 3D images. Only multiscale images displayed in 2D take into account layer._dims_displayed leading to different corner_pixel values depending on the number of displayed dimensions.
Additionally, rolling dimensions when 2D and 3D images are in the viewer leads to incorrect corner_pixels for the 2D layer, which gets one correct set of coordinates and one set to the current slider value.
This inconsistent behaviour makes it difficult to reliably compute the data pixels currently on screen.
To Reproduce
Steps to reproduce the behavior:
import napari
from skimage import data
from scipy.ndimage import zoom
import numpy as np

with napari.gui_qt():
    viewer = napari.Viewer()

    img       = data.camera()
    img_multi = [zoom(img,(1/s,1/s)) for s in (1,2,4)]
    img3D     = np.tile(img[np.newaxis],(8,1,1))

    viewer.add_image(img3D)
    viewer.add_image(img)
    viewer.add_image(img_multi)

Then inspect viewer.layers.corner_pixels before and after rolling dimensions and/or toggling the number of displayed dimensions.
Expected behavior
The layer.corner_pixels attribute consistently displays the top-left and bottom-right pixel coordinates currently being displayed on screen regardless of whether the image is 2D, 3D or multiscale, and regardless of whether or not dimensions have been rolled.

Thanks for filing!

The use case that originally led to this bug being filed was trying to perform some computation on just the pixels currently displayed on screen. This is not possible directly with the current corner_pixels attribute, which was originally added to support the implementation of multiscale layers.
What is needed is some function which, given layer.data, viewer.camera, layer.scale, viewer.dims.ndisplay and viewer.dims.order returns the top-left and bottom-right indices of the bounding box in layer.data containing all pixels on screen (in highest resolution when the layer is multiscale?).
so something like
get_data_in_view(layer.data, layer.scale, viewer.camera, viewer.dims.ndisplay, viewer.dims.order) ->  np.ndarray
I'm not sure whether this should be its own utility function or a method on the viewer? Certainly it shouldn't live on layer as it needs to mostly know about the viewer, not the layer itself.
Special cases/things to consider

layer is multiscale: return coordinates in highest resolution level?
dimensions have been rolled: coordinates should be able to directly index into data - use axis order to transpose the coordinates/ switch them around as required

I would like to  bump this. After trying to debug a similar problem, @jni pointed me to this issue.
After stepping through with the debugger I can see that this is related.
What I observe:
I add a 5d multiscale, multichannel array as an Image layer, also passing in a channel_axis.
The array is displayed.
Now, I add a 5d label image as a Labels layer. After adding the Labels layer, the Image layers become invisible, except for a single row of pixels. The Image layer's corner_pixels attribute is no longer correct after adding the labels .
To reproduce:
Start napari 0.4.11, open an ipython console.
copy and paste:
import numpy as np
import dask.array as da

img_pyramid = [5*da.ones((1,3,1,512,512)), 5*da.ones((1,3,1,256,256))]
label_pyramid = [10*da.ones((1,1,1,512,512), dtype=np.uint8), 10*da.ones((1,1,1,256,256),dtype=np.uint8)]

viewer.add_image(img_pyramid, channel_axis=1)

You should see this:

Now, paste this to add a labels layer and print some output for debugging:
def print_debug_info():
    print("Qt Viewer info")
    print(f"viewer.dims.ndims: {viewer.dims.ndim}")
    print(f"viewer.dims.point {viewer.dims.point}")
    print(f"viewer.dims.displayed {viewer.dims.displayed}")
    print("Layer info")
    print(f"'Image' layer corner pixels: {viewer.layers['Image'].corner_pixels}")
    print(f"Image' layer _dims_displayed:  {viewer.layers['Image']._dims_displayed}")

print("Before adding 5D label")
print_debug_info()

viewer.add_labels(label_pyramid)
print()
print()
print("After adding 5D label")
print_debug_info()

The labels layer is added but the Image Layer becomes invisible:

The viewer.dims.ndim go up from 4 to 5.
The corner_pixels for Image Layer are changed, although we didn't modify the Image Layer.
Deleting the Labels layer restores the visibility of the Image Layer:

to be continued...

This particular problem for the multiscale arrays did not occur before commit
https://github.com/napari/napari/commit/9dd9fa6390ad4dfe9a08194de8c84e7e87bfeaa0
which introduced some changes how multiscale pyramids are handled.
However, I am not sure the underlying problem is in that commit, we just rely on corner_pixels there.
One of my  gut feelings is, that this has to do with .dims_displayed in the viewer object no longer being in sync with ._dims_displayed in the layer object, or that somewhere a layers ._dims_displayed is used where the viewers .dims_displayed should have been used.
The other gut feeling is that there is a problem around here: https://github.com/napari/napari/blob/315e2bf256f2e70fe96202beadeb8fb1458aca2b/napari/_qt/qt_viewer.py#L777

I would like to bump this. After trying to debug a similar problem, @jni pointed me to this issue.

Maybe @grlee77 can look into this too and evaluate the proposals above.

I think possibly this will require our refactor of slicing to do properly... BUT:
@VolkerH in https://github.com/aeisenbarth/napari-ome-zarr/pull/1 you wrote "a channel axis doesn't make sense for a labels image", but maybe we are wrong here. After all, I can easily imagine a different segmentation for the "cells/membranes" channel and one for the nuclei channel. ie a "channel axis" in labels might be just the way to group different segmentations of the same pixel/voxel space. All this to say, should we (napari) add a channel axis to labels and then your workaround would be to use that directly? It seems like OME supports this which means we should probably support it too? CC @joshmoore @tlambert03

We actually had the same discussion, i.e. that it could make sense to have a channel axis for label images to group segmentations corresponding to different structures of the same underlying data.
So yes, it could make sense to add a channel_axis to labels layer. Should I open a separate issue for this?
And while this would fix the specific problem we encountered when combining a 5D label array with 4D image arrays, I think the fundamental problem with incorrect corner_pixels computation in some circumstances with layers with different .ndims goes deeper.

Should I open a separate issue for this?

probably a good idea!

I think the fundamental problem with incorrect corner_pixels computation in some circumstances with layers with different .ndims goes deeper.

Yes indeed, fixing your issue and fixing the overall problem are not necessarily the same. :+1:

Regarding the channel_axis: I see there are proposals to drop it completely https://github.com/napari/napari/issues/3019, so not sure about opening an issue introducing it for labels.

We recently worked around the lack of channel_axis support for labels in https://github.com/ome/napari-ome-zarr/pull/16 by squeezing out the channel axis (since we assume labels data from OME-Zarr is the same shape as image data).
However, if you did have OME-Zarr labels data with size-C being >1 then I think the squeezing would fail and you wouldn't be able to open in napari.
We need to work around this in napari-ome-zarr, either with a channel_axis support, or splitting out channels.

We need to work around this in napari-ome-zarr, either with a channel_axis support, or splitting out channels.

@DragaDoncila do you have any thoughts on this?

@DragaDoncila do you have any thoughts on this?

I'm just catching up with some of this now. Couple of thoughts, not sure if they're helpful:

I think it makes perfect semantic sense for labels data to potentially contain more than one channel e.g. different segmentations based on different confidence levels or different models, or even segmenting for different things
I am in support of dropping the channel_axis option for add_* and providing a separate API which plugins (like ome-zarr) and users (through the GUI or otherwise) could optionally use to split out a particular axis into multiple layers. Yes it might be an additional click/method call, but I think unifying our layer data is more critical - I see this as a similar motivation to #3560
I'm not sure this is directly related to the corner_pixels issue, where my feelings are still the same - no matter what's going on with the dims_displayed, zoom, axes transposing etc., corner_pixels should give me top left and bottom right of whatever data is on my screen right now of the layer whose corner_pixels I asked for

@grlee77 Hi there, do you still plan to take this one on? If not I can unassign it, Thanks!

Please reassign
On Tue, May 3, 2022, 12:27 PM Ziyang Liu @.***> wrote:

@grlee77 https://github.com/grlee77 Hi there, do you still plan to take
this one on? If not I can unassign it, Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/napari/napari/issues/2487#issuecomment-1116294977,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRZ7PN723AD46ETBY4BNHTVIFHWVANCNFSM42A6N35A
.
You are receiving this because you were mentioned.Message ID:
@.***>

I ran into this problem too today, it doesn't work even for a simple 3D image.
The x and y coordinates return sensible values for the corner pixel coords, but the z-slice coordinate is always reported as zero, regardless of which slice the viewer is currently observing.
That's a problem. I would honestly prefer napari not report a value, as opposed to confidently reporting something entirely incorrect.
Reproducible example:
In [1]: import napari

In [2]: viewer = napari.Viewer()

In [3]: viewer.open_sample('napari', 'brain')
Out[3]: [<Image layer 'brain' at 0x106fd84c0>]

In [4]: viewer.dims.current_step
Out[4]: (3, 128, 128)

In [5]: viewer.dims.current_step = [7, 100, 100]

In [6]: viewer.camera.zoom = 6

In [7]: viewer.layers[0].corner_pixels
Out[7]:
array([[  0,  64,  37],
       [  0, 191, 218]])

# This result is clearly not correct
# since we are looking at the seventh image slice
# but napari shows zeroes in that column

authors: DragaDoncila GenevieveBuckley VolkerH grlee77 jni potating-potato sofroniewn will-moore

repo: napari/napari


text:
Add properties to shapes

Description
This PR adds properties to the Shapes layer and the ability to map display colors
to properties.
Type of change

[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

References
Closes #177
How has this been tested?

[ ] the test suite for my feature covers cases x, y, and z
[ ] all tests pass with my change

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works

@sofroniewn , I have added properties to the shapes layer (mappable colors still in progress) and in doing so I realized that the Shapes layer add() method has shape display properties as kwargs. This is pretty different from the Points layer, where the new points just get the current_*_color value. Should do the same in Shapes?
One one hand, it's good to be consistent. On the other hand, it seems like we wouldn't want to get ride of the shape_type kwarg, so at the point, maybe we might as well leave the others just to avoid making a breaking change to the API?

I have added properties to the shapes layer (mappable colors still in progress) and in doing so I realized that the Shapes layer add() method has shape display properties as kwargs. This is pretty different from the Points layer, where the new points just get the current_*_color value. Should do the same in Shapes?

I think we do want to bring Shapes in line with Points, though I now recognize we have quite a bit of duplicate code. I think that's ok for now, but I think we want to start taking the principles of #1343 and making small internal classes that can be reused not through inheritance but through attributes and so moving away from properties like edge_color_cycle and edge_colormap to edge_color.cycle and edge_color.map. Not something I'd do in this PR, but maybe something to think about. I could even imaging a single Rendering class which had all the coloring, opacity, rendering mode, etc inside of it.

@sofroniewn , I am sorry for the late response - it's been a rough week.
I agree that we need to revisit how we're organizing the code related to different features, especially with these annotation layers (shapes, points, vectors) which have a lot of different possible states. I think a strategy using mixins as you've described makes a lot of sense.
In the meantime, I have finished adding properties and colors that are mappable to those properties to the Shapes layer using the approach we have been using thus far. I need to do a bit of cleanup of the docs and see if we can round out the test coverage, but it would be great if you could take a look when you have time.

I think a strategy using mixins as you've described makes a lot of sense.

Here I wasn't thinking mixins, I was thinking more about have small classes and using composition instead of inheritance. See also comment here https://github.com/napari/napari/issues/1356#issuecomment-643786967.
I'll go through the rest of this promptly

Just noting windows failure is popping up a lot right now, independent of this PR, so will go ahead and merge anyway. Nice job here @kevinyamauchi!!

Thanks @sofroniewn for the review and @jni for getting this across the line!

authors: kevinyamauchi sofroniewn


text:
Added Flow Of Control

Solved #153
Added Flow Of Control file and updated README.md

Thanks for your contribution Ayush :)


text:
Problems starting Laghaim

Hi,
I am having some problems starting the global Laghaim: https://www.laghaimglobal.com/
The game works with both ddraw.dll and without, however with the lack of it the FPS drops a lot, it is practically impossible to play.
Using the dll find some bugs on the screen as in the video:
https://user-images.githubusercontent.com/83385054/117370494-d8c74000-ae9c-11eb-8b72-5609abd441cb.mp4
Log: 5588 17:44:59.973 Process path: C:\Laghaim Global\Game.exe
5588 17:44:59.973 Environment variable __COMPAT_LAYER = "RunAsAdmin Win7RTM ElevateCreateProcess Installer"
5588 17:44:59.973 Loading DDrawCompat statically from C:\Laghaim Global\DDRAW.dll
5588 17:44:59.978 DDrawCompat loaded successfully
5588 17:45:00.077 Installing display mode hooks
5588 17:45:00.078 Installing registry hooks
5588 17:45:00.078 Installing Direct3D driver hooks
5588 17:45:00.078 Installing Win32 hooks
5588 17:45:00.097 Hooking user mode display driver: C:\WINDOWS\System32\DriverStore\FileRepository\u0354236.inf_amd64_0a65476e7bdec57f\B354183\aticfx32.dll
5588 17:45:00.105 Dynamic vertex buffers are available
5588 17:45:00.105 Dynamic index buffers are available
5588 17:45:00.108 Checking source color key support: passed
5588 17:45:00.112 Incorrect z-buffer bit depth capabilities detected; changed from "16, 32" to "16, 24"
5588 17:45:00.114 Installing DirectDraw hooks
5588 17:45:00.115 Installing Direct3D hooks
5588 17:45:00.119 Installing GDI hooks
5588 17:45:00.124 Finished installing hooks
Tentei também utilizar o ddraw do compat porem encontro outro erro ao iniciar o jogo, relacionado ao dbgeng.dll

I fixed this issue around the end of June 2020, were you testing an older release? See here: https://github.com/narzoul/DDrawCompat/issues/71
The fix is still there in v0.3.0, hopefully it still works. I can't test it now, because it only happens with integrated AMD GPUs.
About the dbgeng.dll error, if you have a file called dbghelp.dll in the Laghaim install directory, try removing it.

Thanks, deleting the Dbghelp.dll file that was in the game directory it was possible to start, but in a matter of seconds it just closes on its own.
logs if necessary:
5588 17:44:59.973 Process path: C:\Laghaim Global\Game.exe
5588 17:44:59.973 Environment variable __COMPAT_LAYER = "RunAsAdmin Win7RTM ElevateCreateProcess Installer"
5588 17:44:59.973 Loading DDrawCompat statically from C:\Laghaim Global\DDRAW.dll
5588 17:44:59.978 DDrawCompat loaded successfully
5588 17:45:00.077 Installing display mode hooks
5588 17:45:00.078 Installing registry hooks
5588 17:45:00.078 Installing Direct3D driver hooks
5588 17:45:00.078 Installing Win32 hooks
5588 17:45:00.097 Hooking user mode display driver: C:\WINDOWS\System32\DriverStore\FileRepository\u0354236.inf_amd64_0a65476e7bdec57f\B354183\aticfx32.dll
5588 17:45:00.105 Dynamic vertex buffers are available
5588 17:45:00.105 Dynamic index buffers are available
5588 17:45:00.108 Checking source color key support: passed
5588 17:45:00.112 Incorrect z-buffer bit depth capabilities detected; changed from "16, 32" to "16, 24"
5588 17:45:00.114 Installing DirectDraw hooks
5588 17:45:00.115 Installing Direct3D hooks
5588 17:45:00.119 Installing GDI hooks
5588 17:45:00.124 Finished installing hooks

This game crashes very frequently while loading, even without DDrawCompat. I don't think it's related to DirectDraw, it must be an issue with the client. Try it a few more times, maybe you'll get lucky. Let me know if it never crashes without DDrawCompat.

Fixed in v0.3.1.

repo: narzoul/DDrawCompat


text:
Test for blank tile for interleaved cached MRFs is incorrect

Should test band by band with the correct NDV value.  Currently it tests all bands against the first band NDV, which in rare cases is incorrect.

See TODO: in mrf_band.cpp, use of isAllVal() in FetchBlock()
https://github.com/nasa-gibs/mrf/commit/b651af91507416ba0cc557cfeaf940a1c3402bdd

repo: nasa-gibs/mrf


text:
Images with a different crosstrack dimension length

There are a number of EMIT granules with a cross-track dimension of 1306 whereas all documentation seems to suggest that the cross track dimension should be fixed at 1242. Should these granules be handled differently?
['EMIT_L2A_RFL_001_20220810T101138_2222207_001',
 'EMIT_L2A_RFL_001_20220810T065438_2222205_046',
 'EMIT_L2A_RFL_001_20230224T055637_2305504_032',
 'EMIT_L2A_RFL_001_20231021T074842_2329405_010',
 'EMIT_L2A_RFL_001_20220810T065838_2222205_053',
 'EMIT_L2A_RFL_001_20220910T140554_2225309_011',
 'EMIT_L2A_RFL_001_20231016T070407_2328905_014',
 'EMIT_L2A_RFL_001_20230316T202635_2307513_004',
 'EMIT_L2A_RFL_001_20230429T081524_2311905_003',
 'EMIT_L2A_RFL_001_20220811T042658_2222303_011',
 'EMIT_L2A_RFL_001_20230216T120159_2304708_004',
 'EMIT_L2A_RFL_001_20230114T184508_2301412_015',
 'EMIT_L2A_RFL_001_20230601T185504_2315213_013',
 'EMIT_L2A_RFL_001_20231030T161937_2330311_010',
 'EMIT_L2A_RFL_001_20230204T053642_2303504_008',
 'EMIT_L2A_RFL_001_20230222T102534_2305307_018']

I looked at a few of these and they appear to have a cross-track dimension of 1242 to me. Are you opening the files fully or retrieving this from some metadata somewhere?

You are right. Apologies, error is in some other aspect of the processing chain. Will get back with more details.

authors: ebolch piyushrpt

repo: nasa/EMIT-Data-Resources


text:
checking return codes in CFE

For example, in CFE_SB_CreatePipe, it calls CFE_ES_GetAppID but does not confirm that it returned CFE_SUCCESS. Should it check that return value? (The AppID is zeroed by GetAppID.) This could create a situation where an app creates a lock (and somehow an error is generated) and the app could not later delete the pipe as it does not "own" it.
It would be good to scrub all CFE code, looking for calls to internal functions that do not verify the return.
Also, what should be the behavior when these calls do not return CFE_SUCCESS? Should they generate events (when EVS may not be functional) or syslog messages or OS_printf?

Imported from trac issue 195.  Created by cdknight on 2017-05-09T13:51:48, last modified: 2019-07-03T12:58:32

Trac comment by jphickey on 2018-05-14 14:30:21:
Agreed, we should scrub for unchecked return codes.  cppcheck has a ignoredReturnValue rule that might be useful to find and fix these types of instances.
We could combine this ticket with #149

Trac comment by jhageman on 2019-07-03 12:58:32:
Moved unfinished 6.7.0 tickets to next release

Related to #549

repo: nasa/cFE


text:
Add compile time assert that int size is 32 bit

Is your feature request related to a problem? Please describe.
Per discussion 2/26/2020 there's likely breakage in multiple places on a system where int != 32 bit (standard minimum is 16 bit)
Describe the solution you'd like
Along with #204, cFE not really designed to work on a system without char of 8 bit size and int of 32.  Enforce/warn on build.
Describe alternatives you've considered
Improve documentation?  Still nice to bail on compile for those who don't read documentation.
Additional context
#504, and many other places convert int32 to int or the unsigned equiv.
Requester Info
Jacob Hageman - NASA/GSFC

There really shouldn't be an issue running on a system where int is only 16 bits because the code uses int32 and uint32 precisely for this reason, except where interaction with the system library requires 'int'.
Many printf style calls do contain a force cast to int to be compatible with %d, but this could be changed to long and %ld instead.   There should never be an unintended truncation if casting a [u]int32 type to a long type, because  long is guaranteed to be at least 32 bits.
My preference is to still avoid asserting on items that aren't known to be problems.  In this case it is just that we haven't really tested it, not that it doesn't work.

Many printf style calls do contain a force cast to int to be compatible with %d, but this could be changed to long and %ld instead. There should never be an unintended truncation if casting a [u]int32 type to a long type, because long is guaranteed to be at least 32 bits.
My preference is to still avoid asserting on items that aren't known to be problems. In this case it is just that we haven't really tested it, not that it doesn't work.

You describe a known problem with truncation due to casting and then claim there isn't a known problem.  I don't follow this logic.  There is a known problem, lets add an assert.

Because the better solution is to use %ld/long and %lu/unsigned long casts, rather than asserting on something that isn't really a problem, and unnecessarily limiting the software for not a good reason.
I don't like compile time asserts, and especially so when they aren't really a fundamental problem.

I agree there are better solutions, but at such a low priority I don't see it getting resolved soon.  It seems prudent to notify a user of the current issue on such a system.  Maybe @acudmore or @jwilmot could weigh in.  I'd prefer a check along with a response that systems with int of size < 32 bits could encounter truncation due to type casting of 32 bit types to int.  I'd rather be obvious about the current issue than not-so-obvious issues if used on this sort of system.  A user could always remove the assert if they so chose.
Lacking the obvious assert, users could head down a rat hole or run in to not-so-obvious bugs.  I'm not following why this should be the preferred approach.

Yes I agree its low priority, but I'd rather not forcibly break the build on someone just because we haven't explicitly tested the software using their configuration, especially when there is a real fix for the known issue.
The truncation issue is a minor one as it only affects printfs, and only if the value actually exceeds int at runtime.  The code might still run OK otherwise.  Hardly worth a hard-stop on preventing someone from even building the code in that config.
Compile-time asserts should be reserved for items which are known to be truly incompatible with the architecture.  We cannot assert against every system/config variation we haven't tested or for which there might be a potential issue or an open bug.
This seems like more appropriate for release notes and documentation, not a compile-time assert.

authors: jphickey skliper


text:
Implement fixture method in spec runner

Most of the specs that use this method still fail for different reasons. Document those reasons with a NATFIXME comment.

Even though there are not that many occurrences of fixture in the specs in Natalie, there are some specs that haven't been imported yet that depend on them (for example core/argf/argv_spec.rb). I'm really curious as to what the effect of this change will be on the specs graph on the Natalie homepage.

repo: natalie-lang/natalie


text:
Cydia

http://scratch.mit.edu/projects/64192580/
http://phosphorus.github.io/#64192580
Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12F70 Safari/600.1.4

You don't need to file four duplicate bugs.

authors: marttharomero nathan

repo: nathan/phosphorus