Unexpected memory usage with multiple images

package main

import (
        "image"
        "log"

        "github.com/hajimehoshi/ebiten/v2"
)

const (
        screenWidth  = 1152
        screenHeight = 648
)

var (
        ebitenImage   *ebiten.Image
        ebitenImage2  *ebiten.Image
        ebitenImage3  *ebiten.Image
        ebitenImage4  *ebiten.Image
        ebitenImage5  *ebiten.Image
        ebitenImage6  *ebiten.Image
        ebitenImage7  *ebiten.Image
        ebitenImage8  *ebiten.Image
        ebitenImage9  *ebiten.Image
        ebitenImage10 *ebiten.Image
        ebitenImage11 *ebiten.Image
)

func init() {
        img := image.NewRGBA(image.Rect(0, 0, 1366, 768))
        ebitenImage = ebiten.NewImageFromImage(img)
        ebitenImage2 = ebiten.NewImageFromImage(img)
        ebitenImage3 = ebiten.NewImageFromImage(img)
        ebitenImage4 = ebiten.NewImageFromImage(img)
        ebitenImage5 = ebiten.NewImageFromImage(img)
        ebitenImage6 = ebiten.NewImageFromImage(img)
        ebitenImage7 = ebiten.NewImageFromImage(img)
        ebitenImage8 = ebiten.NewImageFromImage(img)
        ebitenImage9 = ebiten.NewImageFromImage(img)
        ebitenImage10 = ebiten.NewImageFromImage(img)
        ebitenImage11 = ebiten.NewImageFromImage(img)
}

type Game struct {
}

func (g *Game) Update() error {
        return nil
}

func (g *Game) Draw(screen *ebiten.Image) {
        op := &ebiten.DrawImageOptions{}
        screen.DrawImage(ebitenImage, op)
}

func (g *Game) Layout(outsideWidth, outsideHeight int) (int, int) {
        return screenWidth, screenHeight
}

func main() {
        ebiten.SetWindowSize(screenWidth, screenHeight)
        ebiten.SetWindowTitle("Ebiten Test")
        if err := ebiten.RunGame(&Game{}); err != nil {
                log.Fatal(err)
        }
}

This consumes about 400 [MB] on macOS. As the image data should not be on system memory, what consumes so much memory?

Profiling doesn't help anything...

Private physics memory was about 135MB

I found buffered was suspicious. I succeeded to create a minimized test case to reproduce the memory usage issue:
package main

import (
        "time"
        "runtime"
)

var f func()

func foo(bs []byte) {
        if f == nil {
                copied := make([]byte, len(bs))
                copy(copied, bs)
                f = func() {
                        foo(copied)
                }
                return
        }

        println(len(bs))
}

func main() {
        bs := make([]byte, 100*1024*1024)
        foo(bs)

        f()
        f = nil

        for {
                runtime.GC()
                time.Sleep(time.Second)
        }
}

The memory usage (private) keeps 200MB, though the allocated memory should be released...

https://github.com/golang/go/issues/48254

Note that it might take several minutes that memory usage becomes stable.

After the fix:


3985  No alternate text specified when reading out loud TOC entries

Signed-off-by: Julien Lacour<EMAIL_ADDRESS>Description
Add a fox:alt-text attribute for each TOC entry, this attribute is set with the navtitle.
Motivation and Context
Fix https://github.com/dita-ot/dita-ot/issues/3985.
How Has This Been Tested?
Not tested, I don't know if this is possible.
Type of Changes

Bug fix (non-breaking change which fixes an issue)

Checklist

My code follows the code style of this project.

https://github.com/dita-ot/dita-ot/wiki/Java-Coding-Conventions
https://github.com/dita-ot/dita-ot/wiki/XSLT-Coding-Conventions
https://github.com/dita-ot/docs/wiki/coding-guidelines

I have updated the unit tests to reflect the changes in my code.

A solution could be to add a new attribute in org.dita.pdf2/xsl/fo/toc.xsl and transform it in @fox:alt-text in an org.dita.pdf2.fop/xsl/fo/toc_fop.xsl new stylesheet.

A solution could be to call a new template in org.dita.pdf2\xsl\fo\toc.xsl and create this template in all three pdf2 plugins (axf, fop, xep) but only implement it in org.dita.pdf2.fop.


virtualbox: 5.1.6 -> 5.1.8 for many CVEs:

Motivation for this change
https://github.com/NixOS/nixpkgs/issues/19884
https://lwn.net/Vulnerabilities/704586/
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

From LWN:
From the NVD entries:
CVE-2016-5501: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core, a different
vulnerability than CVE-2016-5538.
CVE-2016-5538: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core, a different
vulnerability than CVE-2016-5501.
CVE-2016-5605: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.1.4 in Oracle Virtualization allows remote
attackers to affect confidentiality and integrity via vectors related
to VRDE.
CVE-2016-5608: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect availability via vectors
related to Core, a different vulnerability than CVE-2016-5613.
CVE-2016-5610: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core.
CVE-2016-5611: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality via
vectors related to Core.
CVE-2016-5613: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect availability via vectors
related to Core, a different vulnerability than CVE-2016-5608.

This fails: https://www.refheap.com/62dcb17346507ab159f5f2938

Doesn't "reverse patch detected" just mean that the patch is already applied?!

Is it possible this broke the tests?
https://hydra.nixos.org/build/42818365

:thumbsup: at least it is building on my build server for this time, and
deleting that won't require rebuilding to test.
Thank you!
On Wed, Oct 26, 2016 at 5:57 PM Tuomas Tynkkynen<EMAIL_ADDRESS>wrote:

@dezgeg commented on this pull request.
In pkgs/applications/virtualization/virtualbox/default.nix
https://github.com/NixOS/nixpkgs/pull/19887#pullrequestreview-5957039:

@@ -81,7 +81,7 @@ in stdenv.mkDerivation {
'';

patches = optional enableHardening ./hardened.patch

++ [ ./libressl.patch ./qtx11extras.patch ];

++ [ ./qtx11extras.patch ];

You forgot to delete the patch file as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/19887#pullrequestreview-5957039,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAErrECP-FfymyGZYvxvNJvy91tjI5s0ks5q38zCgaJpZM4KhGzn
.


Unclear Datadog SDK Integration in hybrid apps after version 2 update

Question
Hello everyone,
The instructions for using Datadog in hybrid applications were clear for version 1 of the SDK.
However, after updating to version 2, it seems unclear how to import the SDK from the native side if it has already been configured from React Native.
The document hybrid_applications.md says:
# On iOS, add the Datadog iOS SDKs to your dependencies in your ios/Podfile to use in Objective C files.
pod 'DatadogCoreObjc', '~> 2.5.0'
pod 'DatadogLogsObjc', '~> 2.5.0'
pod 'DatadogTraceObjc', '~> 2.5.0'
...

However, these packages do not seem to be available.
It is possible that they are referring to:
pod 'DatadogCore', '~> 2.5.0'
pod 'DatadogLogs', '~> 2.5.0'
pod 'DatadogTrace', '~> 2.5.0'
...

In that case, it would resolve the versions already installed by @datadog/mobile-react-native.
Is there any basic example of how to correctly import the SDK from the native side to log an error in RUM?
Previously, it was possible with this code:
@import DatadogObjc;
...
[DDGlobal.rum addErrorWithMessage:message source:DDRUMErrorSourceCustom  stack:nil attributes:@{}];

Thank you in advance

Hi @fedemartinm, thanks for reaching out!
Indeed there's a mistake in the documentation, you should keep importing the DatadogSDKObjc pod
pod 'DatadogSDKObjc', '~> 2.5.0'

For usage you can look at our documentation. For the example you gave, you would for instance do:
@import DatadogObjc;

DDRUMMonitor *rum = [DDRUMMonitor shared];
[rum addErrorWithMessage:message stack:nil source:DDRUMErrorSourceCustom  attributes:@{}];

Note that installing the DatadogSDKObjc pod currently imports all Datadog pods. If you can, we recommend using the SDK in Swift as much as possible to prevent this issue.
I'll fix the documentation, let me know if you need more information!


Package request: localsend-rs

Project description
CLI implementation of localsend.
Metadata

homepage URL: https://github.com/zpp0196/localsend-rs
source URL: https://github.com/zpp0196/localsend-rs
license: MIT
platforms: unix, linux, darwin, ...

Add a :+1: reaction to issues you find important.

here's a derivation that builds successfully, but i was unable to use the built command to actually send files.
{ lib
, rustPlatform
, fetchFromGitHub
, openssl
, pkg-config
}:
rustPlatform.buildRustPackage {
  pname = "localsend-rs";
  version = "0-unstable-2024-04-03";

  src = fetchFromGitHub {
    owner = "zpp0196";
    repo = "localsend-rs";
    rev = "358c70ed7c293baaef97e3c9e4dc7cd6f5bc52b4";
    hash = "sha256-OUZ1QKV2VqTpkaGqcQyjFAYpcYmMQLU0Wvln+XO5nx0=";
  };

  cargoHash = "sha256-iBTuF5IHBPKphkecfFR1Hs4qyAFW0QuKkJbt+g6hwjw=";

  nativeBuildInputs = [ pkg-config ];
  buildInputs = [ openssl ];

  meta = {
    description = "CLI implementation of localsend";
    homepage = "https://github.com/zpp0196/localsend-rs";
    maintainers = with lib.maintainers; [ binarycat ];
    platforms = lib.platforms.unix;
    license = lib.licenses.mit;
    mainProgram = "localsend";
  };
}

a few things i noticed:

the localsend-rs repo only has 10 commits
the "send" command does not seem to have a way to specify where to send the files to
the built command is named localsend, which is the same as the gui version, meaning the two could not coexist on the same system (generally you should only do this if two programs have identical CLI interfaces)

these factors make me believe this command is not actually finished or in a usable state.

After testing with that derivation i was able to send files to my phone using the android localsend app fine and could find another device using localsend-rs but couldn't actually receive files. this is likely why you couldnt send files unless you didnt have the correct udp and tcp ports open (53317 by default).
the send command wont let you specify where to send files until it finds another device which can receive it, then it lets you choose.
as far as i can tell the localsend gui app doesnt use localsend as a command but only works when executing a binary in the package unless im missing something.
the repo is very recent so there are likely fixes needed, potentially with not being able to receive files unless its a nix specific issue which im unsure of, i think its fair to not have it packaged if thats not fixable but ill leave that up to you.

as far as i can tell the localsend gui app doesnt use localsend as a command but only works when executing a binary in the package unless im missing something.

the binary in the package is named localsend.  anyone who uses the terminal to start apps, or a dmenu_run based wm (dwm, i3, sway) will be unable to launch the gui if they have both packages installed to their profile.  the desktop entry does hardcode the store path, so users of DEs will be mostly unaffected.

it seems the command for me to run it is localsend_app, after looking at the gui app derivation it seems as if it might be localsend in darwin only?

i'm on x86_64-linux and nix build nixpkgs#localsend results in ./result/bin/localsend being produced.

im also on x86_64 linux and the same command results in ./result/bin/localsend_app

what revision of nixpkgs?

24.05.20240403.08b9151
0e74ca98a74bc7270d28838369593635a5db3260

hmm.. maybe they changed it in a recent localsend version, i'm on stable

looking at the derivations for both stable and unstable the stable version is using fetchurl to get the appimage while unstable is using fetchfromgithub. from what i can tell the binary is called localsend_app but was being changed to localsend on stable, which seems like it might still be the case with darwin unstable

after looking at kernel logs for unrelated reasons i realized nixos enables the kernel firewall by default, will test again.

even with the firewall configured appropriately, i am unable to send or receive files.


Security: Make databases private by default

Summary
Currently the config warns, that if no roles or members are configured, the database will be publicly accessible.
If you just PUT {} into <db>/_security, the database will be public.
But in a database it should be very hard to release something to the public and data should be private by default.
The motivation behind this could be a scenario like this:
The database holds sensitive data, e.g. from health care. An issue comes up that requires immediate action, e.g. a leak in a client application which allows to get database account data. Now the admin currently on duty at 4am thinks:
"okay, if i just kick all roles with access from the db, I should be fine".
If you're doing everything right, your database remains private with the current implementation. Things don't always go right however and CouchDB should help the user here to avoid mistakes.
Desired Behaviour
If there is no access configured, only admins should have access, not everyone.
If needed, a config option can be added, that imitates the old behavior. (This should NOT be the default)
Possible Solution
I added a andalso false as POC in  https://github.com/apache/couchdb/blob/0059b8f90e58e10b199a4b768a06a762d12a30d3/src/couch/src/couch_db.erl#L700
This worked in a simple test and denied access, when no roles or members were set, thus the false could be replaced with a config option. The config option should default to false and if true behaves like the current CouchDB.

We made this change in https://github.com/apache/couchdb/pull/2339 some time ago.
It is also referenced from the 3.0 release notes https://docs.couchdb.org/en/stable/whatsnew/3.0.html

From my experiments and how I understand the PR you added a default _admin role to a newly created DB.
Still, the behavoir is, if you remove all roles and members, the DB is accessible by everyone.

Right, if you don't set the security object yourself, it is implicitly;
{
  "members" : { "roles" : [ "_admin" ] },
   "admins" : { "roles" : [ "_admin" ] }
}

which means only admins can read/write/etc.
If you change it to {}, you are opening it up to everyone.

Exactly, this is what the issue is about.

The database holds sensitive data, e.g. from health care. An issue comes up that requires immediate action, e.g. a leak in a client application which allows to get database account data. Now the admin currently on duty at 4am thinks:
"okay, if i just kick all roles with access from the db, I should be fine".

CouchDB should help the user to prevent unintentional data leakage and make it hard to release data to the public.

I think what you are asking for is for {} to mean private and not public. I sympathise with that position but there is a huge backward compatibility issue there that troubles me. {} has had the meaning of "public" in CouchDB since the introduction of the _users database (circa 1.2).
The https://github.com/apache/couchdb/pull/2339 PR addressed the surprising "public by default" behaviour in a more careful way, and we phased its rollout over releases.

CouchDB does now help prevent unintential data leakage by making databases private unless changed to public by an administrator.
You are saying that administrators might set databases to public by accident and I agree; we can all make mistakes.
At this point I'm not sure where to go with this issue and invite others to add their thoughts. Would changing the long-standing meaning of the {} security object be too disruptive? If we did change it to mean "private", how would one open a database for public read+write?

I wouldn’t mind adding an off-by-default config option that when enabled means “empty security means admin-only-access”

How about adding a config option with a warning, that the default will change in the future.
With some bigger release the default can then be flipped.

not sure we will address this before we do a (much needed) major revamp, so let’s not worry about future announcements here.

@thigg are you planning to submit a PR here?

No, unfortunately not.
We will just have a proxy in front which checks the authentication separately and blocks unwanted access, thus this risk is mitigated for us anyway.


slic3r-prusa3d: 1.41.2 -> 1.41.3

Motivation for this change
Upstream version bump.
https://github.com/prusa3d/Slic3r/releases/tag/version_1.41.3
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

+1 works for me ;)

Did you actually do a test print while I was in the kitchen?!

Duplicate of https://github.com/NixOS/nixpkgs/pull/55641 :p
It seems though that the sha256 had changed in the meantime, yours is correct. I'll close my PR.

If they have the habit of changing tags/releases shouldn't we pin it to the
commit then?
On Mon, 18 Feb 2019, 21:03 André-Patrick Bubel<EMAIL_ADDRESS>wrote:

Duplicate of #55641 https://github.com/NixOS/nixpkgs/pull/55641 :p
It seems though that the sha256 had changed in the meantime, yours is
correct. I'll close my PR.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/56006#issuecomment-464859798, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAm_dA5ul1tSOkqQ8X0zgDIad1huSaGGks5vOwcSgaJpZM4bBcym
.

Duplicate of #55641 :p
It seems though that the sha256 had changed in the meantime, yours is correct. I'll close my PR.

My bad, I didn't search before opening the pull request.

@mweinelt @andir I normally try to keep the package up-to-date as soon as a release is posted. Can I cc you in the future, so we can avoid duplicate work?
I already have done a bit of work for the current development version in https://github.com/NixOS/nixpkgs/pull/55475
Maybe you want to have a look, when it finally is released.

@andir I think they only do this shortly after a release. If it happens again we might want to do this though.

@mweinelt No problem :)

@mweinelt @andir I normally try to keep the package up-to-date as soon as a release is posted. Can I cc you in the future, so we can avoid duplicate work?

Not sure if I'll be a regular contributor, this is my first pull request to nixpkgs. You can certainly highlight me to give your changes a try though.

@GrahamcOfBorg build slic3r-prusa3d

cc @thorstenweber83

Printed succesfully!

Great, next time don't print it with the side up and it won't look like :hankey:!

@andir just out of interest what is that part for?

It's a miniature of the white board maker holder at our local hackerspace.
On 2/18/19 11:10 PM, André-Patrick Bubel wrote:

@andir https://github.com/andir just out of interest what is that part
for?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/56006#issuecomment-464899415, or
mute the thread
https://github.com/notifications/unsubscribe-auth/AAICD0V4TeHBpiKty3GipAbhZXnUs7qiks5vOyTNgaJpZM4bBcym.

(Because the email reply stripped the image as it does not support markdown)

Nice :) Has it been posted online somewhere?

Design by @fooker, maybe he still has the design files lying around.

@Moredread: here you go: https://www.thingiverse.com/thing:3438498

Thanks :) @mweinelt already sent me the file privately. I printed it and it looks fantastic!

Thanks :) @mweinelt already sent me the file privately. I printed it and it looks fantastic!


Get "no code actions available" even if code actions are available with vim.lsp.buf.code_action

fastaction doesn't list code actions that vim.lsp.buf.code_action proposes.
Config, in lazy: {'Chaitanyabsprip/fastaction.nvim'}, in lua/bindings.lua:
local opts = {noremap = true, silent = true}
local fastaction = require('fastaction')
vim.keymap.set('n', '<leader>fa', fastaction.code_action, opts)
vim.keymap.set('v', '<leader>fa', fastaction.range_code_action, opts

I get no code actions available.
NVIM v0.11.0-dev
Build type: RelWithDebInfo
LuaJIT 2.1.1703358377

I had the same issue with my Neovim. I don't know if it will be helpful, but I've attached a minimal configuration file.
Version
NVIM v0.10.2
Build type: RelWithDebInfo
LuaJIT 2.1.1731601260
Reproduction
vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()
vim.g.mapleader = " " -- leaderkey is <space>

require("lazy.minit").repro({
    spec = {
        {
            "Chaitanyabsprip/fastaction.nvim",
            opts = {},
        },
        {
            "neovim/nvim-lspconfig",
            config = function()
                -- Some Language Server Settings
                -- As an example, luals
                require("lspconfig").lua_ls.setup({
                    cmd = { "<the path of lua-language-server>" }
                })
                local opts = { noremap = true, silent = true }
                local fastaction = require("fastaction")
                vim.keymap.set("n", "<leader>fa", fastaction.code_action, opts)
                vim.keymap.set("v", "<leader>fa", fastaction.range_code_action, opts)
            end,
        },
    },
})

I was expecting a minimal project where you had this discrepancy between fastaction and vim.lsp.buf.code_actions. I tried reproducing this case in my other repositories, haven't found anything yet.
As a point of clarification, are you getting >20 code actions?

Sorry, this example is only minimal if you already have clangd installed but I didn't manage to have it work with lua_ls.
init.lua:
vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
    spec = {
        {
            "Chaitanyabsprip/fastaction.nvim",
            opts = {},
        },
        {
            "neovim/nvim-lspconfig",
            config = function()
                -- Some Language Server Settings
                -- As an example, luals
                require("lspconfig").clangd.setup({
                    --cmd = {vim.fn.expand("~/.local/share/nvim/mason/bin/clangd") }
                })
                local opts = { noremap = true, silent = true }
                local fastaction = require("fastaction")
                vim.keymap.set("n", "<leader>fa", fastaction.code_action, opts)
                vim.keymap.set("v", "<leader>fa", fastaction.range_code_action, opts)
            end,
        },
    },
})

main.cpp:
#include <iostream>

int main(int, char**)
{
}

Install clangd.
vim -u init.lua main.cpp, the code action on l.1 can be executed with :lua vim.lsp.buf.code_action() but Fastaction doesn't propose anything.

Only one code action available.

vim.lsp.diagnostic.get_line_diagnostic was returning this.
{ {
    code = "undefined-global",
    message = "Undefined global `vim`.",
    range = {
      ["end"] = {
        character = 47,
        line = 40
      },
      start = {
        character = 44,
        line = 40
      }
    },
    severity = 2,
    source = "Lua Diagnostics."
  } }

and #19 's vim.diagnostic.get returns it.
 { {
      bufnr = 5,
      code = "undefined-global",
      col = 44,
      end_col = 47,
      end_lnum = 40,
      lnum = 40,
      message = "Undefined global `vim`.",
      namespace = 19,
      severity = 2,
      source = "Lua Diagnostics.",
      user_data = {
        lsp = {
          code = "undefined-global",
          message = "Undefined global `vim`.",
          range = {
            ["end"] = {
              character = 47,
              line = 40
            },
            start = {
              character = 44,
              line = 40
            }
          },
          severity = 2,
          source = "Lua Diagnostics."
        }
      }
    } }

I patched fastaction/lsp.lua:41 to reformat the result like the old way, and it's working on me.
  local diags = vim.diagnostic.get(M.bufnr, { lnum = lnum })

  local diags_in_lsp_get_line_diags_style = {}
  for key, item in pairs(diags) do
    diags_in_lsp_get_line_diags_style[key] = item.user_data.lsp
  end

  local params = vim.lsp.util.make_range_params()
  params.context = { diagnostics = diags_in_lsp_get_line_diags_style }

I'm having this exact issue with rust-analyzer (using rustacenvim). After some bisecting it seems like the bad commit is 17be938295e715a1b9bfc6ae90adedf4112bf98d.

I'm thinking of removing all the custom code for handling code actions and simply wrapping vim.lsp.buf.code_action and vim.lsp.buf.range_code_action with fastaction.Select. This would simplify the plugin and also make the results consistent.

I'm thinking of removing all the custom code for handling code actions and simply wrapping vim.lsp.buf.code_action and vim.lsp.buf.range_code_action with fastaction.Select. This would simplify the plugin and also make the results consistent.

Don't know if related or not but with https://github.com/nvimtools/none-ls.nvim, i'm not able to see actions like Ignore the lint message and the like. Maybe by reading off of lsp directly, this will also get fixed!


Update run-command.md

Adding missing Version Number

@johnmarco
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Use common Errors and Severity to gather multiple issues over validation

This has been done for builders, there may be other cases of validation in Helidon Inject


Use Django storage API for all file access

Resolves Notion ticket
Django's storage API must be used, rather than Python's functionality, i.e., open, os.remove, so that non-fs storages, i.e., AWS S3, can be utilized.
Reimplements prun_files from #220
Required by #255
I've manually tested that this works with S3.

@amitschang demoted to draft, csv exporters aren't working properly...


[release-v1.7] Drop PDB patch

As per title, this patch picks up https://github.com/openshift/knative-serving/pull/1290
/cc @ReToCode @skonto @matzew

/cherry-pick release-v1.8


Validating with ASYNCH API Call

Hi there, me again.
With regard to validation. Can you explain how I can handle a validation function that makes an ASYNCH API call that returns a promise to be fulfilled?
At the moment I am handling validation manually in the updateItem method, and adding a custom click handler to the cancel edit button that removes the error when the editing mode is cancelled. (For future versions it would be really useful to have a callback  "onEditingCancelled" event to attach this sort of stuff to.

Currently validation is not supporting async checks, it's work in progress.
Please, check out my answer on SO with a workaround http://stackoverflow.com/questions/36277981/how-can-i-check-the-inserted-edited-item-in-jsgrid-isnt-duplicate/36291243#36291243

Thanks for this, I already had a workaround in place which involves manually setting/clearing error element.
The way I got round the lack of onEditingCancelled event was to attach the error clearing method too the clickhandler for the cancel edit button. i.e.:
$( element ).find( ".jsgrid-cancel-edit-button" ).click( function () { $( element ).find( "tr.jsgrid-error" ).remove(); });


Correction for raw affiliation INSERM UMR 1247 – Research Group on Alcohol & Pharmacodependences (GRAP) Université de Picardie Jules Verne  Amiens France

Correction needed for raw affiliation INSERM UMR 1247 – Research Group on Alcohol & Pharmacodependences (GRAP) Université de Picardie Jules Verne  Amiens France
raw_affiliation_name: INSERM UMR 1247 – Research Group on Alcohol & Pharmacodependences (GRAP) Université de Picardie Jules Verne  Amiens France
new_rors: 01gyxrk03;02vjkv261;01c62av11
previous_rors: 01gyxrk03;02vjkv261
works_examples: W3111597125
contact: 39235fe3d36c70997a9844f28964bbd0:4ce82e59b72522cccd6ad1cd9024c8aa @ u-picardie.fr

This issue was accepted and ingested by the OpenAlex team on 2024-10-10. The new affiliations should be visible within the next 7 days.


Badge checkbox in configuration window

Now that logos are not shown by default after #1092, there should be an easy way for people to know that there is a logo available for specified provider and opt-in for it from badge configuration interface.

Let's track this in #2496.


ci: Use rustup provided clippy.

Also see: https://internals.rust-lang.org/t/clippy-is-available-as-a-rustup-component/7967
Move the clippy we use from being installed by cargo to being installed by rustup. If you find strange problems with clippy after they are merged you will need to do: cargo uninstall clippy && cargo uninstall clippy-lints && rustup self update
This is because the old versions of rustup don't know that clippy is managed, so they give errors like subcommand clippy does not exist.
Reasons for doing this:
Currently the clippy version must be managed separate from the Rust nightly. Using Rustup will allow each of our projects to depend on their own clippy versions and help avoid some toolchain related problems.
The PRs:

https://github.com/pingcap/raft-rs/pull/95
https://github.com/pingcap/rust-prometheus/pull/186
https://github.com/pingcap/grpc-rs/pull/208
https://github.com/pingcap/fail-rs/pull/13
https://github.com/pingcap/tikv/pull/3335

LGTM


vnstat not displaying graphs

Reporting Issues:
To ensure that a I has enough information to work with please include all of the following information.
Use proper markdown syntax to structure your post (i.e. code/log in code blocks).
Make sure you provide the following information below:

[4b41640c74e14dcdf77e6e0ea0ecc180bfa4e120 ] Version

[master2] Branch

[eda521c1c814cd536961206b41fb201b] Commit hash

[Linux-4.13.0-32-generic-x86_64-with-Ubuntu-16.04-xenial] Operating system

[2.7.12 (default, Dec 4 2017, 14:50:18) [GCC 5.4.0 20160609]] Python version

[Installed as instructed via the wiki] What you did?

[vnstat shows the correct stats, but isn't showing graphs] What happened?

[for it to display data properly] What you expected?

[not sure] How can we reproduce your issue?

[vnstat is installed locally so SSH is not being used, the correct interface is set] What are your (relevant) settings?

[https://gist.github.com/Kazz3r24/b0e13377da88a9d92834318ef7bda027] Include a link to your FULL (not just a few lines!) log file that has the error. Please use Gist or Pastebin.

Close your issue when it's solved! If you found the solution yourself please comment so that others benefit from it.
Link to log: https://gist.github.com/Kazz3r24/b0e13377da88a9d92834318ef7bda027

UPDATE
I gave it about 24 hours to see if it would display data after it had been running for a bit, sure enough I just checked and it is displaying graphs. Issue closed.


Boosting: Additional explanations in the AdaBoost algo

We should add explanations here, maybe one sentence per line, e.g., when our base-learner predicts the i-th observation correctly we use the old weight as new weight since exp(0) = 1 (something like that)

contains lots of explanation now


This is the final version of preemptible interrupt handler of section 7.2 (no issue as such)

This is the final version of preemptible interrupt handler of section 7.2.
It is possible by allowing mnxti to handle pending interrupts at the same level as current.
This code assumes that functionality will be enabled by using "csrrsi a1,mnxti,1".
The greatest benefit from using this functionality is reduced time to handle very high interrupt loads.
Specifically, 12 instructions with no stack r/w and no interrupt trapping.
I hope the comments are comprehensive and self explanatory.
   .p2align 3
      # Inline preemptible interrupt handler.
      # Only safe for horizontal interrupts.
      #
      # In this version B 2.0:
      #    Selectively hardware vectored interrupts will potentially be substantially
      #       delayed as no interrupts are enable until epilogue.
      #    The worst case delay is from an intrpt2 section bnez to intrpt1
      #       through to interrupts enabled in the epilogue. 24 instructions.
      #
      # Note: This code uses an extension instruction:
      #          Branch Bit Set (bbs) proposed for the Fast Interrupt Extension
      #       Also, a variant of the mnxti csr that allows same level pil selection,
      #                also proposed for Fast Interrupt
      #
      # This version does not handle the type 1 interrupt processing through an
      #    interrupt, but through a mnxti branch sequence. As a result the INT1
      #    value is not enabled in the sp, but rather INC2 is always used to indicate
      #    second (and subsequent) time through the primary entry point.
      #
      #
      # Non preempted code path is 28 instructions including:
      #       5 stores, 4 loads, one amo, mret and 6 csr:
      #       2 csr read, 2 csr write,
      #       1 csr modify (MIE on) and 1 special (a0,mnxti,1).
      #
      # Minimum handle code is 12 instructions, with no stack lw/sw nor hardware trap.
      #   This is the code path from intrpt1 through pending check back to intrpt1.
      # It is during highest interrupt frequency that this code is in play,
      #    which is a very favourable characteristic.
      # It is also the worst latency case as 12 instructions execute between checks.
      #
      # The total count for one pass through each of the 3 paths is
      #  28 + /*first entry to epilogue mret (worst case, best is 19)*/
      #   3 + /*2nd type preemption (no pending) */
      #  13 + /*1st type interrupt (pending int flag clear & accum)*/
      #  19   /* continue to complete current int flag clear and accum and return*/
      #  Total 63 instructions, for an of average 21.
      #
      # Note: With prerequisites met, a single copy of the code handles the low
      #         2K vectored interrupts; All 4K can be handled by replacing the
      #         andi with a slli;srli pair.(and increase the code path by one instruction)
      #         Lower values in the andi are possible to handle 1K, 512, etc. counters.
      #
      #
      # Prerequisites
      # 0. sp is used in non-standard ways in this code but no restrictions on where
      #        sp points in memory.
      #    Minimum alignment is 4 bytes but 8 or more optimizes compressed load/stores.
      # 1. Normal sp management preserving alignment must be performed by other code.
      # 2. It is assumed that routines that use this handler are at the highest
      #      interrupt priority. Thus this code will only be preempted by this code.
      #    If this code can be preempted by selectively hardware vectored interrupts,
      #      their handler must also accommodate the INT2 flag in the sp.
      #      (That is tolerate 1/2 the normal sp alignment).
      # 3. Interrupt flag and counter offsets from their base
      #      are both scaled from exccode in mcause
      # 4. The base for INTERRUPT_FLAGS and COUNTERS should be 4K aligned
      #      this save 2 instructions using lui to provide base and offsets.
      # 5. This code assumes all 2K/4K interrupts are COUNTER accumulators.
      #      Any interrupts can be used for other purposes but there will be
      #      corresponding holes in the COUNTER array.
      #
      #
   .equ  STCK_ALIGN,16             # in bytes (minimum of 4 is required)
                                # with 8 byte aligned stack lw & sw are compressed
   .equ  INC2,STCK_ALIGN/2         #
   .set  COUNTERS,COUNTER_ARRAY    #
   .set  INTRPT_FLAGS,INTERRUPT_FLAGS_ARRAY
                                   #
   foo:
      #----- Interrupts disabled on entry ---#
      bbs sp, INC2, intrpt2        # do subsequent time through processing
      #----- First time in interrupt context ----#
      addi sp, sp, -FRAMESIZE+INC2 # advance sp and flag for intrpt2
      sw a0, OFFSETa0-INC2(sp)     # Save working register.
      sw a1, OFFSETa1-INC2(sp)     # Save working register.
      csrr a0, mepc                # Read epc.
      sw a0, OFFSETepc-INC2(sp)    # save epc
      csrr a0, mcause              # Read cause.
      sw a0, OFFSETcause-INC2(sp)  # save mcause
      # if interrupt pending: to intrpt1 and try to catch up
      csrrsi a1,mnxti,1            # new variant to allow equal pil pending interrupt
      bnez intrpt1                 # process pending interrupt.
   advance:
      # a0 = current mcause
      andi a0,a0,0x7FF             # mask off low 2K entries of exccode
      la a1, INTRPT_FLAGS
      add a1, a0, a1
      sw x0, (a1)                  # Clear current interrupt flag.
      la a1, COUNTERS              #
      slli a0,2                    # scale to words for counters
      add a1, a1, a0
      li a0,1
      amoadd.w x0, (a1), a0        # increment current counter in memory.
      # ---- we've caught up (or had no interrupts) #
      csrrsi x0, mstatus, MIE      # Enable interrupts.
      #----- Interrupts enabled ---------#
      #----- No other critical section until interrupt or mret ----#
      lw a1, OFFSETa1-INC2(sp)     # Restore a1.
      lw a0, OFFSETepc-INC2(sp)    # Restore original epc
      csrw mepc, a0                # Put epc back.
      lw a0, OFFSETcause-INC2(sp)  # Restore original cause
      csrw mcause, a0              # Put cause back.
      lw a0, OFFSETa0-INC2(sp)     # Restore a0.
      addi sp, sp, FRAMESIZE-INC2  # Restore sp
      mret                         # Return from handler
      #
      #  following code executes as a result of preemption
      #
   intrpt1:
      #----- Interrupts disabled  ---------#
      # a0 = prev mcause
      andi a0,a0,0x7FF             # mask off low 2K entries of exccode
      # if all 4K entries are desired replace andi here and above with
      #slli a0,a0,20                # mask off all 4K entries of exccode
      #srli a0,a0,20
      la a1, INTRPT_FLAGS
      add a1, a0, a1
      sw x0, (a1)                  # Clear previous interrupt flag.
      la a1, COUNTERS              #
      slli a0,2                    # scale to words for counters
      add a1, a1, a0
      li a0,1
      amoadd.w x0, (a1), a0        # increment previous counter in memory.
   intrpt2:
      csrr a0, mcause              # Read cause.
      csrrsi a1,mnxti,1            # new variant to allow equal pil pending interrupt
      bnez intrpt1                 # process pending interrupt.
      b advance

      #------------------------------------#

Without the new variant for mnxti  to allow equal pil pending interrupt,
pil in mcause needs to be reduced by 1.
fortunately mcause is in a0 when  csrrsi a1,mnxti,1 would be executed, so we can change the new instruction into
lui a1,PILbit0    # low bit location of mpil in mcause
sub a0,a0,a1    # reduce mpil in mcause by 1
csrrw x0, mcause, a0   # write it back to activate it
csrrci a1,mnxti, MIE   # using reduced pil continue with interrupts disabled
This is costly. The write to mcause especially needs to complete before mnxti executes.
In any case, 3 more instructions including the mcause write back.

Hi David,
I'm a little confused why you want to allow equal pil pending interrupt
here is an example:
interrupts 1,2, programmed to all be at interrupt level 1
interrupts 11 programmed to be at interrupt level 10
My understanding of behavior as currently defined:
running code
-> interrupt 2 occurs
pil set to 0, start processing interrupt 2
-> interrupt 11 occurs
pil set to 1, preempt interrupt 2, start processing interrupt 11
-> interrupt 1 occurs
pil still set to 1, keep processing 11
interrupt 11 finishes, use mnxti to see if any interrupts are pending, none are above level 1 so return to interrupt 2
finish processing interrupt 2,
use mnxti to see that interrupt 1 is waiting
process interrupt 1
finish processing interrupt 1
return to code
Proposed behavior if allow equal pil pending interrupt:
running code
-> interrupt 2 occurs
pil set to 0, start processing interrupt 2
-> interrupt 11 occurs
pil set to 1, preempt interrupt 2, start processing interrupt 11
-> interrupt 1 occurs
pil still set to 1, keep processing 11
interrupt 11 finishes, use mnxti to see if any interrupts are pending, see interrupt 1 level == pil
process interrupt 1,
finish processing interrupt 2,
return to code
if interrupt 2 and interrupt 1 are programmed at the same level, why do you want interrupt 1 to be able to complete before interrupt 2?  program interrupt 1 to a higher level if you want that behavior.
since they are programmed at the same level, interrupt 2 should be able to finish before tail-chaining to interrupt 1, right?
Thanks,
Dan

From: David-Horner<EMAIL_ADDRESS>Sent: Tuesday, September 22, 2020 5:00 PM
To: riscv/riscv-fast-interrupt<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [riscv/riscv-fast-interrupt] This is the final version of preemptible interrupt handler of section 7.2 (no issue as such) (#102)
Without the new variant for mnxti to allow equal pil pending interrupt,
pil in mcause needs to be reduced by 1.
fortunately mcause is in a0 when csrrsi a1,mnxti,1 would be executed, so we can change the new instruction into
lui a1,PILbit0 # low bit location of mpil in mcause
sub a0,a0,a1 # reduce mpil in mcause by 1
csrrw x0, mcause, a0 # write it back to activate it
csrrci a1,mnxti, MIE # using reduced pil continue with interrupts disabled
This is costly. The write to mcause especially needs to complete before mnxti executes.
In any case, 3 more instructions including the mcause write back.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_riscv_riscv-2Dfast-2Dinterrupt_issues_102-23issuecomment-2D697026175&d=DwMCaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=R2WIYoRmomuHhrOH4uCU6OMCPHMd0uav2hKfWsl1d_4&m=z-aaWM8lIBavDcbRCUQq9DXZOYDdWxXOU3be9XI-Rc0&s=6ZPAfiE0NwS6CBLuOFlrXce24qGxBG_O6qVshjia7D4&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_APFWH2ZXKB3KHBH3BTB5IHTSHEUBTANCNFSM4RL76JIQ&d=DwMCaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=R2WIYoRmomuHhrOH4uCU6OMCPHMd0uav2hKfWsl1d_4&m=z-aaWM8lIBavDcbRCUQq9DXZOYDdWxXOU3be9XI-Rc0&s=aeuDv7oW0GMQVTUttMoo0RfBKr3XrPKfonaYttz7zdw&e=.

On 2020-09-23 11:03 a.m., dansmathers wrote:
Thank you very much for your response.
Sorry for the delay in responding.

Hi David,
I'm a little confused why you want to allow equal pil pending interrupt
here is an example:
interrupts 1,2, programmed to all be at interrupt level 1
interrupts 11 programmed to be at interrupt level 10
This is not the situation I have in my code, but we can certainly
discuss it.

Even in this scenerio, one might want to check for and respond to a
pending interrupt of equal pil.

My understanding of behavior as currently defined:
running code
-> interrupt 2 occurs
pil set to 0, start processing interrupt 2
-> interrupt 11 occurs
pil set to 1, preempt interrupt 2, start processing interrupt 11
-> interrupt 1 occurs
pil still set to 1, keep processing 11
interrupt 11 finishes, use mnxti to see if any interrupts are pending,
none are above level 1 so return to interrupt 2
finish processing interrupt 2,
use mnxti to see that interrupt 1 is waiting
process interrupt 1
finish processing interrupt 1
return to code
looks good to me. A typical scenario.
Proposed behavior if allow equal pil pending interrupt:
running code
-> interrupt 2 occurs
pil set to 0, start processing interrupt 2
-> interrupt 11 occurs
pil set to 1, preempt interrupt 2
but only when global interrupts are disabled, otherwise 11 waits.

This allows code to establish a safe return point that does not require
mret, and more importantly extensive register restore and mret setup.

, start processing interrupt 11
-> interrupt 1 occurs
pil still set to 1, keep processing 11
interrupt 11 finishes,
But what does interrupt 11 do when it finishes?

In the case that cares about mnxti, it branches to the safe return point
in interrupt 2 code.
Now, pil = level 1
the safe return code can complete interrupt 2 or it can check with the
special mnxti and handle the interrupt 1 first.
It has substantial flexibility.
But even if it completes 2 first it still wants to detect interrupt 1
without restoring mcause and doing a mret.
In deed  without restoring mcause at all, but only doing a special mnxti
to identify and process any pending same level from there on.
(continuing processing like alternating between 1 and 2)
It is a "minor" optimization, instead mcause could be required to be
restored, but that would require a stack read in my code, no longer a
minor operation.
(not to mention the lockout/delay from a write to a CSR to its use in an
"instruction" like mnxt )
To be explicit, the following is NOT the processing order I envisioned
(but certainly possible):

use mnxti to see if any interrupts are pending, see interrupt 1 level
== pil
process interrupt 1,
finish processing interrupt 2,

return to code
Yes, eventually we get back to original code, but we make every attempt
to catch any pending or coincident interrupt as possible.

Note, my code has interrupts enabled throughout the epilog.
It is especially here that a same level interrupt can occur and set pil
to the current level.
It is this scenario I envisioned. Thus, I stipulated in my code preface
that these horizontal interrupts are configured at the highest interrupt
level in use by the system.
As we see here, that is not absolutely necessary, but any lower priority
level for the code would require the higher level interrupt handler to
be "cooperative" with the code in the lower level for full benefits to
be realized.

if interrupt 2 and interrupt 1 are programmed at the same level, why
do you want interrupt 1 to be able to complete before interrupt 2?
Good question. It was not what I needed. But software could make that
determination,

perhaps the hardware was set incorrectly at equal (an errata or
intentional) and it has to compensate, or
perhaps the relative priorities change dynamically and software
can thus accommodate without reprogramming the CLIC (FLICR? [Fast Local
Interrupt CLIC Renamed])
Anyway, it could definitely come in handy.

program interrupt 1 to a higher level if you want that behavior.
This is high overhead for dynamically changing priorities, perhaps
insufficiently timely.
since they are programmed at the same level, interrupt 2 should be
able to finish before tail-chaining to interrupt 1, right?
Correct.

But even if they were different levels the completion order does not
have to be the invocation order:
As we can see that with interrupt 11; if it occurred first, mnxti
would show a pending interrupt 1 or 2 and software could process it
before finishing 11 if it so chose.

Thanks,
Dan

Thank you!!
Directed questions greatly help me to  flesh/flush out these concepts
in/from my head.

From: David-Horner<EMAIL_ADDRESS>Sent: Tuesday, September 22, 2020 5:00 PM
To: riscv/riscv-fast-interrupt<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [riscv/riscv-fast-interrupt] This is the final version of
preemptible interrupt handler of section 7.2 (no issue as such) (#102)
Without the new variant for mnxti to allow equal pil pending interrupt,
pil in mcause needs to be reduced by 1.
fortunately mcause is in a0 when csrrsi a1,mnxti,1 would be executed,
so we can change the new instruction into
lui a1,PILbit0 # low bit location of mpil in mcause
sub a0,a0,a1 # reduce mpil in mcause by 1
csrrw x0, mcause, a0 # write it back to activate it
csrrci a1,mnxti, MIE # using reduced pil continue with interrupts disabled
This is costly. The write to mcause especially needs to complete
before mnxti executes.
In any case, 3 more instructions including the mcause write back.

Hi David,
Is your preemptible interrupt handler a special case that you would like included in the spec along with the existing handler?  If I'm understanding it right, in your handler, interrupts are only enabled for preemption during the final restore from the stack (epilogue).  the rest of the time interrupts are disabled so there won't be preemption of an interrupt while it is doing work (in the example, the interrupt task is just incrementing a counter).    So this is designed for short, high priority tasks where the amount of work the high priority interrupts have to accomplish is less than the length of the epilogue?   If I'm understanding it right, the horizontal preemption that exists is just used to shorten the epilogue (where all the csr/stack accesses/mret are) and there wouldn't be preemption of the interrupt tasks themselves, right?
maybe this should be added to the beginning of the handler comments?
e.g. Inline interrupt handler for rapid tail-chaining of critical  high priority interrupts.

@dansmathers

Is your preemptible interrupt handler a special case that you would like included in the spec along with the existing handler?

Yes, if it doesn't supersede that example. Each has it own strengths and constraints. So along side is probably best.
It is only a special case in that it takes to the extreme what preemptible means. All handlers will have critical sections. By constraining where horizontal interrupts are allowed to preempt, optimal handling of the high frequency interrupts is possible.,

If I'm understanding it right, in your handler, interrupts are only enabled for preemption during the final restore from the stack (epilogue).

Actually, no. There is a an opportunity to accept another pending interrupt on either side of the core service function (the counter increment and interrupt flag reset) not just epilogue.
If we define preemption in terms of nesting, then this code fails that definition. There is no recursive handling. Instead the request are queued, processed in order. The depth in this example is two. Other possibilities with the same idea of bracketing the service code could allow out of order "preemptive servicing", and especially if the service code were partitioned. However, that is more complex, generates more code, increases the stack foot print (due to more registers required for state) and may increase latency.  So not as good an example in my thinking. But more importantly, keeping order avoid starvation of equal and lower priority interrupts.  Reducing service code overhead compensates for not expediting higher priority handling and also avoids potential drop outs.

the rest of the time interrupts are disabled so there won't be preemption of an interrupt while it is doing work (in the example, the interrupt task is just incrementing a counter).
So this is designed for short, high priority tasks where the amount of work the high priority interrupts have to accomplish is

up to here yes ...

less than the length of the epilogue?

No, that is not the defining characteristic.
In that the epilogue is fully interruptible and rerunnable its length/duration is not a determinant.
This is one of the novel aspects; a generally applicable but not primary objective.
The primary goal is to keep all critical sections (and especially housekeeping tasks) as small as possible to maximize handling bursts of interrupts.
A more complex service portion can be subdivided into multiple critical sections, with a corresponding increase in registers needed to contain intermediate state.
The biggest win is the service portion can become the dominant part of the inner process. In this case the code from intrpt1 and including intrpt2 is all service code. In the most contested case, only two more instructions are needed to manage the hart handler housekeeping: the new mnxti variant and the branch if the new interrupt is detected.[Yes, the service portion does reset the interrupt controller, but the hart handler housekeeping, processing/logic state, register save/restore, mret setup, etc. are moved out of that path as much as possible.]

If I'm understanding it right, the horizontal preemption that exists is just used to shorten the epilogue (where all the csr/stack accesses/mret are) and there wouldn't be preemption of the interrupt tasks themselves, right?

As before it depends whether nesting is central to your idea of preemption. The epilogue is indeed preempted in that case, but we don't see the nesting because the rerunable code allows that nesting to be virtual; absorbed in "tail processing".
But also mentioned before, there are two other points, before and after the service code, that pending interrupts are allowed.

maybe this should be added to the beginning of the handler comments?
e.g. Inline interrupt handler for rapid tail-chaining of critical high priority interrupts.

That is a good summary and I'm happy to include it.
However, I believe the opening comments detail what I consider the salient and distinctive features:

The reduced latency with critical sections comparable to the original non-preempt code.
vastly improved service in the heavily contended case.

Just linking this, code assumes #101


refactor: moved generic errors to generic errors file  #19

Some were kept in the original file as they arguably they are not generic. @ezynda3 please let me know if you have other preferences here.

Looks like one test is broken from this


chore: nix flake update

I got evaluation problems, because aarch64-darwin is now a default system. Update might does help.
• Updated input 'flake-utils':
    'github:numtide/flake-utils/f7e004a55b120c02ecb6219596820fcd32ca8772' (2021-06-16)
  → 'github:numtide/flake-utils/74f7e4319258e287b0f9cb95426c9853b282730b' (2021-11-28)
• Updated input 'mdBook':
    'github:leanprover/mdBook/d97081c547e96b41a9a16197882127e7e8917a3d' (2021-09-30)
  → 'github:leanprover/mdBook/45de7509526f09915b19e4eaeec99c8c2031f1ce' (2021-11-19)
• Updated input 'nix':
    'github:NixOS/nix/9c766a40cbbd3a350a9582d0fd8201e3361a63b2' (2021-09-27)
  → 'github:NixOS/nix/2ff71b021379a2c9bbdcb789a93cdc585b3520ca' (2021-12-02)
• Updated input 'nix/lowdown-src':
    'github:kristapsdz/lowdown/0b85e777f3cdacf4210f0d624a0ceec8df612e05' (2021-09-23)
  → 'github:kristapsdz/lowdown/d2c2b44ff6c27b936ec27358a2653caaef8f73b8' (2021-10-06)
• Updated input 'nix/nixpkgs':
    'github:NixOS/nixpkgs/f6551e1efa261568c82b76c3a582b2c2ceb1f53f' (2021-08-11)
  → 'github:NixOS/nixpkgs/82891b5e2c2359d7e58d08849e4c89511ab94234' (2021-09-28)
• Updated input 'nixpkgs':
    'github:NixOS/nixpkgs/ee084c02040e864eeeb4cf4f8538d92f7c675671' (2021-10-04)
  → 'github:NixOS/nixpkgs/391f93a83c3a486475d60eb4a569bb6afbf306ad' (2021-12-01)
• Updated input 'temci':
    'github:parttimenerd/temci/fe4f47173a27cf75f734502fcb88d3d0a3860dca' (2021-07-21)
  → 'github:parttimenerd/temci/a8d78cb52c248f1ae3f2469bbd0916b14ac9ea84' (2021-11-29)

I got evaluation problems

Could you clarify? Did that fix it?

For flake.nix as follows
{
  description = "aoc";
  inputs = {
    lean.url = github:leanprover/lean4;
    flake-utils.url = github:numtide/flake-utils;
  };
  outputs = { self, lean, flake-utils }: flake-utils.lib.eachDefaultSystem (system:
    let
      leanPkgs = lean.packages.${system};
      leanPkg = leanPkgs.buildLeanPackage {
        name = "AOC";
        src = ./.;
      };
    in {
      packages = leanPkg // {
        inherit (leanPkgs) lean;
      };
    }
  );
}

the invocation nix flake show results in
$ nix flake show
git+file:///home/lorenz/src/github.com/lorenzleutgeb/aoc
└───packages
    ├───aarch64-darwin
error: attribute 'aarch64-darwin' missing

       at /nix/store/pd47gnfw66v0699c99pkqnbf0vdijd10-source/flake.nix:9:18:

            8|     let
            9|       leanPkgs = lean.packages.${system};
             |                  ^
           10|       leanPkg = leanPkgs.buildLeanPackage {
(use '--show-trace' to show detailed location information)

but with just a small change to pin flake-utils to the version that you use, it evaluates nicely
6,7c6
<     flake-utils.url = github:numtide/flake-utils;
---
>     flake-utils.follows = "lean/flake-utils";

The reason is that with the flake-utils you use on master, there's no aarch64-darwin system being generated, but with the current one that people will get when they do not decide to follow Lean's flake-utils input, that's required. Note that your flake template is affected by that.
I decided to just nix flake update which resolves the issue for me. It might have been enough to just update flake-utils, but I decided to nevertheless PR an update of all inputs.

I just noticed that now
$ nix flake show
git+file:///home/lorenz/src/github.com/lorenzleutgeb/lean4
├───checks
│   ├───aarch64-darwin
│   │   └───lean: derivation 'lean-test-stage1'
│   ├───aarch64-linux
│   │   └───lean: derivation 'lean-test-stage1'
│   ├───i686-linux
│   │   └───lean: derivation 'lean-test-stage1'
│   ├───x86_64-darwin
│   │   └───lean: derivation 'lean-test-stage1'
│   └───x86_64-linux
│       └───lean: derivation 'lean-test-stage1'
├───defaultPackage
│   ├───aarch64-darwin: package 'lean'
│   ├───aarch64-linux: package 'lean'
│   ├───i686-linux: package 'lean'
│   ├───x86_64-darwin: package 'lean'
│   └───x86_64-linux: package 'lean'
├───defaultTemplate: template: A custom Lean package
├───packages
│   ├───aarch64-darwin
error: expected a derivation

but also on master:
% nix flake show
git+file:///home/lorenz/src/github.com/lorenzleutgeb/lean4?ref=master&rev=2e47a8d5cafa66f243c424aa72b773fea2d9df71
├───checks
│   ├───aarch64-linux
│   │   └───lean: derivation 'lean-test-stage1'
│   ├───i686-linux
│   │   └───lean: derivation 'lean-test-stage1'
│   ├───x86_64-darwin
│   │   └───lean: derivation 'lean-test-stage1'
│   └───x86_64-linux
│       └───lean: derivation 'lean-test-stage1'
├───defaultPackage
│   ├───aarch64-linux: package 'lean'
│   ├───i686-linux: package 'lean'
│   ├───x86_64-darwin: package 'lean'
│   └───x86_64-linux: package 'lean'
├───defaultTemplate: template: A custom Lean package
├───packages
│   ├───aarch64-linux
error: expected a derivation

So what's up with aarch64? Is it supported or not? If not, then maybe don't just flake-utils.lib.eachDefaultSystem ...

The flake show error has nothing to do with with aarch64 but with our use of nested attrsets as in e.g. https://github.com/leanprover/lean4/blob/2e47a8d5cafa66f243c424aa72b773fea2d9df71/doc/make/nix.md?plain=1#L30. I don't know how a flake should be structured properly around that, except to move everything to legacyPackages, which sounds... wrong.

The flake show error has nothing to do with with aarch64 but with our use of nested attrsets as in e.g. https://github.com/leanprover/lean4/blob/2e47a8d5cafa66f243c424aa72b773fea2d9df71/doc/make/nix.md?plain=1#L30. I don't know how a flake should be structured properly around that, except to move everything to legacyPackages, which sounds... wrong.

Oh, right. Thanks a lot for the pointer! At least in 2020-08 the answer was to use legacyPackages. So you should either go with legacyPackages (🙅🏻) or restructure your flake in a different way.


provided delimeters not working

Hi,
I am trying to extract key value pairs from following log pattern.
Log message :   "Received object { Operation1:extract ~~ Time:Thu Oct 06 12:10:47 ~~ Message:text message 123}"
So, I used keys_delimiter  as ~~ and kv_delimiter_char as :  to seperate key values pairs.
Following given is my full configuration in the filter section.

@type key_value_parser
key content
use_regex true
remove_key false
keys_delimiter ~~
kv_delimiter_char :
filter_out_lines_without_keys false

But seems it is not working. How ever, It extracted some unexpected key values that uses space and = signs as delimeters. It seems that default configurations ( space and = ) are applied here. I tried by wrapping the characters with quatation marks, used forward slashes ( /~~/  and /:/ ) in the configuration. But they also didn't work.
So,  What can be the problem here? Appreciate If someone can help on this.

Worked as expected after changing use_regex to false.


(home-manager) File manager (Nautilus) shows persistent folders as ejectable drives

Nautilus shows my Documents and Downloads folder as ejectable drive as well as showing drive icons beside them in the file view in /home. A solution I am thinking of would be to allow setting mount options with impermanence so the x-gvfs-hide option can be used.
Unsure whether this option would be set per directory/file or per persistent mount (set mount option that affects all of /nix/persist for example).

I think this is fundamentally a bug with Nautilus choosing to display bind mounts like external devices. Should be reported upstream IMO.

@lovesegfault I think this refers to the bind mounts created by the home-manager module, which are fuse mounts and therefore show up in Nautilus. Regular bind mounts should be hidden by default, but could appear anyway in some circumstances (they do to me, probably because bind mounts appear as subvolume mounts on btrfs).
I think we could just always supply the x-gvfs-hide option to bind mounts across the board. I don't see any reason why they should ever be shown in Nautilus.


Test reaction directionality

We can apply simple rules to suggest reactions that should be irreversible, for example, phosphate group transfer from ATP or reactions with quinones as co-factors.

I think this should be done properly using thermodynamic information

Maybe one could base this on thermodynamics calculations instead?

Yeah, this will come into play once we add support for the relevant experimental data.

This is partially addressed by #527 though could be expanded on.


Issues with documentation for Marathon API REST

The documentation is kind of broken:
Marathon REST API
Anchors aren't working.
From DELETE /v2/apps/{appId}/tasks/{taskId} part, all the presentation is destroyed.

Looks like the Markdown interpreter didn't do his job!
Pretty annoying...

I fixed this


Generate API specification (OpenAPI.json) via Quart-Schema

It would help developers to know how the HTTP API works if we generate an openapi.json using Quart-Schema. It also helps in confirming confomance with the HTTP Chat Protocol: https://github.com/Azure-Samples/ai-chat-app-protocol
This issue is for a: (mark with an x)
- [ ] bug report -> please search issues before submitting
- [X] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Hi @pamelafox, have you completed it yet? Can you share with me


update for source-map 0.7.x

there have been breaking changes in the way you call SourceMapConsumer:
https://github.com/mozilla/source-map/blob/master/CHANGELOG.md#070

I tried this but it does not fix it:


Jira comment opens up editor for yml configuration when message was already provided

Executing jira comment ap-41 -m "Foo bar." will open the editor where you can change the yml. However I find this step unnecessary since there are no more fields that I could specify. The only change I could do is edit the message.
Hence I'd propose to not show the editor and submit the comment straight away.

There is a --noedit option:
      --noedit             Disable opening the editor

That will bypass the editor and try to submit immediately.  Does this work for you?

From the name of it, it would yes. How could I configure this in conjunction with:
case $JIRA_OPERATION in
    comment)
        ;;
esac

case $JIRA_OPERATION in
    comment)
        echo "noedit: true"
        ;;
esac

You can also create a .jira.d/comment.yml with noedit: true in it so the config does not need to be executable.

Oh that's even better. Thanks :+1:


pvalues in scipy.stats.linregress

When computing the p-value of null hypothesis that linear regression gradient = 0, why does scipy use Wald Statistic followed by a t-test, as opposed to Wald Statistic followed by a Wald test?

I was unable to find any discussion on the mailing list about this design detail.
I suggest that documentation includes information about this design detail.

The following code performs linear regression on two random 5-element vectors using scipy:
import scipy.stats
import random

# Draw some random X and Y
sampleSize = 5
X = [random.uniform(0, 1) for i in range(sampleSize)]
Y = [random.uniform(0, 1) for i in range(sampleSize)]

# named tuple for scipy's linear regression
resultScipy = scipy.stats.linregress(X, Y)

print(resultScipy)

Example output is:
LinregressResult(slope=-0.36654925096390012, intercept=0.67985896267369861, rvalue=-0.32357812225448918, pvalue=0.59531436421063166, stderr=0.61883685654551934)

I wanted to know what statistical test scipy uses to compute the p-value, in this case 0.59531436421063166. Note that the scipy's documentation isn't particularly enlightening:

p-value: float
two-sided p-value for a hypothesis test whose null hypothesis is that the slope is zero.

After reading some of the scipy's code, I can understand & reproduce scipy's behaviour:
import random
import math
import collections
import scipy.stats
import scipy.stats.distributions as distributions
import numpy as np
import sys

# Draw some random X and Y
sampleSize = 5
X = [random.uniform(0, 1) for i in range(sampleSize)]
Y = [random.uniform(0, 1) for i in range(sampleSize)]

# Compute their average
avgX = sum(X)/sampleSize
avgY = sum(Y)/sampleSize

# Partial steps to compute estimators of linear regression parameters.
XDiff = [X_i - avgX for X_i in X]
XDiffSquared = [i*i for i in XDiff]
YDiff = [Y_i - avgY for Y_i in Y]

# B1 is the estimator of slope.
# B0 is the estimator of intercept.
# r is the estimator of Y given X.
B1 = sum(x * y for x, y in zip(XDiff, YDiff)) / sum(XDiffSquared)
B0 = avgY - B1*avgX
r = lambda x: B0 + B1*x

# Partial steps to compute Wald Statistic.
errs = [y - r(x) for x, y in zip(X, Y)]
errStd = math.sqrt((1/(sampleSize-2))*(sum([err**2 for err in errs])))
XStd = math.sqrt((1/(sampleSize))*sum([diff**2 for diff in XDiff]))
stdB1 = errStd / (XStd * math.sqrt(sampleSize))

# Wald Statistic.
W = (B1 - 0)/stdB1

# pvalue of Wald Test of B1 = 0.
pvalueWald = 2*scipy.stats.norm.cdf(-abs(W))

# pvalue of T test of B1 = 0.
pvalueT = 2*distributions.t.sf(abs(W), sampleSize - 2)

# named tuple for our linear regression, with p-value coming from Wald Statistic
LinregressResult = collections.namedtuple("LinregressResult", ["slope", "intercept", "rvalue", "pvalue", "stderr"])
resultWald = LinregressResult(slope=B1, intercept=B0, rvalue=None, pvalue=pvalueWald, stderr=stdB1)

LinregressResult = collections.namedtuple("LinregressResult", ["slope", "intercept", "rvalue", "pvalue", "stderr"])
resultT = LinregressResult(slope=B1, intercept=B0, rvalue=None, pvalue=pvalueT, stderr=stdB1)

# named tuple for scipy's linear regression
resultScipy = scipy.stats.linregress(X, Y)

print(resultWald)
print(resultT)
print(resultScipy)

It appears that scipy first computes the Wald Statistic on the estimator of the slope (gradient), followed by a (sampleSize - 2) degree of freedom t-test.
Why is the p-value computed in such way? My go-to statistics textbook by Larry Wasserman, suggests that I compute the p-value of linear regression in a different way, by computing Wald Statistic, followed by a Wald test.
The two tests give very different results when the sample size is small and the slope is extreme, with Wald's test p-values being consistently lower than t-test's (even by orders of magnitude).

If scipy underreports very small p-values, this would have a big effect on fields, where very small p-values are very important (like high-throughput genomic data).

They are both wald tests, they just differ in the distribution of the test statistic.
The t-distribution is the exact (IIRC) distribution if the residuals are normally distributed. Even when they are not normally distributed, then the t-distribution with the degrees of freedom correction is a better approximation to the true distribution of the test statistic in small samples.
Normal and t distribution are the same asymptotically as the sample size increases, so both give the same answer in large samples, but using the normal distribution in small samples should usually result in over-rejection, i.e. we reject the null hypothesis more often than a given p-value/type-1 error threshold, like 0.05.
For more information this would be a stats.stackexchange question.
related aside: statsmodels allow users to choose between t and normal distribution (or F and chisquare for joint hypotheses). In many cases we have only the asymptotic theory with the normal distribution, but in practice in many cases wald test based on t distribution has better size in small samples than based on the normal distribution.
Using t-distribution for linear regression is "standard textbook" result, but I never read anything by Wasserman.

Thanks Josef,
that clears up a lot. I can vaguely recall seeing an argument for the t-distribution being the exact distribution if the residuals are normally distributed.
This has already been a stats.stackexchange.com question since yesterday, but it hasn't attracted much attention.
Regarding your "increased type 1 error" comment:

using the normal distribution in small samples should usually result in over-rejection, i.e. we reject the null hypothesis more often than a given p-value/type-1 error threshold, like 0.05.

This is exactly what I've been seeing in the graphs attached in the post above

Using t-distribution for linear regression is "standard textbook" result, but I never read anything by Wasserman.

Would you be able to recommend any mathematical statistics textbook?
Would you support rephrasing the scipy.stats.linregress documentation to include this information about test statistic used?
Perhaps something like this:

pvalue : float
two-sided p-value for a hypothesis test whose null hypothesis is that the slope is zero, using Wald Test with t-distribution of the test statistic.

Perhaps something like this: ...

sounds good to me, you could make a PR to improve it.

Would you be able to recommend any other mathematical statistics textbook?

Unfortunately not. I haven't looked at general statistics books in a long time. I have some general econometrics text books that are in the range of 1000 pages. Otherwise, I'm only reading books on specific topics or overview articles or chapters (handbook chapters are usually heavier to read than text books but skip some of the verbosity that I don't need.)
20 pages for linear and logistic regression is very small. There are many text books that cover linear and generalized linear (logistic, poisson, ...) in more detail.

Thanks for all the help, here's the PR: #7137


committing a string change to see if it passes the build

Codecov Report

Merging #194 (793c8af) into main (0dfc8b7) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #194   +/-   ##
=======================================
  Coverage   49.51%   49.51%
=======================================
  Files          14       14
  Lines         519      519
=======================================
  Hits          257      257
  Misses        211      211
  Partials       51       51

Continue to review full report at Codecov.

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


@QueryInit not working with deep nested paths

I am using QueryDSL 4.1.4 with Spring Data in a project and am having trouble using it with nested paths. Consider the following JPA classes:
@Entity @QueryEntity class Company {}

@Entity
@QueryEntity
class Contract {
  @ManyToOne
  @QueryInit("*.*")
  Company buyer;

  @ManyToOne
  @QueryInit("*.*")
  Company seller;
}

@Entity @QueryEntity class Bill { @ManyToOne @QueryInit("*.*") Contract contract; }

@Entity @QueryEntity class Payment { @ManyToOne @QueryInit("*.*") Bill bill; }

@Entity @QueryEntity class Posting { @ManyToOne @QueryInit("*.*") Payment payment; }

With this set up, the following throws NullPointerException:
QPosting.posting.payment.bill.contract.buyer.name.equalsIgnoreCase(...)

Debugging shows that QPosting.posting.payment.bill.contract.buyer (and QPosting.posting.payment.bill.contract.seller) is null.
The following however work fine:

QPayment.payment.bill.contract.buyer.name.equalsIgnoreCase(...)
QBill.bill.contract.buyer.name.equalsIgnoreCase(...)
QContract.contract.buyer.name.equalsIgnoreCase(...)

I am using com.mysema.maven:apt-maven-plugin:1.1.1 and QueryDSL version 4.1.4.
A full sample project is available here. Run Maven tests as mvn clean test to see the error.

I'm experiencing the same issue.
I cannot actually point a finger to why some nested paths are null but the strange thing is that it is not the case for all entities.
E.g I have paths like:
        Object o = QDriver.driver.nationality.continent;
        Object p = QDriver.driver.nationality.continent.code;
        Object q = QDriver.driver.nationality.continent.name;
        Object r = QDriver.driver.secondNationality.continent;
        Object s = QDriver.driver.secondNationality.continent.code;
        Object t = QDriver.driver.secondNationality.continent.name;

which works perfectly, but I also have:
        Object o = QRace.race.circuit.country;
        Object p = QRace.race.circuit.country.continent;
        Object q = QRace.race.circuit.country.continent.code;
        Object r = QRace.race.circuit.country.continent.name;

where the QRace.race.circuit.country.continent is null and causing a NPE accessing the code field.
The more interesting is that
        Object o = QCircuit.circuit.country.name;
        Object p = QCircuit.circuit.country.continent.code;
        Object q = QCircuit.circuit.country.continent.name;
``

works without problems which are under the covers the same entity classes.

Is there any explanation why this is failing or a possible workaround?

I just encountered the same issue in my model.
I get a NullPointerException when calling upisaniPredmet.upisaniElement.upis.student.
upisaniPredmet.upisaniElement is not null.
upisaniPredmet.upisaniElement.upis is not null.
upisaniPredmet.upisaniElement.upis.student is null.

I have exactly the same problem. Must be the bug

+1

any solutions? facing it too.

Same here, expected this just to work out of the box :(

Please give us the answer,thank you verymuch.

@POJOa Thank you very much :)

Someone managed to resolve the error? I have the same problem.

@lucasfrederico
By default Querydsl initializes only reference properties of the first two levels. In cases where longer initialization paths are required, these have to be annotated in the domain types via com.mysema.query.annotations.QueryInit annotations. QueryInit is used on properties where deep initializations are needed.
http://www.querydsl.com/static/querydsl/3.5.0/reference/html/ch03s03.html#d0e2181

Hey, sorry to bump this old thread but I'm facing the same problem. Is there a fix for this?

There is no fix for this, and it will likely not get fixed because initializing paths so deep is incredibly computationally expensive. As a result, QueryInits from referenced classes are not used transitively, so you have to specify the QueryInits where you want them.
If you want to initialise the path QPosting.posting.payment.bill.contract.buyer you will explicitly have to initialise it, as such:
@Entity @QueryEntity class Posting {
    @ManyToOne @QueryInit("*.*", "bill.contract.buyer") Payment payment;
}

That said, there is one known issue regarding path initialisation, and that one is related to entities that implement Comparable. That issue is described in #2572 and I have suggested a fix in  #2573.


Add AsMemory and AsSpan to StringSegment

With Span and Memory on the rise we should look at bridging our existing types over to those types.

@davidfowl do you mean something like
public ReadOnlySpan<char> AsSpan() => Buffer.AsReadOnlySpan(Offset, Length);
public ReadOnlyMemory<char> AsMemory() => Buffer.AsReadOnlyMemory(Offset, Length);

and maybe Ctor-overloads that accept Span<char> to create a StringSegment of an existing span?
For methods like StringSegment.IndexOf a Span-based version could be faster -- would need some tests therefore (this should be a separate PR anyway).


Allow decimal inputs/outputs in auction form, and rename "Price" to "Output" to avoid confusion

Rather than renaming "Price" to "Output", can we change "Min" to "Min Output" and "Max" to "Max Output"? That way the place that currently says "Price" can have the label for Swap/Auction, next to the Estimate button.


Run Selection doesn't work for neither F9 nor "Shift + return". It works fine for Jupyter notebook but not for Spyder

Issue Report Checklist

[ ] Searched the issues page for similar reports
[ ] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
[ ] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
[ ] Could not reproduce inside jupyter qtconsole (if console-related)
[ ] Tried basic troubleshooting (if a bug/error)

[ ] Restarted Spyder
[ ] Reset preferences with spyder --reset
[ ] Reinstalled the latest version of Anaconda
[ ] Tried the other applicable steps from the Troubleshooting Guide

[ ] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description
What steps reproduce the problem?

What is the expected output? What do you see instead?
Paste Traceback/Error Below (if applicable)

PASTE TRACEBACK HERE

Versions

Spyder version: 4.0.1
Python version: 3.0
Qt version:
PyQt version:
Operating System name/version: Mac

Dependencies

PASTE DEPENDENCIES HERE

I restart the spyder and it works


Integrate LLVM at llvm/llvm-project@95019de8a122

Update BUILD files and submodule for
95019de8a122

Only the last commit is part of this PR. Will rebase before merging.


Cdk drive customers api

Please check the following conditions for your PR.

[ ] apiDefinition.swagger.json is validated using paconn validate command.
[ ] apiProperties.json has a valid brand color. Invalid brand colors are #007ee5 and #ffffff.

@amancdk Could you please resolve the conflicts?

Resolved the conflicts. Thank you


fix: UI port in dockerfile set to same port in config

SUMMARY
Superset ui port set in dockerfile is wrong. That causes healthcheck fails and ui not work in docker deployments .
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

@craig-rueda Compose file in repo works fine since SUPERSET_PORT already redefined in .env file. Problem occurs when you build your own docker-compose. Because image exposes wrong port , you have to define  SUPERSET_PORT. I think image should work fine with default environment values.


Update Matrix exercise to use real newlines

The description of this exercise talks about the data coming in with rows being separated by newlines, but in PHP, newlines are only newlines if they are in double quotes. Unfortunately, all the tests and the example solution are using the string '\n'. This PR updates the incoming string inputs to be double quoted so the newlines are actually newlines.
I've updated the tests and the example and it all appears to be working.

Good good, nice catch/update.  I think we can ignore the configlet warning for now, but I've asked @ErikSchierboom in slack. My concern is that because the config.json fails the configlet check, this fix will not get sync'd to the website.

It looks like it's expecting it to be listed as a slug in the config.json (along with a bunch of others). I am assuming if we add those then that starts making concepts show up on the PHP track, but we're probably not ready for that yet?

Yea, I'm not sure if it will or not. In php's config.json we have concept exercises set to false, so maybe this isn't a concern.
I think getting this fix merged is important though, would you mind adding those concepts to the config.json? If you are on mac/Linux running uuidgen in the terminal will generate a new UUID.

Yeah, I can do that - I guess I'd prefer to do that in another PR since it's unrelated to these changes. I can probably get to it a bit later this afternoon.

Sure, ya, this one or a new one -- up to you.

I was looking at what this structure should look like based on the Go track - it looks like it's expecting an exercise for the concepts which I don't think we have.

I am able to get configlet lint to pass with this PR: https://github.com/exercism/php/pull/453
I am sure it will need to be updated when we get more into implementing the concepts... concept.


Error while installing: " unable to build kubernetes objects from release manifest"

Dears,
After following your instructions:
helm repo add datastax-pulsar https://datastax.github.io/pulsar-helm-chart
helm repo update
curl -LOs https://datastax.github.io/pulsar-helm-chart/examples/dev-values.yaml
helm install pulsar -f dev-values.yaml datastax-pulsar/pulsar

I get this:
$ helm install pulsar -f dev-values.yaml datastax-pulsar/pulsar
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(Prometheus.spec): unknown field "probeNamespaceSelector" in com.coreos.monitoring.v1.Prometheus.spec, ValidationError(Prometheus.spec): unknown field "probeSelector" in com.coreos.monitoring.v1.Prometheus.spec, ValidationError(Prometheus.spec): unknown field "shards" in com.coreos.monitoring.v1.Prometheus.spec]

Is there a bug in your templates ?
Regards

Using a fresh install I didn't see this issue, I'm guessing you have something out of sync locally.  The error message looks like it's coming from the kube-prometheus-stack, do you have a local version of this?


If a viewtab is dragged over the + sign, it is dropped and the 'new view' dialog opens

This is caused by CMainFrame::OnChangingTab, the OnChangingTab is also trigger when dragging another tab on top of the "+" -tab.
I have looked into this, but could not think of an easy solution, as this is not really blocking any functionality, I'll leave it be for now

There was not obvious solution in code, so for now we removed the + tab


RecentClips is unsupported

It appears that the manager is only picking up files that contains 'event.json'
However, the recent clips does not contain such file, so it's not being converted

You are right.  I'll see if I can fix that, probably by just looking at .mp4 files instead.

Has been fixed with b40699a, I believe. I also tagged the docker images
simonkagstrom/tesla_dashcam_manager:4
simonkagstrom/tesla_dashcam_manager:latest
with these changes.


Navigating to the root url in the html template demo

In the html template demo, the root url in my case is localhost:8080. When I typed localhost:8080/foo in the address bar, I got the same default page which is fine. But in that case I'd like to reset the url to localhost:8080.
I tried using router.navigate(window.location.origin) but it doesn't work (I get localhost:8080/foo/#!localhost:8080) Setting absolute path doesn't work either. Is it possible to do this with #! in navigo? Thanks.

Hey @chungvle,
I decided to support only the next version of Navigo. Which is 8.0.0 and it will be released on the first days of 2021. That new version doesn't support the hash based routing. Only absolute paths. So, can you try with that version by installing it via npm install navigo@beta. You should simply use router.navigate('/').
P.S
I'm trying to start fresh on the new version 8.0.0. If you try it and still doesn't work let me know and I'll reopen the issue.


[ISSUE #3371] Fix stack overflow exception when set message mode

Make sure set the target branch to develop
What is the purpose of the change
issue #3371
Brief changelog
XX
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage decreased (-0.08%) to 53.123% when pulling d60eb4a0f431042048cd8608bbb2ba6435a8a62d on maixiaohai:fix_stackoverflow_when_set_message_mode into 48d3c7eeba3d6658de10b5d8fd5890b513a16eb5 on apache:5.0.0-preview.


fuzz: converting object to non-static due to fuzzer OOM

Commit Message: fuzz: converting object to non-static due to fuzzer OOM
Additional Description:
The fuzzer used a static object that kept some internal objects, and caused the fuzz tests to eventually OOM.
Risk Level: low - tests only
Testing: Added corpus entry.
Docs Changes: N/A.
Release Notes: N/A.
Platform Specific Features: N/A.
Fixes fuzz issue 55105
Signed-off-by: Adi Suissa-Peleg<EMAIL_ADDRESS>

/assign @tyxia


Choose the most meaningful detection

This is to be done with the actual system that gives you scores and not with a transference learnt neural network.
You have a top_class_name and a list of predictions.
From that build a list with the class names and do not include there the ones to be ignored.
Grab the first occurrence and use it as a suffix.

https://github.com/eulersson/taconez/blob/9a369455f9efcc78196b9c8d94520ca9398053b7/sound-detector/sound_detector.py#L420-L430


Win Module Share Bar Style Update

Fixes #4987
Set a width on the campaign author info and the share bar so that longer campaign author titles will wrap and they will always stay next to each other at larger breakpoints.
@DoSomething/front-end

:art: :ship:


utils: added days to formatTime

This time a pull request without issues...

@derrod you just missed your tests cases.

 ( I mean, seeking for days )


[Support] Determining ActivityStreams at root level

if you'd like to help, let me know

Hello,
I've built a userscript that converts JSON Feed into an readable HTML.
I'm adding support for ActivityStreams.
I can determine if a file is of JSON Feed by looking into json_file.version, but not so in GNU social (StatusNet) ActivityStream feeds.
If I'm missing anything, please guide me.
Thank you,
Schimon

Look for "@context": "https://www.w3.org/ns/activitystreams" or something similar.

On Mon, 27 Nov 2023 20:51:33 -0800
Evan Prodromou @.***> wrote:

Look for @.***": "https://www.w3.org/ns/activitystreams"` or
something similar.

The StatusNet (GNU social) document has these:
"generator":"GNU social 2.0.0-dev",
"title":"Federati Nu: Federated N-series GNU Social public timeline",
"totalItems":20,

"generator" is the only identifier, yet is a specific identifier.
See https://nu.federati.net/api/statuses/public_timeline.as
Would it be correct to assume that the ActivityStream feeds of
GNU social lack some attributes?

See https://notabug.org/diogo/gnu-social/issues/298


Possible Enhancement: Make DrawTargets Debuggable

Version of embedded-graphics in use (if applicable): 0.6-beta2
Target: [simulator]

Description of the problem/feature request/other
Make DrawTarget a Supertrait of Debug to be able to debug/print/log/... the new error type.
Test case (if applicable)
use embedded_graphics::pixelcolor::BinaryColor::{Off as White, On as Black};
use embedded_graphics::{
    drawable::Drawable,
    fonts::*,
    geometry::Point,
    pixelcolor::BinaryColor,
    style::{TextStyle, TextStyleBuilder},
    text_style, DrawTarget,
};
use log::*;

pub fn draw_text<T: DrawTarget<BinaryColor>, F: Copy + Font>(
    display: &mut T,
    text: &str,
    top_left: Point,
    font: F,
) {
    if let Err(e) = Text::new(text, top_left)
        .into_styled(text_style!(
            font = font,
            text_color = Black,
            background_color = White
        ))
        .draw(display)
    {
        //println!("Error: {:?}", e);
        //log::error!("Error: {:?}", e)
        //write!("Error: {:?}", e);
        //...
    }
}

Maybe I'm missing something, but why does DrawTarget need to be a supertrait of Debug to be able to output an error? Isn't it enough when DrawTarget::Error implements Debug?

No, I think you are right

IMO adding a Debug trait bound to Error shouldn't be necessary either. In your example you could add where T::Error: Debug to be able to output the error for a generic DrawTarget. Or do you have a special use case in mind where the trait bound in e-g itself is required?

Thanks thats already enough :-)


Clearer warning message

Old warning message:

Do not use 'unimplemented' with '@DependencyClient'; it is a replacement and implements the same runtime functionality as 'unimplemented' at compile time

This was confusing because it was not clear what “it” referred to, nor what was a “replacement” for what.
New warning message:

Do not use 'unimplemented' with '@DependencyEndpoint'; the '@DependencyEndpoint' macro provides an 'unimplemented' default value for you.

I also added a period at the end, but I can remove it if it’s not consistent with project style.

Updated with workshopped message.


uploader: invalid_mime_type responds with 422 instead of 415

Bug report

[x] I confirm this is a bug with Supabase, not with my own application.
[x] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug
On failing MIME type validation, upload throws a StorageBackendError with status code set to 422.
Additional context
A more suitable status code might be 415, as per RFC9110.

@imageck thanks for this, we'll amend the status code!

This is now being fixed


pandas json

Implement https://pandas.pydata.org/docs/reference/io.html#json as a data saver/loader.
It should go into pandas_extensions.py, one class for the writer, on class for the reader, e.g. much like how this pandas pickle reader and writer are structured.
There should be requisite tests to exercise the functionality.
Then an example should be added to the example/pandas/materialization example.

i can start taking a look at this issue

Completed with #346


Mark product as returnable

@nishant-cyro @priyank-gupta  We should have an option to mark a product as returnable. Only returnable product should be requested for return / exchange

@akhil - Thanks for the suggestion, we will include it in our next version.

@nishant-cyro - Done in PR #21


Pre-condition Violation in QueryAtom.GetSmarts()

Description:

RDKit Version: 2019.03.1
Platform: Mac OS

The GetSmarts method of a QueryAtom object raises a "Pre-condition Violation":
>>> from rdkit.Chem import rdqueries
>>> qatom = rdqueries.AtomNumEqualsQueryAtom(6)
>>> qatom.GetSymbol()
'*'
>>> qatom.GetSmarts()
[10:50:05]

****
Pre-condition Violation
no owner
Violation occurred on line 124 in file /Users/glandrum/anaconda5/conda-bld/rdkit_1554778814548/work/Code/GraphMol/Atom.h
Failed Expression: dp_mol
****

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: Pre-condition Violation
        no owner
        Violation occurred on line 124 in file Code/GraphMol/Atom.h
        Failed Expression: dp_mol
        RDKIT: 2019.03.1
        BOOST: 1_67

This piece of code did work with a previous version of RDKit (although I did not remember exactly which one).
As a workaround, it is possible to extract an "already created" QueryAtom from a RDKIt Mol created :
>>> from rdkit.Chem import MolFromSmarts
>>> m = MolFromSmarts('[*]')
>>> qatom = m.GetAtomWithIdx(0)
>>> qatom.GetSymbol()
'*'
>>> qatom.GetSmarts()
'*'

Thanks!

Confirmed. Thanks for the report.

This started with the fix for #1756.


Show default workspace rooms

Details

Make the default #announce and #admins rooms show up immediately after creating a new workspace. Also, when the workspace is deleted update the room names to show that they have been deleted. For more context see the design doc here.
Deleting workspaces currently doesn't work on IOS and Android. See the issue here.
Fixed Issues

$ https://github.com/Expensify/App/issues/5946
Tests

Log in with a brand new account
Create a workspace from the green plus button at the bottom left.
Check for the #announce and #admins rooms in the left hand navigation.

For all platforms except iOS and Android:

Go to Settings > Workspace
Click the three dots in the header and select delete workspace, and confirm delete.
Confirm that the room names change to #announce (deleted) and #admins (deleted)

[ ] Verify that no errors appear in the JS console

QA Steps

Same as tests above.

[ ] Verify that no errors appear in the JS console

Tested On

[ ] Web
[ ] Mobile Web
[ ] Desktop
[ ] iOS
[ ] Android

Screenshots

Web

Mobile Web

Desktop

iOS

Android

Following QA steps, seems like creating a new workspace has doubled the default workspace rooms.

@nickmurray47
Based on the design doc I think that is the expected behavior. Each work space gets its own #announce and #admins rooms.  You can see in the subtext which workspace they belong to. I do think it's a bit clunky to have multiple default rooms especially if they both have a default workspace name, but we can always change that down the road. How do you think that should be handled?
I also edited the testing steps to clarify that a brand new account should be used and one workspace should be created with the green plus button.

ok, thanks for the explanation @neil-marcellini! The code lgtm as far as I can tell but also going to loop in the design doc author just to confirm this is the expected behavior.

I do think it's a bit clunky to have multiple default rooms especially if they both have a default workspace name

Yeah, so there's going to be default rooms for the user when they sign up which will have the same names as the default rooms for the first workspace that's created? It was confusing to me on first run-through.

Yeah, so there's going to be default rooms for the user when they sign up which will have the same names as the default rooms for the first workspace that's created? It was confusing to me on the first run-through because I'd expect the default rooms for a user to not exist at all then, i.e. the default rooms should only be there once a workspace is created.

When I make new accounts there are no default rooms and no workspace until you press the button to create a workspace. Could you please test again?

Yeah @nickmurray47 I would guess those default rooms are from some other corporate policy that account has open. They're not getting created with new accounts, right?

When I make new accounts there are no default rooms and no workspace until you press the button to create a workspace. Could you please test again?

Interesting, will re-test again and see if there's any difference. This was with a brand-new account so would assume it was not under any old policies.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@neil-marcellini  Should it be tested on All platforms?

🚀 Deployed to staging by @nickmurray47 in version: 1.1.32-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by @roryabraham in version: 1.1.33-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅