lib.extendMkDerivation: init; buildPython*: support function-based attribute recursion

Description of changes
This PR introduces a unified approach to implement build helpers that support function-based attribute recursion and bring such support to existing build helpers.
The function-based attribute recursion support in stdenv.mkDerivation is introduced in #119942, and there are ongoing attempts to make other build helpers support such syntax (buildRustPackage refactor #194475,  buildGoModule refactor #225051). The overlay-style overrideAttrs brought by the stdenv.mkDerivation  change can be used to implement the functionality, which is adopted by the buildRustPackage refactor and previous version of buildGoModule refactor. The down side of such approach is that the whole set pattern matching the input arguments are degenerated into a single identifier, making it hard to see from the source code which attributes to the build helper accepts.
The new Nixpkgs Library function, lib.extendRecursiveBuilder accepts a base build helper and the builder implementation -- an overlay in the form finalAttrs: inputAttrsPattern: resultAttrs.
The following is the definition of an example build helper, mkLocalDerivation:
{ lib
, stdenv
}:

lib.extendRecursiveBuilder stdenv.mkDerivation (finalAttrs:

{ preferLocalBuild ? true
, allowSubstitute ? false
  # Some other input arguments
, ...
}@args:

removeAttrs [
  # attributes not to be passed into the builder
] args // {
  inherit preferLocalBuild allowSubstitute;
  # Some other build process
})

This PR also provide a variant function, lib.extendMkDerivationModified, that accept an extra parameter to modify the resulting derivation in case the attributes are not enough to include all the implementation.
Another plus to this approach is that we don't have to alter the indentation of an existing, working build helper to make it support recursive attributes. This PR enables the recursive attributes support in buildPythonPackage and buildPythonApplication with slight modification against mk-python-derivation.nix with no rebuilds.
This PR renames the following concepts to reduce ambigualty and avoid confusion:

A function that produces a derivation is now said to be a "build helper" instead of a "builder", to distinguish from the builder input attribute of derivation or the remote builders of Nix.

The use of a (finalAttrs: { })-style function instead of a plain attribute set as the input argument of another function and get the final state of an attribute from finalAttrs is now said to be "function-based attribute recursion" instead of "recursive attributes" to distinguish from the recursive set syntax (rec { }).

The path to existing documentation files are kept unchanged to avoid breaking other open PRs or staging changes.

Cc:
Python maintainers: @FRidh @mweinelt @jonringer
Author of the buildRustPackage refactor PR @amesgen
Reviewer of the buildGoModule refactor PR @zowoq
Author of the merged recursive stdenv.mkDerivation PR @roberth
People who mention 119942 in Python application definition: @LunNova
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[X] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

I should have checked more carefully.
There's a function called makeOverride that deprives the input builder of their recursive attributes support, and buildPythonPackage and buildPackageApplication happens to make use of such function.

Update:
Fix lib.makeOverridable and makeOverridablePythonPackage.
Turn a Python application pyspread into the recursive attributes style.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/proposal-move-values-from-derivation-attributes-to-function-arguments/20697/21

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/avoid-rec-expresions-in-nixpkgs/8293/18

Recently the Packages Modules Working Group started investigating whether something like the module system could be used to evaluate packages. We're tracking all work in this repository, meeting weekly, but working mostly asynchronously. It would be great if you could join the Matrix room of the WG and chat with us

I'm concerned about the increasing complexity, while the goal can be achieved through simplification instead: removing the python-specific level of overriding and turning it into an "overlay" on the mkDerivation arguments instead.

The idea to shift workflow-specific overlays sounds neat, and that could also be friendlier when packaging multi-language projects. Nevertheless, there are some issue on the way to the switch:

Current builders rely more or less on arguments they won't pass into mkDerivation attribute set.
Developers would need to change the way they handle the arguments / attributes, either by passing them directly or through passthru. The impl input argument of the proposed function is essentially an overlay that allows passing not-to-pass-to-mkDerivation arguments through the previous set.

Current attempt to try to implement a builder that supports the (finalAttrs: { }) through an overlay passing to .overrideAttrs, such as #194475, discards the set pattern of input arguments ({ a, b ? "some default", ... }@args) completely and degenerate it into previousAttrs.
It is a pity, since the set patterns itself serves as an interface of the builder, providing information about the expected input arguments to both and the Nix interpreter and people reading the Nix expression.
The solution would be rather simple -- replace the previousAttrs with the set pattern, and then the remaining issue will be point 1.

Overall, the goal of the proposed function is to add (finalAttrs: { }) input support with minimum changes to the existing expressions, and raise the discussion about general approaches to bring such supports to builders.

Just reviewing your change to input-remapper, I like how much this cleaned up its definition. :)

Rename the function to extendMkDerivation and extendMkDerivationModified, and name the finalAttrs builder feature "function-based attribute recursion".
Wonder if we should also change the corresponding sub-section title # Recursive attribute in mkDerivation in the Standard Environment chapter of the Nixpkgs Manual? Should we change the name of the anchor, too?

BTW, it turns out that I forgot to take care of overrideAttrs after applying the modifier, which is the probable cause of extendDerivation failing to disable Python modules for unsupported Python interpreters. Now the issue is fixed.

Rename the following concepts to reduce ambigualty and avoid confusion:

A function that produces a derivation is now said to be a "build helper" instead of a "builder", to distinguish from the builder input attribute of derivation or the remote builders of Nix.

The use of a (finalAttrs: { })-style function instead of a plain attribute set as the input argument of another function and get the final state of an attribute from finalAttrs is now said to be "function-based attribute recursion" instead of "recursive attributes" to distinguish from the recursive set syntax (rec { }).

Keep the path to existing documentation files unchanged to avoid breaking other open PRs or staging changes.

The packages doesn't evaluate after rebasing onto recent revision of the master branch, complaining that passthru.pythonDisabled is missing.
I suspect that someone uses overrideAttrs against python packages but accidentally discard passthru attributes from previousAttrs.

Not 100% sure I follow, but iirc we've made it possible to override overrideAttrs via passthru, if you really really have to. I hope that's not what you need. It probably isn't what you need, and you probably shouldn't use it because it's more surprising, but now you know.

The effects of toPythonModule survive through overrideAttrs as it is implemented through overrideAttrs, and is applied prior to the "disabled logic".

This is a puzzling sentence. Maybe it's because I don't really have the patience today, but it wouldn't need to be said if overridePythonAttrs were just overrideAttrs, so I do still think that overridePythonAttrs should be removed at some point, just so that everyone's head doesn't explode when they have to deal with python overriding.

Overriding up to mkDerivation is tested in pkgs/test/overriding.nix. This function is not language specific, so it could be tested there too.

Thank you @roberth for telling me where to write the tests!
It came to me that that .override after .overridePythonAttrs is already broken before this PR. @FRidh Is this a known issue?
Here's the tests I added:
https://github.com/NixOS/nixpkgs/compare/master...ShamrockLee:nixpkgs:test-overriding-python?expand=1

It came to me that that .override after .overridePythonAttrs is already broken before this PR. @FRidh Is this a known issue?

Ah, I know why. The override attribute is added by makeOverrideae called by callPackage, which is applied after the builder (stdenv.mkDerivation or language-specific builders). .overrideAttrs works fine after .override just because makeOverrideable takes special care of ovelrideAttrs.
We don't expect makeOverrideable to take care of these builder-specific overriding attributes. It would be great  to gradually deprecate these builder-specific overriding attributes, and pass special arguments through passthru instead.

Progress:

Split the documentation part into a new PR #262648 for further discussion.
Add lib.applyToOverridable as a general approach to modify an "overridable" (attribute sets that comes with attribute that enables overriding, including derivations produced by stdenv.mkDerivation). Cover it with unit tests in pkgs/test/overriding.nix.
Define lib.extendMkDerivationModified with lib.extendMkDerivation and lib.applyToOverridable.

Does this PR need a release note entry?

Rebase and update the documentation as #262301 have been merged.

nixpkgs-review reports that this PR removes the package python310Packages.camelot, but that packages evaluates and builds successfully on my laptop.
What's wrong?

@ofborg build python310Packages.camelot

I accidentally rebased and pushed 4 previous commits.
The problem is now fixed, sorry for the noise.

Rebase to resolve merge conflict with the master branch.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-10-30-documentation-team-meeting-notes-90/34936/1

this PR still seems to big, it adds 4 new functions to lib.customisation, each of which supposedly with its own use case. I'd like to see this split into the smallest possible change that makes sense on its own.

I could drop the currently-unused lib.applyToOverridableWithCustomName to ease the burden.
lib.applyToOverridable was originally inlined inside the lib.extendMkDerivationModified implementation. I abstracted out the logic and make it a separated function to increase the granularity of test cases. Now lib.extendMkDerivationModified is simply a composition of lib.extendMkDerivation and lib.applyToOverridable, i.e.
extendMkDerivationModified = modify: mkDerivationBase: impl: rattr:
  lib.applyToOverridable modify (lib.extendMkDerivation mkDerivationBase impl rattr);

The main factor that makes this PR so big is that it

Introduces lib.extendMkDerivation and lib.extendMkDerivationModified, which involves

Defining lib.applyToOverridable
Defining lib.extendMkDerivation
Defining lib.extendMkDerivationModified as their composition.

Make buildPython* supports fixed-points argumnets, which involves

Making lib.makeOverridable supports fixed-point arguments.
Making makeOverridablePythonAttrs in python-packages-base.nix supports fixed-point arguments.
Modifying mk-python-derivation.nix with lib.extendMkDerivationModified
Converting two python packages pyspread and input-remapper to fixed-point argument style to demonstrate and and test the new feature.

Split the Python part into #267296 and #271387. Now this one only focus on lib.extendMkDerivation[Modified], and is much shorter that it was.

@ofborg build tests.overriding

I shortly changed mkDerivationBase to a function getMkDerivationBase yesterday to try to cope with buildPython* taking stdenv as part of its input arguments to customize its stdenv.mkDerivation. but revert back to mkDerivationBase afterward because the definition of getMkDerivationBase would be ugly and the specification would not be overridable, contradicting the goal of lib.extendMkDerivation.
The stdenv specification should be done like (buildPythonPackage.override { inherit stdenv; }} { ... }, the way other build helpers would do.
The .override attribute of buildPython* gets lost because of problems inside python-package-base.nix, which is probably why stdenv is passed in such a strange way. #271762 brings back buildPython*.override and enable the (buildPythonPackage.override { inherit stdenv; }} { ... } way of custom stdenv specification.

Rebas onto the master branch and update the documentation.

@fricklerhandwerk Could you help me take a look at the documentation?

Resolve merge conflict for the release note and refine the examples in Nixpkgs Manual.

Sorry for the leftovers inside the function comment blocks. It was a side effect of coding on a mobile phone.

Should we define build helpers under pkgs/by-name (e. g. pkgs/by-name/fe/fetchFromGitHub/package.nix)?

Bump to resolve release-manual merge conflicts.
Could someone help take a look at the documentation part? It becomes the blocker of this PR for a while.

hmmm, i see this only supports finalAttrs: and not prevAttrs:
is there any sane ways to get that working?

It's different from lib.extend, as finalAttrs: args: { ... } determines the arguments to be passed to mkDerivationBase, and that args won't be passed into mkDerivationBase without going through finalAttrs: args: { ... }

Ah! I understand now

Just updated and renamed the finalAttrs: args: { } input function from "build helper implementation" (impl) to "argument set adapter" (adaptAlgs) to avoid confusion.

Inspired by #293498, we should encourage new build helpers to pass all the arguments into the base build helper whenever possible, to avoid the need of new custom overriders. We don't want even more override*Attrs.
Should we encourage implementing new build helper with fpArgs: (stdenv.mkDerivation fpArgs).overrideAttrs , and fall back to  lib.extendMkDerivation when converting existing.build helpers with arguments not passable to the base build helper? Or should we define lib.extendMkDerivation this way and rename current implementation to lib.adaptMkDerivation?

I found that introducing two separate function makes documentation easier. I don't have to explain why extendMkDerivation is not extending the arguments the way lib.extend does -- now it is.
lib.extendMkDerivation is now a wrapper around <pkg>.overrideAttrs, which passes all the input arguments plus custom updates to the base build helper, while the previous implementation is renamed lib.adaptMkDerivation. The latter is described as a workaround to the unable-to-pass arguments of existing build helper definitions.

I'm concerned about the increasing complexity, while the goal can be achieved through simplification instead: removing the python-specific level of overriding and turning it into an "overlay" on the mkDerivation arguments instead.
The alternative strategy is to

Provide this python layer, which contains the relevant mkPyton* logic in a way that works with overlay-style overriding. This can be done by reading the existing code, attribute for attribute, and adding the logic to the python layer.

Change the python packages to use that layer in combination with mkDerivation, instead of the current mkPython* functions.

Perhaps make the mkPython functions reuse the overlay so that they don't literally reimplement the same logic. I don't know if this would be worthwhile.

Eventually deprecate the mkPython* functions.

I have played around with step 1 of the alternative strategy. It is feasible, but it requires a bit of migration for each package. I'm not a nixpkgs-python maintainer, so I don't feel like I should be the one to make the decision whether to accept the complexity of this PR, or refactor to actually simplify the python logic by fitting it into a mkDerivation layer.

The proposed lib.extendMkDerivation now exposes the attribute overlay used to implement the build helper as <build helper>.attrOverlay.
Current buildPython implementation contains quite a few arguments that is not/cannot pass down to stdenv.mkDerivation, which is why we need overridePythonAttrs.
The migration will start by wrapping the implementation inside mk-python-derivation.nix with lib.adaptMkDerivation, which should cause no rebuilds.
After that, we could start passing down some of those arguments, and pass others through passthru. Other attribute specification can access those arguments passed under passthru as finalAttrs.passthru.<arg>. overridePythonAttrs should also be deprecated afterward. All the attribute overriding should go through overrideAttrs.
After the grace period of deprecation, we can use lib.extendMkDerivation instead of lib.adaptMkDerivation. This way, we'll have buildPythonPackage.attrsOverlay aside from buildPythonPackage.

BTW, attribute overlays taken by .overrideAttrs sounds like a structural alternative to setup hooks.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/mix-workflows-by-extracting-build-commands-from-each-stages/48376/1

I rebased this pr and moved the release note to rl-2411.section.md to resolve the merge conflict.

Would it be desirable to add an extra attribute set to configure the behavior of lib.extendMkDerivation and lib.adaptMkDerivation? This way, we could have lib.adaptMkDerivation { modify = ...; } instead of an additional lib.adaptMkDerivationModified.
lib.adaptMkDerivation { modify = ...; } stdenv.mkDerivation (finalAttrs:

{ preferLocalBuild ? true
, allowSubstitute ? false
, impassableArg ? (x: false)
, ...
}@args:

{
  inherit preferLocalBuild allowSubstitute;
  # Some other build process
} // removeAttrs args [ "impassableArg" ])

extendMkDerivation and adaptMkDerivation now take an extra argument set to configure their behaviors. One can leave them empty (adaptMkDerivation { } stdenv.mkDerivation (finalAttrs: args: { ... })) for the default behavior. This change allows customization like adaptMkDerivation { modify = drv: ...; } stdenv.mkDerivation (finalAttrs: args: { ... }) without adding another variant like adaptMkDerivationModified.
I also adopted the relevant format for writing comment block documentation for lib.extendMkDerivation and lib.adaptMkDerivation and formatted all the examples inside fixed-point-arguments.chapter.md with nixfmt.

I rebased the branch to resolve merge conflicts, restructured the test.overriding test cases according to (#330434), and improved the documentation.

Should probably target this for 25.05 (there a merge conflict anyways)

I'll rebase it before weekend.

I am trying to figure out how to use the redirects system when adding documentation identifiers after #353513. Please take a look at #362850 for the problems I encountered.

Please reopen this PR. Was this a misclick, @AndersonTorres?

Yes, it was. I was trying to remove myself from notifications.

When working on #359641, I realized the necessity of removeAttrs when implementing compatibility layers. Even stdenv.mkDerivation removes some arguments before passing the rest down to builtins.derivation. Forcing all the arguments to pass down to stdenv.mkDerivation is not always feasible, and we should provide a unified interface for situations with/without removed arguments.
Besides, switching to the simple overrideAttrs-based implementation not only requires the current build helper implementation to pass all the arguments down to the base build helper (mkDerivationBase); it also requires mkDerivationBase and all the underlying build helpers to pass arguments all the way down to stdenv.mkDerivation without removal. Even though this is not of concern, as mkDerivationBase is usually stdenv.mkDerivation, the overrideAttrs-based implementation seems less reliable.
As @jian-lin points out in https://github.com/NixOS/nixpkgs/pull/234651#discussion_r1693925073, the overriding order is reversed between the two implementations:

For conventional build helper definitions and the current adaptMkDerivation, it goes like this:
package definition arguments -> new build helper -> base build helper -> ... -> stdenv.mkDerivation -> builtins.derivation.
For overrideAttrs-based implementation and the current extendMkDerivation, it goes like this:
package definition arguments -> stdenv.mkDerivation -> ... -> base build helper -> new build helper -> builtins.derivation.

Maybe we should implement a helper function with an interface similar to extendMkDerivation but an implementation behaving like adaptMkDerivaiton. The implementation would look like
{
  extendMkDerivation =
    let
      extendWithRemoval =
        names: g: f: final:
        let
          originalAttrs = f final;
        in
        (removeAttrs originalAttrs names) // g final originalAttrs;
    in
    {
      removedAttrNames ? [ ],
      ...
    }:
    mkDerivationBase: update: fpArgs:
    mkDerivationBase (extendWithRemoval removedAttrNames update (lib.toFunction fpArgs));

and the definition of a new build helper mkLocalDerivation would look like:
{
  lib,
  stdenv,
}:
lib.extendMkDerivation
  {
    removeAttrNames = [ "specialArg" ];
  }
  stdenv.mkDerivation
  (
    fpArgs:
    {
      preferLocalBuild ? true,
      allowSubstitutes ? false,
      specialArg ? (_: false),
    }@args:
    {
      inherit
        preferLocalBuild
        allowSubstitutes
        ;
      passthru = args.passthru or { } // {
        inherit specialArg;
      };
    }
  )


fix: order of the show on map on mobile

Description
Move Show on map button on top of the filters list in mobile

Issues
Closes
DEV-XXX:
Related
Testing
Automated tests
Manual testing
Screenshots
Additional notes

Sports-Helsinki branch is deployed to platta: https://liikunta-pr584.dev.hel.ninja :rocket::rocket::rocket:

TestCafe result is success for https://liikunta-pr584.dev.hel.ninja :laughing::tada::tada::tada:


Add libnss3 to Debian Package

Fix #287

test me

Build Passed :ok_hand:
You can safely merge 'fix-devian-package' into 'revision'.


Check that forked PRs status checks work

Closing as this PR was always meant to be closed rather than merged.  It was only created to verify that status checks on forked PRs now work properly, since 698e123.


Allow gulp.watch to continue running.

@resistdesign,
This PR has essentially swallowed up errors, meaning that 'error' events no longer get emitted on the stream which is a problem (see #24).
I have opened #29 which takes a different approach to what you did in this PR. I suggest reading through this stackoverflow question which outlines a better way to prevent gulp task errors from tearing down gulp watches.
I will keep #29 open for a little bit so that you and @nikhilmodak have a chance to comment and review the changes.

Thanks Andy, the fix looks good

@andyperlitch Thanks man, wasn't sure how to do that the right way.


Id markranges

I am using markRanges. Need to pass along the range beyond the beginning and length an id that will come from a database and will always be the same is it possible? This will be the use of any element to identify the element.

Hi,
Thanks for submitting.
Please read the contribution guidelines and provide the required information named there.

Thanks for the great work.
I have a comment project:

select the text
browser detects the selected position (image) example: (start: 300, length: 20)
write this information to the database for later retrieval

3.1) I have in my database a table with all selected positions and through the markrange, I can find in my text all user selections.
3.2) The only issue I have is that I need a unique fixed id stored in the database for each position. (start: 300, length: 20, id: 1) (start: 500, lenght: 10, id: 2 ...)]
3.3) User will click on the balloon to see how many comments they have in this text. Here I need the id to find in the database. (Image balloon)
I got through the filter extract an id but it can not vary, because I need to write to the database and so would have a table (start, lenght and id). Each time he clicked the balloon he would use this id to locate the record.
Note: the table that contains the (start, lenght and id) will have the start variable because if the text changes I have a function that recalculates the change. position start: 500 becomes for example (start: 520, lenght: 10, id: does not change)

Within the each callback, the given range is provided. Try this (demo):
$(function() {

  $(".context").unmark().markRanges([{
    start: 36,
    length: 10,
    id: 23452345
  }, {
    start: 325,
    length: 16,
    id: 457574
  }], {
    each: function(element, range) {
      element.dataset.id = range.id;
    },
  });

});


Allow variables to manipulate theme

This is a first attempt at manipulating the base theme via variables. When a new variable is added, it is twice as hard to get rid of it, therefore I wanted some initial thoughts on the current approach in variable choices.
Some colors, sizes, ... are theme specific and not configurable. I think these possibilities should be discussed when the need arises?
Thing to note, breakpoint configuration is not included. This is hard to combine with the Bootstrap responsive utility classes. In other words: breakpoints can't be defined via native css variables, it does work via sass variables. https://stackoverflow.com/questions/40722882/css-native-variables-not-working-in-media-queries.
Small improvement (sorry for enlarging the PR this way), the font families included now include more variating regarding weight and italic possibilities. Looks immediately better IMHO (but could be finetunen in a later PR).

Internet Explorer has not been checked. I do agree with @choldgraf remark in  https://github.com/pandas-dev/pydata-sphinx-theme/issues/138 and don't think the target audience relies heavily on IE support.

Cool!
Will take a closer look later, but some very quick things I noticed:

For some reason, the body and sidebars got narrower again (compare https://349-130237506-gh.circle-artifacts.com/0/html/demo/example_pandas.html with https://pydata-sphinx-theme.readthedocs.io/en/latest/demo/example_pandas.html)
The light color for the "note admonition" doesn't seem to be working (although it works for others)

And fine to lave out breakpoint configuration for this PR, there is already enough other content to focus on ;) (we could always add later a sphinx config variable for this, if it turns out difficult with css variables)

Thanks for noticing @jorisvandenbossche. I replaced bootstraps $container-max-widths instead of complementing it with $grid-breakpoints.

nice! so how would a user go about updating one of these variables for their builds? Just define them in a custom.css file?
And is it possible to do this in a downstream theme (like sphinx-book-theme) that builds its CSS separately from pydata sphinx theme? If not, is there a technical path to make that possible? I'm happy to try building in something extra to the SBT if it's possible.

nice! so how would a user go about updating one of these variables for their builds? Just define them in a custom.css file?

Indeed. I was just testing this with contextily, and I can redefine the primary color variable instead of explicitly styling the h1 and h2 color: https://github.com/jorisvandenbossche/contextily/commit/85c8f87edaf35fe487d670f0b35f130de9a0b89e
For the other aspects I am overriding there (eg the highlight color in the navigation sidebar), it seems we are still missing some variables

And is it possible to do this in a downstream theme (like sphinx-book-theme) that builds its CSS separately from pydata sphinx theme?

Do you mean that you are builing CSS from SASS as well, so you need to override the variables in SASS instead of CSS ?
I suppose as long as you use those variables in SASS, you can redefine the colors in CSS, in the same way as this PR is doing

Another example of a doc site with some colors customized: http://docs.momepy.org/en/latest/index.html (and their custom css: https://github.com/martinfleis/momepy/blob/master/docs/_static/custom.css)

@jorisvandenbossche I'm a little bit confused now haha, in your CSS link you just showed "regular" CSS overrides, no SCSS variables etc, no? Then I'm not sure why this isn't already possible - couldn't someone already over-ride the CSS manually anyway?
@hoetmaaiers can you please document how to use this feature so that others can try it out? I find that writing docs first is a great way to reverse-engineer the functionality you want and it helps people test out the PR as well :-)

I'm a little bit confused now haha, in your CSS link you just showed "regular" CSS overrides, no SCSS variables etc, no?

Yes, I am doing it in CSS (in the end, that's what most end users want, they shouldn't need SCSS), but it's not a "regular" override. Note that in the commit I linked I removed a "regular" override and changed that with overriding a variable.
In this specific case it is not avoiding a lot of lines of code, but for something like the highlight color in the navigation, this will help a lot as now I need to override that in many places (and I need to overide the css just for that, and need to know which exact css I need to override, see eg https://github.com/jorisvandenbossche/contextily/blob/85c8f87edaf35fe487d670f0b35f130de9a0b89e/docs/_static/css/custom.css#L29-L37 all those lines should be a single variable override)

oh interesting - I'm not familiar with this pattern of:
:root {
  --color-primary: #333;
}

and --var...I've always used $myvariable: myval;
so maybe I am not doing things properly (in which case I re-iterate my request above that we document how to do this haha)

I'm not familiar with this pattern of --var...I've always used $myvariable: myval;

That's the difference between CSS variables and SCSS variables.
SCSS variables are compiled away by sass, the CSS variables are kept in the output (you can use CSS variables in the SCSS files as well, and then those are kept in the output CSS, so that you can still override this as a user of the theme. SCSS variables can't be overriden by downstream users, unless they would start from our scss instead of css).
For sure we need to document this, but so what I posted above was a first try to see if it actually works what we would want to document ;)
But basically it is:

Include a custom.css (or other name) in your _static sphinx doc directory, and add ensure this is added in conf.py, eg with
html_static_path = ['_static']

html_css_files = [
    'css/custom.css',
]

(or with app.add_css_file(..), not sure what is actually best)

Inside this custom.css, include a :root section like
:root {
  --color-primary: #333;
}

where you can override any variable that is listed in https://github.com/pandas-dev/pydata-sphinx-theme/blob/aa925282eb23426aff6014389511bbf3d659dd86/pydata_sphinx_theme/static/css/theme.css

Now, the above is for the typical user that will use css to override elements.
For sphinx-book-theme, it's a bit different of course, since you are also using sass.

TIL there are CSS variables and they are different from SCSS variables :-)
let me try it and see if it works. So it must be under :root { yeah?

Great explanation on the difference between css and sass variables, thank you 👏@jorisvandenbossche.
The goal was indeed to allow a user of the theme to only configure the theme without installing and building all sass, js, webpack related items.
With this first PR I was looking for some opinions about the way of working, those I received, thank you 😉. I'll process the feedback and get back with some updates.

I am thinking more about adding extra variables or limiting them to a fixed and more semantic set of variables. To me the difference is about either configuring or theming:

Configuring: every element having a color, font or other configurable value can be configured via css variables.
Theming: a more concise set of colours is defined with values like primary, secondary, tertiary. With these colours the theme is built up. E.g. https://developer.microsoft.com/en-us/fluentui#/controls/web/themes

Theming equals the theme making clear decisions about what type of color is used in what place. Configuration hands over all choices to the end implementation.
Personally I lean towards theming, since the configuration idea can also be achieved by applying a custom.css stylesheet on top of the default css.
What are you thoughts about this?

I think I agree with your intuition, to me it maps on to different user personas as well:
Most people are not CSS experts and don't want to bother with tweaking lots of things, for them, some degree of control is helpful but not total control because it's overwhelming. Theming is a good way to control this level of control.
More advanced or opinionated users will be both more knowledgeable and more motivated to do the manual tweaking themselves, and for this group it should be possible if not necessarily super easy to control each of the things they want (e.g. by writing their own custom.css file.

It doesn't have to be one or the other.
Both ways could be used together in the most customised version of the theme I think 😉.
Good documentation will be key for this. I wait for other opinions ons this matter and will then reconsider the variables list. Your suggestion @choldgraf for starting documentation first is a good idea.

I think we can go for some middle ground here? I suppose we could define some general theme colors (and actually using the bootstrap variables for this might also be possible? like the primary and secondary color variables). And then a few more detailed variables can be defined in terms of those theme variables?
With such a setting, that should somewhat enable both use cases?
Now, for the concrete implementation in this PR, I would start to define those variables that seem needed in practice (based on the few examples we have that are already customizing this theme, so we can see to cover their needs). And then based on that, we can maybe have a more concrete discussion on configuring vs theming?

I see this effort has slowed some, but: yes! Please expose as much configurability as possible in a way that a non-nodejs user can theme to their heart's content with documented web standards in a single file vs having to rebuild the assets with nodejs and whatever SCSS happens to support.
Things this approach can offer out-of-the-box without having to re-load (much less rebuild):

vision impaired, large text/high contrast mode
disabling custom fonts
night mode

Thanks for the feedback @bollwyvl !
That would indeed be good to enable such features like the one you mention (that let's me think of the nigh mode of the docker docs: https://docs.docker.com/develop/dev-best-practices/, the switch is in the right sidebar)

Yeah, CSS-only can go pretty far:
https://codepen.io/demilad/pen/bZRjpb
The genius hack is having a hidden input with a visible label for='that-input', then using the + sibling selector. Gross, but works all over. But to be siblings, the selector would presently need to list all possible top-level elements, e.g. .toggle-night-mode:checked + #navbar-main, .toggle-night-mode:checked + footer. A superdiv, e.g. #main would make that a tad easier.
However, there's no HTML5/CSS way I know of to persist this, so it would be reset on the next page viewed: for that, it would take a wee bit o' javascript to cram some stuff into localStorage/cookie... turns out, that's precisely what docker is doing. They aren't using variables, however, and certain things (like embedded widgets) are already mounting to :root, but it should all play nicely together.

OK, I finally managed to update this PR with feedback applied.
This PR aims to introduce the theming option via variables. How to do this is documented in the README section.
The main idea (TLDR) is:

Theming via variables by changing pydata_sphinx_theme/static/css/theme.css variables.
Apply custom css on top of all other css in pydata_sphinx_theme/static/css/custom.css.

Features like  large text/high contrast mode or night mode are more than just theming but  individual features as such. Shall we create tickets for both? @bollwyvl

As a thing variable change, the primary color now is bright blue. This should be changed before merging.

+1 to high-contrast mode and dark mode being new issues

(since I merged https://github.com/pandas-dev/pydata-sphinx-theme/pull/169, this will need a merge of master now)

The ../static.css/index..css file seems no longer minified?

Looks minified on master...

Also the js file has a lot more files.

Haven't looked at the actual delta... it's possible there's an extra jquery in there or something. But yeah, bootstrap is pretty darned big if you load all the bells and whistles.

I thought I had posted this earlier, but: tooling (e.g. the browser developer tools, code editors, linters) will give a customizer helpful pickers and feedback when variables are defined in a predictable, standards-compliant format.... it doesn't seem much more cognitive load to have multiple variables, e.g. --color-admonition-header-background --color-admonition-body-background if they appear right next to each other in the source.
Another approach is picking an existing color system, which puts it in a named space, rather than a code space. For example, in jupyterlab's variables almost everything is defined in terms of material design, which has already been finessed at a color theory level which can be difficult to pick out of #abc123, even for the trained eye.

:point_up: whaaaa? i didn't know GH could do that.  Case in point!

I thought I had posted this earlier, but: tooling (e.g. the browser developer tools, code editors, linters) will give a customizer helpful pickers and feedback when variables are defined in a predictable, standards-compliant format....

@bollwyvl can you clarify a bit what you mean with a "predictable, standards-compliant format"? You mean the way variables are named (like "color--" or something like that)? And are there standards on this?

it doesn't seem much more cognitive load to have multiple variables, e.g. --color-admonition-header-background --color-admonition-body-background if they appear right next to each other in the source.

Yeah, we can certainly further expand the variables we defined now. But let's see this PR as a good first step setting up the infrastructure and defining a minimum set of variables to do basic theming (needed for some downstream users). I would focus on finishing the PR first with what there is now more or less, and we can certainly further add and tweak the variables we have after that (so feedback on the variables you would like to see is of course very valuable).

I am planning to merge this: I think it is more than good enough for a start, and can then refine in follow-up PRs where needed (when actually using it in downstream docs)

OK, let's see how this goes. Feedback on what is exactly exposed as variables is still very welcome! Example PR of how this simplifies customizing the navigation colors: https://github.com/geopandas/geopandas/pull/1666
Thanks @hoetmaaiers for getting this started!

wow, very exciting to see this one merged in!

Great to see this one make it into the master branch. Will be made good use of future features!


Pull repository from git, not release tarball

The tarball created by Github for the tracktable-data release contains pointers to the files in Git LFS rather than the files themselves.
By asking conda-build to check out a new copy of the repository, we should get the full-fat files as we expect.

Checklist

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

@conda-forge-admin, please rerender


The Mods Stellar Sky and Stellar API Cause a Terra 1-to-t World to Not Generate

I have no idea why, I have been fiddling around in the configs of Stellar Sky and Stellar API for ages and haven't found a fix.

Most Space mods are incompatible with Cubic


Assertionerror 31DA with faked remote

2022-12-06 21:03:19.834 WARNING (MainThread) [ramses_rf.dispatcher] RP --- 32:155617 37:155617 --:------ 31DA 030 00EF007FFF363103AC05DC06CE02C9F80000182A2A0000EFEF091D091D00 < AssertionError(msg from 32:155617 (FAN) inappropriately routed to 37:155617 (REM))

The issue here is an anachronism (battery-operated remotes sending RQs) - the solution will require some refactoring.

I also seem to get it with 2411 commands:
2022-12-11 21:05:03.319 WARNING (MainThread) [ramses_rf.dispatcher]  I --- 32:153258 37:153258 --:------ 2411 023 00003F390F0000003800000000000000A000000001A632 < AssertionError(msg from 32:153258 (FAN) inappropriately routed to 37:153258 (REM))
This is what I have sent and got back:
2022-12-11T21:05:03.279121 000  W --- 37:153258 32:153258 --:------ 2411 023 00003F000F0000003800000000000000A0000000010032
2022-12-11T21:05:03.314753 080  I --- 32:153258 37:153258 --:------ 2411 023 00003F390F0000003800000000000000A000000001A632

Any change here? I was hoping to periodically send a RQ 31DA command to get some better resolution on sensor values, instead of the 5 minute default interval.

I have made the refactoring at the client layer (ramses_rf). I have just pushed the corresponding ramses_cc and am waiting for it to settle.
Can you pm me the ramses_cc: section of your configuration.yaml, and a 24h packet log?

Hmmm... This is currently working for me.
    32:205847:
      class: REM
      faked: true
      commands:
        refresh:     'RQ --- 32:205847 30:071287 --:------ 31DA 001 00'

I miss-read - I'll need to set up a emulated system...

Actually, try this:
refresh:     'RQ --- 18:000730 32:134044 --:------ 31DA 001 00'

Obviously, use

That's basically what I was using:
ramses_cc:
  serial_port: /dev/ttyUSB0

  ramses_rf:
    enforce_known_list: true

  orphans_hvac: [32:134044, 29:150155]

  known_list:
    32:134044 : { class: FAN, _note: Orcon HRC-350 }
    29:150155:
      class: REM
      faked: True
      _note: Orcon 15RF
      commands:
        request31DA:  'RQ --- 29:150155 32:134044 --:------ 31DA 001 00'
        ...

With different IDs of course.

I think you really need to try with the 18:000730 address. It's a sentinel value for the gateway
You should also be using 0.30.2: if it doesn't work out for you it's very straightforward to switch back to your current version.
The only issue is that the entity ID of four FAN attributes have changed (unique ID has not changed).

I see. How does that work with enforce_known_list: true?
Disabling that for now, with 'RQ --- 18:000730 32:134044 --:------ 31DA 001 00' I get the following packet log:
2023-11-15T21:55:07.663238 000 RQ --- 18:066589 32:134044 --:------ 31DA 001 00
2023-11-15T21:55:07.707242 077 RP --- 32:134044 18:066589 --:------ 31DA 029 00EF007FFF3F30041A06C206DD055BF800000248480000EFEF0F810F9D

and the following in HA's log:
homeassistant_1  | 2023-11-15 21:55:07.707 INFO (MainThread) [ramses_rf.dispatcher] || FAN:134044 | HGI:066589 | RP | hvac_state       |      || {'exhaust_fan_speed': 0.36, 'fan_info': 'speed 2', 'remaining_time': 0.0, 'air_quality': None, 'air_quality_base': 0, 'co2_level': None, 'indoor_humidity': 0.63, 'outdoor_humidity': 0.48, 'exhaust_temperature': 10.5, 'supply_temperature': 17.3, 'indoor_temperature': 17.57, 'outdoor_temperature': 13.71, 'speed_cap': 63488, 'bypass_position': 0.0, 'supply_fan_speed': 0.36, 'post_heat': None, 'pre_heat': None, 'supply_flow': 39.69, 'exhaust_flow': 39.97}

So the request now isn't logged anymore, only the reply. However, I still don't get updated sensor values. For example, monitoring sensor.32_134044_indoor_humidity in lovelace only shows an update every 5 minutes, regardless of the 31DA requests I sent. Maybe I'm missing something; I would assume that additional 31DA messages should lead to additional sensor updates?

I see. How does that work with enforce_known_list: true?

It is a sentinel value - it gets changed to 18:066589 by your dongle (and that address should be in your known_list).

So the request now isn't logged anymore, only the reply.

It is logged in the packet.log, it is not logged otherwise, to reduce logspam.

Maybe I'm missing something; I would assume that additional 31DA messages should lead to additional sensor updates?

What is your sync_interval? Set it to:
ramses_cc:
  scan_interval: 60

You haven't aid what version you're using - I am no longer developing on anything older than 0.30.x - any bugfixes will go there.
As long as you don't get this:
msg from 32:134044 (FAN) inappropriately routed to 29:150155 (REM)

... you should be fine.

I am closing this for now - please re-open it if you need to, but only if you're running 0.30.x.
If you could PM me a packet log to test/dev against, that will be helpful to the HVAC users.


Show images persisted in a database or in a non-public folder from the uuf app.

'src' attribute of the  element need to have a valid URL
Need a way to provide a valid URL for the images persisted in a database or in a non-public folder
ex: user-portal/account/account-setting/user-123.jpg

Closing as repo is deprecated.


⚠ BeyondHD has degraded performance

In 7b73262, BeyondHD ($BHD) experienced degraded performance:

HTTP code: 200
Response time: 1653 ms

Resolved: BeyondHD performance has improved in 5fcf931 after 6 minutes.


[5.3][CodeCompletion] Fast completion inside function builder function

Cherry-pick of #32946 into release/5.3

Explanation: Fix an issue where fast-completion inside function builder function including accessor fails to work. This is because PreCheckFunctionBuilderRequest only use FunctionDecl as the cache key. Since fast-completion replaces the body of the function, the function decl alone is not sufficient for the key. Pass the body as well so that the request correctly evaluate the new body.
Scope: Code completion inside function builder function including inferred by protocol requirement
Risk: Low
Testing: Added regression test cases
Issue: rdar://problem/65692922
Reviewer: Robert Widmann (@CodaFi)

@swift-ci Please test

@swift-ci Please nominate


Figure out why Vibration.vibrate() doesn't work in some instances for iOS

The QR code scanner component has it so that a vibrate event is sent upon successfully reading a code. However, calling Vibration.vibrate() doesn't seem to work. Will have to investigate further.

We experience this also, any idea?

can you describe better @robert589, what are you actually experiencing? I would be happy to help you with this if you're still facing it!
but it's not clear to me yet the unexpected behavior here, as it's an older issue that seems to be fixed (not sure) as on reading correctly a QR code the auto vibration in iOS is working.

I'll be closing this because it seems to be already fixed for a long time ago and it doesn't sound still to be a problem at all


doc: document how to receive updates for manually-install slsa-verifier

See https://github.com/flutter/cocoon/blob/main/cloud_build/verify_provenance.sh#L18 of a team installing the slsa-verifier manully in a script. They won't receive updates because dependabot does not recognize commands. We need to document how to receive updates with:

renovate. It supports regex so a config should be do-able
dependabot and other CI systems. See if there's a way to declare slsa-verifier in go.mod to install its binary. Pointers: https://github.com/golang/vulndb/blob/master/tools_test.go and  https://github.com/golang/vulndb/blob/master/checks.bash

/cc @mihaimaruseac


Add a flag to disable the checking of debug_info in jax.core.Jaxpr

Adding a flag to disable Jaxpr debug_info checking.
In the new release of jax==0.4.29, the make_jaxpr() function is crashed in brainstate. This is because the arguments to JIT-compiled are dynamically added in brainstate, leading to the length of debug_info.arg_names (which are given by the functional inputs) is not equal to len(invars).
Therefore, I added a flag to disable the debug_info checking when customizing the make_jaxpr() function. This will provide flexibility for the development of downstream packages. Thanks!

Can you share a reproducer we can run, please?

Here is an example code to reproduce the error:
import numpy as np

import brainstate as bst

lif = bst.nn.LIF(1)
lif.init_state()

def run(i):
  with bst.environ.context(i=i, t=bst.environ.get_dt()):
    lif.update(20.)
  return lif.V.value

indices = np.arange(10000)
vs = bst.transform.for_loop(run, indices)

Thanks.

make_jaxpr was indeed changed in 0.4.29 but I don't expect to see any mismatches. The behavior of make_jaxpr should be identical. Hence my request for a JAX only reproducer. That might help narrow down if it's a jax bug or a bug in your library.

I am going to close this PR. Please open an issue with a minimal repro :)


edit hello world fixes #1

Do not modify or remove the line above.
Everything below it will be ignored.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: awaddell
If they are not already assigned, you can assign the PR to them by writing /assign @awaddell in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm

/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: awaddell
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [awaddell]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

:star: PR built and available in a preview environment cloudsmartio-jx-node-pr-2 here


tensorflow-0.11updated -> tensorflow-0.11

the updated branches do not seem to exist anymore

@garymm, Thank you for this!


no icon in the svc catalog chart

Hi, would it be possible to add an icon in the svc catalog chart

This issue came up during the F2F last week.
We need to have a logo at all, first. Then we can use it.

/remove-lifecycle rotten
/lifecycle frozen

This project is being archived, closing open issues and PRs.
Please see this PR for more information: https://github.com/kubernetes/community/pull/6632


use branch name for DB schemas

per changes and discussions in https://github.com/NYCPlanning/data-engineering/pull/363
approach

for all builds, use the branch to generate the DB schema name without any prefixes
when cleaning stale build schemas, delete all that aren't existing branches

tests

run of cleaning of TDB schemas after these changes
screenshot of schema created by tests in this PR:

considerations

build_ is currently used in builds that don't use PostgresClient, otherwise run_/pr_ are used
there's strong interest in running all builds on main every night and not auto-running product test builds in PRs
may just want to use branch name in all situations

My understanding is that we currently build published version products using our own branches. Wouldn't we want to have the latest version of schema in db even though the branch gets deleted? Or are we moving to builds from main?

My understanding is that we currently build published version products using our own branches. Wouldn't we want to have the latest version of schema in db even though the branch gets deleted? Or are we moving to builds from main?

true it'd be useful to always have the latest published build in the DB, but we don't yet have anything that relies on or ensures that (e.g. when I look at files in an S3 folder with published versions, can I tell what branch was used to build it? maybe with the commit hash in the file metadata?)
frequently building drafts on main is helpful since, assuming the branch was merged, the build on main would be identical to the draft that was published


High memory usage for commits page

I'm just playing with the 0.3 binaries in my free time and noticed that the memory usage starts to grow very fast when navigating to the commits page of a repo. The page itself often takes up to 10 seconds to load when having a larger repo, but the biggest problem is the memory not getting collected fast enough. After a few requests with my browser I got my memory usage to nearly 2GB and after around 30 minutes the memory is still at 600MB.
Here a screenshot from the stats after looking at a commits page:

Here a screenshot from 12 minutes later:

The repos I creating this memory usage are mirrors of torvalds/linux and gogits/gogs.

I also pushed a big repository around ~450 MB. This results into high usage of memory around 1.79GB. After some it decreases to 1.1 GB and stuck there. I waited for half hour and no change in memory usage.
I tried to see the the difference of last commit using web but it took too long.
Than I deleted that repository and memory usage decreases to ~706MB.
Even after deletion of repository through web memory usage is still same and its not freeing up memory.
Also the few process like 'git diff' are running and they do not die even after repository is deleted.
This is after server is empty and do have any repository, all repo deleted.
./gogs web is eating up 330MB.
git diff shdf..............jhf3 is taking 439.8MB.
There are multiple 'git diff' processes running.

But in your version there is a possible memory leak which should be fixed latest release, I recommend you upgrade and try it out.

Should checkout latest v0.7.6.

Close for now but open for continuing discussion.

Same error with "2017 Gogs Version: <IP_ADDRESS>9"
output: https://pastebin.com/6G9AEaSN

still same problem for gogs 0.11 lasted


Better responsive gridline

Description
I think it would be really helpful to have one more layout to differentiate latptop screen of desktop ones. There should be a lg-xx or something like this, because quite every laptop screens are greather that 920px...

Added in 104da64


Complete flexbox and foundation exercises

Flexbox exercises:

Add flexbox layout for header, sidebar, content, and footer
Ensure header and footer are fixed and do not overlap with content
Adjust padding and margins to accommodate fixed elements
Implement responsive card layout with flex properties
Add flex-wrap and gap for card arrangement in content section

Foundation exercises:

Apply consistent padding and box-sizing across elements
Style cards with border, border-radius, and box-shadow
Ensure content section has appropriate padding and overflow handling

Because

This PR

Issue

Closes #XXXXX
Additional Information

Pull Request Requirements

[ ] I have thoroughly read and understand The Odin Project Contributing Guide
[ ] The title of this PR follows the location of change: brief description of change format, e.g. 01-flex-center: Update self check
[ ] The Because section summarizes the reason for this PR
[ ] The This PR section has a bullet point list describing the changes in this PR
[ ] If this PR addresses an open issue, it is linked in the Issue section
[ ] If applicable, I have ensured that the TOP solution files match the Desired Outcome image

Good job completing these exercises. Please note the repo's README which states not to open a PR with your solutions.

Hi Mao,
Sorry, I didn’t realize it was trying to merge into the original repo.
I will keep a note of it.
Best,
Sai
On Tue, Oct 1, 2024 at 5:39 PM MaoShizhong @.***> wrote:

Good job completing these exercises. Please note the repo's README which
states not to open a PR with your solutions.
—
Reply to this email directly, view it on GitHub
https://github.com/TheOdinProject/css-exercises/pull/599#issuecomment-2387323506,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE4SQPVDQGNFTDH7XJRC3WDZZM6DFAVCNFSM6AAAAABPAKSLO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBXGMZDGNJQGY
.
You are receiving this because you authored the thread.Message ID:
@.***>


SKIP_PREFLIGHT_CHECK inoperable etc

on example sdk also sh build-all is also inoperable

Could you show more information


fix qdm bug

This PR fixes #43.
closes #43

Ha yes was already fixing the tests. I like your suggestion for passing keyword args into model.train() - will update that.

@brews ready for another review - I updated the .adjust step too for consistency.


minimize: Pointer coercion from mut to const fails

For the following code,
fn main() {
    let b = &mut 42 as *mut i32;
    let _ = b as *const i32;
}

We get the following error message:
error: internal compiler error: minimize/src/rvalue.rs:220:18: rvalue failed to translate: Cast(PointerCoercion(MutToConstPointer), Move(_6), Ty { id: 3, kind: RigidTy(RawPtr(Ty { id: 2, kind: RigidTy(Int(I32)) }, Not)) })
 --> tooling/minimize/fails/temp_file.rs:7:13
  |
7 |     let _ = b as *const i32;
  |             ^

thread 'rustc' panicked at minimize/src/rvalue.rs:220:18:
Box<dyn Any>
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: aborting due to 1 previous error

MutToConstPointer will soon not be used in the MIR we translate any more: https://github.com/rust-lang/rust/pull/126308.


changed PLT Core's Q2 squad id

I missed changing the PLT Core's team id when copy pasting the new portfolio squad IDs


Add explanatory comment about fitting into a size_t.

As mentioned by @dot-asm in #4357
A comment has been added to explain the rational behind the range check (i.e. the value must fit into a size_t integer).

Thanks.


Texconv fails to read DXT compressed file

When trying to read a DXT1/3/5 compressed texture file, Texconv shows the following error:
[filename] FAILED (88982f07)
The same error message also appears when tryng to read the file with Texdiag.
Converting the file to 32bit and then trying again works fine.
The file in question is attached below.
sample.zip

That BMP is not supported by Windows Imaging Component (WIC). If you try viewing it in the Windows Photo app, it also fails there.
What created that BMP file?
Trying my BMPDUMP tool I see:
BMP c:\Users\Chuck\Desktop\sample.bmp
INFO header (40 bytes)
1024 x 1024
1 planes
16 bits
861165636 compression type
1048576 image size
0 x 0 pels per meter
0 colors used
0 colors important
-Chuck Walbourn
Senior SDE
http://blogs.msdn.com/chuckw

From: JT8D-17<EMAIL_ADDRESS>Sent: Friday, February 16, 2018 4:24:39 PM
To: Microsoft/DirectXTex
Cc: Subscribed
Subject: [Microsoft/DirectXTex] Texconv fails to read DXT compressed file (#79)
When trying to read a DXT1/3/5 compressed texture file, Texconv shows the following error:
[filename] FAILED (88982f07)
The same error message also appears when tryng to read the file with Texdiag.
Converting the file to 32bit and then trying again works fine.
The file in question is attached below.
sample.ziphttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FDirectXTex%2Ffiles%2F1733219%2Fsample.zip&data=04|01|chuckw%40microsoft.com|01c8b9b206cd4fb6769408d5759cd56f|72f988bf86f141af91ab2d7cd011db47|1|0|636544238813035333|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D|-1&sdata=6vJ10coDlnFFRSVSqZRVKjb5WIhFxIv79NenaiLmFpM%3D&reserved=0
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FDirectXTex%2Fissues%2F79&data=04|01|chuckw%40microsoft.com|01c8b9b206cd4fb6769408d5759cd56f|72f988bf86f141af91ab2d7cd011db47|1|0|636544238813035333|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D|-1&sdata=ztULHK7zTiudYvcX9R1mJGxaskcYqBdl43OEYLkreAk%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALUPku5xxDa-B__oT0W-wFG5Qm-nTbkqks5tVhxGgaJpZM4SJGYh&data=04|01|chuckw%40microsoft.com|01c8b9b206cd4fb6769408d5759cd56f|72f988bf86f141af91ab2d7cd011db47|1|0|636544238813035333|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D|-1&sdata=J57PbtHC6Qmy30KbJBbUfSD81mA1DAf4ciy6TcwXMqo%3D&reserved=0.

That BMP is not supported by Windows Imaging Component (WIC). If you try viewing it in the Windows Photo app, it also fails there.
What created that BMP file?
Trying my BMPDUMP tool I see:
BMP c:\Users\Chuck\Desktop\sample.bmp
        INFO header (40 bytes)
1024 x 1024
1 planes
16 bits
861165636 compression type
1048576 image size
0 x 0 pels per meter
0 colors used
0 colors important

The compression type is not one of:
BI_RGB (0)
BI_RLE8 (1)
BI_RLE4 (2)
BI_BITFIELDS (3)
BI_JPEG (4)
BI_PNG (5)

Thanks for the reply.
Yes, both image viewer apps delivered with Windows 10 fail to display it. This is normal.
Nconvert, however, has no problems reading the file.
I'm not the original author of the file, so I can only make an assumption which tool was used to compress it. Since it's a texture for use in Microsoft Flight Simulator/Lockheed Martin Prepar3D, there's only two possibilites. Either ACES' ImageTool, shipped with the Flight Simulator SDK or DXTBMP.
The latter is available here: http://www.mwgfx.co.uk/programs/dxtbmp.htm
The former can't be obtained without installing the rest of the MSFS/P3D SDK, so I've attached it here for convienience. (May be deleted after the next reply by you or me.)
ImageTool.zip
Either tool fails to produce a Texconv copliant file when saving with BC1/DXT1 to BC3/DXT5 compression. Only files saved in 32bit by either tool is correctly read by Texconv.
On the other hand, a BC1/2/5 compressed file produced by Texconv can not be read by ImageTool. DXTBMP has no problems either way.
When in reading a 32bit file produced by ImageTool or DXTBMP, reading the file with Texconv shows that it's read as B8G8R8X8_UNORM. Converting this file into R8B8G8A8_UNORM format (DDS filetype) again produces a file that can not be read by Imagetool. Only selecting B8G8R8A8_UNORM as output format produces a usable file. So I assume that ImageTool/DXTBMP saves files with a non-regular order of channels and that this is what throws WIC and Texconv off.
Hope this helps.

OK, I now see what's happening here. Someone in the FlightSim team got clever and decided to containerize a DXTn texture in a BMP rather than used the long-established DDS format. It's not an officially supported way to write a DXTn, but I might be able to do something about that...

I added support for loading these Extended BMP files, but I don't support writing them.
See this commit.

I would support writing to such a weird format either, to be honest.
Reading these files is all I need and I'll check that feature out in the next release.
I've also edited my previous post to remove the attachment and iron out some mistakes.
For example, I don't know why I stated that BCn compression produces files that are not Imagetool compliant. I've just checked the results from a batch texture conversion to BC2_UNORM (DXT3) DDS again and randomly picked samples opened in Imagetool just fine.
You're correct on the vertical flip requirement and yes, -vflip does the job.
Thank you for investigating and implementing this!

I made a preview release that includes the new version of texconv if you'd like to try it out here

I've just tried a conversion using both the "exotic" input compression and the new aliases for the output format and got a good output file.
Excellent work, thanks!


Update terragrunt.hcl

Ran Plan for dir: . workspace: default
Plan Error
running "terragrunt plan --terragrunt-working-dir=. -input=false -out=planfile.tfplan" in "/atlantis-data/repos/italorafaeltavares/Atlantis/38/default": exit status 1: running "terragrunt plan --terragrunt-working-dir=. -input=false -out=planfile.tfplan" in "/atlantis-data/repos/italorafaeltavares/Atlantis/38/default":
time=2024-10-26T08:52:41Z level=error msg=terragrunt.hcl:3,10-33: Error in function call; Call to function "find_in_parent_folders" failed: ParentFileNotFound: Could not find a terragrunt.hcl in any of the parent folders of terragrunt.hcl. Cause: Traversed all the way to the root.., and 1 other diagnostic(s)
time=2024-10-26T08:52:41Z level=error msg=Unable to determine underlying exit code, so Terragrunt will exit with error code 1

Ran Plan for dir: . workspace: default
Show Output
Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Installing hashicorp/null v3.2.3...
- Installed hashicorp/null v3.2.3 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # null_resource.example will be created
  + resource "null_resource" "example" {
      + id = (known after apply)
    }

  # null_resource.path will be created
  + resource "null_resource" "path" {
      + id = (known after apply)
    }

Plan: 2 to add, 0 to change, 0 to destroy.

:arrow_forward: To apply this plan, comment:atlantis apply -d .

:put_litter_in_its_place: To delete this plan and lock, click here
:repeat: To plan this project again, comment:atlantis plan -d .

Plan: 2 to add, 0 to change, 0 to destroy.

:fast_forward: To apply all unapplied plans from this Pull Request, comment:atlantis apply

:put_litter_in_its_place: To delete all plans and locks from this Pull Request, comment:atlantis unlock

atlantis apply

Ran Apply for 0 projects:

atlantis apply -d .

Ran Apply for dir: . workspace: default
Apply Error
Show Output
running "terragrunt apply --terragrunt-working-dir=. planfile.tfplan --auto-approve" in "/atlantis-data/repos/italorafaeltavares/Atlantis/38/default": exit status 1: running "terragrunt apply --terragrunt-working-dir=. planfile.tfplan --auto-approve" in "/atlantis-data/repos/italorafaeltavares/Atlantis/38/default":
╷
│ Error: Too many command line arguments
│
│ Expected at most one positional argument.
╵

For more help on using this command, run:
  terraform apply -help
time=2024-10-26T08:55:28Z level=error msg=Terraform invocation failed in /atlantis-data/repos/italorafaeltavares/Atlantis/38/default/.terragrunt-cache/EtalRCcPd9vGDhmgqfrXbYH6iY0/1xU125NCArm1swwRlXjDhW49dQI/module/null_resource prefix=[.]
time=2024-10-26T08:55:28Z level=error msg=1 error occurred:
	* [/atlantis-data/repos/italorafaeltavares/Atlantis/38/default/.terragrunt-cache/EtalRCcPd9vGDhmgqfrXbYH6iY0/1xU125NCArm1swwRlXjDhW49dQI/module/null_resource] exit status 1

atlantis plan

Ran Plan for dir: . workspace: default
Show Output
Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # null_resource.example will be created
  + resource "null_resource" "example" {
      + id = (known after apply)
    }

  # null_resource.path will be created
  + resource "null_resource" "path" {
      + id = (known after apply)
    }

Plan: 2 to add, 0 to change, 0 to destroy.

:arrow_forward: To apply this plan, comment:atlantis apply -d .

:put_litter_in_its_place: To delete this plan and lock, click here
:repeat: To plan this project again, comment:atlantis plan -d .

Plan: 2 to add, 0 to change, 0 to destroy.

:fast_forward: To apply all unapplied plans from this Pull Request, comment:atlantis apply

:put_litter_in_its_place: To delete all plans and locks from this Pull Request, comment:atlantis unlock

atlantis apply -d .

Ran Apply for dir: . workspace: default
Show Output
null_resource.example: Creating...
null_resource.path: Creating...
null_resource.example: Provisioning with 'local-exec'...
null_resource.example (local-exec): Executing: ["/bin/sh" "-c" "echo 'Hello from Terragrunt! OKAY'"]
null_resource.path: Provisioning with 'local-exec'...
null_resource.path (local-exec): Executing: ["/bin/sh" "-c" "cd /tmp && pwd"]
null_resource.example (local-exec): Hello from Terragrunt! OKAY
null_resource.example: Creation complete after 0s [id=4587070949168969097]
null_resource.path (local-exec): /tmp
null_resource.path: Creation complete after 0s [id=8530555550042488452]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Locks and plans deleted for the projects and workspaces modified in this pull request:

dir: . workspace: default


alignas support in MSVC2013

In merging #266 we broke MSVC 2013 builds because there is no support for alignas. Will have to put in a small workaround for this. I'd love to start dropping older compilers but I'll save that for a more substantial release. This along with making the new RapidJSON play nicely with MSVC warnings is currently blocking 1.2.

MSVC2013  also does not support 'noexcept'. See https://msdn.microsoft.com/en-us/library/wfa0edys(v=vs.120).aspx


Prepare v1.55.0 release

Prepares Jaeger for release 1.55.0.
Includes jaeger-ui submodule updates.
I can add more updates for the RELEASE.md if needed based on the Slack discussion. Thank you.

Includes jaeger-ui submodule updates.

it didn't, I just added.


listener: ListenerSocketFactoryImpl does not dup listen fd at in place update

Commit Message:
Fixed the bug that in place update listener holding listen fd during the drain.
The solution is to share the listen sockets without fd duplication.
Previous: The new listener create new listen socket fd which has the same inode as the old listen fd.
This PR:  The new listener copy the shared_ptr of the previous listen socket. No fd is created.
Additional Description:
Risk Level:
Testing: Modified unit test.
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
Fix #18616
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

Agree with the direction that the new share() is not appropriate.

I would recommend closing this PR, opening an issue about the above bug, and then we can look at a different and more targeted fix for it?

Make sense. I will create issue and the list the potential fixes

This PR address the minor issue of the below sequence

add listener <IP_ADDRESS>:80. Open fd = {X}
complete an in place update listener, and the old listener is draining filter chain. This draining state last drain_timeout. The new listener create listen fd=Y. Now open fd = {X,Y}.
immediately stop the listener. Open fd = {X}, Closed fd = {Y}.
after the drain_timeout, Closed fd = {X,Y}

The expectation is that after 3 but before 4, tcp client connect to :80 should see reset()
Actual tcp client connect to :80 is successful because the old listener fd = X is open. It's a minor issue because envoy doesn't serve the tcp client.

@lambdai @mattklein123 I seem to be hitting a similar issue in https://github.com/envoyproxy/envoy/issues/20113, where during the listener drain sequence, requests are not rejected by the listener being removed. Instead, the draining listener allows the client to connect to it, which hangs till the drain interval expires.


ASv2 Contract kit wrappers

Merge lint fixes first

Looks awesome!! Just a couple nits about missing sendAndWaitForReceipt's.
The helper function you were probably looking for to submit registerAttestation is here
https://github.com/celo-org/celo-monorepo/blob/1522250ff90d0ab1d8afd328d32ac15ce160b1e5/packages/protocol/lib/fed-attestations-utils.ts#L44
, which is admittedly not a great a place long term (I think the plan was to move these helpers into the SDK). I see you've already created a ticket to add a registerAttestation test which is great 🚀 You might also want to create a ticket to move the attestation signing logic into the identity sdk so we don't forget that's on the roadmap

Thank you for the feedback! I created two tickets to follow up on this PR

closes #9448


Cannot Initialize Another Dialog - RuntimeException in FinTs.php

I encountered a fatal error when running the script related to the FinTS API. The error occurs in the FinTs.php file at line 429. The exact error message is:
PHP Fatal error:  Uncaught RuntimeException: Cannot init another dialog. in /path/to/FinTs.php:429
It seems that the script is trying to initialize a new dialog while another dialog session is still active, which is causing the RuntimeException. This likely indicates that the previous session hasn't been properly closed before attempting to start a new one.
Relevant Code:
if ($this->dialogId !== null) {     throw new \RuntimeException('Cannot init another dialog.'); }
This code is checking if a dialog session is already active by inspecting $this->dialogId. If it's not null, the exception is thrown.
Possible Causes:
A previous session might still be open and wasn't closed properly before a new one was initiated.
The flow of code might be incorrect, leading to multiple dialog initializations without proper session termination.

I did not change anything in my code since a while and suddenly yesterday got this error ! is anything changed by Sparkasse?

Maybe you called persist() at a time when a dialog was still open, but also your code does something that needs a new dialog. So now whenever you load that persisted state, it has the open dialog and is expecting something like submitTan() to finish it up, but you're not delivering that.
 It fixes such corner cases where something went wrong / was interrupted previously, and it doesn't hurt in the normal case where there's no dialog to begin with.


Avoid overflowing shift by special casing inverse of 1

When x=1, then rlen = BITS+1 and newrlen = 1, and thus in the first loop iteration q = BITS, leading to a shift by BITS bits, which may overflow the integer type.
Avoid this situation by special casing x=1. The inverse of 1 is always 1 anyway.

I can't say I fully understand how we arrive here, but given the fuzzer find and sipa's dumbing down of the problem:

Avoid this situation by special casing x=1. The inverse of 1 is always 1 anyway.

Trivial ACK 653d8b2e260e8b51fe372ccf4095928dcd120c95. This does that :)

Looking again, is there any way to return x based on template params alone to potentially eliminate these runtime checks?


Expose git_merge_file function from libgit2 to repo.rs of git2-rs

@alexcrichton BTW, could you point out how I can fix the issue in CI / Test (windows)? Tried but have no idea.

Oh the windows error I think has to do with the fact that enums in C have a different signededness than other platforms. I think you can probably fix things with some casts?

I tried this, but doesn't work, any idea:
trait FileModeConvert {
    type ValueType;
    fn from(mode: Self::ValueType) -> Self;
}

impl FileModeConvert for FileMode {
    #[cfg(target_env = "msvc")]
    type ValueType = i32;

    #[cfg(not(target_env = "msvc"))]
    type ValueType = u32;

    fn from(mode: Self::ValueType) -> Self {
        match mode {
            raw::GIT_FILEMODE_UNREADABLE => FileMode::Unreadable,
            raw::GIT_FILEMODE_TREE => FileMode::Tree,
            raw::GIT_FILEMODE_BLOB => FileMode::Blob,
            raw::GIT_FILEMODE_BLOB_EXECUTABLE => FileMode::BlobExecutable,
            raw::GIT_FILEMODE_LINK => FileMode::Link,
            raw::GIT_FILEMODE_COMMIT => FileMode::Commit,
            mode => panic!("unknown file mode: {}", mode),
        }
    }
}

Can we merge this PR now? Thank you!


getInterval() weird behaviour

IOS: 15.1 on a real device
XCode: 13.1
SwiftDate: 6.3.1 - installed via CocoaPods
Trying to understand the exact behaviour of getInterval() to calculate the difference in calendar days between two DateInRegion instances.
How come
       let d1 = "2021-12-04T12:00:00+01:00".toDate()!
       let d2 = "2021-12-05T06:00:00+01:00".toDate()!
       debugPrint(d1.getInterval(toDate: d2, component: .day))

outputs 1, which is what I would expect, but
      let d1 = "2021-12-04T12:00:00+01:00".toDate()!
      let d2 = "2021-12-05T00:00:00+01:00".toDate()!
      debugPrint(d1.getInterval(toDate: d2, component: .day))

outputs 0 which is unexpected, as clearly, d2 is one day after d1 ?

it's a half day (12 h) difference based on the hours in the date @zero0cool0


Video Filter

Hello,
Has anyone ever managed to set a video filter like saturation or contrast?
Thank you.

I found out how to apply filters to an rtsp video with VLC desktop version, but I don't know which syntax to use to integrate it into react-native....
/Applications/VLC.app/Contents/MacOS/VLC --video-filter adjust --saturation 1.7 rtsp://(yourstream)
for linux:
vlc --video-filter adjust --saturation 1.7 rtsp://(yourstream)
Thanxs


Implementation of OPKG Extractor

Pull request for the OPKG package manager extractor.
Implemented:

Extractor implementation;
Unit test implementation:
Integration of the extractor in the main tool;

Can you resolve the merge conflicts in scan_result.pb.go? The proto file is no longer modified so you should be able to just revert that file


AWS with docker: Can't update to latest version.

Describe the bug
Currently running the version 1.8.3 , pulled the latest code from github then restarted the docker build. Still shows version 1.8.3.
To Reproduce
Steps to reproduce the behavior:

connect to EC2 instance.
go to Flowise folder
take latest pull using git pull
got to docker folder
stop using docker-compose stop
restart using docker-compose up -d
open gui , version still not updated

Expected behavior
Flowise shoud be on the latest version 1.8.4
Setup

Installation [Docker on AWS]
Flowise Version [1.8.3]
OS: [Linux]

The steps should be correct and working fine, any error logs from docker?

No error logs shown in docker logs

Found the issue i need to do docker-compose pull and then docker-compose up --build -d

Massive thanks @mehrajagdish I have been struggling with this.  It seems the commands in the docs no longer have the correct syntax.

Thanks! Updated the docs


Add Data table component

hi there,
first of all, thank you for your awesome work :)
Question:
Is there a data table component for trimox/angular-mdc-web like that https://material.angular.io/components/table/overview ?

Closing for now. Focusing on component refactoring and enhancements.

any hopes of bringing this back into the road map?


[BUG] Layout don't changes when switching workspace

Describe the bug
When you switching workspaces, keyboard layout remains the same as in previously active window, regardless of current active window layout
To Reproduce
Steps to reproduce the behavior:

Setup two different windows in two different workspaces
Try to change layout in one window and switch to another workspace
You will got layout of the previous window

Expected behavior
Switching from another workspace will not change current window layout
Linux Distro (please complete the following information):
Latest Arch (except waybar, nevermind)
Additional context
Saw it first time a months ago. Maybe a half year

I believe you, but I cannot reproduce it.
Please start hyprland-per-window-layout in debug mode in your Hyprland config:
Replace
exec-once = /usr/bin/hyprland-per-window-layout

with
exec-once = RUST_LOG='debug' /usr/bin/hyprland-per-window-layout > /tmp/hyprland-per-window-layout.log 2>&1

and check your hyprland-per-window-layout is not crashed when you see the bug,
and make sure that  activewindow event fired when you switch workspace ( see /tmp/hyprland-per-window-layout.log ).

Actually, I did it in single workspace, so it's not the reason
What have I done:

Start weston-terminal (1)
Start alacritty (2)
Type in 2 (en)
Switch to 1
Type in 1 (en)
Change layout (and type, sure) (ru)
Switch to 2
Type in 2 (en)
Change layout (ru)
Switch to 1
Type in 1 (ru)
Change layout (en)
Switch to 2
Type in 2 (en) - should be ru

Complicated a bit, sorry. Actually I did just typing, changing layout and switching to another window. After a few attempts I got what I got
Log file attached
hyprland-per-window-layout.log

What do you have in hyprland.conf input section?

input {
    kb_layout = us,ru
    kb_variant =
    kb_model =
    kb_options = grp:alt_shift_toggle
    kb_rules =

    follow_mouse = 1

    touchpad {
        natural_scroll = no
    }

    sensitivity = 0 # -1.0 - 1.0, 0 means no modification.
}

It seems the problem related to wvkbd, it creates one more keyboard layout, that is not listed in input {     kb_layout = us,ru, so hyprland can't switch to it. I created a fix, could you install from source and check latest version before i will push it to aur?

Yes, seems like problem was solved


Logstash 2.2.1 never stops using logstash-input-jmx-2.0.2 log contains: The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.

{:timestamp=>"2016-02-17T09:28:10.667000+0100", :message=>#<LogStash::PipelineReporter::Snapshot:0x86f90f @data={:events_filtered=>410875, :events_consumed=>410995, :worker_count=>2, :inflight_count=>244, :worker_states=>[{:status=>"run", :alive=>true, :index=>0, :inflight_count=>120}, {:status=>"sleep", :alive=>true, :index=>1, :inflight_count=>124}], :output_info=>[{:type=>"elasticsearch", :config=>{"hosts"=>"localhost"}, :is_multi_worker=>true, :events_received=>410875, :workers=>[<LogStash::Outputs::ElasticSearch hosts=>["localhost"], codec=><LogStash::Codecs::Plain charset=>"UTF-8">, workers=>1, index=>"logstash-%{+YYYY.MM.dd}", manage_template=>true, template_name=>"logstash", template_overwrite=>false, flush_size=>500, idle_flush_time=>1, doc_as_upsert=>false, max_retries=>3, script_type=>"inline", script_var_name=>"event", scripted_upsert=>false, retry_max_interval=>2, retry_max_items=>500, action=>"index", path=>"/", ssl_certificate_verification=>true, sniffing=>false, sniffing_delay=>5>, <LogStash::Outputs::ElasticSearch hosts=>["localhost"], codec=><LogStash::Codecs::Plain charset=>"UTF-8">, workers=>1, index=>"logstash-%{+YYYY.MM.dd}", manage_template=>true, template_name=>"logstash", template_overwrite=>false, flush_size=>500, idle_flush_time=>1, doc_as_upsert=>false, max_retries=>3, script_type=>"inline", script_var_name=>"event", scripted_upsert=>false, retry_max_interval=>2, retry_max_items=>500, action=>"index", path=>"/", ssl_certificate_verification=>true, sniffing=>false, sniffing_delay=>5>], :busy_workers=>0}], :thread_info=>[{"thread_id"=>18, "name"=>"[base]<jmx", "plugin"=>nil, "backtrace"=>["[...]/vendor/bundle/jruby/1.9/gems/logstash-input-jmx-2.0.2/lib/logstash/inputs/jmx.rb:351:in sleep'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-input-jmx-2.0.2/lib/logstash/inputs/jmx.rb:351:in run'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:331:in inputworker'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:325:in start_input'"], "blocked_on"=>nil, "status"=>"sleep", "current_call"=>"[...]/vendor/bundle/jruby/1.9/gems/logstash-input-jmx-2.0.2/lib/logstash/inputs/jmx.rb:351:in sleep'"}, {"thread_id"=>35, "name"=>"[base]>worker0", "plugin"=>["LogStash::Filters::Mutate", {"gsub"=>["short_message", "^(.{0,20}).*", "\\1"]}], "backtrace"=>["[...]/vendor/bundle/jruby/1.9/gems/logstash-filter-mutate-2.0.3/lib/logstash/filters/mutate.rb:328:in gsub'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-filter-mutate-2.0.3/lib/logstash/filters/mutate.rb:311:in each'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-filter-mutate-2.0.3/lib/logstash/filters/mutate.rb:311:in gsub'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-filter-mutate-2.0.3/lib/logstash/filters/mutate.rb:221:in filter'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/filters/base.rb:151:in multi_filter'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/filters/base.rb:148:in each'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/filters/base.rb:148:in multi_filter'", "(eval):160:in filter_func'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:256:in filter_batch'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:254:in inject'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:254:in filter_batch'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:212:in worker_loop'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:190:in start_workers'"], "blocked_on"=>nil, "status"=>"run", "current_call"=>"[...]/vendor/bundle/jruby/1.9/gems/logstash-filter-mutate-2.0.3/lib/logstash/filters/mutate.rb:328:in gsub'"}, {"thread_id"=>36, "name"=>"[base]>worker1", "plugin"=>["LogStash::Filters::Mutate", {"gsub"=>["short_message", "^(.{0,20}).*", "\\1"]}], "backtrace"=>["[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:298:in synchronize'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:298:in inflight_batches_synchronize'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:223:in worker_loop'", "[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:190:in start_workers'"], "blocked_on"=>nil, "status"=>"sleep", "current_call"=>"[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:298:in synchronize'"}], :stalling_threads_info=>[{"thread_id"=>18, "name"=>"[base]<jmx", "plugin"=>nil, "current_call"=>"[...]/vendor/bundle/jruby/1.9/gems/logstash-input-jmx-2.0.2/lib/logstash/inputs/jmx.rb:351:in `sleep'"}, {"thread_id"=>35, "name"=>"[base]>worker0", "plugin"=>["LogStash::Filters::Mutate", {"gsub"=>["short_message", "^(.{0,20}).", "\1"]}], "current_call"=>"[...]/vendor/bundle/jruby/1.9/gems/logstash-filter-mutate-2.0.3/lib/logstash/filters/mutate.rb:311:in `each'"}, {"thread_id"=>36, "name"=>"[base]>worker1", "plugin"=>["LogStash::Filters::Mutate", {"gsub"=>["short_message", "^(.{0,20}).", "\1"]}], "current_call"=>"[...]/vendor/bundle/jruby/1.9/gems/logstash-core-2.2.1-java/lib/logstash/pipeline.rb:298:in `synchronize'"}]}>, :level=>:warn}
{:timestamp=>"2016-02-17T09:28:10.674000+0100", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}

Jenkins standing by to test this. If you aren't a maintainer, you can ignore this comment. Someone with commit access, please review this and clear it for Jenkins to run; then  say 'jenkins, test it'.

not fully fixing the shutdown issue for me - still gets killed at least sometimes..
hangs in:
/vendor/bundle/jruby/1.9/gems/logstash-input-jmx-2.0.4/lib/logstash/inputs/jmx.rb:352:in `sleep'"

Any chance we get this PR merged? Fixes the issue for me (LS 5.0.0).


Still support node 0.4?

I can't install npm install -g brunch when I use node v0.4.12.
It was installed<EMAIL_ADDRESS>Is that issue or your intended?

Works as intended, 0.6 supports windows etc. so we should force people to upgrade to newer node.
By the way, if you can't upgrade, you can still use brunch from github. just clone the repo and execute npm install -g ..


added missing word

added missing word to make it more readable.

#sign-off
FYI: @zr-msft

@ckittel: I'm sorry - only the author of this article, @zr-msft, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


Make the event_log update more than one line per minute

The event_log only updates 1 line per minute.
As a result, the event log on the website can occasionally get behind. I've seen it be 20 mins behind, but later was able to catch up.
Recommend we update the twisted_comet_wrapper.py to poll the output of the twisted log more often (5sec)

Also recommend that we have more verbose logs (use -v -v to include debug msg).
Based on 3 days of logs from the OG mwa system, we would be receiving a message every 10s on average, so a 5 sec poll time would work.

included in fe820c4387f78c9c3d7975396354e2d55c7c3d51

incorporates #109


pod: CreatedAt time will be 269 years ago if create cri network failed

We should set sandbox CreatedAt first time when we create sandbox struct,
and then set sandbox CreatedAt second time after container started.
Before this commit, we just set sandbox CreatedAt after container
started, but if network create failed, the sandbox time is the
default time, which is 269 years ago, so we need to set sandbox
CreatedAt at first, even if an error occurred before start container.

/ok-to-test

@mxpv

/cherrypick release/1.7

/cherrypick release/1.6


Development

Created 3 integration test projects (for each http format option)
Wired the LinkBased option to the mvc builder extensions
Added an addition link Current to the LinkBased links

#6


Add HmppsDigitalServiceAccount to dormant users allow list

:eyes: Purpose
• PR adds HmppsDigitalServiceAccount to the dormant users allow list. This account is expected to be low activity which could make the account look dormant and removal of the user could break critical services.

:recycle: What's Changed
• User HmppsDigitalServiceAccount added to allow list

I think test is failing due to user not yet being in the org. Will await invite being accepted.


Remove inmanta module freeze command

Motivation for this ticket: inmanta module freeze does not work for v2 modules. pip freeze was deemed an appropriate substitute.
Concern raised in planning meeting: pip freeze freezes the full venv, including the orchestrator. This is not desired. Can this be worked around?


Can't get doesntHaveMorph to work

Laravel Version: 5.8.28
PHP Version: 7.3
Database Driver & Version: mysql 8.0.16

Description:
I cannot seem to get the new doesntHaveMorph to work. whereHasMorph works fine though.
Steps To Reproduce:
Simple example:
I have a Link model and different models can have links (e.g. subscription, license period, product).
This is the relation on the Link model:
    /**
     * Get all of the owning models
     *
     * @return \Illuminate\Database\Eloquent\Relations\MorphTo
     */
    public function linkable()
    {
        return $this->morphTo();
    }

I have seeded these 3 links to the database: (posting a picture since it's easier to look at)

Then the code using doesntHaveMorph:
Link::doesntHaveMorph('linkable', [Subscription::class])->get()
-> returns an empty collection, where I expect to get the links for the License period and Product.
On the other hand Link::whereHasMorph('linkable', [Subscription::class])->get()
-> correctly returns a collection with one item -> the link for the Subscription.

Okay, maybe my understanding of the function is completely wrong, because it seems the behavior would match that of what the test is doing. https://github.com/laravel/framework/pull/28928/files#diff-189f859ae631c6808f0f151fbaf1f985R170
   public function testDoesntHaveMorph()
    {
        $comments = Comment::doesntHaveMorph('commentable', Post::class)->get();
        $this->assertEquals([3], $comments->pluck('id')->all());
    }

So the setUp in the test creates 6 models - Posts with ids [1, 2, 3], and Videos with ids [4, 5, 6]. The 3rd Post is soft deleted.
Then
Comment::doesntHaveMorph('commentable', Post::class)->get(); returns the soft deleted Post.
But isn't it supposed to return all the Video models since they belong to the set of "Comments that don't have Post models" 🤔
If that is not the idea with this function, Is there any way for me to then get all the Comments that don't belong to a Post model?
Basically, I was expecting something like this from the doesntHaveMorph function:
   public function testDoesntHaveMorph()
    {
        $comments = Comment::doesntHaveMorph('commentable', Post::class)->get();
        $this->assertEquals([4, 5, 6], $comments->pluck('id')->all());
    }

Any way to get that result with these new functions? :)

This is indeed the correct behavior, but I can see how it's not the most intuitive.
doesntHaveMorph() is only useful for querying related models with global scopes (e.g. SoftDeletes) or looking for inconsistent data (foreign keys that don't actually exist).
Possible solutions for your situation:

If you know all the other polymorphic types:

Link::hasMorph('linkable', [LicensePeriod::class, Product::class])->get();

If none of the related models uses global scopes and all the foreign keys are valid:

Link::where('linkable_type', '!=', Subscription::class)->get();

If you can't make these assumptions, you need to the get the possible types manually:

$types = (new Link)->newModelQuery()->where('linkable_type', '!=', Subscription::class)
    ->distinct()->pluck('linkable_type')->all();

Link::hasMorph('linkable', $types)->get();

@staudenmeir I see. Yes, at least I found it slightly counter intuitive but now I know. :)
It would be cool to be able to do the other thing as well though!
Thank you for the suggestions!

@staudenmeir On second thought, I think the function name could either be changed, or the documentation updated to better explain what you explained to me.
Right now doesntHaveMorph sits right below whereHasMorph https://laravel.com/docs/5.8/eloquent-relationships#querying-polymorphic-relationships so I believe many people will expect what I expected from doesnt :)
Also, the docs only mention:
whereHasMorph
doesntHaveMorph
If we were to match the behaviour it would be:
hasMorph
doesntHaveMorph
whereHasMorph
whereDoesntHaveMorph
plus the orWhere's

It would be cool to be able to do the other thing as well though!

The idea behind the current implementation is that Laravel can get the possible types for you, but you can also provide them yourself. With your suggestion, Laravel would always have to execute an additional query.

Also, the docs only mention:

I don't think we have to list all methods, "corresponding methods" should cover them.

the documentation updated to better explain what you explained to me

An example with whereDoesntHaveMorph() would probably make more sense. We can also add explanations like some other examples have ("Retrieve...").

Feel free to send in a pr to the docs, thanks.


Data model refactor 2

Supersede #980

Adds DataModel for describing from a FE type is represented in different use-contexts.
Adds ArgInfo for controlling how a FE type is represented as function argument.

Deals with the complicated logic of flattening composite types and unflattening them

Changes in behavior of generated code:

All function arguments are now simple primitive types.  LLVM arrays and structures are unpacked.
To the CUDA backend, this means we are never passing structs, which required a extra memory transfer to handle.

More improvements:

CUDA ndarray gpu_head is now redundant (https://github.com/numba/numba/issues/1012)

All function arguments are now simple primitive types. LLVM arrays and structures are unpacked.

I guess this will make the LLVM IR even less readable... A pity that's required for CUDA.

All function arguments are now simple primitive types. LLVM arrays and structures are unpacked.
I guess this will make the LLVM IR even less readable... A pity that's required for CUDA.

CPU backend has some really weird rules regarding structures as arguments as well.  All because LLVM is driven by clang and C++ ABI standards.  Previously, I have avoided it by passing structures by pointers.  It worked but it slows down CUDA backend for the need of an extra device alloc+mempy.
With this C code:
struct A{
    int an_int;
    float a_float;
};

int foo(struct A a){
    blahblahblah
}

struct B {
    int *a_pointer;
    struct A a_struct;
};

int bar(struct B b){
   blahblahblah
}

Clang gives:
; ModuleID = 'what_clang_does.c'
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.9.0"

%struct.A = type { i32, float }
%struct.B = type { i32*, %struct.A }

; Function Attrs: nounwind ssp uwtable
define i32 @foo(i64 %a.coerce) #0 {
}

; Function Attrs: nounwind ssp uwtable
define i32 @bar(i32* %b.coerce0, i64 %b.coerce1) #0 {
}

!llvm.ident = !{!0}

!0 = metadata !{metadata !"Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)"}

struct A becomes i64.  struct B becomes i32* and i64.  That's for AMD64.  X86 is completely different.
If we wanted to pass structure by values from Python into the compiled code, we will need to get the C ABI for structure type right.  Or, just unpack everything into simple scalars.

For those interested and future reference, the AMD64 ABI can be found at: http://www.x86-64.org/documentation/abi-0.99.7.pdf
Aggregates description starts on page 18.

Beside the last nit above, I think this is good to merge.

Great!  Thanks everyone for the review.


Some fixes for glulxdump

These changes add many missing opcodes to glulxdump and also deal with some compiler warnings.

I've merged in versions of these changes. However, the glulxdump program is still out of date; it doesn't work on most of the test files I have lying around. Sorry about that. It's not at the top of my list.