Initial data does not populate in ModelSelect2Multiple when using ModelMultipleChoiceField.to_field_name

First of all, thanks for all of the work that you all have done on this project, it's awesome!
I am unable to get initial data to populate in the ModelSelect2Multiple widget when using ModelMultipleChoiceField.to_field_name. The use case here is that I have a unique, non-pk field Case.case_num that identifies a given case. I am using this value as a slug to identify a Case in URLs, form fields, etc. It works fine without to_field_name set (i.e. with the PK as the field value).
I have forked the repo and created an example app called to_field_name. It has two forms: CaseFormBasic and CaseFormAutocomplete. The only difference is that CaseFormAutocomplete uses the ModelSelect2Multiple widget, and  CaseFormBasic uses the default.
Explicit steps to reproduce:

Clone https://github.com/tchamberlin/django-autocomplete-light.git
Run server
Navigate to /to_field_name/cases-basic/?cases=123. Observe that the field is populated
Navigate to /to_field_name/cases-ac/?cases=123. Observe that the field is not populated

I assume I'm just missing something obvious here, but I can't see anything about this use case in the docs or previous issues.
Here are my changes from current master
Thanks!

Wow, that's an interesting issue! And clean repo to reproduce! I wish people all make such proper issues ... and ping me often until i see them :joy: so that's me saying sorry for the response delay
I suppose there's some place DAL should deal with to_field_name but doesn't to make this use case work out of the box. However, if it's not too late, here's what was going wrong:
    182     """QuerySet support for choices."""
    183
    184     def filter_choices_to_render(self, selected_choices):
    185         """Filter out un-selected choices if choices is a QuerySet."""
    186         import ipdb; ipdb.set_trace()
--> 187         self.choices.queryset = self.choices.queryset.filter(
    188             pk__in=[c for c in selected_choices if c]
    189         )

From:
class QuerySetSelectMixin(WidgetMixin):
    """QuerySet support for choices."""

    def filter_choices_to_render(self, selected_choices):
        """Filter out un-selected choices if choices is a QuerySet."""
        self.choices.queryset = self.choices.queryset.filter(
            pk__in=[c for c in selected_choices if c]
        )

Well, the particularity of an autocomplete widget is that it shouldn't render all possible options (duh!) so we have to add a hook to the select field to ... filter choices that will be rendered. That's done by QuerySetSelectMixin, which enforces using the PK there.
Pull request all acceptable ... if you're still using DAL for that one ^^


Adjust runtime syscalls to NEO3

Closes #1028 .

And btw, all the new syscalls should be available to Go contracts.

BTW, we're also missing pkg/interop wrappers for syscalls added in #1054.


Broken video in Firefox after Mesa update

Describe the bug
Videos played in Firefox appear to have broken chrominance:

Steps To Reproduce
Steps to reproduce the behavior:

Open YouTube
Play random video

Additional context
I have bisected it to interval 3c76783506e7301748f955abf787f3d7f317ee52 (good) and f994293d1eb8812f032e8919e10a594567cf6ef7 (bad), reverting Mesa to an older version with the following fixes it:
  system.replaceRuntimeDependencies =
    let
      nixpkgsfixed = builtins.fetchTarball "https://github.com/NixOS/nixpkgs/archive/3c76783506e7301748f955abf787f3d7f317ee52.tar.gz";
      mesa = pkgs.callPackage (nixpkgsfixed + "/pkgs/development/libraries/mesa") {
        inherit (pkgs.darwin.apple_sdk.frameworks) OpenGL;
        inherit (pkgs.darwin.apple_sdk.libs) Xplugin;
      };
    in
    builtins.map
      (output: {
        original = pkgs.mesa.${output};
        replacement = mesa.${output};
      })
      pkgs.mesa.outputs;
}}}

Notify maintainers
cc @PedroHLC @LunNova  @vcunat
Metadata
Using nixos-unstable

I'm using a little later mesa now (22.2.2) without experiencing the issue, but it may be depending on GPU or something else, too.

.3 is in staging, but the shortlog doesn't seem to contain anything specific to nouveau.  I'm not sure what to do about this.

Actually, it sounds worth retrying, as this one could be related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5632

Looks like it is indeed fixed on 1462b5397b2c3b8d9891b41de131d0776fd4a63f. Thanks.


Fix some ansible warnings in test suite

Checklist

[ ] Affected Issues have been mentioned in the Closing issues section
[ ] Documentation has been written/updated.
[x] Changelog entry has been written

This PR updates parts of the test suite that were generating ansible warnings like this in the test output:
[WARNING]: when statements should not include jinja2 templating delimiters

Changelog Entry
Improvement - Avoid ansible warnings in CI
Closing issues
n/a

Build is broken pending #1517


Attaching a light probe to a geometry throws exception and cant be removed from node.

Attaching a light probe to the geometry will throw this exception.
SEVERE [com.jme3.gde.core.scene.SceneApplication]: Scene graph is not properly updated for rendering.
State was changed after rootNode.updateGeometricState() call.
Make sure you do not modify the scene from another thread!
Problem spatial name: PBRCube
java.lang.IllegalStateException: Scene graph is not properly updated for rendering.
State was changed after rootNode.updateGeometricState() call.
Make sure you do not modify the scene from another thread!
Understandable, but the attached lightprobe cannot be removed without restarting the SDK after delete.

Reproduced. This leaves SceneComposer completely unusable for any file (not just the one where the mistake was made) until the sdk is restarted.


Incorrect Flow error when function argument is a union of object types with identical properties

Flow version: 0.130.0
Calling the function bar() with an object whose type property is an argument of type AB should not cause any flow error since the resulting object will be of type ABEvent as defined below.
const A:'a' = 'a'
const B:'b' = 'b'

type AB = typeof A | typeof B

type AEvent = {
  type: typeof A,
  prop: string
}

type BEvent = {
  type: typeof B,
  prop: string
}

type ABEvent = AEvent | BEvent

function bar(arg: ABEvent) {

}

function foo(arg: AB) {
  bar({
    type: arg,
    prop: 'hi'
  })
}

Expected behavior
No errors
Actual behavior
Flow throws an unexpected error even though the function is called with appropriate arguments. The identical scenario  in TypeScript doesn't throw any errors which is the expected behaviour in this case

Link to Try-Flow or Github repo: https://flow.org/try/#0MYewdgzgLgBAggLgOQEMkwLw1UgUKSWAIWQCN0slzdcoBPABwFN4jMZ7mQAzeGAHw6MmPGERqcWcAKIA3JmFhYA3rhhDmCDSN5wANGpgMATiAZboxgJZgA5rgC+E4WLkKlMVeslbJoogbqJmYWUNZ2js7MrG6K7DLycYJEsVA03ACuYMBQVuAwpCjGABRFtlpwKYlQAJSeNE64mdm5+dwgIKXG5ax1XgVFxf3ewlplgepGpubYABZWeOoONY4wQA
Link to same scenario in TypeScript: https://www.typescriptlang.org/play?#code/MYewdgzgLgBAggLgOQEMkwLw1UgUKSWAIWQCN0slzdcoBPABwFN4jMZ7mQAzeGAHw6MmPGERqcWcAKIA3JmFhYA3rhhDmCDSN5wANGpgMATiAZboxgJZgA5rgC+E4WLkKlMVeslbJoogbqJmYWUNZ2js7MrG6K7DLycYJEsVA03ACuYMBQVuAwpCjGABRFtlpwKYlQAJSeNE64mdm5+dwgIKXG5ax1XgVFxf3ewlplgepGpubYABZWeOoONY4wQA

What that code has is an object of type { type: 'a' | 'b', prop: string }. It's trying to use it as if it were of type { type: 'a', prop: string } | { type: 'b', prop: string }.
Those types do sound very similar. But Flow is nevertheless correct to treat those as different types, and in particular to say that a value of the first can't be used as the second.
The difference is that the latter type, { type: 'a', prop: string } | { type: 'b', prop: string }, means an object that is either a { type: 'a', prop: string } or a { type: 'b', prop: string }. If you have a { type: 'a', prop: string }, you can't go and mutate its type property to be 'b' instead, because the type doesn't allow that. As a result, when bar gets passed a { type: 'a', prop: string } | { type: 'b', prop: string }, it can assume that whichever type it currently is, it's not going to switch unexpectedly to the other:
function baz(arg: AEvent) { /* … */ };

function bar1(arg: AEvent | BEvent) {
  if (arg.type === 'a') {
    // Now we know `arg` is an `AEvent`.
    f();
    baz(arg); // No error.  `arg` is an `AEvent`, so it can't
              // have been mutated into some other thing.
  }
}

However, if the object is actually of type { type: 'a' | 'b', prop: string }, then that assumption doesn't hold -- there could be some code that mutates it from looking like an AEvent to looking like a BEvent:
let ab: { type: 'a' | 'b', prop: string } = { type: 'a', prop: 'hi' };

function f() {
  ab.type = 'b';
};

bar1(ab); // Error! As there must be, because otherwise `bar1` would have a runtime type error.

If you write bar so that it takes that type, then Flow knows it can't make that assumption, and gives you an error inside the function instead if you try to use it:
function bar2(arg: { type: 'a' | 'b', prop: string }) {
  if (arg.type === 'a') {
    f();
    baz(arg); // Here Flow gives an error because it won't rely
              // on `arg.type` still being 'a'.
  }
}

bar2(ab); // As a result, passing an object with `type: 'a' | 'b'` here is fine.

Here's those examples together on try-flow.

@gnprice I am always enjoying your explanations. Thank you for doing this! 👍


feat: embed Aspecto instrumentations

As their repository has gone dormant and it makes it difficult for us to upgrade to newer OTel versions, temporarily (until either we or Apecto conntribute these instrumentations to OpenTelemetry) move the instrumentations into our codebase.
Changes done:

Make the instrumentations compile under strict configuration of TypeScript. This means the instrumentations had their typings reworked.
Ported over tests and removed the dependency on OpenTelemetry's contrib-test-utils package, opting for a custom solution. This was necessary as registerInstrumentationTesting at contrib-test-utils doesn't support changing instrumentations in the same test suite. Aspecto tested each instrumentation in a separate package / process, which makes it work.
Some of the instrumentations made use of sqlite3 in their tests, which brings in a dependency on newer node-gyp which requires Python 3.6. Some of our pipeline steps don't have it as they are intended to be compile checks on older platforms which don't have Python >= 3.6 out of the box. To avoid unnecessary changes to our test and build pipeline I mocked out the sqlite3 library.

Codecov Report
Patch coverage: 88.92% and project coverage change: -2.32 :warning:

Comparison is base (c70d647) 88.41% compared to head (b9f61c1) 86.10%.

:exclamation: Current head b9f61c1 differs from pull request most recent head 57c88bb. Consider uploading reports for the commit 57c88bb to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #754      +/-   ##
==========================================
- Coverage   88.41%   86.10%   -2.32%
==========================================
  Files          28       19       -9
  Lines        1278      662     -616
  Branches      286      151     -135
==========================================
- Hits         1130      570     -560
+ Misses        148       92      -56

Impacted Files
Coverage Δ

src/instrumentations/external/kafkajs/propagtor.ts
60.00% <60.00%> (ø)

...mentations/external/elasticsearch/elasticsearch.ts
71.91% <71.91%> (ø)

src/instrumentations/external/typeorm/typeorm.ts
85.49% <85.49%> (ø)

src/instrumentations/external/sequelize/utils.ts
85.71% <85.71%> (ø)

...c/instrumentations/external/elasticsearch/utils.ts
91.48% <91.48%> (ø)

...c/instrumentations/external/sequelize/sequelize.ts
95.57% <95.57%> (ø)

src/instrumentations/external/kafkajs/kafkajs.ts
96.31% <96.31%> (ø)

...instrumentations/external/elasticsearch/helpers.ts
100.00% <100.00%> (ø)

...c/instrumentations/external/elasticsearch/index.ts
100.00% <100.00%> (ø)

src/instrumentations/external/kafkajs/index.ts
100.00% <100.00%> (ø)

... and 6 more

... and 28 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Audio problems are completely muted, My cell phone is at 100% volume and no audio comes out from games on xcloud 😭 [Bug] ...

Platform

Device: Phone, Laptop, Desktop, TV...
OS: Windows, Android, iOS...
Browser: Chrome, Safari, Kiwi...
Browser Version:
Better xCloud Version:

Describe the bug
Bug in the audio there is no sound in the games is there a problem with this update 17 and 16 there is no sound in the games
Screenshots/Videos
If applicable, add screenshots/videos to help explain your problem.

Try on another browser

Experimente em outro navegador

Do you recommend another browser because I can only play on my cell phone?

Duplicate #127


Slash command permissions.

Please describe the changes this PR makes and why it should be merged, as well as any and all proof of successful tests:
The nature of this PR is to expand the permission checking that guidebot deploys with legacy commands to interaction commands until finer permission tuning is possible with slash commands.
The big caveat of expanding the custom permission system is that all slash commands (global and guild) will be seen as "usable" to every single user regardless.
For the Guild VS Global command discussion, additional logic will be required within the interaction, and or command to prevent execution of guild intended commands such as moderative, or server info commands in the global scope.
Semantic versioning classification:

[X] This PR changes the framework's interface (methods or parameters added)

[X] This PR includes breaking changes (methods removed or renamed, parameters moved or removed)

[ ] This PR only includes non-code changes, like changes to README, etc.

All permission levels are working!


New Tailwind theme

💥 Proposal
This may be belong in the Infima repo, but I strongly suggest Docusaurus consider Tailwind. Tailwind already solves for theming out of the box. It also gives developers much more freedom. You can still re-implement Infima's core classes with tailwind, so this actually wouldn't need to be a breaking change.
The benefits:

Smaller CSS footprint
Better theming
Less custom CSS needed on other pages

Next Steps

Start on a new Tailwind preset
Get it to feature-parity with classic theme

Have you read the Contributing Guidelines on issues?
Yes

Hi,
I'm not very familar with Tailwind yet.
Currently Infima is a css lib with a few postcss. But it also includes some lightweight vanilla JS components
If I understand correctly, you mean we could implement current Infima CSS classes as a Tailwind preset, instead of the existing css/postcss ?
So we would publish that preset and enable users to extend / customize it more easily?

I see the value of Tailwind, and a similar goal of styling co-located to the markup.
Its scope is larger than current Infima:

People having complex D2 sites will probably need additional one-of CSS styles that's not provided by Infima (afaik it also happens to Tailwind users).
There are also simple D2 sites that do not require additional styles. Can we use Tailwind without adding unnecessary CSS to these sites?

Yes you can and should always purge unused tailwind css. Only the classes actually used in the codebase are kept.

Hoping this is helpful information, as I got TailwindCSS v2 to properly work with the PostCSS config that Docusaurus v2 already uses.
I'm using a custom configureWebpack plugin in a file plugins/my-loaders/index.js like so:
module.exports = function (context, options) {
  return {
    name: 'loaders',
    configureWebpack(config, isServer, utils) {
      console.log(config)
      return {
        module: {
          rules: [
            {
              test: /\.css$/,
              use: [
                {
                  loader: require.resolve('postcss-loader'),
                  options: {
                    ident: 'postcss',
                    plugins: () => [
                      require('postcss-import'),
                      require('tailwindcss'),
                      require('postcss-preset-env')({
                        autoprefixer: {
                          flexbox: 'no-2009',
                        },
                        stage: 4,
                      }),
                    ],
                  },
                },
              ],
            },
          ],
        },
      }
    },
  }
}

with package.json referencing a local module dependency "my-loaders": "file:plugins/my-loaders", and docusaurus.config.js plugins entry set up as plugins: ['my-loaders'],
Note that the PostCSS version in which Docusaurus v2 currently uses is 7.0.XX, while the latest version of PostCSS is 8.0.X and TailwindCSS v2 by default uses PostCSS V8. I had to use a v7 compatibility install of TailwindCSS v2 for this to all work: "tailwindcss": "npm:@tailwindcss/postcss7-compat" in package.json dependencies.
I'm thinking that maybe tailwindcss can be added directly to the https://github.com/facebook/docusaurus/blob/master/packages/docusaurus/src/webpack/utils.ts#L64-L71 plugin block for getStyleLoaders with PurgeCSS configured. Since tailwindcss has PurgeCSS enabled, users who don't use tailwindcss will never see it or even know because all the tailwindcss related css rules will be removed. And there should be no performance penalties in terms of time spent compiling for users who don't import tailwindcss into their .css files or index.js/index.tsx.

Thanks for these infos.
We'll look at this more in depth soon, as we'll work on our theme gallery (https://github.com/facebook/docusaurus/issues/3522) and Tailwind support is part of it

@kvnxiao I tried your config for tailwind and can't seem to get past this error:
Error: Cannot find module 'postcss-import'

Do you have a working repo I could take a look at?

@clairefro https://github.com/Discord4J/documentation

@kvnxiao's solution is great! I just want to add an improvement to it. If you add the following to your tailwind.config.js: important: '#tailwind', then it will not affect the docusaurus pages. Then all you need to do is add
 around the pages that you want to use tailwind on!

@kvnxiao
according to https://github.com/postcss/postcss-import/issues/435
postcss-import@^12 (current ^14) is based on postcss8
also the install guide on tailwindcss does not mention the postcss-import module
https://tailwindcss.com/docs/installation#post-css-7-compatibility-build
why did you made it a dependency on your module?

@wibed This is if you want to have build time imports: https://tailwindcss.com/docs/using-with-preprocessors#build-time-imports It's not a requirement but I enabled it in case I take advantage of it.

FYI the next release will have a configurePostCss lifecycle, can be useful for Tailwind until we have first-class support
https://github.com/facebook/docusaurus/pull/4185

@nahtnam The one with tailwind.config.js: important: '#tailwind' did prevent default styles for other docusaurus pages. I tried tailwind.config.js: corePlugins: { preflight: false} and it worked for me.

FYI the next release will have a configurePostCss lifecycle, can be useful for Tailwind until we have first-class support
#4185

Any idea on a timeline for first-class support?

@Romstar no timeline to be defined, as it requires a significant amount of refactoring work to avoid duplicating everything between the themes

@slorber if someone wanted a tailwind theme now-ish, would you suggest waiting a bit more, or plowing a head and making their own. Is it still a mid term goal? It seems like abstracting common logic from themes, is a fairly significant undertaking and likely requires some rethinking of how themes work?

@jquense I think you'd better implement that theme yourself for now, and we may be able to benefit from this third-party implementation once Docusaurus has refactored its theme system.
The goal is to share the same UX across all the official themes, and just have to implement the UI / head / styled components for each theme. We should also try to make it so that theme refactors are less likely to break sites of users that have implemented a custom theme or swizzled a component. I don't like too much the way swizzling works currently, as it creates a quite implicit API surface for which it's hard to be retrocompatible, so yeah it requires a decent amount of work to prepare all that.
The goal is not just to have a Tailwind theme: it's also to make sure that it's easy to maintain, does not break and stays in sync with the classic theme over time.
We have seen what happens to the "bootstrap" theme over time. As there's currently a lot of code duplication, it became unmaintained and a burden and is now in a very bad state. If we have a Tailwind theme, we don't want that to happen.

@kvnxiao's solution is great! I just want to add an improvement to it. If you add the following to your tailwind.config.js: important: '#tailwind', then it will not affect the docusaurus pages. Then all you need to do is add
 around the pages that you want to use tailwind on!

Actually, can you try this: // tailwind.config.js
module.exports = {
prefix: 'tw-',
}
The prefix solved the collision issue for me.

Ok I've started this: https://github.com/jquense/docusaurus-theme-tailwind It's functional though i've not published it on NPM yet. Would appreciate any contributions if folks have em.

Thanks for that @jquense , that already looks great!
Deployed it so that community can see a preview: https://docusaurus-tailwind-theme-test.netlify.app/
(had trouble running 4c build and there's a missing css module in Navbar, but got it running)
As we'd like to make it easier to implement/maintain a theme as part of the beta period, maybe we can work together on this soon.
Currently, implementing a theme requires maintaining too much code that is not really related to the styling. I'd like to move most of it to the theme-common package and only keep the styled components in themes (those with tailwind classes). If you are willing to help to prepare the new theming infra, let me know.
My goal is to have 2 official themes in the Docusaurus repo, mostly for dogfooding as a proof it's sustainable to implement your own theme (if it's not, we'll feel the pain ourselves). Tailwind has now more traction than bootstrap and is probably the best candidate.

Hello, I have a similar problem with tailwind configuration like people before, and unfortunately, the solution from @kvnxiao is not working in the production build in my case. The problem is that we made a component library based on TailwindCSS and we are installing it as deps, so inside my tailwind.config.js in Docusaurus I have to go through the node_modules path to purge it properly like
'./node_modules/xxx/*-react/dist/*.js', by xxx is our scope.
This line in config file plus monorepo Rush setup in repository plus custom tailwind plugin is creating a problem since purge is going through each and every dependency in node_modules and it shouldn't. This is making a crash a heap JS out of memory which someone also made as a separate ticket.
Is it possible to somehow exclude the whole node_modules in purge but the line which I stated will be in use of webpack/postcss config in some ways?
I can say that storybook with this tailwind setup is working just fine and purge is not going through all deps and it is also in the same monorepo project.

autoprefixer: {
                          flexbox: 'no-2009',
                        }

Hi! @kvnxiao, can you explain me what about with this config lines?

@kvnxiao im tryied to follow your instrucctions from your comment and everything goes well until, in my case, i run yarn start` and the error that i get in my console is the next:

So i´m think that i`m not undestanding well what is going on with the dependencies versions

that is more of a tailwind config question than a docusaurus one. You can use an array of paths to purge content. For libraries there isn't any way to include them expect to manually include it in the purge settings. feel free to upvote: https://github.com/tailwindlabs/tailwindcss/discussions/5208 for better tailwind support

Hi, please, i need support for my case, i´v been following the steps of @kvnxiao but at the end when, in my case, run yarn start  i get the next error message in. my browser console:

y el siguiente en mi terminal:

so, the message suggest a naming and a format for the object props but i don´t understand why happen this if follow the steps one bye one.

@jakub-zebrowski we're also having troubles setting docusaurus with a working Tailwind setup.
In addition I'm pretty interested in options to get Tailwind working with storybook.
Would you like to interact to share thoughts and findings on these problems?

@diegoaguilar we didn't have any problems with the storybook. The setup contains tailwind.config.js, postcss.config.js as you can find in Tailwind docs and inside .storybook/main.js in addons we have this
            name: '@storybook/addon-postcss',
            options: {
                postcssLoaderOptions: {
                    postcssOptions: {
                        plugins: {
                            tailwindcss: {},
                            autoprefixer: {},
                        },
                    },
                    implementation: require('postcss'),
                },
            },
        },```

Quite a few have been asking about the status of the Tailwind theme. We are certainly interested in building another theme that utilizes Tailwind CSS as the styling framework, but it's not blocking for the 2.0 release (see #6113), so we will work on it shortly after the GA release, as a minor version.

There's a question that we never asked about what you expect from this Tailwind theme, compared to the existing Classic/Infima theme:

1: Exact same UX/UI
2: Same UX, but slightly different U
3: Reworked UX/UI

To me, this is 1) or 2), and not 3)
I'm curious to know how much you expect this Tailwind theme to look/behave differently from the classic theme, please tell us
Why do you care about having a Tailwind theme:

1: To implement your homepage with an official tailwind support
2: To avoid mixing 2 CSS solutions on the same page (Infima + Tailwind)
3: Other?

Related to https://github.com/facebook/docusaurus/issues/6649#issuecomment-1042770122

I would hope for the same UX and features but don't require the look exactly the same as the infirma based theme.
I primarily want two things from a tailwind theme

ability to tweak the theme colors, spacing, etc using a familiar tailwind theme config file. As well as having until classes I know when sizzling

being able to use tailwind to style my pages without having two CSS frameworks on page and worring about namespace clashes

Thanks @jquense , that's what I expected
Anyone has other good reasons to use Tailwind here?

Infima bring troubles, maybe tailwindcss can help, or maybe not.
See: https://github.com/facebook/docusaurus/issues/6032

@slorber I appreciate your ask of the community and specifically lean towards 1 and then 2 above, not 3, similar to your thoughts.
I'd love to start building our firm's docs w/Docusaurus but can't until/unless it plays nicely with tailwindcss, which we use to style all of our components, pages, and apps.
Having the tailwindcss theme look and behave similarly to the infima version is probably useful for devs familiar with just one of the frameworks, as a tool to understand the other framework in the context of Docusaurus.
:1st_place_medal: Thanks for the great work on this lib; I'm particularly stoked to see where things go with tailwindcss.

@jquense
Hey there, I would be happy to help.  I've seen your last commits in the "docusaurus-theme-tailwind" are monts ago.
Of course, I'm interested in using tailwind for my own docusaurus projects. 👯

Note the classic theme is under serious refactorings to create smaller fine-grained and encapsulated components, and move the technical code (non-coupled to Infima) to the @docusaurus/theme-common package.

https://github.com/facebook/docusaurus/pull/6844
https://github.com/facebook/docusaurus/pull/6894
https://github.com/facebook/docusaurus/pull/6895
other PRs to come

I'd suggest waiting for these refactorings to be completed before investing too much time in a third-party Tailwind theme.
We'll likely also provide some useful tooling so that all themes that want to provide the same layout/UX as the classic theme can stay in sync and keep the same file-system structure, as the main difference should be the UI/CSS, not the component API surface

I am happy to wait it out. it's been to much work to keep it up compared to what i save using it :P

@slorber
Just a quick question out of curiosity.
Do you have a timeline for the TW theme, or is it more like "it's done when it's done"?
Kind regards

it's done when it's done

We are continuously extracting technical / non-ui code from the classic theme so that producing a new Tailwind does not lead to a ton of duplication.
Unfortunately, it's hard to estimate. We'll first cleanup the theme to make it easier to customize, release 2.0 asap, and only then start working on this new official Tailwind theme.
And as part of an open-source project, there is also general maintenance work, community PRs and other quality of life improvements to ship so it's hard to dedicate 100% of the efforts to this single project. But it is definitively something that we try to slowly make happen in the background

I strongly advise making Tailwind optional.

I don't know if anyone has the same problem, but for me the tailwind installation had lead to the whole site being ugly. After a lot of searching I found that simply disabling preflight solves it because it doesn't change the html defaults.
You can add this in your tailwind.config.json
 corePlugins: {
    preflight: false,
  }

I don't know if anyone has the same problem, but for me the tailwind installation had lead to the whole site being ugly. After a lot of searching I found that simply disabling preflight solves it because it doesn't change the html defaults.
You can add this in your tailwind.config.json

 corePlugins: {

    preflight: false,

  }

How did you import tailwind?

Is there an umbrella task or list somewhere for the work to extract logic out of the classic theme and into theme-common to help out on making more themes possible?

No umbrella issue but you could look at theme components and see if there is some code that is technical and not really related to theming/styles/CSS. Sometimes it's hard to extract, but there are still a few low-hanging fruits that contributors can help moving ;)

Hey @slorber ,
We love Docusaurus, and we're building our documentation website on top of it. We're also looking at using Tailwind, so I'm just wondering if you could shed some light on when the Tailwind theme will be available. I understand that you don't have an ETA, but it would be helpful to know whether it'll take weeks, months, or maybe even more. We're not sure if we'd be better off implementing the key features now and wait for the new theme to be ready before we polish the website or if we should just hack our way through the existing codebase and get all the features implemented on top of the existing classic theme. The main concern is that we have to swizzle a large number of components, and this could cause issues when upgrading our version of Docusaurus.
Thank you,
Andrei.

Hey, I'm sorry but I have limited bandwidth, only work on Docusaurus 3d/week, also take holidays, have to spend like 50% of my time doing support and answering issues (like this one).
In conclusion, I have not much more than 1d/week to work on ambitious features for Docusaurus, and it's hard for me to tell you how much time it will take considering there are more urgent things to handle such as migrating to React 18, MDX 2.0, ESM, fixing important bugs, DX issues and pending PRs to reviews.
So no, I really can't answer you on when a Tailwind theme will land, nor what decision you should make.
Please assume it will take time, and that you should rather take a decision based on the current state of Docusaurus instead of waiting for official support.
If you really want Docusaurus with Tailwind support today, it remains possible to implement in userland, as @jquense did in his POC above. And doing so will help us: once the time comes, we'll be able to copy your existing JSX+className markup to create the official version. For sure it requires a lot of effort to create it and keep it on par with the existing classic theme, but it is definitively possible.
Note that you can still contribute to our opencollective if you want to give us more bandwidth to implement things faster.

Hi,
We appreciate you taking the time to answer our question. We just wanted to get more insight into this. Thanks for sharing all the useful information!
Best,
Andrei.

 corePlugins: {
    preflight: false,
  }

In my team, we prefer to keep the preflight styles but, in order to avoid collisions with Docusaurus styles, we need to load @tailwind base; earlier than the Docusaurus styles.
Unfortunately, in we add  @tailwind base; to the top of the custom.css file, the TW preflight load after the Docusaurus styles. That's what causes the issue with the UI getting borked and the need to disable the preflight.
So, is there any other file we could use to load @tailwind base; earlier? I guess not?

@slorber I think one solution would be to make Docusaurus a headless documentation lib

That's already the direction we take by moving most client code not related to styling to a @docusaurus/theme-common package, but there's still a lot of work to do to make it happen.

Or keep infima for the default CSS architecture but allow users to completely remove it easily.

It is already possible to implement your own theme, not using Infima. The problem is that you'll have to reimplement many things. The goal of @docusaurus/theme-common is that you'll have to only have to reimplement the things related to styling, and reuse all the things we already worked on for the classic theme (theme config, React hooks, accessibility, i18n, UX...).

I can't help much on the Tailwind side, not have much experience using it so far.

Is it possible to apply styling to only one page? I'm working on this use-case in this PR

@gazpachu I found a workaround for loading the preflight before the Docusaurus styles. I disabled preflight in the tailwind.config.js and then Injected the preflight CSS with the injectHtmlTags option:
async function pluginTailwindCSS(context, options) {
  return {
    name: "docusaurus-tailwindcss",
    injectHtmlTags() {
      return {
        headTags: [
          {
            tagName: "link",
            attributes: {
              rel: "stylesheet",
              href: "https://cdn.jsdelivr.net/npm/tailwindcss/dist/preflight.min.css",
            },
          },
        ],
      };
    },
    configurePostCss(postcssOptions) {
      // Appends TailwindCSS and AutoPrefixer.
      postcssOptions.plugins.push(require("tailwindcss"));
      postcssOptions.plugins.push(require("autoprefixer"));
      return postcssOptions;
    },
  };
},

Have this one been resolved?

This hasn't been resolved and is not currently being worked on.
I'm currently working on making Docusaurus much faster, notably by adopting Rust tools like Rspack, SWC, and LightningCSS.
For that, we need to get rid of PostCSS, which is currently needed for Tailwind. In v4 with Oxide Tailwind will also adopt LightningCSS (details).
We'll look into adding first-class Tailwind support, and a Tailwind theme, once we both successfully adopt LightningCSS.

@kvnxiao's (revised/edited) recipe in https://github.com/facebook/docusaurus/issues/2961#issuecomment-735355912 works quite well (better to snoop around in the Discord4J project they linked IMO to see how everything is laid out), with the addition that @tailwind entries need to be added to one's custom.css file, e.g.
@tailwind base;
@tailwind components;
@tailwind utilities;

This is standard fare for a tailwind project ofc, but I neglected to do this at first (I guess I thought postcss would somehow roll things up without those rules), and so thought the tailwind+docusaurus integration wasn't working for a while.

I have setup Tailwind recently on Docusaurus 3.5, here is the commit: https://github.com/betalectic/website/commit/55a5c53f07eefb4e4068ab19de1df5950dd4a405
Thanks to various contributors above.
cc @Abhishek-Beta


Separate setting per user

I think this was what was asked in #76 but its possible there was a misunderstanding there.
I'd like to save settings per-user. I have extended the model provided with this package and am associating user_id with settings that are saved but, and forgive me if I am doing something wrong, each save of settings just updates the existing row of the one setting that was defined.
This means every user in the system can just update the same "global" setting? I'd like a setting preference for each individual user (i.e. notification preferences). This package seems like it would be ideal tool (really don't like making nova components for every little thing)  but I'm not clear if this is possible out of the box with nova-settings?

This is not possible out of the box. You would have to rework the core logic to use user_id <-> settings_key pairs instead of just setting keys.

Ah okay - no problem. Thanks for the quick response!


impl Trait in resources?

Is it possible to use impl Trait in resources?
I get following error on nightly, even with corresponding feature enabled.
error[E0562]: `impl Trait` not allowed outside of bindings or function and inherent method return types
  --> src/main.rs:68:19
   |
68 |     static mut B: impl X = ();
   |                   ^^^^^^

UPD:
Here is the example where I would like to use impl Trait in resource definition, but can't: https://github.com/copterust/fcfs-rtfm/tree/show-compile-fail.

Without this feature you have to provide type aliases for complex types, and you also can't use opaque types as resources.

I think I've got it to work using existentials, but I wonder it this the best way:
mod c {
    use super::hprintln;
    pub existential type C: T;
    pub trait T {
        fn dodo(&self);
    }
    pub struct TT;
    impl T for TT {
        fn dodo(&self) {
            hprintln!("xx").unwrap();
        }
    }

    pub fn mk() -> C {
        TT
    }
}
use c::T;

#[app(device = stm32f30x)]
const APP: () = {
    static mut EXTI: stm32f30x::EXTI = ();
    static mut MPU: MPU9250 = ();
    static mut I: Instant = ();
    static mut CC: CyclesToTime = ();
    static mut ExT: c::C = ();
// rest is ommitted
}

https://gist.github.com/1aefa621a9e179f267afe532a4ddfc9e

Hi Roma
Not sure exactly what you want to do.
This pattern (tried in Playground not RTFM) would allow you to store a reference to an implementer of X in B. The type that implements X is not mentioned here, could be anything (opaque if so wished I believe).
trait X {}
static mut B:Option<&'static X> = None;
or…
mod c {
pub trait X { }
struct C {
    private_field: u32
}

impl X for C {}

fn mk_c() -> C {
    C { private_field: 0}
}

}
static mut C:Option<&'static c::X> = None;
if you want some scoping and opaque data type.
For more on visibility see, https://doc.rust-lang.org/reference/visibility-and-privacy.html.
… or maybe I got your use case wrong…
Best regards,
Per
To learn more, run the command again with --verbose.
On 17 Mar 2019, at 18:34, Roma Sokolov <notifications<EMAIL_ADDRESS>wrote:
Without this feature you have to provide type aliases for complex types, and you also can't use opaque types as resources.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473687503, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD5naAUJDeNC88zfkx5ETpqUkBuACPXyks5vXnylgaJpZM4b4g4Z.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/japaric/cortex-m-rtfm","title":"japaric/cortex-m-rtfm","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/japaric/cortex-m-rtfm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@little-arhat in #164: Without this feature you have to provide type aliases for complex types, and you also can't use opaque types as resources. "}],"action":{"name":"View Issue","url":"https://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473687503"}}} [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473687503", "url": "https://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473687503", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Hi Roma..
Is trait sealing perhaps what your after.
https://rust-lang-nursery.github.io/api-guidelines/future-proofing.html
Restricting the implementation of a trait, to some specific scope. Else associated items in a pub trait are pub by default.
Best regards,
Per
On 17 Mar 2019, at 19:24, Per Lindgren <per.lindgren<EMAIL_ADDRESS>wrote:
Hi Roma
Not sure exactly what you want to do.
This pattern (tried in Playground not RTFM) would allow you to store a reference to an implementer of X in B. The type that implements X is not mentioned here, could be anything (opaque if so wished I believe).
trait X {}
static mut B:Option<&'static X> = None;
or…
mod c {
pub trait X { }
struct C {
    private_field: u32
}

impl X for C {}

fn mk_c() -> C {
    C { private_field: 0}
}

}
static mut C:Option<&'static c::X> = None;
if you want some scoping and opaque data type.
For more on visibility see, https://doc.rust-lang.org/reference/visibility-and-privacy.html.
… or maybe I got your use case wrong…
Best regards,
Per
To learn more, run the command again with --verbose.
On 17 Mar 2019, at 18:34, Roma Sokolov <notifications<EMAIL_ADDRESS>wrote:
Without this feature you have to provide type aliases for complex types, and you also can't use opaque types as resources.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473687503, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD5naAUJDeNC88zfkx5ETpqUkBuACPXyks5vXnylgaJpZM4b4g4Z.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/japaric/cortex-m-rtfm","title":"japaric/cortex-m-rtfm","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/japaric/cortex-m-rtfm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@little-arhat in #164: Without this feature you have to provide type aliases for complex types, and you also can't use opaque types as resources. "}],"action":{"name":"View Issue","url":"https://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473687503"}}} [ { "@context": "http://schema.orghttp://schema.org/", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473687503", "url": "https://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473687503", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.comhttps://github.com/" } } ]

@perlindgren, no, I'm not interested in sealed traits, I just want to define resource that has quite a long type. Users (tasks) shouldn't have to know those details, they should only its trait.
I guess I can go with references, but then it's another level of indirection, and I would have to store my object as a static manually, without using rtfm resources.
type:
mixer::MotorCtrl<nalgebra::base::matrix::Matrix<f32, nalgebra::base::dimension::U6, nalgebra::base::dimension::U4, nalgebra::base::array_storage::ArrayStorage<f32, nalgebra::base::dimension::U6, nalgebra::base::dimension::U4>>, (alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA0<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim2::Channel<alt_stm32f30x_hal::timer::CH1, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF1>, alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA1<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim2::Channel<alt_stm32f30x_hal::timer::CH2, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF1>, alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA2<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim2::Channel<alt_stm32f30x_hal::timer::CH3, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF1>, alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA3<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim2::Channel<alt_stm32f30x_hal::timer::CH4, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF1>, alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA6<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF2, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim3::Channel<alt_stm32f30x_hal::timer::CH1, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF2>, alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA7<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF2, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim3::Channel<alt_stm32f30x_hal::timer::CH2, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF2>)>

Hi Roma
Hmm, if you store them outside of RTFM they would require unsafe access. That's the main point with RTFM, safe access to shared resources. If only one task can access/mutate the resource, then you can make it a task local (with mutable safe access without any need for locking).
The same rules to storing trait objects should apply with or without RTFM, so you would gain nothing by unsafe access.
Let us know how you ended up solving the problem and/or if you run into further problems/questions. (There might still be things in RTFM that should be possible to express, but the current implementation would block you, and we are eager to work those out...)
Best
Per

Från: Roma Sokolov<EMAIL_ADDRESS>Skickat: den 17 mars 2019 20:06:15
Till: japaric/cortex-m-rtfm
Kopia: Per Lindgren; Mention
Ämne: Re: [japaric/cortex-m-rtfm] impl Trait in resources? (#164)
@perlindgrenhttps://github.com/perlindgren, no, I'm not interested in sealed traits, I just want to define resource that has quite a long type. Users (tasks) shouldn't have to know those details, they should only its trait.
I guess I can go with references, but then it's another level of indirection, and I would have to store my object as a static manually, without using rtfm resources.
type:
mixer::MotorCtrl<nalgebra::base::matrix::Matrix<f32, nalgebra::base::dimension::U6, nalgebra::base::dimension::U4, nalgebra::base::array_storage::ArrayStorage<f32, nalgebra::base::dimension::U6, nalgebra::base::dimension::U4>>, (alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA0<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim2::Channel<alt_stm32f30x_hal::timer::CH1, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF1>, alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA1<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim2::Channel<alt_stm32f30x_hal::timer::CH2, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF1>, alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA2<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim2::Channel<alt_stm32f30x_hal::timer::CH3, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF1>, alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA3<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim2::Channel<alt_stm32f30x_hal::timer::CH4, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF1>, alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA6<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF2, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim3::Channel<alt_stm32f30x_hal::timer::CH1, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF2>, alt_stm32f30x_hal::pwm::PwmBinding<alt_stm32f30x_hal::gpio::PA7<alt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn<alt_stm32f30x_hal::gpio::AF2, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed>>, alt_stm32f30x_hal::timer::tim3::Channel<alt_stm32f30x_hal::timer::CH2, alt_stm32f30x_hal::timer::Pwm1>, alt_stm32f30x_hal::gpio::AF2>)>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473704760, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD5naNWhI1xMuerSxEs2k93TQCsD3PjZks5vXpIngaJpZM4b4g4Z.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/japaric/cortex-m-rtfm","title":"japaric/cortex-m-rtfm","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/japaric/cortex-m-rtfm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@little-arhat in #164: @perlindgren, no, I'm not interested in sealed traits, I just want to define resource that has quite a long type. Users (tasks) shouldn't have to know those details, they should only its trait.\r\n\r\nI guess I can go with references, but then it's another level of indirection, and I would have to store my object as a static manually, without using rtfm resources. \r\n\r\ntype: \r\nmixer::MotorCtrl\u003cnalgebra::base::matrix::Matrix\u003cf32, nalgebra::base::dimension::U6, nalgebra::base::dimension::U4, nalgebra::base::array_storage::ArrayStorage\u003cf32, nalgebra::base::dimension::U6, nalgebra::base::dimension::U4\u003e\u003e, (alt_stm32f30x_hal::pwm::PwmBinding\u003calt_stm32f30x_hal::gpio::PA0\u003calt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn\u003calt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed\u003e\u003e, alt_stm32f30x_hal::timer::tim2::Channel\u003calt_stm32f30x_hal::timer::CH1, alt_stm32f30x_hal::timer::Pwm1\u003e, alt_stm32f30x_hal::gpio::AF1\u003e, alt_stm32f30x_hal::pwm::PwmBinding\u003calt_stm32f30x_hal::gpio::PA1\u003calt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn\u003calt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed\u003e\u003e, alt_stm32f30x_hal::timer::tim2::Channel\u003calt_stm32f30x_hal::timer::CH2, alt_stm32f30x_hal::timer::Pwm1\u003e, alt_stm32f30x_hal::gpio::AF1\u003e, alt_stm32f30x_hal::pwm::PwmBinding\u003calt_stm32f30x_hal::gpio::PA2\u003calt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn\u003calt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed\u003e\u003e, alt_stm32f30x_hal::timer::tim2::Channel\u003calt_stm32f30x_hal::timer::CH3, alt_stm32f30x_hal::timer::Pwm1\u003e, alt_stm32f30x_hal::gpio::AF1\u003e, alt_stm32f30x_hal::pwm::PwmBinding\u003calt_stm32f30x_hal::gpio::PA3\u003calt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn\u003calt_stm32f30x_hal::gpio::AF1, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed\u003e\u003e, alt_stm32f30x_hal::timer::tim2::Channel\u003calt_stm32f30x_hal::timer::CH4, alt_stm32f30x_hal::timer::Pwm1\u003e, alt_stm32f30x_hal::gpio::AF1\u003e, alt_stm32f30x_hal::pwm::PwmBinding\u003calt_stm32f30x_hal::gpio::PA6\u003calt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn\u003calt_stm32f30x_hal::gpio::AF2, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed\u003e\u003e, alt_stm32f30x_hal::timer::tim3::Channel\u003calt_stm32f30x_hal::timer::CH1, alt_stm32f30x_hal::timer::Pwm1\u003e, alt_stm32f30x_hal::gpio::AF2\u003e, alt_stm32f30x_hal::pwm::PwmBinding\u003calt_stm32f30x_hal::gpio::PA7\u003calt_stm32f30x_hal::gpio::PullUp, alt_stm32f30x_hal::gpio::AltFn\u003calt_stm32f30x_hal::gpio::AF2, alt_stm32f30x_hal::gpio::PushPull, alt_stm32f30x_hal::gpio::MediumSpeed\u003e\u003e, alt_stm32f30x_hal::timer::tim3::Channel\u003calt_stm32f30x_hal::timer::CH2, alt_stm32f30x_hal::timer::Pwm1\u003e, alt_stm32f30x_hal::gpio::AF2\u003e)\u003e"}],"action":{"name":"View Issue","url":"https://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473704760"}}} [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473704760", "url": "https://github.com/japaric/cortex-m-rtfm/issues/164#issuecomment-473704760", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Existensial is the solution: RTFM need a type for its code génération, and impl ils not a type.

@TeXitoi however, with existentials I still can't hide type parameters, due to part of concrete type but not used in parameter list for existential type, so I still have to expose internal details and create huge type aliases.
Or maybe I'm missing something?

I'm not really award of thé existential feature. I think you may use something like existential un trait. Can you give your needs, I might try to find something tomorrow.

@little-arhat what you really want is whole-crate type inference. That is you want this to compile:
static mut X: Option<_> = None;

fn main() {
    unsafe {
        X = Some(0i32);
    }
}

Then you don't need any intermediate trait. However, I haven't seen any RFC for that.
Existential types and impl Trait won't really help. AFAICT, the opaque / existential type is only resolved when it appears in the signature of a function which defeats the point as you would need to a dummy function that calls a constructor or similar (the c::mk in your example).

however, with existentials I still can't hide type parameters

I imagine you are trying to write something like this:
#![feature(existential_type)]

use core::ops::{Deref, DerefMut};

existential type Foo: DerefMut;

static mut X: Option<Foo> = None;

fn foo() -> i32 {
    unsafe { *X.as_ref().unwrap().deref() + 1 }
}

fn main() {
    unsafe {
        X = Some(0i32); // <- `Foo = i32`
    }
}

AIUI this won't work because of how rustc does type unification today. Whether this would work some day I don't know; you would need to ask the compiler team.
AFAICS we can't do anything about this on the RTFM side as it needs better compiler support.
P.S. I can relate to the inconvenience of the long types. I get rid of them using type aliases in a library crate that the application links to.

@japaric thanks for info and insights! Yeah, I guess that's not strictly related to cortex-m-rtfm, but more of a general rust question...
Yes, whole-crate inference would help, but I guess we'll not get it (anytime soon) %).
But I also wonder how to create abstract types, in a sense that they should hide internal and unintresting details: users of a library should know that lib::Thing can do SomeThings, but they don't have to know that Thing is parametrized over N other types. I guess type aliases could help a bit, but then in the type error you'll still see nalgebra::base::matrix::Matrix<f32, nalgebra::base::dimension::U6, nalgebra::base::dimension::U4, nalgebra::base::array_storage::ArrayStorage<f32, nalgebra::base::dimension::U6, nalgebra::base::dimension::U4>> instead of Matrix6 that you've used.
Adding dynamic dispatch in the mix would also help, but for a price.
Another related thing bothers me: I have a sensor that my program communicates with over I2c. I've defined type I2c = device::I2c<...> with all the pins and details,  and I use Sensor<I2c> as a type of resource. Then, I want to use another i2c connected sensors and I use something like shared-bus to make it work:
    let i2c = ...
    let bus = SharedBus::new(i2c);
    let mut sensor1 = Sensor1::new(bus.acquire());
    let mut sensor2 = Sensor2::new(bus.acquire());

(I acknowledge shared bus might not be ideal soluation in the RTFM, but bear with me).
But now the type of the sensor is something like shared_bus::CortexMBus<shared_bus::CortexMProxy<RecCell<I2c>>, I2c> (it's actually worse)! Of course, type aliases would help, especially if provided by library author, but is this really how it should be?
Thanks for your input, everyone!

This seems to be done discussing.


Update snowflake-setup.md

Proposed changes
RETL docs, are missing allowlist info. Added the pre-built IP allowlist info.
Merge timing

ASAP once approved?

@charholt is there a reason why we need this specifically on the Snowflake RETL setup page?

It really should be on all the set-up pages except BQ, since allow listing is a requirement for almost all the connections.

@charholt is this note still necessary to have in our docs? It's been almost a year. Did all users not update their allowlists?


Additional resources field shows different links for "status" tab vs. version "01", "02", "03", etc.

Describe the issue
In datatracker, the Additional Resources field can be used to add references relevant to the document, such as a GitHub link of (proof-of-concept) implementations or to the mailing list discussion.
When opening an Internet-Draft datatracker page, the "Status" tab is displayed with no specific version in the URL and the Additional Resources field shows multiple links. However, if one opens a specific version, say 03, it only shows the link to the Mailing list discussion
For example, see draft-ietf-dnsop-dns-error-reporting and the screenshots for the two URLs:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/03/

Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

We aren't storing additional resources along with DocHistory (and likely neither GroupHistory or PersonHistory). See the mechanics for RelatedDocumentHistory for what we might do different.


#1 corrected .travis.yml file

Corrected first line in file.

@rultor merge pls

@rultor merge pls

@amihaiemil OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge pls

@amihaiemil Done! FYI, the full log is here (took me 1min)


Release/0.3.1

Codecov Report

Merging #51 (f768f77) into main (995d32b) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #51   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           31        31
  Lines          826       831    +5
=========================================
+ Hits           826       831    +5

Impacted Files
Coverage Δ

pfhedge/features/_base.py
100.00% <ø> (ø)

pfhedge/features/_getter.py
100.00% <ø> (ø)

pfhedge/features/features.py
100.00% <ø> (ø)

pfhedge/instruments/_base.py
100.00% <ø> (ø)

pfhedge/nn/bs/bs.py
100.00% <ø> (ø)

pfhedge/nn/modules/loss.py
100.00% <ø> (ø)

pfhedge/_utils/bisect.py
100.00% <100.00%> (ø)

pfhedge/_utils/hook.py
100.00% <100.00%> (ø)

pfhedge/_utils/operations.py
100.00% <100.00%> (ø)

pfhedge/nn/bs/_base.py
100.00% <100.00%> (ø)

... and 1 more

Continue to review full report at Codecov.

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


Disable redirects by default and add options to configure redirects

Summary of changes
The RedirectPolicy no longer follows redirects by default when using the default Transport. This behavior is configurable via new options in two scenarios:

Customers choosing to enable or disable redirects globally via ClientOptions.ClientRedirects.IsClientRedirectEnabled. This setting takes precedence over the following setting.
Client authors choosing to enable or disable redirects globally via HttpPipelineTransportOptions.IsAutoRedirectEnabled

Because the RedirectPolicy is still added to the pipeline in all scenarios, the per-message  RedirectPolicy.SetAllowAutoRedirect(...) method's behavior is unchanged.

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

Customers choosing to enable or disable redirects globally via ClientOptions.ClientRedirects.IsClientRedirectEnabled. This setting takes precedence over the following setting.

Why do we need this option? Shouldn't it always be turned off unless needed for a library? For something truly custom, customers can customize the pipeline via the second option being added here.

Client authors choosing to enable or disable redirects globally via HttpPipelineTransportOptions.IsAutoRedirectEnabled

Couldn't this one be configured using the RedirectPolicy.SetAllowAutoRedirect method?

Customers choosing to enable or disable redirects globally via ClientOptions.ClientRedirects.IsClientRedirectEnabled. This setting takes precedence over the following setting.

Why do we need this option? Shouldn't it always be turned off unless needed for a library? For something truly custom, customers can customize the pipeline via the second option being added here.

One of the explicit goals was to allow this to be configurable by customers easily. The HttpPipelineTransportOptions.IsAutoRedirectEnabled option is only accessible to client authors that are building the pipeline. Setting a custom transport is the only other way a customer could enable redirects, but that seems like overkill.

Client authors choosing to enable or disable redirects globally via HttpPipelineTransportOptions.IsAutoRedirectEnabled

Couldn't this one be configured using the RedirectPolicy.SetAllowAutoRedirect method?

Not really. RedirectPolicy.SetAllowAutoRedirect is only available if you have access to the HttpMessage and must be set per-request. So, for example, in an HLC, this would require customizing each generated method.

One of the explicit goals was to allow this to be configurable by customers easily.

Why is this one of the goals? I thought the goal was to turn off redirects unless it is explicitly required by the service. To me that seems like we would only need this to be configurable by library authors, not necessarily by end users.

One of the explicit goals was to allow this to be configurable by customers easily.

Why is this one of the goals? I thought the goal was to turn off redirects unless it is explicitly required by the service. To me that seems like we would only need this to be configurable by library authors, not necessarily by end users.

There are scenarios where customers would want to enable this, but I'm ok with removing this for now and adding it back if we receive feedback on it.


🐛 [Epic Games Free] Version discrepancy seems to have reappeared

Which addon?

Addon name : Epic Games Free
Addon version : Latest/Current/etc.

Describe the bug
Add-on version has fallen behind released version of the original docker image again.
Note
Snipped the other questions because they do not apply.

Hi, the automatic update is every saturday.
67778639ee9bc09c8a543f7e7904116f850dcabc was released 16 days ago (so is the current version), a730bceb8ad5c476fd6c2a90e5685e2ed6783957 was released 1 day ago (and will be updated tomorrow).
So it seems to me everything is as should be ?

Ah! I didn't realize there was a schedule. Apologies, and you are correct.

Thanks! As the updater runs on my rpi I've limited the run of time it runs. It also reduces the probability of picking up releases with issues that would have been pulled or for which a new version would be instantly pushed


add folder upload with drag&drop

I tried to upload some folders. Seems like they are handled as an empty file because Buefy-upload can't handle folders yet:

Found #25 in a quick search, so I tried to add this as a feature.
With some (small) changes in the frontend it seems already to work:

Browser.vue

unbind Buefy-upload from 'dropzone'

Upload.vue

bind resumable directly to 'dropzone'
changes to combine relativePaths from filegator and resumable

Codecov Report

Merging #147 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #147   +/-   ##
=========================================
  Coverage     89.42%   89.42%
  Complexity      402      402
=========================================
  Files            26       26
  Lines          1021     1021
=========================================
  Hits            913      913
  Misses          108      108

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 ccd935d...962ec7b. Read the comment docs.

Seems to work great at first glance! I'm surprised 👍

I'll add a quick note here, this is broken in IE and Safari, maybe it will be fixed in the future...
https://github.com/23/resumable.js/issues/221

wow, different browsers have different implementations and behaviours for drag&drop folders.
found a nice overview here: https://github.com/leonadler/drag-and-drop-across-browsers#drag--drop-for-folders

Yup. Anyway, I'm willing to merge this since it works great in chrome & firefox


Pr/demo

Please check this PR and let me know.

If it is a chore: will this make a release? Because the demo is broken and fixed in this PR.


External downloader

How can I use this script with a external downloader like aria2c.

Hey @cyber-hunt7, unfortunately, it is not supported. You may use flag -l to get m3u8 link, then try to external downloader... But I still think using ffmpeg is easier.

Hi, ok will try that thank you


Validation SARIF output doesn't fully work with VSC SARIF extension

When opening @monokle/validation SARIF output with VSC SARIF extension, not all fields are correctly filled-up. See the difference how it looks in the cloud and SARIF ext below:

Rule name and description are missing.
Steps

I generated output file by running below command in the terminal:

monokle validate --output sarif pod-errors.yaml > results.sarif

And then loaded it to SARIF ext via Ctrl+Shift+P > SARIF: Show Panel > Open logs.

Potential causes
Not sure yet, either our output is not full compliant with SARIF specs, or VSC SARIF ext is not fully compliant with it.
What I noticed is that adjusting the output runs.results[].rule.toolComponent from:
      "results": [
        {
          "ruleId": "KSV001",
          "rule": {
            "id": "KSV001",
            "index": 0,
            "toolComponent": {
              "name": "open-policy-agent"
            }
          },
        ...
      }

to adding an index in toolComponent:
      "results": [
        {
          "ruleId": "KSV001",
          "rule": {
            "id": "KSV001",
            "index": 0,
            "toolComponent": {
              "index": 0,
              "name": "open-policy-agent"
            }
          },
        ...
      }

fixes it:

The question is why 🤔 I need to check with the specs if this is valid and we can follow this route or something else should be adjusted or fixed (could be an issue on SARIF ext side too).

The output file for quick testing:
It's not a .zip file, I just added the extension so GH upload accepts it. It's a .json file so you may want to get rid of .zip ext after downloading.
results.sarif.zip

WIP... expect this comment to be updated soon
Went through the specs a bit and my interpretations is as below:
toolComponent lookup
For a toolComponent part:

A toolComponentReference object identifies a particular toolComponent object (§3.19), either theTool.driver (§3.18.2) or an element of theTool.extensions (§3.18.3). We refer to the identified toolComponent object as theComponent.

So toolComponent / theComponent would be on of the below:

Identified based on:

3.54.2 toolComponent lookup
If neither index (§3.54.4) nor guid (§3.54.5) is present, theComponent SHALL be theTool.driver (§3.18.2).
If index is present, theComponent SHALL be the object at array index index within theTool.extensions (§3.18.3).
If index is absent and guid is present, theComponent SHALL be either theTool.driver or an element of theTool.extensions, whichever one has a matching guid property.

This means that if there is no index or guid, .driver will be used as theComponent, which in our case doesn't include any info on rules. Everything is stored inside .extensions.
How is theComponent used to relate .results.rule data with rules metadata?
toolComponent
As described here:

3.19.23 rules property
A toolComponent object MAY contain a property named rules whose value is an array of zero or more unique (§3.7.3) reportingDescriptor objects (§3.49) each of which provides information about an analysis rule supported by the tool component.
Some tools use the same identifier to refer to multiple distinct (although logically related) rules. Therefore, the id properties (§3.49.3) of the reportingDescriptor objects do not need to be unique within the array.


Error after closing Vertcoin wallet - v<IP_ADDRESS>

This issue tracker is only for technical issues related to Vertcoin.
Expected behaviour
close vertcoin wallet
Actual behaviour
when closing appears this error
Screenshots.

What version of Vertcoin are you using?
v<IP_ADDRESS> Bug Fix Release:
vertcoin-x86_64-w64-mingw32.zip
Machine specs:

OS: Windows 8.1
CPU: i5-4210M 2.6GHz
RAM: 8gb
Disk size: 1tb
Disk Type (HD/SDD): HD

Any extra information that might be useful in the debugging process.
2017-03-06 18:18:57 tor: Thread interrupt
2017-03-06 18:18:57 opencon thread interrupt
2017-03-06 18:18:57 scheduler thread interrupt
2017-03-06 18:18:57 addcon thread interrupt
2017-03-06 18:18:57 msghand thread interrupt
2017-03-06 18:18:57 torcontrol thread exit
2017-03-06 18:18:57 net thread interrupt
2017-03-06 18:18:57 Shutdown: In progress...
2017-03-06 18:18:57 Stop
2017-03-06 18:18:57 Dumped mempool: 0s to copy, 0.038973s to dump
2017-03-06 18:18:57 *** System error while flushing: CDB: Error -30974, can't open database wallet.dat
2017-03-06 18:21:47 CDBEnv::EnvShutdown: Error -30974 shutting down database environment: DB_RUNRECOVERY: Fatal error, run database recovery
2017-03-06 18:21:47 Shutdown: done

please excuse me, this error occurs only with a OLD Vertcoin wallet version 13.99


Include flutter.jar in pre-built engine artifacts

We'll need it for the gradle-based workflow.

https://codereview.chromium.org/1870043004/
On Saturday, April 9, 2016, Adam Barth<EMAIL_ADDRESS>wrote:

We'll need it for the gradle-based workflow.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/flutter/flutter/issues/3233

Now we just need to add an entry to flutters cache to have it pulled down
and update the gradle plugin to only need a flutter.src and not a
flutter.jar and to just find the jar in the cache.
On Saturday, April 9, 2016, Eric Seidel<EMAIL_ADDRESS>wrote:

https://codereview.chromium.org/1870043004/
On Saturday, April 9, 2016, Adam Barth<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>> wrote:

We'll need it for the gradle-based workflow.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/flutter/flutter/issues/3233

Jason did this.


It makes styled-components doesn't work.

I'm having the same problem. As soon as I try to actually use the  component anywhere in my app, all styled-components styles stop working.

I agree, this is completely bizarre and a showstopper. Using the control anywhere in an app that has Styled-Components, makes them stop working everywhere in the whole application. No errors or anything in the console, just no styles anywhere. I will have a dig around and see if I can find anything.

This library is based on styled-components 2.0.0; the current version is 3.4.2.
There is nothing in this project that isn't compatible with 3.4.2. The version in package.json needs to get changed.

Is there any progress on this? Can we submit a pull request to upgrade the version of styled components?


Remove version: Jackett.Jackett version 0.20.2782

404 - release deleted
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/Jackett/Jackett/releases/download/v0.20.2782/Jackett.Installer.Windows.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 918)


Switch from Xdebug to phpdbg for code coverage

Let's see if phpdbg if faster than Xdebug...

It seems that phpdbg for PHP 7.1 hangs.
Let's try to use phpdbg with PHP 7.2...

https://github.com/concrete5/concrete5/pull/7323/commits/a0d4ebee42477254c7dd361171822bbc50f23c16 fixes the phpunif freeze problem.
It seems that using phpdbg instead of xdebug actually saves some time (about 2 minutes).


Plugins

Hey can you provide an example of how can I use UltimateTheadGroup plugin in your action?

bump

Hey @rbhadti94 - has the UltimateTheadGroup issue solved, or is this still an issue

Hey @rbhadti94 - has the UltimateTheadGroup issue solved, or is this still an issue.

Hey @rbhadti94 the ultimate thread group is still an issue. Are you planning to include the plugin in the docker so that it can pick at runtime when JMX file having ultimate thread group is passed to the action

Hey @rbhadti94 : the ultimate thread group is still an issue. Are you planning to include the plugin in the docker so that it can pick at runtime when JMX file having ultimate thread group is passed to this action

Hi @king-raj7 @ptupakul @DawidOskwarek
I see that ultimate thread group is part of jpgc-casutg. Can you specify the plugin argument?
      - name: Run JMeter Action
        uses: ./
        with:
          testFilePath: tests/sample_test.jmx
          outputReportsFolder: reports/
          args: "--loglevel INFO"
          plugins: "jpgc-casutg"

I'll update the docs if this works.

Thank you @rbhadti94,now able to get the ultimate thread group after adding the above plugin argument

I've added this into the README now. Going to close the issue. Thanks for the feedback!!


docs(ui): include special chars query reference

see #129

@dvsrepo  I will include this PR in next release. We can discuss better content after


Consider adding more "secret" params to WF API

It may be useful to allow extra functionality / arguments / control to be injected into the WFs to help debugging, tune per run optimizations, etc.
For example:
log level: bool,
bioformats chunk size: int,
ng_shader_param_quantiles: [float, float]
rechunk_in_memory: bool

Note common logging systems use "[DEBUG|INFO|WARNING|ERROR]" for logging levels.

Maybe, we can load them from .env file. Currently we have them already setup.

prefix any param that is not for public use is prefixed with x_

This is inspired by HTTP experimental or non-standard/custom headers.

The "X-" prefix indicates that a particular header is an extension or experimental header that is not part of the official HTTP specification. This naming convention helps prevent clashes with future standard headers that might be introduced in subsequent HTTP versions.


Unknown layer type encountered: PReLU

Originally posted by @maryhh in https://github.com/ethereon/caffe-tensorflow/issues/88#issuecomment-432899412
do you know how to save it ？

I'm also keen to understand how this was resolved

I ran into the same issue. See PR on how solved it: https://github.com/ethereon/caffe-tensorflow/pull/187


Report arch and kernel version

Could you please report arch and kernel version ?
Nowadays raspberry pi Os can be 64 bits and 5.x version so it would be great to report these data.

I'll happily accept pull requests for this.


Implement equals/hashcode for named DocValueFormat inner classes

Description
Implements  equals and hashCode methods for the named inner class DocValueFormat.DateTime.
Per the contract as described in the Writeable interface, any class implementing equals/hashcode must ensure that a copy made be serializing and deserializing must be equal. As InternalDateHistogram /  InternalHistogram implement equals/hashcode and are Writable classes, this requires that DateTime also implement equals and hashcode , as the DateMathParser will otherwise cause it to fail equivalence.
Check List

[x] New functionality includes testing.

[x] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff
[x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #6357 (fe01144) into main (c772596) will increase coverage by 0.12%.
The diff coverage is 42.85%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff              @@
##               main    #6357      +/-   ##
============================================
+ Coverage     70.58%   70.71%   +0.12%
- Complexity    58841    59041     +200
============================================
  Files          4799     4799
  Lines        282421   282428       +7
  Branches      40717    40720       +3
============================================
+ Hits         199341   199711     +370
+ Misses        66584    66315     -269
+ Partials      16496    16402      -94

Impacted Files
Coverage Δ

...org/opensearch/common/time/JavaDateMathParser.java
96.46% <42.85%> (-3.54%)
:arrow_down:

...java/org/opensearch/client/indices/DataStream.java
0.00% <0.00%> (-76.09%)
:arrow_down:

...adonly/AddIndexBlockClusterStateUpdateRequest.java
0.00% <0.00%> (-75.00%)
:arrow_down:

...readonly/TransportVerifyShardIndexBlockAction.java
9.75% <0.00%> (-73.18%)
:arrow_down:

...rch/test/junit/listeners/ReproduceInfoPrinter.java
9.52% <0.00%> (-68.26%)
:arrow_down:

...a/org/opensearch/client/cluster/ProxyModeInfo.java
0.00% <0.00%> (-60.00%)
:arrow_down:

...n/admin/indices/readonly/AddIndexBlockRequest.java
17.85% <0.00%> (-53.58%)
:arrow_down:

...ch/transport/ReceiveTimeoutTransportException.java
50.00% <0.00%> (-50.00%)
:arrow_down:

...pensearch/indices/breaker/CircuitBreakerStats.java
27.77% <0.00%> (-41.67%)
:arrow_down:

...indices/readonly/TransportAddIndexBlockAction.java
20.68% <0.00%> (-41.38%)
:arrow_down:

... and 537 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@bryanlb What would you like to do with this?

@dblock I'd still like to see this addressed, with the most recent suggestion from @reta. We can close this PR out and if there's interest in fixing this, I can followup with a PR that introduces those equals()/hashcode() fixes on the DocValueFormat class.

I ran across this when attempting to compare the equivalence of an InternalDateHistogram instance that had been serialized and deserialized.

@bryanlb Can you share more details about what you're trying to do at a higher level that led you to need to do this?

@andrross sure! I have a slightly unique case where I'm importing the server package as a dependency, and then using the AggregationBuilder classes to create Lucene collectors. I've had no problems with this approach - consuming the collectors, or utilizing the returned InternalAggregation classes.
I only ran into this issue when attempting to verify that serializing an InternalAggregation and deserializing it resulted in an equivalent object. While the Writeable interface notes that implementers aren't required to implement equals/hashcode, it does state that "If the implementer also implements equals and hashCode then a copy made by serializing and deserializing must be equal and have the same hashCode". In the case of InternalDateHistogram this class does implement both an equals and hashcode, but does not maintain this stated contract.

@bryanlb So are you using the OpenSearch server as a library in a separate (non-OpenSearch) application? It's always interesting to hear unique use cases :) I will caution that there are no stability guarantees with these internal classes so you may frequently encounter breaking changes.
That's a fair point about not correctly implementing the contract defined by the Writeable interface. I'm not sure about implementing equals/hashcode in DocValuesFormat (though I am no expert in this area). A possible alternative: the only information InternalDateHistogram sends over the wire for its DocValuesFormat field is it's name (DocValuesFormat is a NamedWriteable), would it be fair to use format.getWriteableName() in the equals/hashcode implementation of InternalDateHistogram?

That's a fair point about not correctly implementing the contract defined by the Writeable interface. I'm not sure about implementing equals/hashcode in DocValuesFormat (though I am no expert in this area).

@andrross Just to give some context on the issue at large, the InternalDateHistogram and others like  InternalHistogram do implement the equals / hashCode using internal state. That basically assumes that internal components do implement the equals / hashCode as well, which in case of InternalDateHistogram means equality for DocValueFormat:
    ...
    private final DocValueFormat format;
    ...

It think this is indeed a problem (may be uncovered in unusual way by @bryanlb) but we need to fix.

It think this is indeed a problem (may be uncovered in unusual way by @bryanlb) but we need to fix.

@reta Got it. Seems like we should override equals/hashcode in each DocValueFormat concrete class. Should be pretty straightforward.

@andrross @reta I can get an update done for those changes next week. Do we want to keep it tied to this PR or would you prefer a new one that references this?

@bryanlb LGTM, could you please add the entry to CHANGELOG? thank you

Backport: https://github.com/opensearch-project/OpenSearch/pull/6584


Update migrate-from-hub-spoke-topology.md

Remove premium restriction for ER after constraint lifted by product team

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

Thanks! I've updated this in a different PR. It will publish this week. #please-close


Style multiple line charts differently

Hi there! This is an awesome library. I would like to know if it's possible to style multiple line charts differently. Please find below a screenshot of what I have currently vs what I am trying to achieve. I am able to render multiple data sets using a line graph for projection. I would like to know if it is possible to style the line graphs to look different from each other? Thanks!
What I have curently

What I am trying to achieve. Note how the line graphs have different gradients an stroke colors

please check the doc for details, you can pass your own color under each data
    {
      data: [20, 45, 28, 80, 99, 43],
      color: (opacity = 1) => `rgba(134, 65, 244, ${opacity})`, // optional
      strokeWidth: 2 // optional
    }

@Billmike how did you get the stroke to be fully opaque?


Dynamically ask user to fill webdash.json with current defaults

Rather than asking the user, guess these values just like Workbox does
by searching the project directory for a manifest.json (for example)

fs-finder or find-in-files

Folders: node-find-folder
Files: find

[x] src
[x] dist
[x] jsBudgetLimit
[x] jsBudgetPath
[x] manifestPath
[ ] readableAssets
[ ] generate json config rather than copying file
[ ] refactor into lib

Fix:
 "jsBudgetPath": ".//Users/....com/dist/js/*.js",
 "manifestPath": "./build/default/manifest.json",

knowing that dist is ./dist/

✅


Found a better fixed table header lib

Found a lib that doesn't seem to have as many issues as this one:
http://mkoryak.github.io/floatThead/
Many of the open issues of this lib do not exist there. Wanted to pass this on since it saved me some headaches

94 Open Issues now.  Thanks for the link jesscold.  Projects in this state should really be labeled "currently unusuable" on the front page, to save people trying to get work done from spending time trying in vain to make them work.  Putting the header in a separate div with different col-widths and an un-synced scroll bar is not "ready for production" by a stretch.


Weekly heads-up email before charging

Reticketed from #1124:
"If you warn me first, it might reduce chargebacks / fraud complaints / failed charges. You can put a link in the warning email back to my account so that I can immediately cancel my giving."
Basically: we want an opt-in weekly email to send people notifications on the day before payday, informing them that we will be charging their credit card, preferably with an estimate.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

+1 from Braintree on https://github.com/gratipay/gratipay.com/issues/3287.

E.g. from Shareable:

Etc. Etc. It's quite verbose.

Loose +1 from support:

Why don't you try to charge again for failed payments in the past?

This user's credit card was "processor declined." Maybe if the user was notified beforehand, this could have been rpevented?

Closing in light of our decision to shut down Gratipay.
Thank you all for a great run, and I'm sorry it didn't work out! 😞  💃


Allow interpreting JoyAxis as JoyButton

Let the user configure, if a JoyAxis should be interpreted as a pair of JoyButtons (negative and positive side).
When an axis is configured as a button, then InputEventJoypadButton-events are sent instead of InputEventJoypadMotion-events for this axis.
resolve #72636
Being unfamiliar with this part of the code-base, It is likely, that I have missed some details.
MRP for testing: AxisButton.zip

If there's the problem that is_action_pressed/released() doesn't have enough resolution (e.g., two quick presses in a row are registered as a continuous press, with no release in the middle), #77062 could help. That one would only address the problem on Android, and for other OS abstrations that are rearchitected to split main and OS threads.
It'd be interesting to know if on non-Android platforms, there's an issues at the moment with is_action_pressed/released() and that's forcing games to need a feature like the one implemented here.

As discussed in a previous PR-review meeting, there are better ways to resolve the linked issue. Closing.


[Bug]: system_fingerprint is always null when using CreateResponse.fake

Description
When I'm creating a fake chat response via CreateResponse.fake and I attempt to override the system fingerprint field, it is always set to null in the client's response. This means that I'm unable to use the fake method to test code that relies on system_fingerprint. The current workaround is to use CreateResponse.from and provide the full attributes array (including the system fingerprint).
Steps To Reproduce
<?php

use OpenAI\Responses\Chat\CreateResponse;
use OpenAI\Testing\ClientFake;

// Create a fake client and override the `system_fingerprint` field
$client = new ClientFake([
  CreateResponse::fake([
    'system_fingerprint' => 'abcxyz123'
  ]),
]);

// Make a call to the fake client
$response = $client->chat()->create([
  'model' => 'gpt-4',
  'messages' => [
    ['role' => 'system', 'content' => 'Some system prompt'],
    ['role' => 'user', 'content' => 'Some user prompt']
  ]
]);

// The response's system fingerprint property is `null`
var_dump($response->systemFingerprint);

OpenAI PHP Client Version
v0.8.0
PHP Version
8.1.24
Notes
It appears that because the system_fingerprint field isn't specified in the CreateResponseFixture, it can't be overwritten by Fakeable.buildAttributes. It seems that support for system_fingerprint was added in November, but it wasn't included in the fixture.

Fixed in https://github.com/openai-php/client/pull/308


B escape task

This branch was created to work with the EscapeTextTranformer class, which have the function converts special characters of input text into a Latex form. The Transform method for the decorator template was added, documentation and tests were also added. Also in this branch maven-enforcer-plugin was added to pom.xml. And the properties file was updated for the correct work of a logger at the DEBUG and INFO levels. In addition the logger in 2 functions : inverting text and escape characters to Latex form. Also logger is present in main Controller

The build is failing.


add breadcrumb to build scope

Docs Build status updates of commit 0a14e8c:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/docfx.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


no module named esri2open

do I have to install anything? All I did was download and unzip the package, but I saw a folder called Install and then I got this error.
sorry if i'm missing something really obvious; new to github

IDLE has also been saying that there's no module named arcpy?

Been trying to use the tool from 10.4 with no luck.


Upgrade to jammy

Issue

Solution

Context

Testing

Release Notes

I have checked the content of PR. IMHO we should consider to switch to jammy now as OCI dataplatformoci/postgres-patroni:latest is already in Jammy, but charm and tests are in focal... Uff...
@marceloneppel do you see the reason not to jump now?

These changes need to be tested agains the bundle to ensure it's working correctly. I'll do it during the week to merge this PR.

The Discourse charm started to request extensions today (the version that requests extensions was promoted to stable today): https://github.com/canonical/discourse-k8s-operator/commit/08830d595de9bd391e74d5b0740f0390b8861a1e. So, the test was changed in this PR. Also,


sort with ApiMode = false

it is not support sort and filtering with ApiMode= false ?

@cpfarher Not at the moment.

Checking on this as I ran into the issue using VueX as well...
I was going to utilize the:
getSortParam: function(sortOrder) {
console.log(sortOrder)
}
to access the object and sort my own data array, however I noticed that in api-mode = false it just states that "Data Mode Array" and no data is being sent. If that could send the same object even if data mode is false, then this would suffice :D just tossing 2 cents out there

@SeoRoman Have you check out this codepen. I'm not sure if it's what you're looking for.
In Data mode, the (chunk of) data is supplied directly to Vuetable, so it never assume to manipulate those data directly because it never assume that the whole data is given. That means the sorting and filtering is likely to produce incorrect result. But you can use external library like lodash to manipulate the data before giving to Vuetable. Vuetable will only help conveying user intention/interaction back to your code to be handled appropriately as you see fit. This is demonstrated in the above example.
I, personally, think the Data mode is not fluent as it should be and hope to improve it, but, somehow, constraint by the current responsible work.

Hey there. Seeing that this was last commented 6 days ago I just wanted to slide-in to echo my support and enthusiasm for sorting with the data prop : ).
I'm fresh to using your component but it looks like the most robust and best-documented out there, so I'm excited to dig in.
I haven't fully absorbed the docs yet so I'm not sure it's possible, but in my use case the data is already present in state so I am passing it to the datatable component through a prop, and I was thinking that if I could control the click events on the table headings I could just toggle between my getters in Vuex, which can handle the sorting.
I am doing this already outside of the component with a dropdown, but I think filtering from the headings feels more conventional.

+1
Isn't there an event fired when a header is clicked ?
The class already changes when hovered, we just need the sortOrder icon
and then we could use an event to trigger a sort in a computed function


Added hierarchy for derive spec, changed trait with new function is_child to test for unsized stream end

Added hierarchy for derive spec
Changed trait with new function is_child to test for unsized stream end.

This is an intermediate PR, proper async stream supporting unknown sizes coming soon.
This is made to contribute to the webm-iterable crate that i use.
A few tests are missing, notably around is_child.

if you do not wish the changes to be breaking for direct trait implementors it would be possible to change it for an additional optional trait, however it will not be possible to do a blanket implementation suppoorting unknown sizes.

I tried running this version with some existing tools that use this crate, but I started getting errors where there weren't any before.  I managed to trace it down to the fact that this branch currently emits [EndTag] variants before it ever emits the [StartTag].  This should definitely be fixed before merging this, as that would break any existing use cases that rely on an EndTag.

see latest commit, i fixed a mistake and added support for malformed hierarchies if the size is known.

also take a look at the new easy_ebml macro :), i changed the impl in the webm-itertor PR so you can see how it looks.

there are still issues with the async sizes, don't merge

Ok, now every case i could test is parsed properly, mostly based on a Mediarecorder sourced x-matroska stream on chrome.

All my contributions are pushed, on this crate and the webm-iterator one.
I will use my forks directly so no rush to integrate it.
I'm under great time pressure at work, i can't spend any more time here unless it's to fix bugs, now i'm off to the MP4 side of the rustverse. Take care, hope i helped.

Thanks so much for the contribution!  It's great to have someone else offering different opinions and use cases - I feel like that's the best way for libraries to grow.  I completely understand about the time pressure at work (I have that myself).  I will probably write some more test cases/documentation and run some performance comparisons before merging.  With this being a hobby project of mine, it may be a minute until the feature is fully added.
Again, I really appreciate your work here :)  Good luck with the rest of your project!

You' re welcome :)
I coded for clarity not speed, but in theory it should be mostly comparable except for the extra copies, to optimize my impl you can change the API to pass the owned values directly, and remove the extraneous to_vec for the string creation :)
And before i go, there is an edge case that is not handled, but it will never realistically happen: when an unknwn sized element has a known sized parent it should end at the end of the parent. Currently it does not as it doesn't explore the stack up to determine the size. However i don't see how any encoder would ever make a known sized parent of an unknown sized stream... the only use i see is if you have n children that can have 0-N children each but a known total, but that is nonsense, might as well compute that in advance.

I updated some documentation, added some tests, and also did some refactoring of the synchronous iterator so that it should be able to properly handle buffering tags of an unknown size.  I tested what I could - hopefully I didn't break anything!  I know you're running on your own branch, but if you do ever happen to pull these updates and they break any of your use cases, definitely let me know and I can take a stab at fixing anything that was introduced here.

Thanks a lot, haven't gotten around to use your changes yet, however i noticed the ebml matcher creates huge binary sizes, at least in wasm... maybe there is a way to reduce that at least ten fold... each line of spec removed is almost .5kB removed. The curlpit seems to be the generated spec code. The solution would be to change the enum to specific impls for each, as well as removing the values returning options in favor of a referenced enum kind of like the Entry helper enum of HashMap that would resolve to the value if required, and using dynamic dispatch around the code to avoid running through the match arms every time an operatiojn is done.