Use pre-built Docker images for prod deployment

Is your feature request related to a problem? Please describe.
Right now, the prod containers are built on the prod machine as part of the deployment process.
Describe the solution you'd like
Move to having Travis build tagged builds images, push them to Hub, and deploy from there.

The current ansible deployment uses the images built by GitHub actions


Add support for custom config keys

Some projects may wish to specify their own keys in the config.json file, that differ from the default values:

manUpAppUpdateURL
manUpAppVersionCurrent
manUpAppVersionMin

This will also assist with backwards compatibility with any existing installations as the keys have changed.

Fixed in #8


Unable to run a simple node.js script from testcontainers

I was trying to run node.js from testcontainers but I do not see a way to just perform "docker run" kind of use-case with TestContainers. I basically do not want to start the container, but just run a command on it.
For example, I do not find an easy way to run something as simple as
docker run -it --rm -v "$PWD":/usr/src/app -w /usr/src/app node:alpine node node.js

docker run starts a container. See https://www.testcontainers.org/features/commands/#container-startup-command for more information.


fs.verify: failed verify needle :: rpc error: code = Unknown desc = not found

Describe the bug
When running fs.verify I get plenty of errors like this:
file:/buckets/foo-plan-20230920/2023092018_8000101.xml failed verify needle 2348:17180506: rpc error: code = Unknown desc = not found

The volume in question does exist, though, and contains the respective bucket:
volume id:2348 size:2655816 collection:"foo-plan-20230920" file_count:2179 delete_count:741 deleted_byte_count:564485 replica_placement:100 version:3 compact_revision:6 modified_at_second:1695230276

The error happens across multiple buckets.
Attempting to retrieve an affected file via S3 (using mcli) just hangs at 0 bytes:
$ mcli cp -r seaweedfs/foo-plan-20230920/2023092018_8000101.xml .
...230920/2023092018_8000101.xml: 0 B / 2.06 KiB ━┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉┉━^C%

Filer logs:
E0131 07:37:25.062631 filer_server_handlers_read.go:259 failed to stream content /buckets/foo-plan-20230920/2023092018_8000101.xml: read chunk: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
E0131 07:37:25.062661 common.go:297 processRangeRequest: read chunk: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
I0131 07:37:25.382782 filechunk_manifest.go:197 read http://<IP_ADDRESS>:8787/2348,0106275a926eb849 failed, err: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
I0131 07:37:25.383397 filechunk_manifest.go:197 read http://<IP_ADDRESS>:8787/2348,0106275a926eb849 failed, err: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
I0131 07:37:25.383407 filechunk_manifest.go:203 retry reading in 1s
I0131 07:37:26.385095 filechunk_manifest.go:197 read http://<IP_ADDRESS>:8787/2348,0106275a926eb849 failed, err: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
I0131 07:37:26.385644 filechunk_manifest.go:197 read http://<IP_ADDRESS>:8787/2348,0106275a926eb849 failed, err: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
I0131 07:37:26.385654 filechunk_manifest.go:203 retry reading in 1.5s
I0131 07:37:27.887368 filechunk_manifest.go:197 read http://<IP_ADDRESS>:8787/2348,0106275a926eb849 failed, err: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
I0131 07:37:27.888010 filechunk_manifest.go:197 read http://<IP_ADDRESS>:8787/2348,0106275a926eb849 failed, err: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
I0131 07:37:27.888021 filechunk_manifest.go:203 retry reading in 2.25s
I0131 07:37:30.139094 filechunk_manifest.go:197 read http://<IP_ADDRESS>:8787/2348,0106275a926eb849 failed, err: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
I0131 07:37:30.143433 filechunk_manifest.go:197 read http://<IP_ADDRESS>:8787/2348,0106275a926eb849 failed, err: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
I0131 07:37:30.143449 filechunk_manifest.go:203 retry reading in 3.375s
I0131 07:37:33.519529 filechunk_manifest.go:197 read http://<IP_ADDRESS>:8787/2348,0106275a926eb849 failed, err: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
I0131 07:37:33.520147 filechunk_manifest.go:197 read http://<IP_ADDRESS>:8787/2348,0106275a926eb849 failed, err: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
I0131 07:37:33.520161 filechunk_manifest.go:203 retry reading in 5.0625s
E0131 07:37:38.582855 filer_server_handlers_read.go:259 failed to stream content /buckets/foo-plan-20230920/2023092018_8000101.xml: read chunk: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found
E0131 07:37:38.582923 common.go:297 processRangeRequest: read chunk: http://<IP_ADDRESS>:8787/2348,0106275a926eb849?readDeleted=true: 404 Not Found

System Setup

master -ip=10.147.254.{1,2,3} -ip.bind=<IP_ADDRESS> -port=9333 -port.grpc=19333 -metricsPort=9324 -defaultReplication=100 -peers=<IP_ADDRESS>:9333,<IP_ADDRESS>:9333 -volumeSizeLimitMB=128
Ubuntu 20.04. Docker 24.0.8
version 30GB 3.62 59b8af99b linux amd64
if using filer, show the content of filer.toml: AFAICS filer is running with defaults as provided by the "official" Docker image

The cluster was in a kind of bad state for a few hours after a Docker upgrade to 25.0.x broke container IP addresses. This has been remedied by preserving (Docker) volumes and re-creating containers with Docker 24.0.8. However, I wouldn't expect this to cause data loss.
Any ideas how to reconstruct the index (?) are much appreciated.

version 30GB 3.62 - this version has a critical bug https://github.com/seaweedfs/seaweedfs/issues/5215
@chrislusf  Let's delete releases 3.60, 3.61 and 3.62?
People are losing data

Thanks for the speedy reply!
I do have backups, but am wondering how to figure out when the corruption happened. Any idea how to identify the point in time when things went downhill?

Thanks for the speedy reply!
I do have backups, but am wondering how to figure out when the corruption happened. Any idea how to identify the point in time when things went downhill?

After executing the background vacuum task, the index was saved with incorrect sorting and was truncated during mounting using Truncate.
Look in the logs for this line:
volume_checking.go:123 Truncate /data/bucket_254.dat from<PHONE_NUMBER>00 bytes to<PHONE_NUMBER>58 bytes!

https://github.com/seaweedfs/seaweedfs/pull/5259

I restored all nodes from backups and downgraded to 3.59. Unfortunately, filer is logging the following error since bringing the cluster back up on the old data:
I0201 21:00:46.485940 meta_aggregator.go:92 loopSubscribeToOneFiler read <IP_ADDRESS>:8888 start from 2024-02-01 20:54:20.656446769 +0000 UTC<PHONE_NUMBER>656446769
I0201 21:00:46.486726 meta_aggregator.go:259 readOffset <IP_ADDRESS>:8888 :<PHONE_NUMBER>091015551
I0201 21:00:46.486739 meta_aggregator.go:148 follow peer: <IP_ADDRESS>:8888, last 2024-01-27 01:06:49.091015551 +0000 UTC<PHONE_NUMBER>091015551)
I0201 21:00:46.486748 meta_aggregator.go:189 subscribing remote <IP_ADDRESS>:8888 meta change: 2024-01-27 01:06:49.091015551 +0000 UTC, clientId:1409806249
I0201 21:00:46.490764 meta_aggregator.go:103 subscribing remote <IP_ADDRESS>:8888 meta change: rpc error: code = Unknown desc = reading from persisted logs: reading /topics/.system/log/2024-01-27/01-07.4ab65cb6: http://<IP_ADDRESS>:8787/5756,0250798169726fc8?readDeleted=true: 404 Not Found

I guess this might be elated to the fact that the backups for all three involved hosts were taken at a slightly different time of the day. Any ideas how to fix this?

You are using leveldb for filer? If so, you can copy the filer directory from <IP_ADDRESS>:8888 to other filer instances, and then delete the missing system log file /topics/.system/log/2024-01-27/01-07.4ab65cb6

Looks like we have the same issue but our volume servers are not restarted so we didn't lose our data yet
What should I do to avoid losing data at this point?

version 30GB 3.62 - this version has a critical bug #5215
Data needs to be restored from backup.
@chrislusf Let's delete releases 3.60, 3.61 and 3.62? People are losing data

Does version 3.63 also suffer from this critical bug?
May be it worth noting this bug in the release notes.


Add "v2" and "2" tags to dockerhub releases

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you expect to see?
I expected that docker pull traefik:v2 will not result in not existing image.
I use traefik in docker swarm and watchtower to automatically update. I don't want to use latest tag, in case v3 is released.

I agree, can we please get this?

v3 and 3 as well please

This would be very helpful to keep it at latest version 2 and not upgrade to version 3 before I'm ready to do a lot of config changes.  Please add a latest version 2 tag, so I don't have to manually keep an eye on which is the latest and change the version manually.

Yes, please! We usually want to be on the latest version, but got a bit of downtime for all of our services after v3 was released. If we could just pin to the major version, that would be just about right...

@vini-nu could you rename the issue to Add major version tags to dockerhub releases (e.g. "v2", "2", "v3", "3") or similar?

closed as completed without comment or commit? I'm not seeing the new tags.

Hi @dumbasPL,
Sorry about that, we have an internal tool that generates Docker manifest file for official Docker build. This tool has been updated internally and for the next Traefik release the tags v2, 2, v3 and 3 will be available
This is why there is no commit associated
Linked to https://github.com/traefik/traefik/issues/11057


[RFC v2] Sass theming, theme zoning, and whitelabelling

This RFC is the second iteration of #1822. This addresses the feedback on the original RFC to:

Minimize breaking changes (renaming files, renaming Sass variables/mixins/functions)
Simplify custom theming
Be able to change more than just colors in inline themes

As demonstrated in the first commit, the only Sass change is calling @include carbon--theme; instead of @include carbon--theme-white();. The rest of the changes are in carbon-elements themes, which as open to change as they were introduced in v10.
Global Variables
Like before, global variables come from many different places specified with !defaults. Sass files often import global variables from @carbon/colors, @carbon/elements themes, etc. You can take any of those and globally define them in your custom Sass build:
$prefix: 'foo'; // from _vars.scss
$interactive-03: pink; // from _theme-tokens.scss, ultimately @carbon/elements
$carbon--orange-40: yellow; // from _colors.scss, ultimately @carbon/colors

@import '../node_modules/carbon-components/scss/global/styles.scss';

If you want to use a non-default theme like g10, g90, g100... now you can simply set the new carbon--theme global variable.
$carbon--theme: 'g90';

@import '../node_modules/carbon-components/scss/global/styles.scss';

If you wanted to modify one of the alternate themes, you can do that too!
$interactive-03: pink;
$carbon--theme: 'g90';

@import '../node_modules/carbon-components/scss/global/styles.scss';

Inline Themes
Regardless if you are using global variables for your default theme or not... you can define inline themes by setting global variables after styles.scss has been built. In this simple example, $interactive-03 is orange in the default theme and the inline theme with namespace class my-inline-theme sets $interactive-03 to pink then includes button declaration blocks.
$interactive-03: orange;

@import '../node_modules/carbon-components/scss/global/styles.scss';

@if feature-flag-enabled('components-x') {
  .my-inline-theme {
    $interactive-03: pink;
    @include button--x;
    // other component mixins go here to include in inline theme
  }
}

Should you want to include an alternate theme as provided by @carbon-elements, use the new mixin  carbon--theme-overrides that defines all tokens without !default so they can globally override the default declarations.
$interactive-03: orange;

@import '../node_modules/carbon-components/scss/global/styles.scss';

@if feature-flag-enabled('components-x') {
  .my-dark-theme {
    @include carbon--theme-overrides('g90');
    @include button--x;
    // other component mixins go here to include in inline theme
  }
}

To Do

[x] Refactor button example so you can call a colors mixin to prevent inline theme CSS bloat

Whitelabelling
Any global variable with a default value is fair game in default and inline theming. Let's say you wanted bigger buttons in your default theme and giant buttons in an inline theme. Assuming each component has separate colors mixins, if modifying something beyond colors, you'd need to call the full component mixin again.
$button-height: 100px;

@import '../node_modules/carbon-components/scss/global/styles.scss';

@if feature-flag-enabled('components-x') {
  .my-custom-theme {
    $button-height: 200px;
    @include button--x;
    // other component mixins go here to include in inline theme
  }
}

To Do

[ ] Evaluate button component variables, following Bootstrap's example on variable naming conventions and what component variables they include (colors, text, box model)

In the second commit, I demonstrate how we can move color properties to new color-only mixins. That allows us to prevent CSS bloat when using inline themes, since inline themes only include color changes. E.g.
@import '../node_modules/carbon-components/scss/global/styles.scss';

@if feature-flag-enabled('components-x') {
  .my-dark-theme {
    @include carbon--theme-overrides('g90');
    @include accordion-colors--x;
    @include button-colors--x;
    @include text-input-colors--x;
  }
}

Naming convention is that component mixins that only contain colors are suffixed with -colors.
Accordion
Accordion is a straight forward example. It may seem a little awkward to split up CSS shorthand like border into border-width and border-style in the main mixin, and border-color in the colors mixin, but I don’t find that a big deal. As a convention, it’s feels right to keep all use of color variables in the colors mixins.
You’ll also notice that included mixins that use color variables like @include focus-outline('outline’); have been moved to the -colors mixin.
Button
button/_mixins.scss has button-theme--x mixin, and I moved color properties out of that into button-theme-colors--x mixin. That’d be a breaking change, as somebody currently using:
@include button-theme--x(…vars);

Would need to modify to:
@include button-theme--x;
@include button-theme-colors--x(…vars);

If we’re concerned about that breaking change, we could create the button colors mixin in a way that doesn’t change the original theme mixin - it’d just have duplicated non-color declarations in inline theme CSS.
Input
Nothing new was discovered when creating text-input-colors—x, that hadn’t already been done in the accordion example.

@asudoh part two of this RFC is ready for review: color-only mixins to use in inline theming. As demonstrated in the second commit and the above comment, I tried it out with three components.
@joshblack do you have any ideas on how we could test for styling regression as this moves around outputted css source order a bit?

@mattrosno one potential way for checking this would be to "render" the styles in jsdom and then make sure the CSS Style Rules themselves are the same.
So something like:
test('some selector', async () => {
  // Render Sass to get the output
  const { result } = await renderSass(`
// Imports here
`);

  // Create the stylesheet and add the CSS as its content
  const stylesheet = document.createElement('style');
  stylesheet.textContent = result;

  // Iterate through cssRules to find selector in mind
  const selector = Array.from(stylesheet.cssRules).filter(/* ... */);

  // Make an assertion on the value of the selector
  expect(selector).toMatchSnapshot();
});

Copying note over from the other one, once concern I have is that we would need to parse out anything that is theme-able into it's own mixin. Is there any worry about how this could impact authorship? Seems like it could be easy to do the wrong thing when it comes to color and add it to the selector instead of pulling it out. In addition, would we have to do this for other theme-able properties in the future? For example, type, spacing, etc.

Thank you for coming up with the second round of RFC @mattrosno! Not sure if it's the same as what @joshblack brought up above, but wanted to understand why themeable colors are extracted out in a mix-in. It appears that other abstractions we have like variables, lower-level mixins are good enough for many places (e.g. border color of accordion) and CSS bloat is a concern only for extreme cases of customization (e.g. using some other property instead of border).

Color-Optimized Inline Theming
@asudoh the purpose of color-only mixins is inline theming. Why optimize inline theming for color overrides? Because that's the need. @joshblack with this approach, you could make an inline theme that modifies more than just colors with:
@import '../node_modules/carbon-components/scss/global/styles.scss';

@if feature-flag-enabled('components-x') {
  .my-crazy-theme {
    $button-height: 400px;
    $button-border-width: 10px;
    @include button--x;
  }
}

This uses the full button mixin. With that comes CSS bloat via unnecessary selector overrides. I don't see that happening often. I expect non-color global overrides to just be needed at the default theme level (also applied to inline themes).
A more realistic example is marketing page striping where sections of the page use alternate themes:

Page heros... call to action sections... all just modifications to color:

Authorship
@joshblack on authorship, it's just something that we document and enforce along with our BEM-style selectors, component variable naming convention, oh and when you use colors, do so in -colors mixins so those can be cleanly used in inline themes.

Thank you for more explanation @mattrosno! Your 2nd screenshot and the words around it give me an impression that you wanted component-specific, color-only theme zoning. Is it correct?

^ If so - From a technical sense I see the current codebase doesn’t have a good way to do that. OTOH, mulling over this topic further, I imagine that applying the notion of theme zoning only to a combination of specific styling area (color) paves a way for applications to easily lose UX coherency. Good to see without designers where we'd go with theme zoning.

@asudoh I think our Sass should allow anything to be used in inline themes to allow ultimate flexibility. That being said, I expect (through personal experience, discussions with various teams here) color-only changes to be the primary use of inline theming. That's why this RFC allows anything to be used in inline theming, and optimizes for color-only inline theming to minimize CSS bloat.
@photodow @elizabethsjudd can you chime in with your needs regarding inline theming?

@mattrosno This is beyond the scope of this PR but as I was reading these files, it would be nice if the mixins were defined in a separate file from the where the @include exports is declared so we can reference only mixins without fear of side effects in our CSS. (This would be a non-breaking change to existing Carbon users)
We use the carbon @include exports in WH and there are still areas where we are getting duplicate code in our generated CSS but I haven't had a chance to dig in to why it's happening on some components and not others.  Separating these aspects (code that is stripped from CSS and code that is the CSS output) in to separate files could be a failsafe for these concerns.

I'm still concerned on creating a mechanism extracting out components' color definitions to apply flexibility there. Though we strive toward flexibile APIs, I see adding flexibility there comes with significant overhead in our codebase (e.g. how Carbon core authors components) without being cautious on what we do in detail and how.
That's why it's good to better understand what are the underlying use cases behind and work with our designers to see what is the best way to meet the requirement. CC @IBM/carbon-designers to let them take a note and to see a chance to chime in.
What I would imagine about theme zoning is something like applying white theme to the main portion and g10 theme to some portions. Two screenshots in @mattrosno's earlier comment seem to represent such use case. That said, need to understand why @mattrosno seems to be trying to fiddle with our lower-level API instead of our higher-level API (set).

Can we set up a meeting and talk about this in person, to make sure we're (designers) are correctly understanding what's being proposed.

That said, need to understand why @mattrosno seems to be trying to fiddle with our lower-level API instead of our higher-level API (set).

That said, need to understand why @mattrosno seems to be trying to fiddle with our lower-level API instead of our higher-level API (set).

@asudoh changes to @carbon/elements/scss/themes as demonstrated in first commit necessary to (1) let app developers set default theme through global Sass variable and (2) let app developers define inline themes in their Sass builds.
Why modify lower-level component APIs? To optimize CSS output (reduce CSS bloat) for the most common use of inline-theming, which AFAIK is only colors. I have discussed the need with @photodow for marketing pages and with @elizabethsjudd for their portfolio's needs.
I guess we need more underlying use cases. No need to meet. @IBM/carbon-designers please share designs or supporting material for needing one theme inside another. After that, if we're in agreement that the primary purpose of inline theming is just for color changes, we then make the authorship vs CSS bloat decision to determine if we move CSS color declarations to mixins that only set colors.

@aagonzales and @jeanservaas have asked me to chime in here with some general thoughts about how the colors are intended to work in regards to our Dark and Light UIs. I’ve been wondering if referring to our default color system as having light and dark “UIs” helps us given that the word "themes" seems to be causing confusion in this context.
Here’s a few foundational principles:

There are 2 distinct UIs—Dark and Light. We’ve intentionally avoided the use of midtones and skewed towards either end of the spectrum.
Within each UI, there are several degrees of nuance and flexibility. The background color of the “zone” that is being designed is the primary factor in determining how the rest of the colors are applied.
There are 5 global background colors for any of these zones in the default dark and light UIs. In light, we use White and Gray 10 and in dark we use Gray 100 / 90 / 80.

Light UI:

In general, components with Gray 10 backgrounds are applied to white zones and components with White backgrounds are applied to Gray 10 zones. While this should probably be the limiting case for a default set, there is actually a bit more flexibility within the system. For example, a White table may sit on top of a White zone OR a Gray 10 zone. Both options are viable and constitute the light UI. Similarly, a card component with a White background may sit on top of a White zone OR a Gray 10 zone. Furthermore, both scenarios may exist in the same experience whether product or digital. Perhaps an alt or an override would be useful to classify these additional degrees of nuance.
The light UI does not use Gray 20 background zones, the nuances are achieved most commonly by alternating between White on Gray 10 and Gray 10 on White combinations. The dark UI is a different beast entirely with different behaviors.

Dark UI:

Contrary to the light UI with its alternating use of White / Gray 10 background layering, the dark UI always gets progressively lighter as layers are added. In other words, we never use a component background that is darker than the background zone it's being applied to. The same is true of interaction states, such as hover, selected and active.
In general, Gray 90 components are applied to Gray 100 background zones and Gray 80 components are applied to Gray 90 background zones.
Similar to the light UI, there is also the possibility of having a Gray 100 table sitting atop a Gray 100 background zone. The same applies to cards and various other components. To reiterate the possibility, perhaps the default set is Gray 90 on Gray 100 and Gray 80 on Gray 90 with alts and overrides being used to achieve combining the same component and background color as needed.
Another nuance within the system for dark UI is that one could also apply a Gray 80 component to a Gray 90 OR a Gray 100 background. One way to simplify may be to have the default case be 80 on 90 with an alt to use 80 on 100.
Because our layering gets progressively lighter in the dark UI, there are some occasions where we might use a Gray 70 component on a Gray 80 background. This scenario would be in the case of compound components specifically. For example, you may have a background zone of Gray 90 that you’ve applied a Gray 80 card too. Then on top of that Gray 80 card is an overflow menu with it’s own background color. In this case the overflow background would be Gray 70. The use of Gray 70 is only applicable in this compound component scenario.

It's much easier to grasp the concepts written above with visual examples. Attached is the latest working version of the Color UI page on Design Language for reference.

I'm going to do my best to outline some thinking around how our tokens and variables might work. Of course I have nearly 0% experience as a developer so I know very little about how tokens work but in a few discussions with different devs early on it did not seem entirely out of the ordinary to have a set of tokens that were dependent on another variable.
In regards to our system, I've always contemplated the tokens being dependent on the primary background color that the component is being applied to—White / G10 / G100 / G90 / G80. The same token would give you different colors dependent on which of the 5 global background colors are being used.
Take links for example, there isn't a single link color across the board. Even in light and dark UIs respectively, link colors are different depending on which zone it's sitting on. Primary buttons may be the only component that is the same across all of our backgrounds, everything else has a high degree of nuance driven by accessibility requirements above all else.
With all of that in mind. I'll share an exploration from many months ago regarding how tokens might play out for links. Again, I have no idea how this works so it should be considered merely as a logical exercise.

Thanks @mattrosno for explaining that the attempt to fiddle with lower-level API is for de-duping CSS rules, and @sadekbazaraa for outlining the theme zoning requirements in detail.
Starting with theme zoning requirements, though there are some constraints wrt what theme can be on what background, the set constraints are not as hard as I had imagined and I have an impression that it may not make sense to bake in the constraints to our Sass API level.
Wrt the requirements of de-duping CSS rules, I see the requirements is fair. My suggestion is utilizing toolchain instead of changing our Sass API. e.g. It's fairly easy to extract out non-color CSS rules with PostCSS. IIRC @joshblack has created JavaScript version of theme token table, and with that, I think we can extract out CSS rules just of theme colors.

My quick experiment showed that we can reduce the bundle including all components from 28K to 8K, minified/gzipped.

Thanks for sharing @sadekbazaraa. @asudoh regarding component mixins and the desire to not change them unless we need to... let me do this. Unless I hear otherwise, I'm under the impression that inline theming will be primarily done for only colors changes. (Components in inline themes can leverage modifiers if they need changes beyond color.)
I'll evaluate (1) baseline CSS bundle (minified/gzipped) all components as you did. Then (2) if a user defines an inline theme that includes all components using our mixins as-is. Then (3) as @photodow suggested, creating new color-only override mixins for each component to only use those in the inline theme.
I hope that will help give confidence in inline theming approach so we can make it happen.

@mattrosno thanks for the hard work on this. It's really looking great!
For Digital Design performance is critical. Especially where we are in development at the moment, and how it relates to theming. At the moment, it's looking like we'll need each variation for each component built out. As @mattrosno's work in progress here tries to avoid, I'd really like to avoid building out and delivering 4 copies of each component to our adopters. (That can get large fast even when you're using a minimum number of components) Anything we can shave off using these component color mixins would be very much appreciated. If padding isn't necessary in a g100 theme when it's already defined with the default white then why include it? With that said unless y'all have another solution in mind the separation of colors look like a great way to minimize the theming's impact on performance.
I don't know if y'all will support this in the future, but another need outside of color we have is updating the majority of the components to body-long-02 instead of the current default of body-long-01. I think @mattrosno addressed this need in this WIP as well. I have a hard time seeing at the moment we need it to be inline. After discussing with him things like this can be defined at the component level, and cross all theme variants.
If there is concern around governance. Like y'all don't want people like myself touching the lower level APIs. (e.g button--x, button--color--x) I wonder if adopters like myself could pass in the themes including potentially new themes to build it all vs. giving us the button--color--x and expecting us to build the themes. If possible this could potentially improve governance, simplicity from adopters like myself, and even enforce more consistency with the naming conventions and more. See example below...
Instead of adopters like myself doing the following that was proposed.
@import<EMAIL_ADDRESS>@import '~carbon-components/scss/components/accordion/accordion';

@if feature-flag-enabled('components-x') {
    @include button-colors--x; // default

    .my-theme-g10 {
        @include carbon--theme-overrides('g90');
        @include button-colors--x;
    }

    .my-theme-g90 {
        @include carbon--theme-overrides('g90');
        @include button-colors--x;
    }

    .my-theme-g100 {
        @include carbon--theme-overrides('g100');
        @include button-colors--x;
    }
}

We pass in the theme names we want to include, and y'all cycle through and build within the component?
// custom-pink theme defined earlier at the global level
$import-themes: ['g10', 'g90', 'g100', 'custom-pink'];

@import '~carbon-components/scss/components/accordion/accordion';

Just some thoughts, but maybe I'm getting ahead of the discussion here, or not have a full understanding of implications yet. Either way, if y'all still need more use cases after what @sadekbazaraa shared let me know, I'd be happy to track down some that we've worked directly on, and even some out in wild on IBM.com.

I like @photodow's idea for the default themes (would make things even easier for the end user) but I do think that doesn't resolve the issue for our users that need to be able to white-label.  We need the flexibility to call these mixins ourselves and make changes as needed without having to constantly change the name.

@photodow @elizabethsjudd thanks for the feedback! This is great. I'll crank out another commit to demonstrate how I see this working and get your feedback. Stay tuned!

Just in case I was not clear enough - Even though I see theme zoning is mostly about colors, I do not think it's a good idea fiddling with e.g. button-theme mix-in for the purpose of theme zoning (BTW I think button-theme name is confusing, as it's for defining different button variant). Given the requirement around fiddling with it is eliminating redundant style rules, we can do it with additional toolstack.
Creating styles for alternate themes in an application can be done by building our Sass code with alternate settings, and we may define a higher-level API for that purpose.

Given the requirement around fiddling with such mix-in is eliminating redundant style rules, we can do it with additional toolstack instead.

@asudoh can you give an example? What specific tool/library could take CSS like:
.foo {
  height: 100px;
  width: 100px;
  position: relative;
  background-color: red;
  border: 1px solid blue;
}

.my-theme .foo {
  height: 100px;
  width: 100px;
  position: relative;
  background-color: yellow;
  border: 1px solid green;
}

And optimize as
.foo {
  height: 100px;
  width: 100px;
  position: relative;
  background-color: red;
  border: 1px solid blue;
}

.my-theme .foo {
  background-color: yellow;
  border-color: green;
}

Or something similar so an inline theme with all components included doesn't nearly double CSS filesize?

@mattrosno It's PostCSS: https://postcss.org. It creates AST for CSS and where you can mangle - Very similar to Babel for JS. If we separate the former/latter rulesets, we can apply something like https://github.com/rsanchez/css-color-extractor, which is a PostCSS plugin. Extending that PostCSS plugin to apply color extraction only to ones with the selector beginning with .my-theme should be do-able, too.

Here are my findings. Using:
# get file size
du -h filename.css

# get file size when gzipped
gzip -c filename.css | wc -c

You can explore demo/scss/demo.scss to see the custom Sass builds for scenarios 1 - 4 below. I also made temporary changes to gulpfile.js so I had minified demo CSS.
Findings

File
Size
Gzipped

(1) Normal build all components

demo.css
272KB
30.0KB

demo.min.css
216KB
27.2KB

(2) With inline theme all components

demo.css
428KB
47.0KB

demo.min.css
352KB
43.2KB

(3) With inline theme all components using color override mixins

demo.css
328KB
35.4KB

demo.min.css
264KB
32.4KB

(4) With inline theme all components using PostCSS

demo.css
332KB
35.9KB

demo.min.css
272KB
32.7KB

It's clear that (3) file size is much better than (2). As shown in previous commit, color-only override mixins are very tedious and error-prone. (4) uses PostCSS to eliminate the need for authoring color-only override mixins. Using Gulp like so:
const postcss = require('postcss');
const colorsOnly = require('postcss-colors-only');
const removeSelectors = require('postcss-remove-selectors');

const inlineTheme = () =>
  through.obj((file, enc, callback) => {
    // 1. split up default and inline theme declarion blocks
    const defaultCSS = postcss()
      .use(
        removeSelectors({
          selectors: [/.my-dark-theme/],
        })
      )
      .process(file.contents.toString(enc)).css;

    const themeCSS = postcss()
      .use(
        removeSelectors({
          selectors: [/^((?!.my-dark-theme).)*$/],
        })
      )
      .process(file.contents.toString(enc)).css;

    // 2. only keep color declarations for the inline theme
    const themeColorsCSS = postcss()
      .use(colorsOnly())
      .process(themeCSS).css;

    // 3. concatenate default and optimized inline theme
    file.contents = Buffer.from(
      `${defaultCSS}
      ${themeColorsCSS}`,
      enc
    );

    callback(null, file);
  });

gulp.task('sass:dev:compiled', () =>
  gulp
    .src('demo/scss/demo.scss')
    .pipe(sourcemaps.init())
    .pipe(
      header(`
        $feature-flags: (
          components-x: true,
          breaking-changes-x: true,
          grid: true,
          ui-shell: true,
        );
      `)
    )
    .pipe(
      sass({
        includePaths: ['node_modules'],
        outputStyle: 'compressed',
      }).on('error', sass.logError)
    )
    .pipe(
      autoprefixer({
        browsers: ['> 1%', 'last 2 versions'],
      })
    )
    .pipe(inlineTheme())
    .pipe(
      rename(filePath => {
        filePath.extname = `.min${filePath.extname}`;
      })
    )
    .pipe(sourcemaps.write('.'))
    .pipe(gulp.dest('demo'))
    .pipe(browserSync.stream({ match: '**/*.css' }))
);

Recommendation

Create issue to update theme from @carbon/elements as shown in first commit. We don't need to touch any lower-level component Sass APIs.
Document how to override default theme in Sass build and how to inline theme.
Document how to use PostCSS to de-dupe CSS when using inline theming.
Move component variables to better support whitelabelling to a new RFC.

To reiterate, inline theming works like so, where after primary styles are built, you set your namespace class, whatever global variables you want (or use a helper like carbon--theme-overrides('g90')) and include just the components that you want in that inline theme.
@import '../../src/globals/scss/styles';
@if feature-flag-enabled('components-x') {
  .my-dark-theme {
    @include carbon--theme-overrides('g90');
    @include accordion;
    @include breadcrumb;
    // other components here
  }
}

Just trying to understand, but if y'all decide to go the PostCSS route you're removing duplicate CSS on build and begin to dictate/influence adopter's build process? Am I understanding that option correctly?
Maybe y'all are already doing that, and I'm just improperly building the code base. 🤭

@mattrosno Is the gulp work that you did going to actually be delivered to Carbon users?  We do this a lot in WH (look at our tools package) and it looks like it's pretty repeatable that it could be distributed with Carbon to users that want it.
To be clear, the new recommendation is that there isn't any new mixins and it's to use PostCSS (btw this was a really interesting concept. I've used PostCSS but not this plugin specifically).  My question that still remains about the accordion mixin is currently meant to be private mixins and the name  needs changed based on the the feature flag.  But the demo code specifically shows the "user" calling these mixins.

@photodow my opinion is that Carbon can't optimize product Sass builds, but we can share best practices on how to do so given product needs.
@elizabethsjudd I think it'd be great to define our build tools in an exportable way. Might need to be more of a post-v10 effort.
Correct, my recommendation is to leverage PostCSS and not create new mixins. Related to https://github.com/IBM/carbon-components/issues/1856, I understand the desire to not call --x mixins for inline theming. I'll add that to the recommended TODO list, moving the feature flag in the main mixin. E.g., from:
@mixin accordion {}

@mixin accordion--x {}

@include exports('accordion') {
  @if feature-flag-enabled('components-x') {
    @include accordion--x;
  } @else {
    @include accordion;
  }
}

To:
@mixin accordion {
  @if feature-flag-enabled('components-x') {
    @include accordion--x;
  } @else {
    // styles here
  }
}

@mixin accordion--x {}

@include exports('accordion') {
  @include accordion;
}

So accordion is public to be used in inline themes, and accordion--x is private. Is that what you're looking for?

Hey @mattrosno, if there isn't a second mixin for colors, but a developer needs alternate color versions of a given component, but they do not have the skillset/permission/access/whatever to change the build process, doesn't that leave them with bloated code and no way to fix it?
This choice feels like it's mixing the skillsets required to use carbon's sass files. It's not abnormal for the front-end UI person to have no access to changing the build processes. Seems like this hurdle could be avoided if the white-label-able parts were in their own mixin.

Great to hear that @mattrosno could achieve optimization to CSS output he needed! Given that, the only question here seems whether we want to make component mixins public. Given it was originally for stable/experimental switch and had no intention to make it public, we need to be careful to some extent. e.g.:

Should the component mixin take a theme token map as an optional argument, defaulting to the one of the applied theme?
Should we rename stable mixin so we can use that name (e.g. @mixin button) for entry-point purpose (doing stable/experimental switch inside)? - This discussion item will be stale once we do cleanup to eliminate stable code after v10 release, but just wanted to note

@scottnath

It's not abnormal for the front-end UI person to have no access to changing the build processes.

PostCSS we are discussing here is similar to Sass compiler from the perspective of the complexity of build toolchain setup - Instead of introducing a big leap there. PostCSS generates a mangled version of .css from a .css file, similar to Sass compiler that generates a .css file from a .scss file. Hope this makes sense.

Hey @mattrosno! 👋 Seems like the RFC has gone quiet, are we down for closing it and moving forward with the theme work over in elements?


demo broken in Safari

TypeError: undefined is not a function (evaluating 'Object.assign({},this.bindClass,{})')

Hi @raywill, Thank you for writing an issue~
I have just updated the Vue, hopefully it will fix the issue.
But I'm so sorry, I have no Safari to check it :cry:

Hey @raywill, I like to try to fix this issue. I have change the "Object.Assign" to "Lodash assign", but I haven't test it in Safari. Would you like to help me to test it?
Latest Commit - Fix Object.assign Safari

Good job! Fixed for both iphone saferi and Macbook saferi.


Write a documentation (readme)

Pictures in docs/images can be used to create a documentation.

Keycloak, or indeed most apps, ask for a lot of fields to configure auth and searches against crowd ldap. It would be nice to have the ldap-crowd fields in a table for things like baseDN, user DN, group DN, uid, RDN, entryUUID, object classes for user and group etc.
I can make a list from my recent struggles with keycloak

Such a list is a great idea.
The entryUUID attribute is currently not supported. However, I created a ticket for it. #14


feat: Sync from noir

Automated pull of development from the noir programming language, a dependency of Aztec.
BEGIN_COMMIT_OVERRIDE
feat: Sync from aztec-packages (https://github.com/noir-lang/noir/pull/5917)
chore: bump some dependencies (https://github.com/noir-lang/noir/pull/5893)
chore: make nested slice error more clear for [[T]; N] case (https://github.com/noir-lang/noir/pull/5906)
feat: better println for Quoted (https://github.com/noir-lang/noir/pull/5896)
feat: LSP diagnostics for all package files (https://github.com/noir-lang/noir/pull/5895)
feat: LSP code action "Fill struct fields" (https://github.com/noir-lang/noir/pull/5885)
chore: Cleanup str_as_bytes (https://github.com/noir-lang/noir/pull/5900)
chore: update git user for release PRs (https://github.com/noir-lang/noir/pull/5894)
END_COMMIT_OVERRIDE

Benchmark results
Metrics with a significant change:

protocol_circuit_simulation_time_in_ms (private-kernel-tail-to-public): 767 (-42%)
avm_simulation_time_ms (Token:assert_minter_and_mint): 304 (+545%)
avm_simulation_time_ms (Token:transfer_public): 23.5 (+74%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.

Metric
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256_ms
5,758
1,561
713
745 (+1%)
778

proof_construction_time_sha256_30_ms
11,475 (-1%)
3,081
1,377 (-1%)
1,423
1,452 (-1%)

proof_construction_time_sha256_100_ms
44,094
11,806
5,438
5,539 (-6%)
5,723 (-2%)

proof_construction_time_poseidon_hash_ms
78.0
34.0
34.0
60.0 (+2%)
87.0 (-1%)

proof_construction_time_poseidon_hash_30_ms
1,527
421
202
231
269

proof_construction_time_poseidon_hash_100_ms
5,643
1,533 (+1%)
671 (-1%)
722 (-1%)
738 (-1%)

L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
4 txs
8 txs
16 txs

l1_rollup_calldata_size_in_bytes
4,356
7,876
14,884

l1_rollup_calldata_gas
50,196
92,930
178,288

l1_rollup_execution_gas
843,037
1,576,667
3,362,081

l2_block_processing_time_in_ms
252 (-2%)
448 (+2%)
799

l2_block_building_time_in_ms
10,874
21,383 (+1%)
42,453 (+1%)

l2_block_rollup_simulation_time_in_ms
10,874
21,382 (+1%)
42,453 (+1%)

l2_block_public_tx_process_time_in_ms
9,258
19,753 (+1%)
40,779 (+1%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 8 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
3,052 (+3%)
3,947 (+1%)

node_database_size_in_bytes
12,484,848 (+1%)
16,449,776

pxe_database_size_in_bytes
16,254
26,813

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Circuit
simulation_time_in_ms
witness_generation_time_in_ms
input_size_in_bytes
output_size_in_bytes
proving_time_in_ms

private-kernel-init
71.7 (-7%)
378
21,377
44,898
N/A

private-kernel-inner
157 (+3%)
676
72,358
45,020
N/A

private-kernel-reset-tiny
276 (+1%)
687 (+3%)
65,018
44,886
N/A

private-kernel-tail
149
127 (-2%)
50,589
52,921
N/A

base-parity
5.54
N/A
160
96.0
N/A

root-parity
35.0 (-1%)
N/A
73,948
96.0
N/A

base-rollup
3,029
N/A
189,207
664
N/A

block-root-rollup
41.1
N/A
58,205
2,448
N/A

public-kernel-setup
79.9 (+1%)
N/A
105,085
71,222
N/A

public-kernel-app-logic
92.6
N/A
104,899
71,222
N/A

public-kernel-tail
799
N/A
390,582
16,414
N/A

private-kernel-reset-small
271 (+1%)
N/A
66,341
45,629
N/A

private-kernel-tail-to-public
:warning: 767 (-42%)
578 (-5%)
446,144
1,825
N/A

public-kernel-teardown
78.4
N/A
105,349
71,222
N/A

merge-rollup
20.1 (-1%)
N/A
38,174
664
N/A

undefined
N/A
N/A
N/A
N/A
82,610

Stats on running time collected for app circuits

Function
input_size_in_bytes
output_size_in_bytes
witness_generation_time_in_ms

ContractClassRegisterer:register
1,344
11,731
344

ContractInstanceDeployer:deploy
1,408
11,731
18.1

MultiCallEntrypoint:entrypoint
1,920
11,731
401

FeeJuice:deploy
1,376
11,731
383 (-1%)

SchnorrAccount:constructor
1,312
11,731
62.5

SchnorrAccount:entrypoint
2,336
11,731
370

FeeJuice:claim
1,344
11,731
36.4 (+6%)

Token:privately_mint_private_note
1,280
11,731
75.3 (-4%)

FPC:fee_entrypoint_public
1,344
11,731
26.7 (+6%)

Token:transfer
1,312
11,731
212

Benchmarking:create_note
1,344
11,731
74.8 (+1%)

SchnorrAccount:verify_private_authwit
1,280
11,731
26.3 (-11%)

Token:unshield
1,376
11,731
495 (-1%)

FPC:fee_entrypoint_private
1,376
11,731
655 (-2%)

AVM Simulation
Time to simulate various public functions in the AVM.

Function
time_ms
bytecode_size_in_bytes

FeeJuice:_increase_public_balance
52.8 (+15%)
2,307

FeeJuice:set_portal
13.1 (-6%)
2,680

Token:constructor
76.1 (+2%)
13,839

FPC:constructor
49.7 (+2%)
8,553

FeeJuice:check_balance
38.8 (+4%)
2,041

Token:mint_public
451
4,572

Token:assert_minter_and_mint
:warning: 304 (+545%)
3,006

AuthRegistry:set_authorized
45.4 (-1%)
923

FPC:prepare_fee
70.2 (-5%)
3,925

Token:transfer_public
:warning: 23.5 (+74%)
9,482

FPC:pay_refund
45.4 (+13%)
4,856

Benchmarking:increment_balance
1,163
3,170

Token:_increase_public_balance
37.3 (-4%)
2,284

FPC:pay_refund_with_shielded_rebate
52.9 (+7%)
4,856

Public DB Access
Time to access various public DBs.

Function
time_ms

get-nullifier-index
0.167 (+6%)

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
256 leaves
512 leaves
1024 leaves

batch_insert_into_append_only_tree_16_depth_ms
2.16 (+1%)
3.86
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.8
31.7
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.112 (+1%)
0.108
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
11.4 (+3%)
17.8 (+1%)
30.4 (-3%)
60.7 (+3%)
112

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
287
543
1,055

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.109 (+3%)
0.103 (+1%)
0.0987 (-3%)
0.104 (+3%)
0.0990 (-2%)

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
14.1
25.7 (+1%)
43.2 (-3%)
83.4 (+3%)
160

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
107
207
355
691
1,363

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.108
0.103 (+1%)
0.105 (+2%)
0.103 (+3%)
0.102 (+1%)

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
16.7 (+2%)
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
132
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
0.107 (+2%)
N/A
N/A
N/A
N/A

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
64,838
668,997

Transaction size based on fee payment method
| Metric |  |
| - |  |


Scrolling: Using a UIScrollView makes the y-Axis disappear

Hey,
first of all, thanks for the library!
I have a question on scrolling. In the examples scrolling is enabled through a UIScrollView which contains the hole chart-view. That way the y-axis isn't visible any more when the user scrolls.
Would it be possible to implement that the axis stay visible? Could you describe which steps would be required to take (high level), then I would try :)

You can create a second chart with only the y axis and remove it from the original chart. And add the view of this chart on top of the original chart.
I tried the steps myself because I wanted to confirm it works, so you get the code ;)
let chart = Chart(
    frame: chartFrame,
    layers: [
        xAxis,
        // removed yAxis
        guidelinesLayer,
        chartPointsLineLayer
    ]
)
// add another chart with only yAxis
let axisChart = Chart(
    frame: CGRectMake(0, 70, yAxis.rect.width + ExamplesDefaults.chartSettings.leading, yAxis.rect.height + ExamplesDefaults.chartSettings.top + 7), // 7 is such that the first axis label is not cut at the bottom
    layers: [
        yAxis
    ]
)
scrollView.addSubview(chart.view)
self.view.addSubview(scrollView)
axisChart.view.backgroundColor = UIColor.whiteColor() // opaque background such that we don't see the scrollview's contents behind
self.view.addSubview(axisChart.view) // axisChart view is now over scrollview and will not scroll
self.axisChart = axisChart
self.chart = chart

There's one little issue though with the x-axis labels, as you see the axisChart frame doesn't cover the bottom and you will see the x labels scrolling below it. The reason is if it does it would cut the first x-axis label. One possible solution is to not show a label at the origin of x-axis, then you can set the height of axisChart to cover also the bottom.

Wow, what a simple but effective solution. Works like a charm!
Thank you very much.


Cleanup some dartfmt / publish --dry-run complaints

Resolve some of the complaints from pub:
https://pub.dev/packages/graphql/versions/1.1.1-beta.5#-analysis-tab-
Also moved graphql/utility.dart to graphql/utlities.dart for consistency

Codecov Report

Merging #331 into beta will decrease coverage by 0.72%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             beta     #331      +/-   ##
==========================================
- Coverage   57.88%   57.16%   -0.73%
==========================================
  Files          30       32       +2
  Lines        1211     1242      +31
==========================================
+ Hits          701      710       +9
- Misses        510      532      +22

Flag
Coverage Δ

#graphql_client
57.88% <ø> (ø)
:arrow_up:

#graphql_flutter
29.03% <ø> (?)

Impacted Files
Coverage Δ

...kages/graphql/lib/src/core/raw_operation_data.dart
87.5% <ø> (ø)
:arrow_up:

...phql_flutter/lib/src/widgets/graphql_provider.dart
16% <0%> (ø)

...phql_flutter/lib/src/widgets/graphql_consumer.dart
83.33% <0%> (ø)

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 d5bea2d...2788319. Read the comment docs.

:tada: This PR is included in version 1.1.1-beta.6 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Incorrect name Customer Data Service for Apps

Changed Customer Data Service for Apps to Common Data Service for Apps.

Thanks for bringing this to my attention. Took to live via my working branch.


chore(syncing): hotfix for syncing without response

I do know how is this happening, but we somehow end up without any syncing repose from peer (maybe this TP is overloaded?), because we still received other packets from that peer.
This should fix it.

prnet cleaned-up successfully


RuntimeError when using pylint

This issue was reported via the feedback survey.
Environment data

VS Code version: 1.24.1 (24f62626b222e9a8313213fb64b10d741a326288)
Extension version (available under the Extensions sidebar): 2018.6.0
OS and version: Windows 10
Python version (& distribution if applicable, e.g. Anaconda): 3.7
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
Relevant/affected Python packages and their versions: pylint==1.9.2, dataclasses==0.6

Actual behavior

Expected  behavior
Linting should not fail
Steps to reproduce:

Install and enable pylint, workspace settings:

{
    "python.pythonPath": "C:\\Python37\\python.exe",
    "python.linting.flake8Enabled": false,
    "python.linting.pylintEnabled": true,
}

Install dataclasses.
Repro:

from dataclasses import *

I've reproduced this on Linux (Ubuntu 18.04) and Python 3.7.0 on the insiders build. Hovering over the 'from' will show the same popup with the same error.

Seems that pylint isn't 100% compatible with Python 3.7 (yet). See PyCQA/astroid#539 and the hint near the last comment in PyCQA/pylint#2234. If you install the latest pre-release of PyLint you will see it works:
python -m pip install --pre pylint
and then see your file:

We should close this as its not causing any issues in the extension. Basically we're reporting the errors as we get them from pylint.
Or am I missing something?

You are correct, sir.


mixin and extends have a different behavior than Vue 2

Version
3.0.0-rc.9
Reproduction link
https://jsfiddle.net/ef6o4rLd/2/
Steps to reproduce

see the console

What is expected?
properties defined in the component should have a higher priority than properties from extends and mixin
What is actually happening?
mixin and extends properties override those defined in the component

vue2 works well : https://jsfiddle.net/whv3dLzq/6/

sorry I just find that it's a duplicate issue with #1978 😂


Add proper logging, use logger as one should using Python

And use https://www.structlog.org/en/stable/getting-started.html for structured logging

Use https://www.structlog.org/en/stable/getting-started.html for structured logging

Done, using structlog.


Injecting one Scheduled service into another fails.

When injecting one scheduled service into another, the injection fails. Here's my situation:
A.module.ts
...
providers: [AService],
exports: [AService],
...

A.service.ts
...
@Scheduled()
@Injectable()
export class AService {
...

B.module.ts
...
imports: [AModule],
providers: [BService],
...

B.service.ts
...
@Scheduled()
@Injectable()
export class BService {
    constructor(private aService: AService) {
...

This fails with the following error:
Nest can't resolve dependencies of the  (?). Please make sure that the argument + at index [0] is available in the BModule context.

If I remove one of the @Scheduled decorators, injection works as expected.

@PalokhaO, lib is deprecated. Use @nestjs/schedule


Manually creating a script tag does not use the set prefix

Using a configuration with a delayed script tag and a prefix, the prefix is not used when the script tag is inserted and first page view generated.
I've identified the place with the error and will be submitting a pull request.

thanks for the PR, merged !


[docs] Add documentation for GPU w/ docker-engine

What this PR does / why we need it: GPU nodes require docker-engine. Add documentation for the current workaround implementation. Follow-up for #4262.
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
If applicable:

[ ] documentation
[ ] unit tests
[ ] tested backward compatibility (ie. deploy with previous version, upgrade with this branch)

Release note:

/hold incoming PR to change the implementation

/lgtm


Release Google.Cloud.SecurityCenter.V1 version 3.10.0

Changes in this release:
New features

Add cloud_dlp_inspection and cloud_dlp_data_profile fields to finding's list of attributes (commit f4c7a0e)

Documentation improvements

Miscellaneous style improvements (commit f4c7a0e)

Created release for Google.Cloud.SecurityCenter.V1-3.10.0


Parameter System Testing

This draft pull request includes Python scripts which can be used with COSMOS to test parameter system functionality, namely table validate and table update commands. A mock table is generated as a byte array, and various responses are scintillated by sending commands and checking the Software_Status_Packet that is returned.

Since commit 8bc9f2d, it will be necessary to ensure bitstring is installed in the COSMOS Script Runner container. This is needed by the Adamant parameter_table_record Python import. This can be achieved by running:
docker exec -it cosmos-project-openc3-cosmos-script-runner-api sh

Followed by:
pip install bitstring


change the special local variables

_returned_ -> _return
_raised_ -> _raised
On info command, show _... instead of %...
But if there is a local variable conflicts with special
variables, use %... and do not introduce special lvars.

Another idea is $_return.


Select alias in PSSQLite.psm1

This is kind of an odd one and I can fork and fix if you want, but in the PSSQLite.psm1 file you're using the alias for Select-Object as part of the function export process (at the end).  Under normal circumstances this is totally ok, however I've been banging my head over the last few days trying to figure out why I can't get the PSSQLite module to work as part of a constrained endpoint (JEA) and after doing a lot of debugging the use of the Select alias is not playing nice with a locked down endpoint\shell (SessionType='Empty' and LanguageMode='RestrictedLanguage').  I tried defining Select as a valid alias with VisibleAliases but the only way I could get it to work is if I edited the module and spelled out the alias as Select-Object.
So anyway we can get the Select alias removed and the full cmdlet name put int the PSSQLite module file?  I can do it if you want, but it seems like a really small change :)

Must have missed this!  Sure, makes sense to me, would gladly take a PR : )  I should probably start adding psscriptanalyzer gating for particular rules to avoid cases like this
Thanks!

Alright...pull request in.  Take a look.  I also am working on
Invoke-SqliteTransaction to execute a series of statements in a transaction
which I'll be submitted soon.
On Mon, May 1, 2017 at 12:21 PM, Warren Frame<EMAIL_ADDRESS>wrote:

Must have missed this! Sure, makes sense to me, would gladly take a PR : )
I should probably start adding psscriptanalyzer gating for particular rules
to avoid cases like this
Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/RamblingCookieMonster/PSSQLite/issues/13#issuecomment-298365960,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGBoYE5-B1a_7m4piWfVwmhEg5hHvBhKks5r1gZ-gaJpZM4M-qei
.


Name Change Suggestion

I would propose changing the name to binary-info or bin-info or something related for search optimization since it basically provides information about binary files.

makes sense - i also see that in crates bininfo is available... thats for the suggestion


Structured output

Related to #28
We should also support structured output, i.e., validate the output with Pydantic and retry if necessary. This library supports it: https://docs.phidata.com/assistants/structured-output
Seems doable with https://python.langchain.com/v0.2/docs/how_to/extraction_parse/#using-pydanticoutputparser

Solved by https://github.com/vintasoftware/django-ai-assistant/pull/171


Abstract wineclassification.ipynb into modular files

Abstract methods section (pipeline construction - tuning the different models) into its own .py file
Abstract data visualization code (EDA and end viz) into it's own .py file
Create at least four modular files out of our literate code document

2 created: optimize + pipeline
2 more to create: eda + ?


Major Makefile Refactoring

Coverage remained the same at 81.81% when pulling 5a8768222f4e81cca24868944fa39267a400ffbe on makefile-refactor into 3b59363ab7a9a4701cc1821e34ae49063c584320 on master.


Create documentation with Sphinx

Setup the doc with Sphinx and eventually GitHub pages.

GitHub pages
This is just the indication where we take the documentation. The idea is to use a specific 'gh-pages' branch where the documentation is stored in html format. Then we can normally see the site under M05-project-group5.github.io/mini-project/index.html.

The documentation with Sphinx and GitHub pages is done when a tag is push.
The code for that is in the continous integration.


scala single line unnecessary :pate & interpreting

I am a bit bothered by this, but not a show stopper.
When I send a single line on Scala.
via:
autocmd Filetype scala nmap \ :call luaeval('require("iron").core.send(_A[1],_A[2])', [&ft, getline('.')])
line is =     val sr = Set( 1 to 5 ) // Set[Range.Inclusive] = Set(Range.Inclusive(1,2, 3, 4, 5))
I get following verbose interaction on the terminal
scala> :paste
// Entering paste mode (ctrl-D to finish)

    val sr = Set( 1 to 5 ) // Set[Range.Inclusive] = Set(Range.Inclusive(1,2, 3, 4, 5))

// Exiting paste mode, now interpreting.
sr: scala.collection.immutable.Set[scala.collection.immutable.Range.Inclusive] = Set(Range(1, 2, 3, 4, 5))
scala>

The :paste ... // Exiting paste mode, now interpreting. seems unnecessary for a single line sending.
This should be reserved for multiline.
Python repl does not do this & look clean.
Thanks much,

Hi, thanks for the issue.
I'll check this. It should be simple to fix for single line.
Cheers

Would really be great!
Apologies about bother u about the darn software (apt) problem. I would have never guessed until I dug in deeper.
Thank you,

I'm really sorry for not looking at this before. It should be fixed by the commit above.
I'm trying to burn down all the issues on my projects now, so hopefully this is still relevant.
Best regards,
Henry.

The commit was reverted as it caused #127. I'll approach this with another solution, more specific for scala.


Default CAE challenge handling in BearerTokenAuthenticationPolicy

This adds handling CAE challenges by default in our policy.
Fixes #41984

API change check
API changes are not detected in this pull request.


Integrate StoryRecordingClient with Admin/Metadata operations client

This ticket depends on Issue #33  and Issue #30
The task is to integrate client RPC communication with the ChronoVisor process and client RPC communication with the ChronoKeeper processes under the same chronolog client   interface. The client should maintain  its connection state as well the state of  all the chronicles/stories it has acquired.

client integration changes are done on branch 52-client-integrations


Warning in logs : 'sensor' implements device_state_attributes. Please report it to the custom component author.

Hello,
HA 2021.12 updates the sensor mechanism so i guess update needs to be backported :
device_state_attributes has been deprecated and replaced with extra_state_attributes
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_parking_light (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_doors_locked (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_door_closed_left_front (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_door_closed_right_front (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_door_closed_left_back (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_door_closed_right_back (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_trunk_locked (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_trunk_closed (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_hood_closed (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_windows_closed (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_window_closed_left_front (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_window_closed_left_back (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_window_closed_right_front (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-15 20:15:10 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.ibiza_window_closed_right_back (<class 'custom_components.seatconnect.binary_sensor.SeatBinarySensor'>) implements device_state_attributes. Please report it to the custom component author.

Regards

Yes I will fix this in upcoming release, right now it's only an eyesore though and I don't have much time for this at the moment.


Introduce part operation.

Valid when at least one rule is valid
Returns AST with all errors in case no rules are valid
Add visit_set and visit_part to Result

One of the changes I mentioned in:
https://discourse.dry-rb.org/t/extensions-for-dry-logic-and-dry-validations-to-support-open-api-schemas/525
I have 2 questions about the implementation:

Is name part good?
Is it enough to return Result::SUCCESS or should I put successful or failed rules into successful result?

@solnic Just after some thinking, we can imagine 2 different groups of operations:

Applying a rule to multiple items, Each already exists, I'd expect also Any. and some operation either to verify that rule returns true from a to b items(or just 1). None can be a shortcut to Not(Any(...)) or a separate rule, also there can be All as alias to Each. Not sure if a rule or shortcut for Not(Each(...)) is required.
Applying multiple rules to a single item(it can also be an array, Set already exists, Part is in this PR, I'd expect also expect a rule from a to b rules are true(or just 1). Not sure about negation, it can be exposed via Not(Part(...)) and Not(Set(...)), but we can also provide shortcut or rule.

By shortcut I mean applying 2 rules via 1 method/class without creating new kind of operation and new type of ast.
WDYT?


an error about migraphx::load

I use migraphx::save to save the CRNN((Convolutional Recurrent Neural Network)) model successfully,but migraphx::load can not load the saved model. I do not know why. The migraphx is from commit 7596f3f10ffc66b9c09d35bcc7b72af808f395af.
the model link : https://drive.google.com/file/d/18ftm_ve6vty7o5upiKbPGUuWL7wQ13ao/view?usp=sharing
the part of the code is as follows:
  // save
  migraphx::program net= migraphx::parse_onnx("dynamic_crnn_2048.onnx");
  migraphx::compile_options options;
  net.compile(migraphx::gpu::target{},options);
  migraphx::save(net, "CRNN.mxr");
  ...

   // load
    std::string pathOfModel="dynamic_crnn_2048.mxr";
    migraphx::program net = migraphx::load(pathOfModel);
    ...

Are there any error outputs?

@CharlieL7 ,Segmentation fault

I'm not able to compile this model; same problem from the previous issue. It does look to be CPU memory maxing out. Need to make some adjustments on my system to test this out.

@CharlieL7 ，this is the same model with issue #1319,I create a new issue .

@CharlieL7 , you can use a smaller size to make the compile faster.the code:
    migraphx::onnx_options onnx_options;
    onnx_options.map_input_dims["input"]={1,1,32,256};
    migraphx::program net= migraphx::parse_onnx("dynamic_crnn_2048.onnx",onnx_options);

I have compiled the full model and I see the same segmentation fault on trying to load. There's likely an issue during the compiling process to begin with, as we shouldn't need to have 50+ GB of RAM to compile the model. I will need to investigate the issue. It might take me a while to pin down the cause. Let me know if you get any clarifying information.

Hi @qianqing13579. Can you please check if your issue still exist with the latest ROCm? If not, please close the ticket. Thanks!

Hi @qianqing13579,
I tried compiling, saving, and loading the given model, and was able to do so successfully without any seg faults. Could you please try again on the latest version of ROCm/MIGraphX and see if the issue is resolved? I used the following python script:
import numpy as np
import migraphx as mgx
from functools import wraps

class Test():
    def __init__(self):
        print("Load model")
        self.model = Test.load_mgx_model()

    def load_mgx_model():
        file = "dynamic_crnn_2048"
        print("Parsing from onnx file...")
        model = mgx.parse_onnx(f"{file}.onnx")
        model.compile(mgx.get_target("gpu"))
        print("Saving model to mxr file...")
        mgx.save(model, f"{file}.mxr", format="msgpack")
        model = mgx.load(f"{file}.mxr", format="msgpack")
        print("Loaded Successfully")
        return model

if __name__ == "__main__":
    test = Test()


cmd/cue: import/export (go|rust|...)

In #646 we discuss renaming cue get go to be cue import go. In the future we also intend to more clearly support exporting from CUE to some other language representation (this is currently made possible via the cuelang.org/go/encoding/gocode package) from the command line.
Which begs the question: what about languages other than Go?
For example, @nyarly has previous enquired about Rust being added to that list.
This is a general placeholder for import/export support for "insert your language here".
Building on the motivation in #646, this would purely be the support for importing/exporting from/to "a another language", e.g. Rust. The method for resolving packages (or the equivalent in any given language) would be delegated to language specific tooling/loader/something. e.g. for Go, package resolution is handled by go/packages, which requires that (as of Go 1.16) a go.mod is present through which a package can be resolved.

I wonder if there is a way to use tree-sitter in reverse, given all the language grammars that have accumulated there.
There looks to be an unofficial Go binding here: https://github.com/smacker/go-tree-sitter

For import (currently cue get go) we need type information for Go, and suspect we would for every other language: syntax by itself would not be enough (unless I misunderstood what you were suggesting, or am missing a piece in the puzzle here with respect to tree sitter?). For export I'm not sure of the need for a common format - we simply need to take convert from CUE API values (already well defined) to a target language (could be as simple as fmt.Printf calls, could use text/template, could use an AST for the language...)

This issue has been migrated to https://github.com/cue-lang/cue/issues/1036.
For more details about CUE's migration to a new home, please see https://github.com/cue-lang/cue/issues/1078.


Sink drop

Fixes sinks to correctly stop playing sounds when they are dropped.

Sorry for the misunderstanding, but since your three PRs have things in common it's ok to submit them together. It would avoid you having to solve merge conflicts.
Anyway, looks good except for the small problems.


Feedback from porting Yasteroids

Speaking of https://github.com/kvark/yasteroids/pull/2  - since it's the largest existing project using specs, I thought I'd share my impressions of using it at this scale:

system interface is needed (#30), so that the systems are moved between threads, and their contents don't need to be syncable
run shortcuts have a very limited use - only 2 out of 6 of the systems I got use it. We should focus instead on the custom run ergonomics, or empower the shortcuts with more abilities.
overall it was mostly a pleasure to use it after simplecs, although checking for components in custom run functions is still quite noisy.
it's non-trivial to get the BitSet performance by writing our custom runs
dynamic entity creation/deletion works extremely nice and convenient. I used to do pooling of the like-entities in order to avoid creating them (which was simply not supported), but now the code is absolutely clean and lean.
I had to fix a few places in specs in order for it to work. We need to establish strong rules about the order we lock things in (to avoid deadlocks).

Everything is fixed by #45 and #41, and #39


refactor: move styles to theme for form reorder

Closes https://github.com/yamada-ui/yamada-ui/issues/3925
Description

Current behavior (updates)

New behavior

Is this a breaking change (Yes/No):

Additional Information

🤔
❯ pnpm prettier --write packages/react/src/components/reorder
packages/react/src/components/reorder/index.ts 34ms (unchanged)
packages/react/src/components/reorder/reorder-context.ts 9ms (unchanged)
packages/react/src/components/reorder/reorder-item.tsx 18ms (unchanged)
packages/react/src/components/reorder/reorder-trigger.tsx 5ms (unchanged)
packages/react/src/components/reorder/reorder.stories.tsx 21ms (unchanged)
packages/react/src/components/reorder/reorder.test.tsx 18ms (unchanged)
packages/react/src/components/reorder/reorder.tsx 13ms (unchanged)


Simple_GA: Wrong decay parameter ("sigma_limit" instead of "sigma_decay")

It seems that there is a typo in the SimpleGA strategy's "tell_strategy" method (line):
Instead of updating state["sigma"] with state["sigma"] * state["sigma_decay"] (correct), it says: state["sigma"] * state["sigma_limit"] (wrong).

Good catch! Thank you very much. It is fixed in 57235ca15c75ec9804463f31286c1ff96b580708.


⬆ Upgrade version of Starlette to >= 0.36.3

⬆ Upgrade version of Starlette to >= 0.36.3

@tiangolo There was an unintentionally breaking change that affected Starlette from 0.36.0 to 0.37.0.
Fixed in v0.37.1: https://github.com/encode/starlette/pull/2485
Could you pls bump requiremens to starlette>=0.31.7 and release FastAPI v0.109.2?

I agree - https://github.com/tiangolo/fastapi/pull/11146
@tvasenin - what is the Starlette API deprecation policy. Wondering if we need a max version

I agree - #11146
@tvasenin - what is the Starlette API deprecation policy. Wondering if we need a max version

I'm not aware of Starlette deprecation policy -- though, given the v0.x version scheme, according to SemVer, anything could happen in any release :)

Newly released v0.110.0 still has the old dependency -- here's PR #11320 to finally fix this.


Setting Long-form posts in Content Filters always reverts to displaying Notes Instead of Long Form Content

In admin, I changed the Content Filter to show only "Long-form Posts". Regardless of this setting site is populated with Notes instead of "Long-form Posts". It ocassionally works just after changing this setting but always reverts to Notes.

Hi apologies about that, fixed it for your site. Latest site event wasn't published on our relay, and another issue didn't let us fetch it from your outbox relays.
We've created another issue for this case, and your site should be fine now, is it?

Yes, seems to be working correctly now.


fix(UI/Strings/tr): Improve translation of dark

Previous translation of dark = karanlık is not widely used in software in the context of dark mode.

Thanks for the fix!


pytest missing

pytest is missing from the requrements.

py.test isn't a requirement as it isn't needed by a user. I don't think it should be in the requirements.

Good point.


SRIOV integration for OpenStackVmSets

NOTE: This will require changes to dev-tools before it should ever be merged!  Among them:

Logic to install SRIOV network operator
Changes to OLM subscription to watch openshift-sriov-network-operator namespace in addition to those already included
For dev/testing in virtualized environments: logic to use the new "virtualized SRIOV" functionality

Adds a new OspNetwork option to OpenStackVmSets (which will we later surface in OpenStackControlPlane once we finalize the design) to allow a user to configure SRIOV on CNV VMs.

This is now outdated.  We are taking a different approach.


Add queryset filtering on HistoryManager with as_of support.

Description

The discussion in #397 is about using filtering and querysets with point-in-time queries.  The current as_of implementation returns a generator so it can only be used to make a single query and obtain the result.  It does convert those results to the genuine model.  The ideal solution would allow someone to express the following:
    queryset = MyModel.history.filter(as_of=<datetime>, ...)

That's what this pull request provides.  One of the challenges with as_of filtering is handling deletions; the logic is not trivial and requires a subquery.  When querying this way you get a queryset that returns Historical models, unless you tell it you want genuine instances:
    queryset = MyModel.history.filter(as_of=<datetime>, ...).as_original()

Calling as_original on the queryset will cause it to return genuine instances instead of historical records.  You can still query directly on history_date if you want to be able to retrieve deletion records.  You cannot query on as_of with any qualifiers like __lte.
I had originally made the as_of query a method on the HistoryManager called as_of_filter.  One benefit to this approach is that if the original model had a field named as_of there would not be a conflict.  However it seems more natural to allow an as_of filter expression, so that's what I'm submitting as a solution.
Also note there is a small test change to deal with #862 before it gets merged.
Related Issues

#229
#354
This closes #397
#715
Motivation and Context

A long-standing issue that kept me from using the library effectively.
How Has This Been Tested?

Tests were added, all tests pass.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X] I have run the make format command to format my code
[X] My change requires a change to the documentation.
[X] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.
[X] I have added tests to cover my changes.
[X] I have added my name and/or github handle to AUTHORS.rst
[X] I have added my change to CHANGES.rst
[X] All new and existing tests passed.

Sorry about the churn, I decided after the initial PR to make it so one could not call as_original() on the HistoricalQuerySet once it fetched.

The latest force push allows as_of=None to be passed into filter() without incident (it is effective ignored, whereas before it would cause an error).  I caught this while re-integrating with my project.

While this passes tests, I'm running into problems with _as_of_filter keeping the settings while integrating, so working on that.

Will re-submit when I work out the kinks.


Hosting with imported Cognito Auth fails to build the backend

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

How did you install the Amplify CLI?
No response
If applicable, what version of Node.js are you using?
No response
Amplify CLI Version
latest
What operating system are you using?
WSL Ubuntu
Amplify Categories
auth, hosting
Amplify Commands
Not applicable
Describe the bug
Upon trying to deploy this application which uses imported auth with Cognito, the build fails mentioning that the input parameters userPoolId, webClientId, nativeClientId are missing. I have checked the Amplify Environment variables docs but didn't find environment variables specified to set these input parameters.
Expected behavior
Environment variables should be available to set these parameters.
Reproduction steps

Create a React application in the Amplify Console.
Enable auth with a Cognito pool
Attempt to build the application with the following build settings using Amplify Hosting

version: 1
backend:
  phases:
    build:
      commands:
        - amplifyPush --simple
frontend:
  phases:
    preBuild:
      commands:
        - yarn install
    build:
      commands:
        - yarn run build
  artifacts:
    baseDirectory: build
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

The application I'm trying to deploy is available here.
GraphQL schema(s)
No response
Log output

# Put your logs below this line

2021-09-15T20:39:59.368Z [INFO]: Git SSH Key acquired
2021-09-15T20:39:59.437Z [INFO]: # Cloning repository: git@github.com:WarwickAI/wai-platform.git
2021-09-15T20:39:59.477Z [INFO]: Agent pid 137
2021-09-15T20:39:59.481Z [INFO]: Identity added: /root/.ssh/git_rsa (/root/.ssh/git_rsa)
2021-09-15T20:39:59.772Z [INFO]: Cloning into 'wai-platform'...
2021-09-15T20:40:00.370Z [INFO]: Warning: Permanently added the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts.
2021-09-15T20:40:06.830Z [INFO]: # Switching to commit: aa2d8914354da2216e44a15ab5df1bbfabb30109
2021-09-15T20:40:06.934Z [INFO]: Agent pid 150
2021-09-15T20:40:06.935Z [INFO]: Identity added: /root/.ssh/git_rsa (/root/.ssh/git_rsa)
                                 Note: switching to 'aa2d8914354da2216e44a15ab5df1bbfabb30109'.
                                 You are in 'detached HEAD' state. You can look around, make experimental
                                 changes and commit them, and you can discard any commits you make in this
                                 state without impacting any branches by switching back to a branch.
                                 If you want to create a new branch to retain commits you create, you may
                                 do so (now or later) by using -c with the switch command. Example:
                                 git switch -c <new-branch-name>
                                 Or undo this operation with:
                                 git switch -
                                 Turn off this advice by setting config variable advice.detachedHead to false
                                 HEAD is now at aa2d891 Update landing page text
2021-09-15T20:40:06.941Z [INFO]: Successfully cleaned up Git credentials
2021-09-15T20:40:06.941Z [INFO]: # Checking for Git submodules at: /codebuild/output/src649041263/src/wai-platform/.gitmodules
2021-09-15T20:40:06.966Z [INFO]: # Retrieving environment cache...
2021-09-15T20:40:07.007Z [INFO]: # Retrieved environment cache
2021-09-15T20:40:07.007Z [INFO]: ---- Setting Up SSM Secrets ----
2021-09-15T20:40:07.008Z [INFO]: SSM params {"Path":"/amplify/dtq3eg2x08klj/dev/","WithDecryption":true}
2021-09-15T20:40:07.064Z [INFO]: # Ensuring NPM package '@aws-amplify/cli' is version: 'latest'
2021-09-15T20:40:13.829Z [INFO]: # Patching NPM package '@aws-amplify/cli' from 4.29.4 to 5.6.0...
2021-09-15T20:42:04.257Z [INFO]: # Done patching NPM package '@aws-amplify/cli'
2021-09-15T20:42:04.404Z [INFO]: # Retrieving cache...
2021-09-15T20:42:09.029Z [INFO]: # Extracting cache...
2021-09-15T20:42:17.481Z [INFO]: # Extraction completed
                                 # Starting phase: build
2021-09-15T20:42:34.254Z [INFO]: Amplify AppID found: dtq3eg2x08klj. Amplify App name is: waiplatform
2021-09-15T20:42:34.310Z [INFO]: Backend environment dev found in Amplify Console app: waiplatform
2021-09-15T20:42:35.120Z [INFO]: App not deployed yet.
2021-09-15T20:42:35.165Z [INFO]: App not deployed yet.
2021-09-15T20:42:35.178Z [INFO]:
                                 GraphQL schema compiled successfully.
                                 Edit your schema at /codebuild/output/src649041263/src/wai-platform/amplify/backend/api/waiplatform/schema.graphql or place .graphql files in a directory at /codebuild/output/src649041263/src/wai-platform/amplify/backend/api/waiplatform/schema
2021-09-15T20:42:35.183Z [INFO]: App not deployed yet.
2021-09-15T20:42:35.226Z [INFO]: Successfully generated models. Generated models can be found in /codebuild/output/src649041263/src/wai-platform/src
2021-09-15T20:42:35.228Z [WARNING]: - Fetching updates to backend environment: dev from the cloud.
2021-09-15T20:42:35.529Z [WARNING]: ✔ Successfully pulled backend environment dev from the cloud.
2021-09-15T20:42:35.556Z [WARNING]: ✖ There was an error initializing your environment.
2021-09-15T20:42:35.559Z [INFO]: Failed to pull the backend.
2021-09-15T20:42:35.561Z [INFO]: auth headless is missing the following inputParams userPoolId, webClientId, nativeClientId
2021-09-15T20:42:35.609Z [INFO]: Error: auth headless is missing the following inputParams userPoolId, webClientId, nativeClientId
                                     at ensureHeadlessParameters (/root/.nvm/versions/node/v12.21.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/src/provider-utils/awscloudformation/import/index.ts:1288:11)
                                     at Object.headlessImport (/root/.nvm/versions/node/v12.21.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/src/provider-utils/awscloudformation/import/index.ts:1145:40)
                                     at importedAuthEnvInit (/root/.nvm/versions/node/v12.21.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/src/provider-utils/awscloudformation/import/index.ts:922:18)
                                     at processTicksAndRejections (internal/process/task_queues.js:97:5)
                                     at updateConfigOnEnvInit (/root/.nvm/versions/node/v12.21.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/src/provider-utils/awscloudformation/index.js:50:72)
                                     at /root/.nvm/versions/node/v12.21.0/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-auth/src/index.js:306:22
2021-09-15T20:42:35.626Z [ERROR]: !!! Build failed
2021-09-15T20:42:35.626Z [ERROR]: !!! Non-Zero Exit Code detected
2021-09-15T20:42:35.626Z [INFO]: # Starting environment caching...
2021-09-15T20:42:35.626Z [INFO]: # Uploading environment cache artifact...
2021-09-15T20:42:35.697Z [INFO]: # Environment caching completed
Terminating logging...

Additional information
No response

I think what's going on is a chicken and egg problem.
Having imported the Cognito details into my project (resulting in the details being added to team-provider-info.json) the amplify CLI tool can read those details which is the whole reason of using amplify import auth)
However to initialise the project so that the Congnito details can be read amplifyPush.sh needs the imported Cognito details passed - which are in the project configuration.
This is why the env var solution works as it breaks this loop, but also sucks because it means that whole feature of importing Cognito into Amplify is broken (assuming you're using CI/CD).
The solution, which is better IMO is to do what others have done. Have a custom "init script" based on amplifyPush.sh that parses team-provider-info.json and pass that JSON to the amplify init command like a lot of other examples have done (with the CATEGORIES env var)
CC https://github.com/aws-amplify/amplify-console/issues/1271

What worked for me was adding the Environment variables to
Please see here for all available environment variables.

Our documentation is up-to date around the environment variables needed for social sign in:

https://docs.aws.amazon.com/amplify/latest/userguide/environment-variables.html#amplify-console-environment-variables
https://docs.aws.amazon.com/amplify/latest/userguide/environment-variables.html#creating-a-new-backend-environment-with-authentication-parameters


[NVIDIA TF] Enable BF16 Scan ops

Adds GPU bfloat16 support for Cumprod and Cumsum. CumulativeLogsumexp is excluded because the op definition doesn't allow BF16 datatype.

Hi @trevor-m Any update on this PR? Please. Thank you!


Added debug example code and required changes to vulkano debug module

Putting changes into branches; I hadn't realized how messy it had gotten with the array of things I had found.

I've been hesitating about this PR because I'm not sure if an example demonstrating debug callbacks is really useful.
The example assumes that the user has the SDK installed, which is not mandatory to use vulkano. I also don't want user to get the feeling that they need to have the SDK installed.

I could add a note about installing the SDK in order to get the default layers; but I think Vulkan in general needs some very basic example code.
It took me time to setup these callbacks because although I read the documentation I hadn't properly setup the extensions as well; this required reading your code to convert from the regular Vulkan constant to the Vulkano version. Until I got those steps correct I had code that built but did not log; which was frustrating.
IMHO setting up a debug-ready codebase on a new platform is extremely helpful, because seasoned programmers we are all new to Vulkan.

I actually really like this for the reasons @attackgoat mentioned.

Ok, since there are 3 people in favor of it, let's merge this.
@attackgoat Please remove the implementation of Display for MessageTypes and use {:?} in the println instead. Once it's done I'll merge.

Completed; I'd like to get back to the compute shader example too and see how the newly baked code is doing. Thanks!

Also, just do let _debug_callback = ... which removes the warning, and remove the last line that you added in your latest commit.

Awesome, didn't know that _ feature worked as a prefix in Rust.


Anchor Billing Cycle API error

Say someone needs to have all subscriptions anchored on the first of the month rather than the anniversary date, this would be a useful option, but it seems to not work.
Giving out an API parameter unknown error.

@Francismori7  can you please share more details? I don't seem to understand.

Give me a few hours.
On Wed, Nov 23, 2016, 11:50 Mohamed Said<EMAIL_ADDRESS>wrote:

@Francismori7 https://github.com/Francismori7 can you please share more
details? I don't seem to understand.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/laravel/cashier/issues/300#issuecomment-262569806,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAfxx_7WbmUdDzyiKtRV4sQ30C7YEQXjks5rBG7AgaJpZM4IrlIf
.

@Francismori7 have you managed to check the issue again?

Oh wow I completely forgot about this. Tonight I should be able to provide details. Notes in agenda

@Francismori7 open another issue when you have time then :)


Publishing failure error message is empty

To reproduce this you can use invalid credentials in GW config and publish the API.

Fixed in https://github.com/wso2/carbon-apimgt/pull/7538


Save vs update

I wasn't able to get a sense from the documentation whether "update" and "findOneAndUpdate" are supported by mongoose-version. I know they have different hooks from standard "save" so can you confirm whether or not those are supported?
Thanks!

I'm currently using this module and i can confirm that this doesn't work on update. The versioning is applied only on pre('save')  which is not fired on updates.

Would it be difficult to add such functionality? According to http://mongoosejs.com/docs/middleware.html

Pre and post save() hooks are not executed on update(), findOneAndUpdate(), etc. You can see a more detailed discussion why in this GitHub issue. Mongoose 4.0 has distinct hooks for these functions.

[...]

For instance, if you wanted to add an updatedAt timestamp to every update() call, you would use the following pre hook.

schema.pre('update', function() {
  this.update({},{ $set: { updatedAt: new Date() } });
});

+1

I may need this kind of functionality as well so I did a little bit of searching/reading.
As @benoror pointed- pre/post hooks for update (and findOneAndUpdate) do not receive the instance but a Query object. In discussion/documentation, they show how to add "updatedAt" field using these hooks.
From what I've gathered, it is (possibly) possible to add the version tracking functionality for update by executing the query within the hook and then replicating the "versioning" functionality for each of the instances returned.
From what I see, this plugin works by adding pre hooks on the schema for 'add' and 'remove'. To add update functionality, I'd suggest something like so:
In array / collection  strategies (lib/strategies):
schema.post('update', function(query) {
    // we have the query - we can fetch the instances
    query.find(function(updatedInstances) {
        // here we can update the array/collection
        // need to take care of the plumbing etc but something along (assuming collection strategy):
        updatedInstance.forEach(function(doc) {
            if (!options.suppressVersionIncrement) {
                // figure out to increment... maybe:
                doc.increment(); // Increment origins version - this won't work without additional doc.save()
                doc.save(); // this will trigger the pre-save mechanism, so we could be done
                                 // not sure whether there are other implications...
            }

            var clone = doc.toObject();
            delete clone._id
            clone.refVersion = this._doc.__v;   // Saves current document version
            clone.refId = doc._id;        // Sets origins document id as a reference

            new schema.statics.VersionedModel(clone).save(function(err) {
              if (err) {
                debug(err);
              } else {
                debug('Created versioned model in mongodb');
              }
            });
        });
    });
});

Note - I believe the post hook is better because it is executed at the end and doesn't receive flow control so it will not slow the process .
Of course, need to figure out how to set the refVersion property properly without causing havoc... Need to think this through...
Note: this is all conceptual and I didn't even try to run it (yet). I posted here to receive comments/suggestions.  Is this repository still active? Anyway one the authors is around to comment/assist/merge? .

Any updates? This feature is the major use-case.


Saving Figures of the Model Output

I want to save original figures but model.plot() returns None so that I could not save them with high quality. Adding such a feature definitely will be helpful.

Hi @mekazanc ,
This package already offers support for that (maybe we should better document this feature still).
To manage your figures, you can run ci.plot(show=False) and then run commands such as:
import matplotlib.pyplot as plt

plt.savefig(...)

This will save your plots as expected (you can also manipulate the axis as you wish as well).
Please let me know if this works for you,

Thank you very much @WillianFuks