Allow additional connector to be specified via Custom Resource

Additional connectors can now be specified via:
libraries:
  - url: http://www.google.com
    filename: notreallyalibrary.jar

The string can be up to 2MB in theory. If we assume typical URL of 60 chars, and filename of 20 chars plus && seperator that's a lot of libraries. For now the arbitary limit is set to 253, though these limits have not yet been tested.


WIP: Add Dockerfile

This is a partial PR of #12.
This is the very first image of Jarbas, the only goal here is deploy the code. Probably I'll improve this image as a code-image only.
Currently I'm working on a docker-compose.yml file to work with this image.

Coverage remained the same at 69.454% when pulling d3a43fa35459750e1f5208fe49d9fb3e1793c576 on pedrommone:add-docker-image into 76b627134cbd6b5411df12543f1e99b73af56c25 on datasciencebr:master.

@cuducos I need your help here! :)
In order to generate secured tokens for Docker Hub, I need you to sign up the org and generate the credentials for me, after that you need encrypt them with this Travis feature

Coverage remained the same at 69.454% when pulling d3a43fa35459750e1f5208fe49d9fb3e1793c576 on pedrommone:add-docker-image into 76b627134cbd6b5411df12543f1e99b73af56c25 on datasciencebr:master.

Coverage remained the same at 69.454% when pulling 879c4f92258e1c39d81ae442612e983b5f85a1dd on pedrommone:add-docker-image into 76b627134cbd6b5411df12543f1e99b73af56c25 on datasciencebr:master.

@pedrommone I added you as a contributor to hub.docker.com/u/datasciencebr
Could you generate the keys yet?

@cuducos I saw you request, I'll try to code more today.

Just some feedback. I've faced some issues:

In order to make it functional, I need to build an container with NodeJS and Python and this is not cool.
For fully CI integration, we'll need to move to another CI SaaS that provide pipelines.

How to run what I've done?
Clone this branch and run docker build -t jarbas . then run docker-compose up. It will provision all containers and will fail into nodejs requirement step.

In order to make it functional, I need to build an container with NodeJS and Python and this is not cool.

Actually this is a good thing. We can create another container to run NodeJS and this is the first step to address Issue #18 (splitting front-end and backend cc @leomeloxp).
What I can do is to some edit the repo in a separate branch and send a PR to this branch here. I make the Django and the Elm commands independent of each other — i.e. The elm-make command will be ran outside Django (e.g. npm run build instead of python manage.py assets build).
The only link between both worlds will be that the output file will be saved directly into the staticfiles/ (where Django HTML template will look for app.js). Surely later we can use nginx to have NodeJs creating the HTML too, but I'd say this is mostly a matter of Issue #18 (we're gonna address it later anyway).
Does that help?

For fully CI integration, we'll need to move to another CI SaaS that provide pipelines.

I have no idea about this limitation, but I don't mind leaving Travis either. Any ideas? cc @luiz-simples @vitallan @gwmoura @ayr-ton

Clone this branch and run docker build -t jarbas . then run docker-compose up. It will provision all containers and will fail into nodejs requirement step.

Does the separation I mentioned in my first point here helps? IMHO it worth it to have a working local version before depending on a CI tool. So if we fix the NodeJS thing the only pending issue will be the CI, am I right?

Does that help?

Yep. it helps a lot.

Does the separation I mentioned in my first point here helps? IMHO it worth it to have a working local version before depending on a CI tool. So if we fix the NodeJS thing the only pending issue will be the CI, am I right?

Yep, we'll have some work to be done here. :)

Done in extract-nodejs. No Django command depends on NodeJS anymore.

app.js is generated by npm run assets (not by python manage.py assets build)
ceapdatasets.html loads the CSS from a CDN (not from node_modules/)

Is there anything I might have left behind?
I felt that if I isolate it more I'd be splitting the repo and I'd like to do this with Docker linking front-end and back end. Otherwise I don't know how to locally have a static front-end (generated by NodeJS) at root (e.g. http://localhost:8000/) and a Django app at /api/ (e.g. http://localhost:8000/api/) serving it.

For fully CI integration, we'll need to move to another CI SaaS that provide pipelines.

@cuducos we can create our simple pipeline on Travis CI like: test > build > push to docker hub > deploy container on server. One script for each step, the big problem is the deploy on the server.
Today I am using tsuru.io, but as we need deploy one app, I think better study docker swarm (a docker orchestration tool) or use some service of container deploy.

e a static front-end (generated by NodeJS) at root (e.g. http://localhost:8000/) and a Django app at /api/ (e.g. http://localhost:8000/api/) serving it

@cuducos  about this, we can create on the project two folders and use docker-compose to manage this environments:
web/
   |__ Dockerfile
   |__ files to frontend app
api/
   |__ Dockerfile
   |__ files to back-end app
docker-compose.yml

# docker-compose.yml content some like this
version: '2'
services:
  db:
   images: postgresql
  web:
    build: ./web
    ...
  api:
    build: ./api
    ...

@gwmoura the main problem with this approach is the Travis itself, its made for Continuous Integration, not Continuous Delivery. We can't build a pipeline with Travis.
I'm sorry for holding this MR for too long, I've been busy with work and college (I need to finish my thesis).

Closing this PR since we get a working docker-compose.yml on master branch 🎉


Auroraboot tests are faillig

Since this commit https://github.com/kairos-io/AuroraBoot/commit/d974ed4583e326ab3f92e37a85cbd931463be055
(not sure if related) tests have been failing in AuroraBoot
https://github.com/kairos-io/AuroraBoot/actions/runs/6407845555/job/17395540022

Fixed here: https://github.com/kairos-io/AuroraBoot/pull/45


Add BMS Support

Include as many relevant documents/sites as possible to help me decipher the file format
https://fileformats.fandom.com/wiki/Be-Music_Script
https://hitkey.nekokan.dyndns.info/cmds.htm

obj: slash bms dls http://slash24th.web.fc2.com/nanidosp.htm

Due to lack of interest in keysounding in competitive VSRG scene in general, keysound conversion will not be supported/negligible.

Writing will also not be supported unless there's high demand.

Seems like a couple of things break the BMSMap.readFile method:

Non-integer BPM (attempt at bin -> int conversion fails)
Reference to a sample that has not been defined in the #WAV header (maybe could be fixed with an option to ignore all samples and just read the notes)

I attach an example .bme that includes both. Starting BPM is defined as #BPM 175.89, and sample ZZ is called in many measures, starting at #03214 for example - I think BMS emulators just ignore the sample and treat it as a sound-less note.

Changed BMS to cast BPM as floats (didn't know they could use floats)
Allow conditional gets (sample will be None if sample isn't found)

fixed in branch 0.0.20
Will close this, feel free to open another issue, doing a bit of house keeping on old issues


41 engines have detected this file as a Trojan

Virus Total says it's a Trojan. 41/69 https://www.virustotal.com/gui/file/4f7f28e5fc1aa5a89e942b3f223f6442668510f6051319aaaa9632d94ecee6e4/detection
Isn't that a lot for a false positive?

hm, yeah, there all comming up as "Gen:Variant.MSILHeracles"
2 possiblities:

maybe MSIL Heracles is a file infecting trojan and its on my pc, thus it infects the file whenever i compile it with itself.

my code is similar enough to Gen:Variant.MSILHeracles make AV think that it is that-
possibly we use the same code copied off stackoverflow >_<

renamed some shit almost all the detections went away- av is weird, lol
i dont understand why but, resolved!
https://www.virustotal.com/gui/file/e42ed7cd4aa13bf2f897046b5217b75f92cfa20e822657c40bdd93840a7485db/detection


WEBPAGE: Data visualization

count over time
male vs. female
percent tagged
number of each tags
percent wounded
count distressed over time
high frequency sectors on the island (pie chart?)

https://blog.logrocket.com/top-5-react-chart-libraries/

Victory

https://formidable.com/open-source/victory/docs/
https://formidable.com/open-source/victory/docs/victory-line/

recharts

https://github.com/recharts/recharts

React-vis

https://uber.github.io/react-vis/examples/showcases/misc
https://github.com/uber/react-vis/blob/premodern/showcase/misc/time-chart.js

chart.js

https://www.chartjs.org/docs/latest/charts/line.html


XD-2539: Fix XD on Windows

JIRA: https://jira.spring.io/browse/XD-2539
ResourcePatternScanningOptionHandlers.SingleNodeDataTransportOptionHandler.resolveMessageBusPath()
results in a regular expression pattern containing invalid escapes (\) on Windows platforms.
Replace back-slashes with forward slashes.
Tested on Windows with xd-singlenode.

LGTM; merging

LGTM; merging

merged as https://github.com/spring-projects/spring-xd/commit/386762afd49f5b1173190dcbfda4c17bafda412f

merged as https://github.com/spring-projects/spring-xd/commit/386762afd49f5b1173190dcbfda4c17bafda412f


Add tip for playing custom sound files with Xcode breakpoints

Add a tip for sound file playback with Xcode breakpoints. This includes a link to an example sound file collection hosted on GitHub, and the original article. Blog post is a bit dated but this is a technique I still use continually, and the custom sound files linked are usually a better choice than the default system alert sounds.

thanks @matthewreagan! 💯


arch: arm: mpu: Make XN bit conditional on CONFIG_XIP for RAM region

Make the execute never (XN) bit conditonal on CONFIG_XIP for the RAM MPU region attribute. This is required because when CONFIG_XIP is not set, the entire image will be linked into SRAM. In this case, SRAM must be executable.
The alternative to this would be to configure two MPU regions within the SRAM region (one with the XN bit set, and the other with it clear). However, trying to use linker symbols in order to initialize the ARM MPU regions needed for this setup results in the build failing with the error: initializer element is not computable at load time.
I'm open to any ideas for a better approach for how to handle CONFIG_XIP=n on ARM Cortex M platforms, since currently the MPU must be disabled to run an image built with CONFIG_XIP=n on this architecture.

@carlocaione Would be interested in any feedback you have here- the benefit I see to enabling CONFIG_XIP=n to function on Cortex M parts (versus defining two regions within the SRAM address space, and using one as "flash"), is that the linker can more efficiently utilize the SRAM space, since no padding is needed between the text and data sections

This looks totally reasonable to me. I'm kinda confused why cortex-R and NXP are instead using CONFIG_MPU_ALLOW_FLASH_WRITE to control the X bit of the SRAM MPU region.

This is reasonable. I am not clear with what NXP is doing, but in terms of FVP, unfortunately, there is no XIP support for R.

This looks good to me, but can you maybe add a comment here noting why this is being added, as a future signpost? Something like:

Sure, I've added a comment explaining why we do not set the XN bit when CONFIG_XIP=n.


Valid grasps not displayed in scene generation

Hey,
I have an issue with the scene generation. Everything seems to work fine, except the valid grasps are not displayed when generating a scene(--show_grasps is set). I am working with Ubuntu 20.04 and conda environment. Do you have an idea why it is not working? Thanks!

Hi, this was tested under 18.04. Is there any output/error message that you get when executing the code?
Another possibility that comes to mind is that there might be no valid grasps in the particular scene you are looking at (if all of them are in collision). You can test this by e.g. adding print(len(gripper_markers)) in line https://github.com/NVlabs/acronym/blob/main/scripts/acronym_generate_scene.py#L115 and check that the output is greater than zero.

Hello,
thank you for you fast reply. So it works under Ubuntu20.04, too. I just had to uncomment or exit the first window which appears containing only the objects in the scene.

So I guess it is normal, that not every possible, collision-free grasp is displayed?
Again, thanks!

Yes, not every grasps is shown, the visualization will become very slow, but you can increase the parameter --num_grasps_per_object, see here:
https://github.com/NVlabs/acronym/blob/cd20a7cc5b5b1f3f5d9488be6ff8698651d96590/scripts/acronym_generate_scene.py#L61


[RFC] Add makeStyles back?

Summary
Implement a makeStyles API back powered by emotion.
Basic example
import React from 'react';
import { makeStyles } from '@material-ui/core/styles';

const useStyles = makeStyles({
  root: {
    backgroundColor: 'red',
    color: props => props.color,
  },
});

export default function MyComponent(props) {
  const classes = useStyles(props);
  return
;
}

Motivation
We currently plan to remove all support of the @material-ui/styles package in v6. This direction creates two main problems.
v4 to v5 migration
The migration from makeStyles to the styled and sx API is expensive and very hard to automate. It's unlikely that most projects will have the bandwidth to migrate. This leaves these projects with a limited number of options, none are great.

Spend hours and hours to migrate, very costly.
Migrate to react-jss and get used to the difference in the edge cases (e.g. different configuration/options). Developers will have to load emotion & JSS in their bundle.
Stay on @material-ui/styles until the end of the rope. They won't get access to bug fixes as they would do in 1. and 2. (react-jss is no very active, so maybe mostly in 1.) Developers will have to load emotion & JSS in their bundle.

DX
Based on https://github.com/mui-org/material-ui/issues/16947#issuecomment-851077596, we started to get interesting feedback on why makeStyles is great. By order of preference, I would personally rank them: 1. sx 2. makeStyles 3. styled(). The main argument we got was the capability to have multiple class names declared side by side. This constraint yields a couple of interesting properties:

It matches the work habit that some developers have. It's especially relevant with a background in SASS and CSS modules. You get a separation of concerns: the style usually at the top of the file, and the rest (JS + HTML) at the bottom.
You get a classes object of class names you can forward to any component, portaled element included

Detailed design
There is a proof of concept done by @garronej in https://github.com/garronej/tss-react. However, I'm not sure that we can leverage the approach (@emotion/css). We might want to rely on @emotion/react using the source of ClassName as inspiration.
Drawbacks
I can see a couple of classes of drawback:

Fragmentation in the community. Providing two ways to solve the same problem.
What about styled-components users? Emotion seems to be the only styling engine. To keep a close eye on this graph.
What if we want to use a different styled engine by default in the future?
Opportunity cost. The time we spend creating this new module is time not spent somewhere else.

Alternatives
Do nothing.
Adoption strategy
We don't want it to be significantly adopted, just enough by the teams that have a real need for it.
How we teach this
We implement the same API as in v4, we document the differences regarding global configuration in the migration guide. For instance, they won't be a class name generator anymore.
Unresolved questions

[ ] What's the real long-term value of working on this?
[ ] Is this really technically possible?

As far as I know, @layershifter was also working on a similar utility for Fluent-UI, tagging him to get his opinion on the matter. My biggest worry is that it would be the first utility that would be emotion's only API, which will break our story of supporting two styling engines. Not sure how big the cost would be for building and supporting the API. On the other hand, I understand the pain of the migration, and even more importantly I understand why developers may prefer this API.
Things we need to consider:

SSR needs to work still
order of injection (need to make sure it can be used for customizing components created with the styled() util)
how do we document that it is emotion exclusive API?
else?

Thanks for considering this. I have almost forced to cancel plan of v5 migration on our app coz there are loads of effort involved to replace makeStyles with styled or sx.

replace makeStyles with styled or sx

@thecodejack option 1 is not the only option, 2 and 3 are also valid. You could wait v6 to migrate the makeStyles.

Add makeStyles back will be more compatible with other non-material plugin, such as react-image-gallery use additionalClass to customize Its widget, If we lose makeStyles, we should tweak all this-kind widget in theme.

I am also hugely in favor of adding back makeStyles. My team and I were worried that we would be permanently locked into v4 due to the lack of makeStyles support - we've created an entire component library wrapping material components, and all of it uses the makeStyles hook.
It would be a massive bonus if this update/migration to makeStyles also fixed the known performance issues of passing props into makeStyles - it's something we've been trying to avoid, but on a large team, knowledge share is hard and people keep doing it.

Yes, we even are blocked on 5.0.0-alpha.34 cannot upgrade to 5.0.0-alpha.35 because it moves makeStyles to another package and we have to rewrite almost every file in our project. (And even worse, makeStyles in 5.0.0-alpha.35 have an empty Theme so we need more work to migrate)

To upgrade to v5, we need to choose between https://github.com/garronej/tss-react (already available today) and this RFC (not implemented yet).
If this RFC is accepted but unfortunately implemented too late, some teams might already migrate to tss-react and not be able to migrate back to the @material-ui solution.
Hope the team can decide this topic early (implement makeStyles in emotion, or encourage people to migrate to tss-react) so we don't have to bet on choosing either solution. Thanks!

I am open to work with you on this. If you'd like @oliviertassinari, we can discuss what would be the requirements that tss-react should meet to be officially recommended by you guys.

I am open to work with you on this. If you'd like @oliviertassinari, we can discuss what would be the requirements that tss-react should meet to be officially recommended by you guys.

It's interesting, it's the first time I am seeing it. Let me test out and see what you've got already and I could come back to you next week.

It’s important to keep makestyles feature there because some projects only use material ui as a component library instead of the css solution. For example, people only use the textfields, checkbox etc, but control the page layout by css-grid instead of Mui grid and control padding using raw css instead of Box. Thus the team would have more flexibility to access the latest css technology instead of been only relying on what mui supports.
Also the tss package looks pretty cool and looking forward something could be built based on it.

I am open to work with you on this. If you'd like, we can discuss what would be the requirements that tss-react should meet to be officially recommended by you guys.

@garronej I have open https://github.com/garronej/tss-react/issu so that we can start the discussion :)

Hope your team will add makeStyles back soon. Currently, I had to write my own makeStyles function. :cry:
import { useMemo } from "react";
import { Theme, useTheme } from "@material-ui/core/styles";
import { CSSObject } from "@emotion/styled/types/base";
import createCache from "@emotion/cache";
import { css } from "@emotion/react";
import { insertStyles } from "@emotion/utils";

const cache = createCache({ key: "prefix", prepend: true });
cache.compat = true;

export const makeStyles = <Key extends string>(
  generateStyles: (theme: Theme) => Record<Key, CSSObject>
) => {
  return () => {
    const theme = useTheme();
    const classes = useMemo(() => {
      const styles = generateStyles(theme);
      return Object.keys(styles).reduce((s, key) => {
        const serialized = css(styles[key as Key]);
        s[key as Key] = `${cache.key}-${serialized.name}`;
        insertStyles(cache, serialized, false);
        return s;
      }, {} as Record<Key, string>);
    }, [theme]);

    return classes;
  };
};

Hope your team will add makeStyles back soon. I had to write my own makeStyles function. 😢
import { useMemo } from "react";
import { Theme, useTheme } from "@material-ui/core/styles";
import { CSSObject } from "@emotion/styled/types/base";
import createCache from "@emotion/cache";
import { css } from "@emotion/react";
import { insertStyles } from "@emotion/utils";

const cache = createCache({ key: "prefix", prepend: true });
cache.compat = true;

export const makeStyles = <Key extends string>(
  generateStyles: (theme: Theme) => Record<Key, CSSObject>
) => {
  return () => {
    const theme = useTheme();
    const classes = useMemo(() => {
      const styles = generateStyles(theme);
      return Object.keys(styles).reduce((s, key) => {
        const serialized = css(styles[key as Key]);
        s[key as Key] = `${cache.key}-${serialized.name}`;
        insertStyles(cache, serialized, false);
        return s;
      }, {} as Record<Key, string>);
    }, [theme]);

    return classes;
  };
};

Thanks, this is actually helpful. I will implement this approach in tss-react it will enable to rely on @emotion/react that is included in @material-ui instead of @emotion/css that isn't.
ref
Thanks for sharing!

@garronej I read emotion source code and copied it from this https://github.com/emotion-js/emotion/blob/dcc72d06ace804330fd285a76c8574f3a89001f9/packages/css/src/create-instance.js#L78.
I think it will give you some ideas. 😄

Thx @nguyenvanthanh97

@garronej some more ideas here https://github.com/emotion-js/emotion/issues/1853#issuecomment-623349622 and here https://github.com/mnajdova/material-ui/blob/feat/makeStyles-emotion-poc/docs/pages/index.tsx

Hi @mnajdova ,
I am happy to announce that tss-react have made a big leap forward this weekend.
What's new:

Server Side Rendering support, no 0-config because it's impossible and because it's discouraged by @oliviertassinari anyway.
Embrace the more familiar naming scheme makeStyles -> useStyles -> classes.
Minimal impact on the bundle size when used alongside material-ui v5. tss-react is now built on top of @emotion/react instead of @emotion/css.
API improvements:

useStyles() with or without callback.
useStyles(), alongside classes also return css and cx as defined in @emotions/css.

New GIF:

You can give the new version a try in the test apps.
Hopes it meets your needs. Next up is the implementation of a composition mechanism

@garronej I was testing the latest changes and could not spot any issues 🚀  I would say that we can recommend in the Migration guide for people that want to still use the makeStyles API with emotion, to migrate to tss-react. This is a great example of a community contribution :)
Having this said, we are not going to add the makeStyles API back as part of Material-UI, basically because we moved to the styled() and sx API as a recommended approach for styling.

Some additional comments regarding the implementation in tss-react (@garronej please correct me if I am wrong somewhere):

There is an initial step required for setting up the makeStyles utility (using the useTheme coming from @material-ui/core/styles)
The API is slightly different:

-const useStyles = makeStyles(theme => ({
+const { useStyles } = makeStyles()(theme => ({
  button: {
    color: theme.limeGreen,
  }
}));

There is ready to use template for setting up SSR (thanks @garronej for setting this up, you were better than me :))
The previous $-syntax of JSS is not working (expected, as we are using emotion now, but I think it's worth mentioning)
The API is not supported for those who use styled-engine as a styling engine (unless the community comes up with an implementation for it as well :))

@garronej I was testing the latest changes and could not spot any issues 🚀 I would say that we can recommend in the Migration guide for people that want to still use the makeStyles API with emotion, to migrate to tss-react. This is a great example of a community contribution :)

Thank you for the kind words.  I am very glad we successfully collaborated on this 😊

Some additional comments regarding the implementation in tss-react (@garronej please correct me if I am wrong somewhere):

You got everything right. I just have a few comments.

The previous $-syntax of JSS is not working (expected, as we are using emotion now, but I think it's worth mentioning)

I will not re-implement this feature because it can't be implemented in a type safe way but I will implement an other mechanisms for composition

The API is not supported for those who use styled-engine as a styling engine (unless the community comes up with an implementation for it as well :))

No, it's not, well of course it will work but they will end up with both styled-component and @emotion/react in the bundle.
Let me know if you need anything,
Best

Having this said, we are not going to add the makeStyles API back as part of Material-UI

@mnajdova I'm closing then. Thanks to everyone for participating.
Since I have opened the issue, I'm going to bring my perspective on why we are not moving forward. In this RFC, I have drawn two value propositions:

Migration from v4 to v5. Not providing the makeStyles API back means that we will have a fragmentation of the community for a longer period between v4 and v5 (the community will move more slowly to v5). However, because we don't expose makeStyles, it also means that, eventually, we will have less fragmentation between the different APIs. The latter has more value, considering we are playing in the long run (5 years).
The DX of makeStyles is superior to styled(). This is a matter of taste, it's going to depend on who you ask. I'm among the people that think that it's true. Now, you might ask. But if it's true, why did styled components win over jss? I would personally analyze by the lake of the CSS template string syntax in JSS. We would still rather expose fewer APIs.

For those that prefer working in the makeStyles why the styled and sx API allows them to very similar outcomes. This example:
import clsx from 'clsx';
import { makeStyles } from '@material-ui/styles';

const useStyles = makeStyles((theme) => ({
  grid: {
    display: 'grid',
    gridGap: theme.spacing(2),
    gridTemplateColumns: '1fr 1fr',
    [theme.breakpoints.down('md')]: {
      gridTemplateColumns: '1fr',
      gridGap: theme.spacing(1),
    },
  },
  column: {
    gridTemplateColumns: '1fr',
  },
  margin: {
    margin: theme.spacing(1),
  },
}));

const Example = () => {
  const classes = useStyles();
  return (

{/* ... */}

{/* ... */}

  );
};

Can be written with styled():
import clsx from 'clsx';
import { styled } from '@material-ui/system';

const Root = styled(({ theme }) => ({
  '&, & .grid': {
    display: 'grid',
    gridGap: theme.spacing(2),
    gridTemplateColumns: '1fr 1fr',
    [theme.breakpoints.down('md')]: {
      gridTemplateColumns: '1fr',
      gridGap: theme.spacing(1),
    },
  },
  '&, & .margin': {
    margin: theme.spacing(1),
  },
  '& .column': {
    gridTemplateColumns: '1fr',
  },
}));

const Example = () => {
  return (
    <Root className={clsx('grid', 'margin')}>

{/* ... */}

{/* ... */}

    </Root>
  );
};

@siriwatknp has a WIP codemod to automate this type of migration: #27292.
or sx:
import clsx from 'clsx';
import { mui } from '@material-ui/system';

const styles = {
  grid: {
    display: 'grid',
    gridGap: {
      xs: 2,
      md: 1,
    },
    gridTemplateColumns: {
      xs: '1fr',
      md: '1fr 1fr',
    },
  },
  margin: {
    margin: 1,
  },
  column: {
    gridTemplateColumns: '1fr',
  },
};

const Example = () => {
  return (
    <mui.div sx={{ ...grid, ...margin }}>
      <mui.div sx={{ ...grid, ...column }}>{/* ... */}</mui.div>
      <mui.div sx={{ ...grid, ...column }}>{/* ... */}</mui.div>
    </mui.div>
  );
};

Can be written with styled():

Your example isn't type checked so if there is a typo, the type system cannot catch it for me.
Ant btw will tss-react recommended now?

Ant btw will tss-react recommended now?

yes

@oliviertassinari that example doesn't work, and also, isn't the same thing:

It doesn't include the component (it would have to be styled('div')(({ theme }) =>, right?) - this is pretty annoying, as you write your markup as a string, rather than let it be jsx markup (a
). Let's also consider the case where this top-level root component is dynamic (like the Typography component), it simply wouldn't work at all.

It's not typesafe! Material-ui itself is written in typescript, so, this doesn't seem like an unreasonable request.

No one like breaking changes and I'm sure this was a difficult decision, but I can't help but feel like the migration path and drawbacks have not been considered very thoroughly.

@sarink thank for pointing out. Here is a working example:
https://codesandbox.io/s/kind-resonance-ldo25?file=/src/Demo.tsx

this is pretty annoying, as you write your markup as a string, rather than let it be jsx markup (a

This is for the host elements. The components are used as:
const Root = styled(Typography)({...styles});

For dynamic element rendered, you can use the as prop, available in both emotion & styled-components:
<Root as={YourCustomComponent}></Root>

@mnajdova what about typesafety?

Also came here hoping the answer was "we're going to add it back", and disappointed that that's not the case. (Same reasons as everyone else: styled is ugly, verbose and fragments style definitions; losing type safety is a step backwards.)
I appreciate the efforts of react-tss but I want something that's really as close to the API of makeStyles of possible, without worrying about access to css, cx etc.
So, building on the work of  @nguyenvanthanh97, I added in simple dynamic style support. It still doesn't have "$" support, might have bugs, but appears to be type-safe and successfully support all the things I use:
import createCache from '@emotion/cache'
import { serializeStyles } from '@emotion/serialize'
import { Interpolation } from '@emotion/styled/types/base'
import { insertStyles } from '@emotion/utils'
import { Theme, useTheme } from '@material-ui/core/styles'
import { useMemo } from 'react'

const createEmotionCache = () => {
  return createCache({ key: 'css', prepend: true })
}

const cache = createEmotionCache()

const makeStyles = <Key extends string, Props extends {} = {}>(
  generateStyles: (theme: Theme) => Record<Key, Interpolation<Props>>
) => {
  return (props?: Props) => {
    const theme = useTheme()
    const classes = useMemo(() => {
      const styles = generateStyles(theme)
      return Object.keys(styles).reduce((s, key) => {
        const serialized = serializeStyles<Props>([styles[key as Key]], cache.registered, props)
        s[key as Key] = `${cache.key}-${serialized.name}`
        insertStyles(cache, serialized, false)
        return s
      }, {} as Record<Key, string>)
    }, [theme, props])

    return classes
  }
}

const createStyles = <Key extends string, Props = {}>(
  styles: Record<Key, Interpolation<Props>>
): Record<Key, Interpolation<Props>> => styles

export { createEmotionCache, createStyles, makeStyles }

Use it like this:
type DynamicStyleProps = {
  color: string
}

const useStyles = makeStyles(({ palette }: Theme) =>
  createStyles<string, DynamicStyleProps>({
    badge: ({ color }) => ({
      backgroundColor: color,
      color,
      boxShadow: `0 0 0 2px ${palette.background.paper}`,
    }),
  })
)

const MyComponent = ({ color }: Props) => {
  const { badge } = useStyles({ color })
}

Also came here hoping the answer was "we're going to add it back", and disappointed that that's not the case. (Same reasons as everyone else: styled is ugly, verbose and fragments style definitions; losing type safety is a step backwards.)
I appreciate the efforts of react-tss but I want something that's really as close to the API of makeStyles of possible, without worrying about access to css, cx etc.

Again, we don’t plan to add the API as part of the library and we are recommending using tss-react in the migration guide for the people that want to use the same API.
Regarding tss-react, we’ve also tested server side rendering to ensure that it works (I don’t think it works with the codesnipet you shared). It is type safe as well, as last when I saw there was a PR for adding an API as a replacement for the $ syntax. @garronej can give more info on this.

Hi @majelbstoat,
In fact, you don't have to worry about cx and css if you're not gonna use them.
The only API difference between TSS's makeStyle and the OG makeStyle is that you have to deconstruct classes.
-const classes = useStyles();
+const { classes } = useStyles();

As @mnajdova mentioned, in TSS much effort have been put into making SSR work and to feature support of custom emotion cache. If you choses to go with your custom implementation and if you need SSR remember that it won't be trivial to get it working.
Regarding the $ syntax, I choose not to implement it because it isn't type-safe. We tried some things with @jsakas to come up with an alternative and finally settled on this API.
If you have a specific request regarding tss-react feel free to open an issue. I am open to API changes until mui v5 is officially released.

Our project has 100% migrated to tss-react and feeling good.

If you have a specific request regarding tss-react feel free to open an issue. I am open to API changes until mui v5 is officially released.

Could you implement withStyles in tss-react too? It's convenient when just want to overwrite the style of a Mui Component.
const StyledLinearProgress = withStyles(LinearProgress)({
    root: {},
    // other LinearProgressProps.classes properties...
})

@Jack-Works I opened an issue for withStyles.

Again, we don’t plan to add the API as part of the library and we are recommending using tss-react in the migration guide for the people that want to use the same API.

Yep, no worries, I understand it's not coming back. I think it's a bad call which makes styling in Material UI harder to reason about, but v5 is also a major version jump and y'all considered it carefully, so no hard feelings, and I wasn't trying to re-legislate the decision. I just offered this up for folks who are in the same boat, of which there seem to be a few.

Regarding tss-react, we’ve also tested server side rendering to ensure that it works (I don’t think it works with the codesnipet you shared). It is type safe as well, as last when I saw there was a PR for adding an API as a replacement for the $ syntax. @garronej can give more info on this.

Oh yeah, thanks for the pointing that out. I had to add in const cache = useEmotionCache() with the neat unsafe trick from react-tss (I really do appreciate the effort!), but with that, it all works nicely.

The only API difference between TSS's makeStyle and the OG makeStyle is that you have to deconstruct classes.

TSS's makeStyles is also invoked differently, and when I dug through the code to understand how it worked, I got lost in a maze of factories. I know these seem like minor quibbles, but for a large legacy codebase it's just easier to have something that's directly compatible and easy to understand.

@sarink Regarding typesafe, I have updated https://github.com/mui-org/material-ui/issues/26571#issuecomment-881925962 to work better. If you want to avoid the boilerplate, https://github.com/garronej/tss-react is a great option.

I'm newbie at material UI. The question is: how we can create reusable classes using sx syntax without makeStyles?
The only decision I came up with - creating object with styles in parent component and import it anywhere I need, but I don't think that's a perfect solution?
Can someone help?


master

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@c5acf73). Click here to learn what that means.
The diff coverage is 47.4%.

@@            Coverage Diff            @@
##             master      #38   +/-   ##
=========================================
  Coverage          ?   17.23%
=========================================
  Files             ?       81
  Lines             ?     2460
  Branches          ?      135
=========================================
  Hits              ?      424
  Misses            ?     2021
  Partials          ?       15

Impacted Files
Coverage Δ

.../lab/varis/adapter/viewholder/BuildViewHolder.java
0% <0%> (ø)

...hmelenko/lab/varis/converter/BuildStateHelper.java
0% <0%> (ø)

...lenko/lab/varis/activity/BuildDetailsActivity.java
0% <0%> (ø)

...melenko/lab/varis/dagger/module/NetworkModule.java
0% <0%> (ø)

...com/khmelenko/lab/varis/log/TravisCommandLeaf.java
0% <0%> (ø)

...enko/lab/varis/network/retrofit/raw/RawClient.java
0% <0%> (ø)

...m/khmelenko/lab/varis/fragment/RawLogFragment.java
0% <0%> (ø)

...ko/lab/varis/presenter/BuildsDetailsPresenter.java
86.02% <100%> (ø)

...n/java/com/khmelenko/lab/varis/log/LogsParser.java
2.63% <2.63%> (ø)

...in/java/com/khmelenko/lab/varis/log/AnsiCodes.java
40% <40%> (ø)

... and 4 more

Continue to review full report at Codecov.

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


can not get filename from head method

in version of 1.4.1, I can get filename by the http method header, now I have upgrade to version 1.7.7 and I lost the way to get it. How can I get the filename in version 1.7.7?

Please add some details on how to reproduce.


WCAG 2.0 AA

It would be nice if the software added the proper aria roles for error messages and requirements. If this issue is accepted I may consider making a pull request for this.

PR’s are always welcome.


RM-1554 Updated debian 10 image tag for OSRP 5.3.0 (#122)

brings #122 from main to releases-5.3.0 so that we can create a new v0.6.5-20220914 release with ONLY the 5.3.0 OSRP updates.

Updates Debian 10 image for 5.3.0  OSRP  -- only the -MPi- images are affected.

Co-authored-by: Keshav Ray<EMAIL_ADDRESS>

@keshavray below MPI tags are now ready for the 5.3.0 Catalog:

quay.io/domino/distributed-compute-operator-mpi-sync:v0.6.5-20220915
quay.io/domino/distributed-compute-operator-mpi-init:v0.6.5-20220915


AI Behaviour

Program the AI Behaviour of the enemy character.

Resolved with the following commit: https://github.com/BraisGlezArias/TheHeroNeverDies/commit/ce3bac5cf37f71d3d883efadc261124ade55a6c5


Unexpected character '' error

my packages:
"electron": "^21.3.3",
"electron-builder": "^23.6.0",
"next": "^12.3.4",
"nextron": "^8.7.0",
"react": "^18.2.0",
"react-dom": "^18.2.0"
"@uiw/react-monacoeditor": "^3.5.9",
how can i fix this?

@croxywastaken
To import a TTF file in Next.js, you need to configure the appropriate loader in the next.config.js file of your project.
Here is an example next.config.js file that demonstrates how to configure the loader for importing TTF files:
module.exports = {
  webpack: (config, { isServer }) => {
    // Add a loader for TTF files
    config.module.rules.push({
      test: /\.(woff|woff2|eot|ttf|otf)$/,
      use: {
        loader: 'file-loader',
        options: {
          name: '[name].[ext]',
          publicPath: '/_next/static/fonts',
          outputPath: 'static/fonts',
          esModule: false,
        },
      },
    });

    // Configure behavior when importing TTF files on the server-side
    if (isServer) {
      const originalEntry = config.entry;
      config.entry = async () => {
        const entries = await originalEntry();
        if (entries['main.js'] && !entries['main.js'].includes('./utils/fix-ttf-import.js')) {
          entries['main.js'].unshift('./utils/fix-ttf-import.js');
        }
        return entries;
      };
    }

    return config;
  },
};

This configuration file does the following:

Adds a loader for TTF files using file-loader to handle the import of font files.
Configures the behavior when importing TTF files on the server-side to ensure that the font files load correctly during server-side rendering.

Additionally, you need to create a file named fix-ttf-import.js in the utils directory of your project with the following content:
if (typeof window !== 'undefined') {
  require('monaco-editor/min/vs/base/browser/ui/codicons/codicon/codicon.ttf');
}

This file is responsible for importing the TTF file on the browser-side.
Please note that the above configuration is suitable for Next.js version 10 and above. If you are using an older version, refer to the respective documentation or community resources for the appropriate configuration method.

https://github.com/jaywcjlove/react-monacoeditor/blob/bff1838125ea5fe209cf7693cd3d4d9dc58a2e4f/core/src/index.tsx#L6-L7

Now it gives me this error :(

My code:
import React, { useEffect, useRef, useState } from "react";
import MonacoEditor from '@uiw/react-monacoeditor';

function App() {
	const [code, setCode] = useState('')

  return (
    <>

				<MonacoEditor
					language="html"
					value="
I ♥ react-monacoeditor
"
					options={{
						theme: 'vs-dark',
					}}
				/>

    </>
  );
}

export default App;

Btw, i'm using this module on electron app. (next.js + electron)


UI: use more horizontal space

this is a bit ironic because i'm normally the one complaining sites are too wide, but i feel like probase is so narrow that it makes it tough to see more than a few problems on the screen at a time.

i think my suggestion for changing the UI to be more space-efficient (at least on desktop) would be something like

increase the width to about 80 characters a line (right now it's less than half of that);
try to put some more metainformation to the left of the statement rather than above it (maybe sort of like what i have on blog.evanchen.cc)

Oh yeah, I left some extra space because I was planning to add more things on each side.
Left side would have a sidebar like the one on https://www.probase.app/. Right side will have all the Add Problem / Search / Filter / Sort settings, so you don't have to scroll all the way to the top to use these


D3D12_TEXTURE_LAYOUT - fix weird extra line breaks

Reading this article looks like:

This is purely a whitespace change.

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


Provide a means for custom io.Writer's to pass the new IsTerminal call.

I originally implemented an io.Writer to process special color codes that my application uses, but since this change I've discovered I can probably handle this fine via hooks. Although I still have issues with this change -- it's breaking a core concept of my application which is multiple log targets. For those I take advantage of io.MultiWriter to group more than one io.Writer which can't be cast as an *os.File to be determined to be a "terminal." It would be great if you added a logrus.Terminaler (that's probably a terrible name, just a quick example) interface that would let custom io.Writer types determine if they, themselves are a terminal or not.
To be clear, I'm not asking for any kind of reversion, but an interface that would let custom writers tell logrus if they are a "terminal" or not.
I originally commented on https://github.com/sirupsen/logrus/issues/478 but I don't feel like the comment is getting visibility. To be clear, I'm fine with the addition of the IsTerminal method. I'm just asking for some means to allow custom io.Writer implementations to pass the test, as in my case I use io.MultiWriter to wrap a terminal and file and want terminal behavior or, also provide a wrapper around standard outputs and want to allow them to also pass the test.

Closing per the project being put into maintenance mode


Updated Readme

With instructions. v1.0

i am changing to sql lite next checkin. You should run postgres without a role or username

brew install postgres and then start it like this pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start


Adding Contributors in Sidebar.

Adding contributors section in sidebar using GitHub API.

@imabp Are you working on this?

Yes I am planning to work on it.

Can you provide me with, some keys so that I can set things up . I am facing this error on running the server:

The keys are being used on the production server. Here you can use MONGO local URL or create your own MONGO URL via Mongo Cloud.
On Mongo DB Cloud connect your cluster to an application.
mongodb+srv://<username>:<password>@ecomerce-website.qfwmi.mongodb.net/<dbname>?retryWrites=true&w=majority

I will add this in the Instructions part.

Added in README.

@tarunnsingh I have added the contributors section and tested it too, its working fine.
Update: I have also restricted the BOT entry in contributors section
Please review #12

Merged your PR #12
Closing now.

Just noticed that on clicking the usernames of contributors, the api json opens up. Slight change in the URL is required.

Yaa I also noticed now oppsie 🙊🙊... 😅😅
Actually just need to replace the href  part line
<a href=https://github.com/${contributor.login}`>`

That's done Now, with the latest commit to master.


support tp

Hi, thanks for the great work!
What if I want to support larger model, say, beyonds one gpu card's memory and needs tp. Is there a reason why qserve doesn't support tp? If I add sharp the quantized weight on my own, will it affect the gemm kernel you developed?

Hi! Thank you very much for your interest in QServe.
Yes. TP is definitely helpful for serving larger models. Currently, we have not supported TP in QServe yet, but we believe that QServe is compatible with TP and other parallelization strategies. By the way, since QServe greatly compresses the weights and KV cache of LLMs, it is viable to serve most of the open-sourced models within a single A100 GPU, so that the communication overhead between GPUs can be avoided (possibly with DP).

Thanks for you reply!
Qserve indeed can serve large model in one card. However, if other framework enable tp, for example, vllm with tp=4, may result in higher throughput since each card compute less. In our real experiment, when serving Qwen1.5-72B-chat, vllm with tp=4 can double qserve's throughput with tp=1. So I think tp is important and look forward for qserve to support it lol.


{security} HTML tags are rendering as empty parameter values in reference docs

Describe the bug
Problem to solve:
HTML tags in source code are causing build warnings in MicrosoftDocs/azure-docs-cli. More importantly, customer-facing reference docs are not instantiating properly -- parameter values formatted with `<>` are missing. Here's an example:

Requested solution:
These values should be escaped with a backtick. Here's an example from az webpubsub.

Related GitHub issues:
This is the same issue as these GitHub issues.
List of HTML tag instances that need update:

File name
Build error

latest/docs-ref-autogen/security/contact.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/security/contact.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/security/security-connector.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/security/security-connector.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/security/setting.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/security/setting.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

Related command
az security
Errors
n/a
Issue script & Debug output
n/a
Expected behavior
n/a
Environment Summary
Azure CLI 2.62.0
Additional context
No response

Thank you for opening this issue, we will look into it.


Lightning control

Hello,
First let me thank you for the amazing project, it seems like just the perfect solution for me. Also, let me apologize, because this is not exactly an issue, but a question.
I'm using home assistant and want to make my light switches smart. So far I only found the Panasonic Advance (Plus) series.
Is my assumption correct that I need the Link-plus wireless adapter to read out the states and issue commands?
I was hoping that you can give me a small push in the right direction and how to start off.

Unfortunately link plus itself isn’t echonetlite compatible. The Aiseg2 adapter makes them controllable via the web browser, and it also allows (limited) control of echonetlite devices via web browser, but it doesn’t do any bridging to echonetlite.
There exists a limited homebridge project for controlling link plus lights, but none for home assistant. The work involved appears straightforward— it’s a matter of building a scraper. But someone just has to do it.

Here’s the homebridge project:
https://github.com/vwhitteron/homebridge-aiseg2

@flutschepfeil
I have no connection with Panasonic, so I can't give you an exact answer.
ECHONETLite2MQTT is an application that communicates using the ECHONET Lite specifications.
We can check supported devices on the ECHONET website.
I found a wireless adapter for the Panasonic Link Plus Switch.

ja: https://echonet.jp/introduce/gz-000755/
en: https://echonet.jp/introduce_en/gz-000755/

If your switch is Panasonic Link Plus, you may be able to control it with ECHONETLite2MQTT using this device.
However, I do not recommend trying it, because this device is expensive and you may not be able to control the switch.

Yeah you won’t be able to control the switches with that adapter.
That said, if you’re handy with coding you could build a bridge that allows you to control the lights over MQTT (or whatever).

Apologies for the late reply. Thanks for all the ideas and answers. I have sadly no experience with coding, so creating something from scratch will be difficult for me.
As for the homebridge, I would need an AppleTV to make use if it I assume?
Are there in general smart switches (tactile, also 3way or 4way) that would work with home assistant in Japan?
@banban525 may I ask if/what you are currently using as smart switches? :)

Can confirm! WTY2001 works great.

@aftertommy and mathewbadeau many man thanks for the information and link to the other thread, this look like amazing news! :)


Compile user research for personas

[x] google user stories
[x] gather quotes

I went on Amazon, Target, and Walmart's websites and compiled quotes about a few different baby monitor devices. All of the quotes are in this document below.
https://docs.google.com/document/d/1TkN1xzfGtXkWzfaGBC5YBUw5xu6LE0pQQahO6MX0JX0/edit#

Reviewed and done

updated user research after getting feedback from professor, task switched from Andrew to Beatriz


Xpense: Updating ERD

Added the latest changes:

House: User, Name, Description
Chainning City & Country
Removed Story
Tips: Added Description

Addressing Issue #130

Hey Lior :) House have no ID as PK any more

Isn't there an inner id of the django system?
The Expense model contains a foreign key of house, doesn't it use the id of the house?


Update Mergify for v2.1.0 backports

Updated Mergify rules for backporting PR's to release-v2.1 branch and to auto-merge the PR if the author is mergify bot
Signed-off-by: Madhu Rajanna<EMAIL_ADDRESS>

Merging this manually. Thanks.


ViewModel unit test problems with SavedStateHandle.navArgs()

Hi,
I'm using SavedStateHandle.navArgs() to get the navigation arguments on my ViewModel. However, on my Unit tests the call fails with NoClassDefFoundError: Could not initialize class error. I've added the value directly in my SavedStateHandle with no success.
How can I manage to test the ViewModel with the navigation arguments without having to do a UI test?
Could not initialize class com.ramcosta.composedestinations.navargs.primitives.DestinationsStringNavType
java.lang.NoClassDefFoundError: Could not initialize class com.ramcosta.composedestinations.navargs.primitives.DestinationsStringNavType

Code snippets:

ViewModel

class SearchViewModel @Inject constructor(
    savedStateHandle: SavedStateHandle,
    ...
) {

    init {
        // Test fails here
        val initialQuery = savedStateHandle.navArgs<SearchScreenNavArgs>().initialQuery
    }

Unit test

@Before
fun setup() {
    viewModel = SearchViewModel(
            savedStateHandle = SavedStateHandle().apply {
                set("initialQuery", "")
            },
            ...
    )
}

Hi 👋
You can receive the initial query in the constructor of the ViewModel, making use of dependency injection principles.
Then in the test you can inject whatever you want.
Let me know if this helped 🙂

I closed this but I’ll be paying attention to your replies here 😃

Do you mean I'm not able to use either? When is the case I can use them in the ViewModel and also be able to Unit test it?
SearchScreenDestination.argsFrom(savedStateHandle)

savedStateHandle.navArgs<SearchScreenNavArgs>()

data class SearchScreenNavArgs(
    val initialQuery: String = ""
)

@Suppress("LongMethod")
@Destination(
    navArgsDelegate = SearchScreenNavArgs::class,
)
@Composable
fun SearchScreen(...)

One option would be passing by the compose screen... which looks a bit bad.
@Destination
SearchScreen(initialQuery: String) {
    vm.loadNavArgs(initialQuery)
}

No, you can and should use one of those options, but do it before calling the ViewModel constructor and pass the result to it.
Are you using Hilt or any other DI framework?

Ok, so search for assisted injection. This is a good practice either way, it’s not just a workaround to this issue 😁

Let me try to find you an example of this

Coming from Manuel himself ☝

I'll give it a try. Thank you for the fast responses!

Hmm I actually went through this and gave a quick DM to Manuel, and it seems this is not recommended 🤔
https://github.com/google/dagger/issues/2287

So.. you can either use a setter and call it from the Composable, or you can mock the navArgs method.. Are you using a mocking library?

Yes, Mockito.

Hmm not sure how to mock these methods with mockito 🤔
Maybe your best bet until they fix the assisted injection in Hilt is to use a setter like you said before. If you were using manual dep injection this would be trivial, so yeah, it’s annoying that this issue is worse because Hilt is missing this support.

@raamcosta should this issue be reopened? I'm facing the same issue and seems related with DestinationsStringNavType, when I use the SavedStateHandle directly it works.
Does NOT work
@HiltViewModel
class CountryLocalIdConfirmationViewModel @Inject constructor(
    savedStateHandle: SavedStateHandle,
) : ViewModel() {

    private val _viewState = MutableStateFlow<ViewState>(savedStateHandle.navArgs()) // <======= Unit tests fail here
}

Does work
@HiltViewModel
class CountryLocalIdConfirmationViewModel @Inject constructor(
    savedStateHandle: SavedStateHandle,
) : ViewModel() {

    private val _viewState = MutableStateFlow(
        ViewState(
            countryLocalIdType = savedStateHandle.getOrThrow("countryLocalIdType"),
            countryLocalId = savedStateHandle.getOrThrow("countryLocalId"),
            checkBoxValue = savedStateHandle.getOrThrow("checkBoxValue"),
        )
    )
}

This is the current generated code
	override fun argsFrom(savedStateHandle: SavedStateHandle): ViewState {
	    return ViewState(
			countryLocalIdType = countryLocalIdTypeEnumNavType.get(savedStateHandle, "countryLocalIdType") ?: throw RuntimeException("'countryLocalIdType' argument is mandatory, but was not present!"),
			countryLocalId = DestinationsStringNavType.get(savedStateHandle, "countryLocalId") ?: throw RuntimeException("'countryLocalId' argument is mandatory, but was not present!"),
			checkBoxValue = DestinationsBooleanNavType.get(savedStateHandle, "checkBoxValue") ?: throw RuntimeException("'checkBoxValue' argument is not mandatory and not nullable but was not present!"),
	    )
	}

maybe should generate something like this?
	override fun argsFrom(savedStateHandle: SavedStateHandle): ViewState {
	    return ViewState(
			countryLocalIdType = savedStateHandle["countryLocalIdType"] ?: throw RuntimeException("'countryLocalIdType' argument is mandatory, but was not present!"),
			countryLocalId = savedStateHandle["countryLocalId"] ?: throw RuntimeException("'countryLocalId' argument is mandatory, but was not present!"),
			checkBoxValue = savedStateHandle["checkBoxValue"] ?: throw RuntimeException("'checkBoxValue' argument is not mandatory and not nullable but was not present!"),
	    )
	}

or maybe making DestinationsStringNavType a class instead of an object? the generated
val countryLocalIdTypeEnumNavType = DestinationsEnumNavType(CountryLocalIdType::class.java)

seems to work fine.

@raamcosta should this issue be reopened? I'm facing the same issue and seems related with DestinationsStringNavType, when I use the SavedStateHandle directly it works.
Does NOT work
@HiltViewModel
class CountryLocalIdConfirmationViewModel @Inject constructor(
    savedStateHandle: SavedStateHandle,
) : ViewModel() {

    private val _viewState = MutableStateFlow<ViewState>(savedStateHandle.navArgs()) // <======= Unit tests fail here
}

Does work
@HiltViewModel
class CountryLocalIdConfirmationViewModel @Inject constructor(
    savedStateHandle: SavedStateHandle,
) : ViewModel() {

    private val _viewState = MutableStateFlow(
        ViewState(
            countryLocalIdType = savedStateHandle.getOrThrow("countryLocalIdType"),
            countryLocalId = savedStateHandle.getOrThrow("countryLocalId"),
            checkBoxValue = savedStateHandle.getOrThrow("checkBoxValue"),
        )
    )
}

This is the current generated code
	override fun argsFrom(savedStateHandle: SavedStateHandle): ViewState {
	    return ViewState(
			countryLocalIdType = countryLocalIdTypeEnumNavType.get(savedStateHandle, "countryLocalIdType") ?: throw RuntimeException("'countryLocalIdType' argument is mandatory, but was not present!"),
			countryLocalId = DestinationsStringNavType.get(savedStateHandle, "countryLocalId") ?: throw RuntimeException("'countryLocalId' argument is mandatory, but was not present!"),  // <======= Unit tests fail here
			checkBoxValue = DestinationsBooleanNavType.get(savedStateHandle, "checkBoxValue") ?: throw RuntimeException("'checkBoxValue' argument is not mandatory and not nullable but was not present!"),
	    )
	}

maybe should generate something like this?
	override fun argsFrom(savedStateHandle: SavedStateHandle): ViewState {
	    return ViewState(
			countryLocalIdType = savedStateHandle["countryLocalIdType"] ?: throw RuntimeException("'countryLocalIdType' argument is mandatory, but was not present!"),
			countryLocalId = savedStateHandle["countryLocalId"] ?: throw RuntimeException("'countryLocalId' argument is mandatory, but was not present!"),
			checkBoxValue = savedStateHandle["checkBoxValue"] ?: throw RuntimeException("'checkBoxValue' argument is not mandatory and not nullable but was not present!"),
	    )
	}

or maybe making DestinationsStringNavType a class instead of an object? the generated
val countryLocalIdTypeEnumNavType = DestinationsEnumNavType(CountryLocalIdType::class.java)

seems to work fine, also DestinationsBooleanNavType.

I just realised that DestinationsStringNavType uses
import android.net.Uri
import android.os.Bundle
....
internal val DECODED_EMPTY_STRING: String = Uri.decode(ENCODED_EMPTY_STRING)
...
private val DECODED_DEFAULT_VALUE_STRING_PREFIX: String = Uri.decode(ENCODED_DEFAULT_VALUE_STRING_PREFIX)

that might be the reason we are not able to access it in the unit tests.

That is the reason, yes.
I can make it a lazy initialized field, and if the tests don't need it (it seems like that is your case) then that would work.
But I still need to think more about it since what if the tests do need it? 🤔
I'll reopen this to see if I can come up with a better solution. Thanks @epool

Until then, use assited injection and pass the arguments to the ViewModel (this is much better from a clean code perspective in my opinion).
If not, you can set the args from the outside with some setter.

This should be fixed guys @epool @luanbarbosa-sanoma please test version 1.x.20 and let me know!


copy_volume: add phase at err msg

Helps debug https://github.com/coreos/etcd-operator/issues/588

fixed

lgtm


Native response handler

Adds a native response handler for use in the LargeFileUpload task requests used in Java-Core for Kiota.
Adds setResponseHandler function to the requestInformation class.

@ramsessanchez can you do a first pass removing the code smells reported above please before we proceed with a review?


Provide some guidance for usage of CSS classes in templates

Is your feature request related to a problem? Please describe.
I worked on several templates in the code base and struggled to choose the correct column width classes (like col-xx col-md-xx offset-md-xx and so on).
Describe the solution you'd like
I would like a short style guide with advice like:

Use class="col-12 col-md-10 offset-md-1 content-area" for pages with short textual explainations
Use <h2> for the page headline
Use ... for forms
See ... as an example how to style ...

Describe alternatives you've considered
I looked into our existing codebase but it unfortunatelly it is a bit inconsistent regarding CSS class usage. The existing styled pages (Profile form, Session grid, Start page) are very specific and not sufficient as general advice.

I will extend the README in /frontend with some Information.


seems the resize() method has incorrrect output

The resize function itself seems correct but maybe some overflow is not defined right. Use the ADC quantization example, do the following:
... setup f_sig, n, n_samples as shown in the example,
sig = Anp.sin(2np.pif_sign/n_samples)
sig_8_7=Fxp(sig, signed=True, n_word=8, n_frac=7)
sig_8_4=Fxp(sig, signed=True, n_word=8, n_frac=4)
sig_8_4[21].resize(True, 8, 7)        # ==> just pick a single point
sig_8_4[21].bin(frac_dot=True)    #  ==> sig_8_4[21] is not resized to the same size as sig_8_7[21]
sig_8_7[21].resize(True, 8, 4)
sig_8_7[21].bin(frac_dot=True)    # ==> sig_8_7[21] is not resized to the same as sig_8_4[21] either
Another example that had incorrect resize output too:
x = Fxp(10.75, dtype='S5.16')
x.bin(frac_dot=True)        # return '01010.1100000000000000'
x.resize(True, n_word=12, n_frac=9, restore_val=True)
x.bin(frac_dot=True)        # return '011.111111111' or 3.99. Correct answer should be 10.75/2**7=0.083984375

Hello @steven918 ,
First case:
The resize method is not allowed to each element, because a Fxp object is homogeneous in size. So, I think you need to work with a list of Fxp objects instead a Fxp of a list (or numpy array) if you want to change the size of individual elements.
Second case:
restore_val is True by default and it does that original value should be keep in new size, but resized Fxp object has to be able to represent that value. In your example, resized x has upper limit of 3.998046875 because of 2 bit for integer part and 9 bits for fractional. The original value of 10.75 is truncated to that upper limit.
I don't understand what you wrote as correct answer.

Thanks @francof2a,
I understand your answer to the first case where a list was used now.
As for the second case, I thought "restore_val" is intended to have the same value after resizing. But it seems setting "restore_val" to False still returned the same value as it is set to True. Both of them returned
x.bin(frac_dot=True)
Out[11]: '011.111111111'
My understanding of the resize operator was scaled version of the input: before scaling there were 16-bit fractional and after scaling there was 9-bit fractional so from fixed point representation "real_value = scale * x" (assuming zero biased and x is the fixed point), the resized value would be shifted by (16-9=7) bits. Of course, this is not intended to be a "restore_val" operation and it sounds not supported by the resize() function

if restore_val is False, the resized Fxp is going to keep de raw value (fixed point, not fractional), but for that Fxp resized must have enough word *bits) size to store that value. In the second case, you are resizing from a 21 bits Fxp to a 12 bits Fxp, that's because truncation occurs also.
if you do:
x.resize(True, n_word=12, n_frac=9, restore_val=False) # keeping same word size
x.bin(frac_dot=True)

Out[ ]: '010101100000.000000000'

You have same binary but with different fractional size. That's the function of resize method, but it's not rescaling function you need.
If I understood well what you need, maybe following is a solution:
x = x >> 7
x.resize(True, n_word=12, n_frac=9, restore_val=True)
print(x)
print(x.bin(frac_dot=True))

0.083984375
000.000101011

Please, let me know if this is what you're trying to implement.

oh, I see. You intended not to keep the fractional value after resizing. You're right that the scaling version is simply a right shift of input and then resize. This is the right shift and decimal alignment (for example through resize()) process I was looking for and thought the resize() would do. Thanks for clarify that.
I was trying to find a similar fxp version to match to Tensorflow's quantization (in tf.quantization.quantize), which quantize float to qint8, qint16, etc. That's why I bumped into your implementation. Thanks for all the answers and great work!

You are welcome. Thanks for using this module and report your problem.
I think your issue is solved. I'm going to close, but if you consider that something remains, please don't doubt to open a new one.
P.S.: It would be great that fxpmath could work with tensorflow!

Yes, please close it and label "solved". I will certainly bug you if I run into something else.


Clarify the meaning of positive/negative regulation of cellular protein localization

Dear Editors,
Would it be possible to better explain the meaning of positive/negative regulation of cellular protein localization (respectively GO:1903829, GO:1903828)?
I understand the necessity of a regulation term, but I don't think that the above terms provide meaningful information as they are.
Many thanks,
Elena Speretta

Dear Elena,
Thanks for bringing this up.  We can add an explanation of what cellular protein localization is, for example, for the positive regulation term, the new definition would be:
Any process that activates or increases the frequency, rate or extent of cellular protein localization.
Cellular protein localization is any process in which a protein is transported to, and/or maintained in, a specific location and encompasses movement within the cell, from within the cell to the cell surface, or from one location to another at the surface of a cell.
Would this be helpful?
Thanks,
Tanya

Dear Tanya,
thanks for looking into this. Yes, I agree with you that this definition will make the terms less ambiguous and would actually cover a lot of situations in which children of these terms are not yet listed.
Many thanks,
Elena

Added the sentence to all the regulation terms.


Improve styling, add css classes to admin templates

makes this ...

look like this ...

You shouldn't use styles that are not available in base Django https://github.com/django/django/tree/main/django/contrib/admin/static/admin/css


Find text containing in tests

Description
This PR adds a new finder to find text widgets that contain a specified text. This is useful when you have longer dynamic texts and just want to verify a given sentence or word is there.
Usage in tests:
// Text('this is a test')
expect(find.textContaining('test'), findsOneWidget);

The same applies for EditableText widgets.
Related Issues
#65070
Tests
I added the following tests:

Test to ensure finds Text widgets containg a string
Test to ensure finds Text.rich widgets containg a string
Test to ensure finds EditableText widgets containg a string

Checklist
Before you create this PR, confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[x] No, no existing tests failed, so this is not a breaking change.
[ ] Yes, this is a breaking change. If not, delete the remainder of this section.

[ ] I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
[ ] I got input from the developer relations team, specifically from: Replace with the names of who gave advice
[ ] I wrote a migration guide: https://flutter.dev/go/breaking-changes-template Replace this with a link to a pull request that adds the migration guide to https://flutter.dev/docs/release/breaking-changes

I can understand why this would be useful. Are you trying to use this in your own project? We want to make sure it's solving a real problem.
If we are to add it to Flutter, would this be better to use regex so it's more widely applicable?

Yes, we are already using it as an extension.
Probably using regex would be more widely applicable. We should call it textMatching(pattern) then.


Updated linting rules

Hi @stefanjudis,
you're using some rules for linting and in the contributing.md you're asking not to create lines with length more than 80. So I've added this rule to the eslintrc and also fixed some linting issue.
Feel free to change or comment anything.

Cool stuff! Thanks! :+1:


[GEARPUMP-226] refactor build files

Refactored build files as follows

break Build.scala into parts for different module categories, e.g. BuildExternals, BuildDashboard.
libraries to shade are now added as managed dependencies, shaded with their depending projects and finally assembled to a uber jar. For example, gearpump-core-$version.jar will now contain both the gearpump sources and shaded libraries, whose package names are both org.apache.gearpump.  The original dependencies are excluded from pack.
package names in the codebase are changed as needed by 2
gearpump-core is now provided for gearpump-streaming and won't be transitive dependencies for projects depending ongearpump-streaming. gearpump-core needs to be explicitly included as provided dependency so I add it to the published pom files for users.

@huafengw please review.

Current coverage is 72.91% (diff: 100%)

Merging #108 into master will increase coverage by 1.17%

@@             master       #108   diff @@
==========================================
  Files           186        186
  Lines          5981       5981
  Methods        5456       5462     +6
  Messages          0          0
  Branches        525        517     -8
==========================================
+ Hits           4291       4361    +70
+ Misses         1690       1620    -70
  Partials          0          0

Powered by Codecov. Last update cbf59fb...8631b62

+1


Add missing tomli dependency

This merge alphabetizes dependencies and adds the missing tomli dependency needed for python <3.11.
It also updates the source URL and adds python_min to make the linter happy.
@xylar is added as a maintainer.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I would strongly recommend removing automerge because grayskull isn't catching everything it should.  I'm going to add that to this PR.

Thanks @jan-janssen!


EHS-439- Outdated validation

https://gazelle.ihe.net/jira/servicedesk/customer/portal/8/EHS-439
The test
https://ehealthsuisse.ihe-europe.net/EVSClient//detailedResult.seam?type=FHIR&oid=<IP_ADDRESS>.4.1.125<IP_ADDRESS>.13.45610
returns errors:
Location
Bundle.entry[1].resource.subject.reference
Description
Can't find 'Patient/680b37b0-815e-47ef-a781-d5dd7506c251' in the bundle (Composition.subject)
Location
Bundle.entry[1].resource.author[1].reference
Description
Can't find 'Practitioner/486db8e5-18ce-4401-9db8-885efaf4351b' in the bundle (Composition.author)
Location
Bundle.entry[1].resource.author[2].reference
Description
Can't find 'Organization/6cf6cacd-7555-4f15-9dd2-0478a965cfef' in the bundle (Composition.author)
Location
Bundle.entry[1].resource.custodian.reference
Description
Can't find 'Organization/f583a9c1-2846-4e71-a269-bfc9afde2145' in the bundle (Composition.custodian)
These errors are not returned with the java validator. It looks like the validator needs an update.

updated hapi-fhir to 5.2.0-SNAPSHOT
updated fhir.core.version 5.1.15 (later is not yet possible due to class name changes)
added testcase for EHS-439 to verify correct behaviour with 5.1.15 https://github.com/hapifhir/org.hl7.fhir.core/releases/tag/5.1.15


After running successfully, the screen is shared, but it is black

After running successfully, the screen is shared, but it is black
git clone https://github.com/twilio/twilio-video-app-react.git
vim .env
npm run build
npx update-browserslist-db@latest
npm run build
npm run start
http://localhost:8001

HTTPS doesn't work either


Replaced dynamic versioning of fbjni in build.gradle with version 4 e…

What
This PR fixes the issue whereby all projects consuming this project right now are failing, due to fbjni releasing version 5.0.

Changes
Fixes the dynamic import version of the fbjni dependency on android, explicitly depending on version 4. This fixes any consuming app that includes this library failing to build due to the following error:
Could not find fbjni-0.5.0-headers.jar (com.facebook.fbjni:fbjni:0.5.0).
     Searched in the following locations:
         https://repo.maven.apache.org/maven2/com/facebook/fbjni/fbjni/0.5.0/fbjni-0.5.0-headers.jar

This PR updates the import of fbjni within the build.gradle file to explicitly depend on version 4, rather than having a dynamic import, which just pulls in the latest version.
Tested on

Google Pixel, Android 13.
Related issues

Fixes #1664

Please @mrousavy, can you merge this PR?

Hey! Sorry my bad I didn't see this PR before making this change myself. Thanks so much for your contribution, my fault I really didn't see it first ❤
Just released this patch on npm :)


Update docker-machine version in installation docs

From 0.5.3 to 0.5.4

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:juliengarcia/machine.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

thx @juliengarcia
LGTM

LGTM


Considering changing to TailwindCSS

Do you have any consideration for using TailwindCSS for styling instead of using the UI components from ChakraUI?

Thank you for reaching me. I use Chakra UI as my go-to UI provider because I've struggled to use Tailwind. Tailwind is a great library, but it makes debugging really difficult for me. A lot of classes yields longer className and it makes more difficult to read. I use Chakra UI because Chakra is built on top of Tailwind. It also has a pre-built component to easily use which React recommended.
If you have further question. Let me know.
Thank you.
Regards,
Andrew V. Victorio

Thank you for reaching me. I use Chakra UI as my go-to UI provider because I've struggled to use Tailwind. Tailwind is a great library, but it makes debugging really difficult for me. A lot of classes yields longer className and it makes more difficult to read. I use Chakra UI because Chakra is built on top of Tailwind. It also has a pre-built component to easily use which React recommended.
If you have further question. Let me know. Thank you.
Regards, Andrew V. Victorio

After thinking a lot of research and testing, I will migrate from chakra UI to tailwind CSS. Thank you for the proposal. It helps a lot.
Regards,
Andrew V. Victorio


(Userreview) Camera stays blank on Android 7.0

Not working on my Android Nougat on OnePlus 3. I remember it was working in an earlier Android version, on the same phone.
The screen stays blank (black, maybe different colors depending on the filter), with the buttons on top.

https://forums.oneplus.net/threads/cardboard-camera-black-screen-view.494048/

http://stackoverflow.com/q/42411268/5125132


Link to Privacy Commissioner site for French Privacy Statement

Discrepancy on https://staging.covid-hcportal.cdssandbox.xyz/fr/privacy/
Figma FR content: https://www.figma.com/file/znPqLTQQDcUkaNjdDcShiz/Exposure-Notification-Health-Portal?node-id=7627%3A54328
Add link for Privacy Commissioner of Canada in French
commisaire à la protection de la vie privée du Canada
https://www.priv.gc.ca/fr/pour-les-individus/

Pull Request for this issue has been created - https://github.com/cds-snc/covid-alert-portal/pull/733

Merged in stage and production.


invalid_internal_annotation gives false positive inside part file

Not sure why this is happening:
// blah.dart
import 'package:meta/meta.dart';

part 'src/abc.dart';

// src/abc.dart
part of '../blah.dart';

class A {
  @internal // Triggers invalid_internal_annotation.
  foo() {}
}

From the docs: "Only public elements in a package’s private API can be annotated as being internal."
Is the blah.dart library public? If so, this it looks like this is working as intended.

The blah library is indeed public.
Maybe I don't understand "public elements in a packages private API" - that makes no sense to me. - how can you have public elements in private API?.
The documentation of @internal says:

Used to annotate a declaration which should only be used from within the package in which it is declared, and which should not be exposed from said package's public API.

I interpret that as annotating something that would otherwise be public (such as A.foo() because it is public via blah.) to mark it for private consumption only.
If that is not the intention I think we should update the docs of @internal with an example.

Is this fixed yet?

Trying to use it in my SDK.


[admin interface] rest interface exposed on kubernetesip by using a defined dns hostname as specified during install

probably not kubernetes its now a VM


popovers: Refactor resend and revoke invitation confirmation modals.

This PR refactors the confirmation modals for resending and revoking invitations.
It includes the following changes:

Use dialog_widget instead of confirm_dialog to launch confirmation modals for resending and revoking invitations.

Change the error text as stated in #31395.

Associate each modal with a specific ID.

resend_invite_modal: for the resend invitation confirmation modal.
revoke_invite_modal: for the revoke invitation confirmation modal.

Display errors encountered during resending or revoking invitations within the confirmation modal, keeping the modal open.

Stop the process of revoking or resending invitations if an error occurs.
For example, earlier, in the case of revoking an invitation, the invitation was revoked disregarding the error if modal_invite_id !== invite_id || modal_is_multiuse !== is_multiuse from the settings_invites.ts file.
Now, if an error occurs during the process of resending or revoking an invitation, it will be displayed inside the confirmation modal, and the process will be discontinued to prevent further actions.

Fixes: #31395.

Screenshots and screen captures:
Before Changes:

1. Resend Invitation Modal

2. Revoke Invitation Modal

3. Revoke Invitation Modal (for Invitation Link)

After Changes:

1. Resend Invitation Modal

2. Revoke Invitation Modal

3. Revoke Invitation Modal (for Invitation Link)

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Thanks! Please complete the self-review checklist, add the "maintainer review" label using Zulipbot, and mention @sahil839 for review.

@zulipbot add "maintainer review"

Following feedback from Alya Abbott:

mention @sahil839 for review.

@sahil839 can you please review this PR. Thank you.

Following the review, I have updated this PR.

The dialog_widget.close(); call to close the confirmation modal, is now moved inside the success function of the API call.
Now, the errors returned from the server are also shown inside the confirmation modal for resending and revoking invitations, keeping the modal open (I have kept this as a separate commit).

Screenshots and screen captures:
Before Changes:

Resend Invitation Confirmation Modal (Error: No such invitation.)

Revoke Invitation Confirmation Modal (Error: No such invitation.)

Revoke Invitation Link Confirmation Modal (Error: No such invitation.)

Revoke Invitation Link Confirmation Modal (Error: Invitation has already been revoked.)

After Changes:

Resend Invitation Confirmation Modal (Error: No such invitation.)

Revoke Invitation Confirmation Modal (Error: No such invitation.)

Revoke Invitation Link Confirmation Modal (Error: No such invitation.)

Revoke Invitation Link Confirmation Modal (Error: Invitation has already been revoked.)

Requesting a review from @sahil839.
I would like your input regarding the display of error messages returned from the server during the revocation or resending of invitations under the Actions tab of Invitaions. Currently, we use ui_report.generic_row_button_error(xhr, $revoke_button);(for example, in revoke invitation), which removes the Resend and Revoke buttons and displays the error in their place.
Should we continue with this approach, or would you recommend a new method? Please let me know if any changes are needed. Thank you.

Requesting a review from @sahil839.
I would like your input regarding the display of error messages returned from the server during the revocation or resending of invitations under the Actions tab of Invitaions. Currently, we use ui_report.generic_row_button_error(xhr, $revoke_button);(for example, in revoke invitation), which removes the Resend and Revoke buttons and displays the error in their place.
Should we continue with this approach, or would you recommend a new method? Please let me know if any changes are needed. Thank you.

If we are showing the error in the moda, there is no need for showing it by removing the button.

Following the review, I have updated this PR.
As @sahil839 mentioned:

Can we not use confirm_dialog as before?

If we choose to use confirm_dialog (as we did previously), we will need to pass close_on_submit to false in order to display any encountered errors while keeping the modal open. Therefore, we would need to manually close the modal in the success function of the API call.
I propose two possible approaches:

The modals.ts file provides a function named close_active_if_any() that can close any active modal. We can utilize this to close the confirmation modal.
The confirm_dialog.launch() function returns the unique ID of the launched modal. We can use this ID, pass it to the do_revoke_invite() function, and then use the close_if_open() function from modals.ts, passing in the unique ID to close the modal.

For testing, I have implemented the first approach. Please let me know if any changes are required. Thank you.

The commits are not orderd correctly, since in the first commit the modal will not close. So, the changes to close modal manually should also be in the first change.

The commits are not split correctly, since in the first commit the modal will not close on success. So, the changes to close modal manually should also be in the first commit.

I apologize for the inconvenience caused. I have updated this PR following the review. @sahil839, please let me know if any further changes are needed. Thank you.

Following the review, I have updated this PR.
I made the following changes:

Passed loading_spinner: true when launching the confirm_dialog to show a loading spinner.
The "Working..." button text, which was previously displayed while processing the request to resend or revoke an invitation, is no longer shown.

Requesting a review from @sahil839.
Please let me know if any further changes are needed. Thank you.

Following the review, I have updated this PR with the following changes:

I reordered the commits as indicated in this comment.
As indicated here, the Revoke button is no longer disabled. However, the Resend button is disabled after resending the invite to maintain the original behavior.

Requesting a review from @sahil839.
Please let me know if any further changes are needed. Thank you.

Following the review, I have updated this PR with the following changes:

Moved loading-spinner in second commit as indicated in this comment.
As indicated here, the Resend button is disabled only after the process of resending the invitation succeeds.

Requesting a review from @sahil839.
Please let me know if any further changes are needed. Thank you.

Looks good to me.
@alya can you have a look at once. I will summarize the changes once -

Changes mentioned in issue #31395 are done in the first commit.
Second commit does the changes to show the errors returned by server in the modal itself which were previously shown in the button, which was used for resending/revoking the invites.

Sounds reasonable to me, thanks! I'm not sure how to test this efficiently, and would prefer for @timabbott to review next.

@timabbott approved by @sahil839 .

Merged, thanks @saubhagya-patel! I hope you learned a lot about creating a readable PR from this review process :)

My pleasure, @timabbott. I admit that I have learned a great deal from the review process. I would also like to extend my gratitude to @sahil839 and @alya for their valuable feedback. I'm looking forward to contributing more in the future.


chore(main): release 1.2.1

:robot: I have created a release beep boop
1.2.1 (2024-02-21)
Bug Fixes

blsq: Add ICU developement package to handle unicode in R (f74a067)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/BLSQ/openhexa-docker-images/releases/tag/1.2.1 :sunflower:


Improved gaming experience

Today, gaming is a clunky experience on secureblue.
The recommended method is to use steam from flathub, which isn't verified so it isn't available by default.
Even with flatpak steam, there are issues loading numerous games.
This issue tracks the information gathering and solution proposals for an improved gaming experience, and potentially a bazzite variant.

I don't know if this is worth the time investment.

With games, it usually goes straight to the point where there is no security to be had. You want to run mods, you trust random third party software running directly on the host.
Security hardening often takes away performance. An example would be the CPU vulnerability mitigations. Are you going to disable stuff like SMT for security, or are you gonna keep the Fedora defaults? You can even improve performance by disabling mitigations too... And if there is no security to be had, why not just disable the mitigations? How are you going to handle this?

I don't know if this is worth the time investment.

We already have it working

You want to run mods, you trust random third party software running directly on the host.

Not everyone running games is modding..?

Does Steam even do any sandboxing

Yes, it uses pressure-vessel: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/tree/main/pressure-vessel
"to run games in individual game-specific containers."

Are you going to disable stuff like SMT for security

Yes, that stays the same

I would personally be in favor of a Bazzite variant.

The recommended method is to use steam from flathub, which isn't verified so it isn't available by default.
Even with flatpak steam, there are issues loading numerous games.

As for interesting projects/software that are perhaps worth mentioning here for tackling the situation around Steam (in alphabetical order):

Bazzite-Arch;

Steam is included with the image. And can be invoked (within the image) with steam.
Can only be used on the images with User Namespaces.
Works.
Container workflow isn't appreciated by everyone.
IIRC, Bazzite actually doesn't actively rely on this anymore. As such, I wonder how much it's getting improved and how healthy this project is.

Bottles;

Flatpak.
Doesn't come with Steam pre-installed. Though, they've put some effort to streamline the process.
Unfortunately, for some reason, I wasn't able to open Steam with this using their streamlined approach. Though, it might be an issue on my end.
Team behind it is currently working on multiple projects and even on another related project Bottles Next. Therefore, the project isn't as healthy as it was a year or two ago.

Conty;

Includes Steam out of the box. Can either be opened through Conty's binary (i.e. ./conty.sh steam) or through Steam's exported .desktop file after invoking the ./conty.sh -d command; this command exports all .desktop files inside Conty's /usr/share/applications to user's $XDG_DATA_HOME/applications/Conty folder.
Works (with some effort) on all images.
Already uses bubblewrap and comes with built-in options for sandboxing.
So far, my experiences with updating were cumbersome. But this might be on my end.
Looks like a well-maintained project.
"This repository has GitHub workflows that allows you to make GitHub automatically generate a new Conty binary of your specification, every week or at any time you want."; I'm sure this will be useful.

RPM-fusion's Steam:

I couldn't find a lot on this in combination with Fedora Atomic. I guess it should work, but don't quote me on this.

I'm by no means an expert, but Conty seems most promising to me.
Just my two cents.

@throwaway43 There's no situation to tackle around steam, it works well out of the box. Also, secureblue will not be inventing a new gaming variant, so anything related to that is offtopic and out of scope. The purpose of this project is to harden existing uBlue/Fedora Atomic images.

I couldn't find a lot on this in combination with Fedora Atomic.

One note is that you really should be enabling SquashFS by default with the Bazzite variant - they ship a lot of AppImages ootb.

@TommyTran732 done https://github.com/secureblue/secureblue/commit/442eaae49652d35ada4550f71a015ca567932fd7

Abandoning the bazzite variants in staging. Users are instructed to use the flatpak or layer the steam rpm.
https://github.com/secureblue/secureblue/commit/9f92777c95174d7a316569d53e0184cb1b1fb4a3
https://github.com/secureblue/secureblue/commit/6180c4f4c8bfc1172fb9090c8c19174e8919debf


Add SHA-256 and SHA-512 digest auth algorithms

Added SHA-256 and SHA-512 auth algorithms to requests/auth.py   Added test code to test_requests.py
Requires SHA-256 and SHA-512 in the httpbin test framework.

Seems like the digest stuff is 404ing: mind taking a look?

@Lukasa @linuxlizard, the changes were merged in httpbin but I don't believe we cut a release. I think that may be a prerequisite for pytest-httpbin working here.
I pinged Ian but didn't get a response and wasn't sure what SOP was for httpbin releases/deployments.

Should I move my testing to tests/test_lowlevel.py ?   Would be more of a learning curve for me, take a bit longer.

@linuxlizard, I don't believe there's any reason we need to move down to low level tests here. We just need to get your changes from httpbin into pytest-httpbin.

Has there been any movement on this? It's a pretty simple fix but it's killing our router testing. Thanks!

@linuxlizard I believe we’re still waiting on an httpbin release for the tests to be able to run. @sigmavirus24 is there anything we’re waiting on to cut 0.6.3?

@nateprewitt I think there's a new httpbin release that's been out for ~1 week.

@sigmavirus24 yep, this looks fixed. I think the blocker is just appveyor now.

Those are some truly bizarre test failures, but I wonder if they'd be solved by rebasing.

They occur at the tip of master too but aren’t consistent failures. I tried to debug last night without success. I’ll take another look on the plane.

Going to close and re-open this to trigger a new merged build with master

Codecov Report

Merging #4410 into master will decrease coverage by 23.64%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           master    #4410       +/-   ##
===========================================
- Coverage   90.18%   66.53%   -23.65%
===========================================
  Files          15       15
  Lines        1548     1560       +12
===========================================
- Hits         1396     1038      -358
- Misses        152      522      +370

Impacted Files
Coverage Δ

requests/auth.py
68.96% <100%> (-17.46%)
:arrow_down:

requests/packages.py
0% <0%> (-100%)
:arrow_down:

requests/status_codes.py
0% <0%> (-100%)
:arrow_down:

requests/__version__.py
0% <0%> (-100%)
:arrow_down:

requests/exceptions.py
17.14% <0%> (-82.86%)
:arrow_down:

requests/certs.py
0% <0%> (-75%)
:arrow_down:

requests/structures.py
52.5% <0%> (-47.5%)
:arrow_down:

requests/api.py
36.36% <0%> (-45.46%)
:arrow_down:

requests/hooks.py
73.33% <0%> (-26.67%)
:arrow_down:

requests/cookies.py
51.27% <0%> (-25.85%)
:arrow_down:

... and 5 more

Continue to review full report at Codecov.

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

Thanks again @linuxlizard!


[Bug]: TOO MUCH OF WHITE SPACE BELOW FOOTER IN THE MAIN PAGE

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
There is a lot of space below the footer in the main page
Add Screenshots
No response
What browsers are you seeing the problem on?
No response
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC contributor
[X] I want to work on this issue
[X] I'm willing to provide further clarification or assistance if needed.

Hi! Could you please assign this bug to me? I’d like to work on fixing it.


HTML entities codes doesn't pass instead of strings

Challenge Bonfire: Convert HTML Entities has an issue.
User Agent is: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:
function convert(str) {

  // new tmp string for hoding subStrings
  var tmp = [];

  // get the char code
  for (var i = 0; i <= str.length; i++) {
    // any char < 65 will not be an alphabitical character
    // 32 is the space
    if (str.charCodeAt(i) < 65 && str.charCodeAt(i) != 32)
      {
        // str = "&#" + str.charCodeAt(i);

        // insert the new char inside
        tmp.push("&#" + str.charCodeAt(i));
      }
    // if it's a regular char just put it back
    else
      {
       tmp.push(str[i]);
      }
  }

  // join the string
  str = tmp.join("");

  return str;
}

convert("Dolce & Gabbana");

It doesn't accept HTML codes instead of strings, I wrote the solution in a generic way where I search for the decimal value of the ASCII character and check if it was an entity then convert it to HTML codes such as &#38 ; (without the space) for & instead of &amp ; because it's much more generic and better in that way, but unfortunately it doesn't pass the test

I don't see this as a problem. The bonfire asks for you to use entities, we provide a link that shows you exactly what those entities are, and the spec explicitly shows you that entities are expected. Your code is good, but you're simply not solving the problem we asked you to solve.
I'll leave this open for discussion briefly in case anyone else on the team has a differing opinion on this.

Ok, I'll write another function that does the conversion needed to pass the test, thanks!

Closing this issue. Feel free to reopen if you still experience problems, thanks.

I already wrote the extra function that day, thanks!