new.target type is too narrow

Bug Report
🔎 Search Terms
new.target, narrow
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about new.target

⏯ Playground Link
Playground link with relevant code
💻 Code
class AssertionError extends Error {
    name = "AssertionError";
}

function assert(
    boolean: boolean,
    message: string = "Assertion failed",
): asserts boolean {
    if (!boolean) {
        throw new AssertionError(message);
    }
}

type PathInit = {
    isRooted: boolean,
    parts: ReadonlyArray<string>,
};

type AbsolutePathLike = AbsolutePath | `/${ string }`;
type PathLike = Path | string;

abstract class Path {
    static parse(path: `/${ string }`): AbsolutePath;
    static parse(path: string): AbsolutePath | RelativePath;
    static parse(path: string): AbsolutePath | RelativePath {
        const isRooted = path.startsWith("/");
        if (isRooted) {
            return new AbsolutePath(path.slice(1).split("/"));
        }
        return new RelativePath(path.split("/"));
    }
    static from(path: AbsolutePathLike): AbsolutePath;
    static from(path: RelativePath): RelativePath;
    static from(path: PathLike): AbsolutePath | RelativePath;
    static from(path: PathLike): AbsolutePath | RelativePath {
        if (typeof path === "string") {
            return Path.parse(path);
        }
        return path;
    }
    static join(
        first: RelativePath,
        ...paths: Array<PathLike>
    ): RelativePath;
    static join(
        first: AbsolutePathLike,
        ...paths: Array<PathLike>
    ): AbsolutePath;
    static join(
        first: PathLike,
        ...paths: Array<PathLike>
    ): AbsolutePath | RelativePath;
    static join(
        first: PathLike,
        ...paths: Array<PathLike>
    ): AbsolutePath | RelativePath {
        first = Path.from(first);
        const allPaths = [first, ...paths].map((path) => Path.from(path));
        if (first.isAbsolute()) {
            return new AbsolutePath(
                allPaths.flatMap((path) => path.#parts),
            );
        }
        assert(first.isRelative());
        return new RelativePath(
            allPaths.flatMap((path) => path.#parts),
        );
    }
    readonly #isRooted: boolean;
    readonly #parts: ReadonlyArray<string>;
    constructor({
        isRooted,
        parts,
    }: PathInit) {
        if (new.target !== AbsolutePath
        && new.target !== RelativePath) {
            throw new TypeError("Path should not be constructed directly");
        }
        const realParts: Array<string> = [];
        for (const part of parts) {
            if (part.includes("/")) {
                throw new RangeError(`path segments may not contain "/" characters`);
            } else if (part === "." || part === "") {
                continue;
            } else {
                realParts.push(part);
            }
        }
        this.#isRooted = isRooted;
        this.#parts = Object.freeze(realParts);
    }
    isAbsolute(): this is AbsolutePath {
        return this.#isRooted;
    }
    isRelative(): this is RelativePath {
        return !this.#isRooted;
    }
    #toString(): string {
        let path = this.#parts.join("/");
        if (this.#isRooted) {
            path = `/${ path }`;
        }
        return path;
    }
    get path(): string {
        return this.#toString();
    }
    get parts(): ReadonlyArray<string> {
        return this.#parts;
    }
}
class RelativePath extends Path {
    constructor(parts: ReadonlyArray<string>) {
        super({
            isRooted: false,
            parts,
        });
    }
}
class AbsolutePath extends Path {
    constructor(parts: ReadonlyArray<string>) {
        super({
            isRooted: true,
            parts,
        });
    }
    get fileURL(): string {
        const url = new URL("file://");
        url.pathname = `/${ this.parts.map((part) => encodeURIComponent(part)).join("/") }`;
        return url.href;
    }
}

🙁 Actual behavior
The value of new.target is too narrow as it does not actually allow proper subclasses to assume the value of new.target despite this being entirely possible. This is because, in this case, typeof Path has an incompatible construct signature with typeof AbsolutePath/RelativePath.
🙂 Expected behavior
In general subclasses can be expected to change the signature of the constructor, this is a core part of class-based OO, hence new.target type is overspecified.
I think the simplest resolution would be to simply widen new.target to new (...args: any[]) => this, as the only thing guaranteed about a subclass signature is that it will return an instance of this.

Smaller example that's not as motivating, but it demonstrates the issue in a minimal way:
class Class {
    constructor(x: number) {
        // This condition will always return 'false' since the types 'typeof Class' and 'typeof Subclass' have no overlap.
        if (new.target === Subclass) {

        }
    }
}

class Subclass extends Class {
    constructor(arg: [number, number]) {
        super(arg[0]);
    }
}

Just for the record, this works:
if (new.target !== Class) {}

which is probably how I would write it anyway, since as you hinted at in the OP, unless you control the entire hierarchy, your class doesn't know what its subclasses are going to do or even what all of them are.

From TypeScript's perspective, there's nothing different between this code and the "obviously-wrong" comparison Path === AbsolutePath. The only theoretically-grounded fix would be to make all constructors secretly generic so we could introduce a hidden constrained type parameter to represent the type of new.target, but the performance implications of this would be quite expensive. The upside - avoiding one type assertion - isn't particularly high given how often this comes up.
That said, we might be able to tweak the "can you compare X to Y" rule to allow this. @DanielRosenwasser , any thoughts?

The only theoretically-grounded fix would be to make all constructors secretly generic so we could introduce a hidden constrained type parameter to represent the type of new.target

I'm confused as to why one couldn't just set new.target equal to the type new (...args: any[]) => this (or perhaps even the wider type new (...args: any[]) => Path. This doesn't seem like it should require any hidden generic, just a redefinition of what new.target.
Like we can already define the type itself within the constructor:
class Path {
    constructor() {
        type NewTarget = new (...args: any[]) => this;
    }
}

The fix would just be to set new.target to this type, rather than to the current class.

Actually I realise the correct type is actually just new (...args: any[]) => Path, not even requiring the ``thiscostraint. THis is because in general you don't know what subtype you'll be getting fromnew.target` alone.

this in that position is effectively a hidden generic - that's how this parameters are implemented

Actually I realise the correct type is actually just new (...args: any[]) => Path

new.target.staticMember should be legal. The type is (an arbitrary subtype, sort of, of)-typeof Path

new.target.staticMember should be legal. The type is (an arbitrary subtype, sort of, of)-typeof Path

Admittedly I had never noticed that subclasses overriding static members with unrelated types is an error (I suppose because I've never done it). Given this though, doesn't our type just become:
type Base__NewTarget = {
    // This obliterates the construct signature from (typeof Base), admittedly I do not
    // know if there is an easier way to remove the call/construct signatures
    [K in keyof typeof Base]: (typeof Base)[K]
} & {
    new (...args: any[]): Base;
};

class Base {
    static isBase(value: any): value is Base {
        return #tag in value;
    }

    readonly #tag = true;

    constructor(arg: number) {
        // fine
        const newTarget: Base__NewTarget = new.target;

        // Allowed
        newTarget === Sub;

        // works
        newTarget.isBase(3);
    }
}

class Sub extends Base {
    constructor(arg: string /* incompatible with Base's arg */) {
        super(Number(arg));
    }
}

I dunno how the internals of TS work, but this type is again already definable so it feels like TypeScript should be able to define new.target equivalently.

We could maybe imagine something like that. Another approach is to say that instead of checking for a some form of compatibility from each type (a relationship check that we call comparability today), we could try another approach where we just check whether the intersection of both sides of a type form a non-empty type. I think @ahejlsberg and @weswigham have brought up in the past.
The problem with that is that almost every single object type ruins this. An object type forms a non-empty intersection with almost everything.
To start, here's a questionable example:
interface Equalalable {
    equals(other: unknown): boolean;
}

interface Barkable {
    bark(): void;
}

declare const dog: Barkable;
declare const horse: Equalalable;

function foo(dog: Barkable, horse: Equalalable) {
    // Not allowed today, would be allowed under intersection rules.
    if (dog === horse) {
        // ...
    }
}

This produces runnable JavaScript, but questionable. The object hierarchies theoretically overlap, but this has the chance to catch logic errors today across unrelated types.
Here's a severely questionable example.
interface TrafficLight {
    state: "red" | "green" | "yellow"
}

function drive(trafficLight: TrafficLight) {
    // Not allowed today, would be allowed under intersection rules.
    if (trafficLight !== "red") {
        // ...
    }
}

This also produces runnable JavaScript, but the if block will always run. That's because the intersection of "red" and TrafficLight is considered non-vacuous. We assume "red" & TrafficLight is a type that can exist (and while it technically can, we all know that's bogus for all practical purposes).
So I think intersection takes us to the other extreme of having no guarantees in === checks.
Maybe we could

vary this behavior on a strict-mode flag? (seems questionable)
special-case how literals form intersections for this operation?

Both seem like areas we could experiment in.


Some device cannot seem to detect badger

Realme 7 pro

Stale ticket. Closing it till we can confirm it's still relevant.


Please configure product custom options and fix the validation errors

I have vuestore configured along with products imported via mage2vuestorefront .
This is magento2 for a optical vision store, so each product has custom options like "Right-sphere" , "Left-sphere" etc. which user has to specify power etc. before selecting an item. In M2 it shows the dropdown for each option.
However in vue-storefront I can see the default options like size, color etc., but all the custom options show these errors at the top - "Please configure product custom options and fix the validation errors.", and next to each field name I see the below error - "Field is required." , with no dropdown to select the power etc.
I was unable to find anything in the previous issues regarding this, so I have opened as a new issue.

Hi! Thanks for this issue! We're currently supporting just a basic types of the configurable options:
https://github.com/DivanteLtd/vue-storefront/blob/master/core/components/ProductCustomOptions.js
https://github.com/DivanteLtd/vue-storefront/blob/master/src/themes/default/components/core/ProductCustomOptions.vue
It seems like Your options types differs from "radio", "select" neither "checkbox".
So You probably should extend this feature a little bit for Your case

Thanks, for some reason github took 20 hours your reply to be visible on my end.
I can see in the code that "select" dropdowns don't seem to be covered. Will attempt to change the code on my end and send a PR in when I get it to work with default theme

This is a simplistic patch for the default theme that enables support for "drop_down" custom options. This is apparently different from "select" which the theme already has code for.
In this patch had elected to use a custom ProductOptions.js within the theme itself.
This is mainly for the reference of anyone else who faced problems with their "drop_down" product options.
1.05-productoptions-patch.txt

Cool! How about including this change in the core? Would be great if you will be willing to test it a little bit and send us a Pull Requst?

@chetan-prime let me know what do you think about it?

Sure, will do a PR in a day or two. I am checking on my end for the correct vue classes to use to make the select look better


Adjust events polling filter to handle edge case

Description
The problem:
In the new LKE Node Pool display, I noticed that after creating a new cluster the Node Rows weren’t always updated with the Linode’s status once provisioned. A few of the nodes might be displayed as "Powered off", even though the Linodes were running.
The cause:
After studying the polled requests to /events during this sequence, I realized this was happening because we weren't receiving all events from the API. And if we don’t receive a completed linode_boot event, for example, we don’t update the Linode’s status.
So why aren’t we receiving all events from the API? A little context on how we poll /events...
When we receive a batch of events, we find the most recent created time. We use that timestamp in a filter like this:
{ "created": { "+gt": <mostRecentCreatedTime> } }

This means we won’t receive any events created on or before the most recent created time. If there are events still in progress, we add an "+or" clause, like this:
{
  "+or": [
    { "created": { "+gt": <mostRecentCreatedTime> } },
    { "+or": [{ "id":<inProgressEventId> }] }
  ]
}

This approach works fine for most cases. But as it turns out, there is a potential dead zone.
Consider the case where there are four events with the same created time (let’s say 2020-04-08T12:00:00). It turns out, this is likely with something like LKE cluster provisioning.
If the request/query lands at just the right time, you may only see the first 3 of these events. Since subsequent /events requests have a filter on created being greater than 2020-04-08T12:00:00, we’ll never see the 4th event! (unless the app is refreshed). This means the UI might not update appropriately.
My solution:
To solve this, I’ve changed the "+gt" filter to "+gte". Any (non-in-progress) events created at the mostRecentCreated time will be excluded via "+neq" filter.
Bottom line:
Instead of polling /events with a filter like this:
{ "created": { "+gt": <mostRecentCreatedTime> } }

We poll with a filter that looks like this:
{
  "+and": [
    { "created": { "+gte": <mostRecentEventTime> } },
    { "id": { "+neq": <mostRecentEventId> } }
  ]
}

Check the new test cases for variations for in-progress events.
Note to Reviewers
Most of the app should function like before.
To see the bug that started this thing, provision a new LKE cluster with at least 6 nodes.

I think I understand the bug you're describing, but why is this necessary: { "id": { "+neq": <mostRecentEventId> } }?
is it just to save the effort of retrieving and parsing that event which you know you've already seen?

is it just to save the effort of retrieving and parsing that event which you know you've already seen?

Yeah, pretty much. Without it we'd be grabbing the same event(s) over and over from the API, and we'd have to change a lot of other logic that depends on events (or lack thereof) coming back after each request.


On Unsent Entries/Pages, "Unpublish" doesn't appear on status setting screen.

Steps:

Create an unpublished entry.
On app, go to Edit Entry of the unpublished entry, make sure the status is "Unpublish".
Save it to local.
Go to Unsent Entries > Edit Entry of the unpublished entry.
Tap status.

Expected: You can find "Unpublish" is checked.
Observed: "Unpublish" doesn't exist, and any status isn't checked.

ストレージ保存時に非公開かどうかの情報を保存忘れしていました。
こちら修正します。

修正しました

@cmatsuo build 106

verified fix.


LIMIT offset/count values from bind variable (array)?

My Environment

ArangoDB Version:        3.7.3
Storage Engine:             RocksDB
Deployment Mode:       Single Server
Operating System:        Ubuntu 20.04
Total RAM in your machine:        256GB
Disks in use:        SSD

Component, Query & Data
Affected feature:
AQL Query
AQL query (if applicable):
This is a very contrived example, but it shows my question:
FOR item IN @items
    FOR i IN 1..100
        LIMIT item.quantity
        RETURN i

Here is the bind variables used:
{
  "items": [
    {
      "part_number": "000555",
      "quantity": 5
    }
  ]
}

AQL explain and/or profile (if applicable):
I receive the following error when attempting to use this query:
Query: AQL: LIMIT offset/count values must be constant numeric values (while instantiating plan)
Steps to reproduce

Run the above query with using the above bind variables.

Problem:
The example above is very contrived, but it shows an issue that I was encountering while trying to build my API.  The actual query that I am working on loops through an array of items, filters the data by a few parameters and then returns a number of records limited by the value present in the loop - this value can be different for each iteration.
Providing a value such as 5 as a bind variable works perfectly fine, but when using the value from an array it throws an error.
Expected result:
For the example above, I would have expected the result to look like:
[
  [
    1,
    2,
    3,
    4,
    5
  ]
]

Question:
This is likely by design, and there is likely no way that I can perform this exact query - but are there any alternative solutions you'd recommend?

There seems to be a misconception here. The LIMIT is not applied to a specific loop, but to its whole input.
The LIMIT arguments have to be known at compile time, and that's by design.
You could write it like this instead, I guess that's what you mean:
FOR item IN @items
    FOR i IN 1..item.quantity
        RETURN i

Thank you for clearing that up, I wrongfully assumed that LIMIT could be applied in other ways.  Your alternative solution will likely work for me.  Thanks again.


add $.asyncBalloon to support balloons with lazily-loaded content

This PR adds a new method, $target.asyncBalloon, which takes the boilerplate out of implementing balloons whose content is loaded asynchronously. It takes an asynchronous function which yields an options object, which is then used to register and display a balloon for the target.
The function can yield the options object either via a callback:
$target.asyncBalloon(balloon => {
    $.get(url, json => {
        let contents = JSON.parse(json)
        let options = $.extend({ contents }, BALLOON_OPTIONS)
        balloon(options)
    })
})

or by returning a promise:
$target.asyncBalloon(() => {
    return fetch(url).then(res => res.json()).then(contents => {
        let options = $.extend({ contents }, BALLOON_OPTIONS)
        return options
    })
})

On second thoughts, this would be better implemented as an extension to the current options so that it can take advantage of the support for displaying a spinner/loading message before the content loads.
Not sure what the name should be: ajax, async?
$target.balloon({
    contents: 'Loading...',
    ajax (balloon) {
        let contents = JSON.parse(json)
        let options = $.extend({ contents }, BALLOON_OPTIONS)
        balloon(options)
    }
})

or:
$target.balloon({
    contents: 'Loading...',
    async () {
        return fetch(url).then(res => res.json()).then(contents => {
            let options = $.extend({ contents }, BALLOON_OPTIONS)
            return options
        })
    }
})


data-placeholder expression instead of string

Hi,
is it possible to pass an expression to data-placeholder instead of a simple string? It'd be very handy working with i18n applications, and in conjunction with, for instance,  angular translate.
Thanks for the great directive!

I always use an expression like this:
data-placeholder="{{ 'projects.edit' | translate }}"

Any solution to this issue?

@develup: I tried both unsuccesfully.
@lpsBetty: is it working for you? I wasn't able to. I'm always getting the default Chosen placeholder text.
I recenlty got back to the project which orginated this issue. I updated the libs to these versions:

chosen => 1.4.2
angular-chosen-localytics => 1.0.7

I've encountered the same behaviour still, so I decided to modify angular-chosen-localytics source in order to have a quick fix. Just edit chosen.js:

New line 50

  defaultText = (attr.placeholderExpression !== undefined) ? attr.placeholderExpression : null;

New line 57

return defaultText = (defaultText) ? defaultText : chosen.default_text;

Here you'll find an example of html markup with the newly placeholder-expression attribute:
<select multiple chosen ng-model="selectModel" ng-options="item.id as item.name for item in selectOptions" placeholder-expression="{{'SELECT_SOMETHING' | translate}}"></select>

Cheers,
Luca

@lanceschi yes it is working, I install chosen with bower, don't know what version of chosen is used:
├─┬ angular-chosen-localytics#1.0.7
│ ├── angular#1.3.15 (1.4.0-build.3954+sha.9dfa949 available)
│ └── chosen#e-tag:face03d32

@lpsBetty: you're right. I made a codepen. Translated placeholder works, simple expression doesn't. In my app I'm using the same library versions. The only difference is the size. I don't know for sure, albeit it may be related to the asyncronous nature of translation process ...

The pull request in #115 enables the use of interpolation in config attributes.

@darlanalves: big thx! Btw, why does it work in the codepen I posted in this thread?

@lanceschi I'm not sure. I've tried using exactly the same thing, a interpolation in the data-placeholder attribute, but the chosen plugin gathered the literal value, including the brackets, instead of the interpolated value.
So I've read the angular-chosen code and seems it keeps the attributes in sync with the chosen plugin options, but the directive evaluates anything on custom attributes, such as placeholder-text-single, which is also an issue for me.
My pull request only checks if the attribute starts with "{{" and uses the interpolated value instead of evaluate it. Maybe it is something in the chosen version used within the directive.

I was having the same issue on one of  my views.
I was having two chosen controls (cascading) and it wasn't working ..
When I use resolve (angular ui-router)  the placeholders from the translation started to work and load normally!

One time it only worked when my array was available! So I added ng-if="array" to the <select chosen
Hope this helps!


JWT refresh-token contains former base64 encoded refresh-token in JTI

I have an issue using JWT refresh-tokens. As you know, the JWT refresh-token contains two IDs (jti and ati). Using the “password” grant-type for authorization returns two tokens (access-token and refresh-token). The access-token contains a jti and the refresh-token contains another jti and an ati. Both jti’s are strings like “e2492e9c-ae6e-474c-ba2d-bebd14bb8b4f” and the ati of the refresh-token equals the jti of the access-token. Here is everything as it is supposed to be. But if I use the refresh-token grant-type the jti of the refresh-token is not a random string anymore, it’s the base64 encoded JWT value of the former refresh-token. I can’t imagine that this is the intended behavior.
Since I don’t use the jti in my project, I just recognized this behavior because of a HeadersTooLargeException. Using the refresh-token multiple times in a row nests all the encoded former refresh-tokens in the new tokens jti. So it grows extremely large and becomes too large for the webresponse.
The jti is set by refreshTokenInfo.put(TOKEN_ID, encodedRefreshToken.getValue()); in the enhance(OAuth2AccessToken accessToken, OAuth2Authentication authentication) method of the JwtAccessTokenConverter.

+1 this is a problem for me to

I ran into this problem when I had multiple JwtAccessTokenConverters in the enhancer chain. I haven't investigated very deeply, but after bringing the number of converters down to 1 the problem disappeared.


proposal: cmd/go: add a flag to use stdin as a cancellation side-channel

The go command executes a lot of subprocesses as it runs, including:

the Go compiler and linker, and in cgo-enabled builds the C compiler and linker,
version-control tools to download modules that aren't available from a proxy,
the vet tool to analyze programs,
test binaries built for packages under go test and go test -fuzz=., and
binaries executed by go run (#54868 notwithstanding).

Some clients of the go command end up starting a command, letting it run a while, and then wanting to cancel its execution. For example, gopls may start running go list to evaluate a program being edited, but then cancel that command due to another edit to the files in the user's workspace or a failure in some other concurrent processing that renders the go list result irrelevant.
If the go process itself is forcibly terminated using os.Kill (via either (*os.Process).Kill or exec.CommandContext), its subprocesses may continue to execute for an arbitrarily long time, leaking resources and (on Windows, at least) potentially preventing cleanup of temporary files and directories.
On Unix platforms, we can instead request a clean shutdown using os.Interrupt. (The go command may or may not respond appropriately to that signal today, but in principle it can and that's what matters in terms of the public-facing API.) However, os.Interrupt does not work on Windows, and per discussion on #6720 and #46345 we don't know of a general way to make it work. (At the very least, it would require os/exec to make invasive and likely-incompatible assumptions about consoles and process groups.)
Since os.Kill leaks resources and os.Interrupt isn't always available, we need some other way to request cancellation of a running go command.
Fortunately, we have a way out: as far as I am aware, every platform that supports os/exec in Go also supports inter-process pipes, and cmd/go to my knowledge does not use stdin for anything today.

I propose that we add a new flag to the go command, -stdin=keepalive, that will cause it to read from (and discard bytes from) stdin until EOF, then make a best effort to cancel all subprocesses, clean up, and exit as soon as possible.
The choice of -stdin=keepalive leaves open the possibility of using stdin in other ways in the future, while being clear about both its role (“keepalive”) and mechanism (“stdin”).
(CC @golang/tools-team)

Operating systems do allow for creating a child process in a way that it doesn't leave any orphan behind when killed.
On Linux, the standard way is to call prctl(PR_SET_PDEATHSIG, SIGKILL); after fork, before exec. On Windows, you create a job with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE and assign the project to that job.
The fact that we can't do either of the above with exec.Command and the fact that we have a clear use case that needs it, seems to point to the direction of adding this capability to exec.Command, rather than providing a ad-hoc workaround that requires writing, debugging, testing and maintaining code that does cleanups which kernels are better at doing.

That functionality is already available via syscall.SysProcAttr for systems that support it.  Unfortunately, not all systems support it, so I don't see a feasible way to add it to the os/exec package.  In particular, it's not supported on MacOS, which is a widely used Go development platform.

How would this work with 'go run', which delegates its stdin/out/err to the target process?

@rasky

rather than providing a ad-hoc workaround that requires writing, debugging, testing and maintaining code that does cleanups which kernels are better at doing.

I see several problems with that approach:

The steps to perform a clean shutdown may involve more than just killing processes. (For example, they may include deleting temporary files or directories.) So even if we chain the processes that way, we still don't get a completely clean shutdown.
It isn't obvious that that approach is even possible on all platforms that support cmd/go. (Notably, I don't see a way to do it on macOS, Solaris, or Plan 9.)
If we did try to use platform-specific cleanup mechanisms, we would need to test and debug each different mechanism. That can be much more involved than testing and debugging one platform-independent mechanism even if that one mechanism is somewhat more complex than any individual platform's platform-specific approach.

We did use the platform-specific approach for file locking in the module cache, but there we didn't have a clean cross-platform alternative. Here we do.

@adonovan

How would this work with 'go run', which delegates its stdin/out/err to the target process?

Ideally go run should exec the requested program instead of running it as a subprocess (that's #54868), and then it would be up to that program to watch the keepalive from there. (You wouldn't be able to pipe actual data to such a program because go run --stdin=keepalive would swallow some arbitrary number of leading bytes, but you could at least use the same “open pipe” mechanism for both cmd/go and the underlying program.)
In the interim, on platforms that support SetDeadline for pipes I think we could arrange for cmd/go to stop reading from the pipe just before starting the subprocess, so that any data sent on stdin after the subprocess writes to stdout or stderr would correctly go to the subprocess. But that also seems like something of an edge-case...

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

should the libraries be individually updated to utilize the new flag/pipe?

I suspect this thread was at least in part motivated by some of the cancellation problems we've seen in gopls, which uses go/packages, so I expect we would update that go/packages (actually its internal go-command helper package) to use the new mechanism.

Will there be any way to wire this through os/exec

The parent process would set exec.Cmd.Stdin to an open file descriptor (os.File) returned by, say, os.Pipe, and then close the other end of it in response to context cancellation. It might be useful for the flag documentation to link to an example of the correct code (in the absence of a standard package that would host it).

Can we use this with go test too? It's rare to write a test utilizing stdin but nothing prevents using it.

A test that defines its own main can do whatever it wants with stdin---a similar situation to 'go run'.

If the flag is added, should the libraries be individually updated to utilize the new flag/pipe?

Yes!

Will there be any way to wire this through os/exec, or should there be a special package only for go command execution?

That's #50436, for which I am hoping to merge an implementation next week (assuming that the API revisions are approved).

It seems like we should disallow go run -stdin=keepalive.
The keepalive only makes sense when stdin is going to send zero bytes and then close.
There's no good answer for what to do if stdin has real data on it.

Disallowing go run -stdin=keepalive seems fine for now.
(I can think of reasonable ways one might use it, but use-cases are pretty niche and the implementation is simpler without it.)

Does anyone object to making this change?

I think this is a good idea. Perhaps a bit surprising to use this stdin mechanism directly, but I also don't imagine many people will need to do that themselves, instead relying on go/packages or not needing proper cancellation in practice.
Out of curiosity, doesn't the same problem bubble up to programs like gopls? I understand that the LSP protocol has a "stop" message which is a stand-in for os.Interrupt, so that's likely enough. For other programs which need to gracefully cancel cmd/go, they might need to also support the same stdin cancellation mechanism for their users.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group


Use leveldb2 database by default for new databases

PR Description
Switch default format for new databases to leveldb2.  Does not affect existing databases which will continue to use RocksDB.
Also fixed deprecation warnings in ForkChoiceStrategyTest because I thought it was doing something specific and started there before investigating further - turns out it just needed the updates to InMemoryStorageSystemBuilder.
Fixed Issue(s)
fixes #3881
Documentation

[x] I thought about documentation and added the documentation label to this PR if updates are required.

Changelog

[x] I thought about adding a changelog entry, and added one if I deemed necessary.

Documentation wise on this one it may be useful to have some docs a) clarifying that existing databases are unaffected and continue to be supported, and b) explaining how to delete the db and resync if people do want to switch to leveldb now.
Better migration tools will be provided in future releases but for nodes using "prune" mode, the migration is quick and simple:

Download the latest finalized state curl -o state.ssz -H 'Accept: application/octet-stream' http://other-node:5051/eth/v1/debug/beacon/states/finalized
Stop teku
Delete the beacon directory under your data-path.  Make sure not to delete the validator directory if one is present which contains your slashing protection data
Start teku with the --initial-state state.ssz option to start from the finalized state you just downloaded. A new leveldb database will be created and teku will start from that recent state and should be back in sync and validating within a couple of minutes.


'electron-builder' is not recognized as an internal or external command, operable program or batch file.

Hi everyone
I try to compile the program on Windows and I lack something. What should I do? I just installed node.js and never needed to do anything similar on Windows.
'electron-builder' is not recognized as an internal or external command,
operable program or batch file.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>build-win: `electron-builder -w`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>build-win script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above
npm WARN Local package.json exists, but node_modules missing, did you mean to install?

What should I have installed first?

@Nocxy If you just want to use the program you can simply download the installer, no need to compile it. Here is a link to compiled/built windows 64bit version Click to download
However if you want to compile it yourself or make any changes to it, let me know, I will reply accordingly.

I saw the direct download options and I already tried it but I would like to know how I could compile it on my own. What are the requirements ?


Removes script tag from public/index.html preview. It's not required

See #76

Same comment as on #79, therefore I cannot except.


Register and document scheduler.alpha.kubernetes.io/tolerationsWhitelist annotation

This is a Bug Report

Problem:
Kubernetes has alpha support for an annotation scheduler.alpha.kubernetes.io/tolerationsWhitelist ; however, this is not registered or documented.
Proposed Solution:

register the annotation
document it

We can achieve both of these by updating Well-Known Labels, Annotations and Taints with information about the annotation.
Page to Update:
https://kubernetes.io/docs/reference/labels-annotations-taints/

Additional Information:
We should document this name even though WG Naming have recommended avoiding the term “whitelist”. After documenting it, the next step could be to deprecate the annotation, or to make a new, non-alpha annotation that has a different name.
/language en
/kind bug
/sig scheduling
/lifecycle frozen

Also see #34212

/triage accepted

Relevant to https://github.com/kubernetes/kubernetes/issues/90277

/assign

@PriyanshuAhlawat Are you working on this issue? Do you need any help?

@NitishKumar06 yes I am working on it.

Need any help from my side?

No as of now

@PriyanshuAhlawat I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on 🙂
/unassign @PriyanshuAhlawat

I found this issue while going through Admission Controllers Reference and trying to learn more about these annotations.
I have raised a PR regarding same  here: #40403 PTAL!
Also, how to proceed with this?

the next step could be to deprecate the annotation, or to make a new, non-alpha annotation that has a different name.


CSS Mirroring Not Working in WSL

Environment (please complete the following information):

OS: Windows 11 WSL - Ubuntu
Extension version: 2.1.2

Describe the bug:

Trying to change CSS properties has no effect on the linked CSS file in VS code.
Repro steps:

Start any server in WSL and open it in the extension's browser.
Change any CSS property in the DevTools panel that has a link to the stylesheet you're editing in VS Code.
Expected behavior:

Expected the updated devtools styles to reflect in VS Code (CSS Mirroring feature).
Additional context:

This was mentioned in feedback for the initial CSS Mirroring issue (#476), but I wasn't able to find any comments addressing it or references to it in the pinned Known Issues (#1317). Is this something that isn't planned on being fixed? Thanks for everything!

Thanks for reporting this. Let me copy your message over to #436 and close this issue, because I believe they're duplicate.


Android keyboard appears

On Android, when the selector is touched, the keyboard input appears. I suspect this is because the generated input is of type="text"
			<selectize  ng-model="filters.min_bedrooms"
						options="[
								{title:'0', id:0},
								{title:'1', id:1},
								{title:'2', id:2},
								]">
			</selectize>

Generates:
    <input type="text" autocomplete="off" tabindex="" style="width: 4px; opacity: 0; position: absolute; left: -10000px;">

This behavior is the result of the underlying jQuery selectize plugin. So it's not something I can change since this repo is just an Angular wrapper around the jQuery plugin.


HadoopShell jobtype and property override documentation

Documenting user-facing aspects of hadoopShell jobtype and uncovering mysteries of property overrides in azkaban.

@logiclord looks great to me.
Do you mind responding to other reviewers' comments so that we can merge this change soon.
Since the HadoopShell job type is similar to the Hadoop Java job type, what do you think about just referencing the Hadoop java job type documentation and only highlight the differences. This way the documentation is not duplicated and it makes future updates to the common portion easier. However there are benefits of reading one job types's configuration in one place.
Thanks!

Hi folks.
Thanks for the feedback. I have incorporated all the feedbacks. I have kept a separate reading section of hadoopShell for easy understanding. Otherwise, it will be hard for many users to understand that HadoopShell is a wrapper on top of HadoopJava.
Can you please have a look ?


Getting error in saavn_downloader.py

 Enter link : https://www.jiosaavn.com/song/o-saathi-humsafar/OiEDR0cBcwY

 Enter bitrate( default:256 ) : 256
Traceback (most recent call last):
  File "C:/Users/amail101/Music/jio-saavu-downloader-master/Saavn/Saavn_Downloader.py", line 27, in <module>
    qq = s.find_all('div', id="header")[0]
IndexError: list index out of range

Process finished with exit code 1

Thanls

 Enter link : https://www.jiosaavn.com/song/o-saathi-humsafar/OiEDR0cBcwY

 Enter bitrate( default:256 ) : 256
Traceback (most recent call last):
  File "C:/Users/amail101/Music/jio-saavu-downloader-master/Saavn/Saavn_Downloader.py", line 27, in <module>
    qq = s.find_all('div', id="header")[0]
IndexError: list index out of range

Process finished with exit code 1

Thanks for identifying that , i will fix this soon 👍

 Enter link : https://www.jiosaavn.com/song/o-saathi-humsafar/OiEDR0cBcwY

 Enter bitrate( default:256 ) : 256
Traceback (most recent call last):
  File "C:/Users/amail101/Music/jio-saavu-downloader-master/Saavn/Saavn_Downloader.py", line 27, in <module>
    qq = s.find_all('div', id="header")[0]
IndexError: list index out of range

Process finished with exit code 1

Fixed Just clone latest one 👇👇👇
https://github.com/dedshit/jio-saavu-downloader/


Track the global focus state of the UI

Closes https://github.com/emilk/egui/issues/1845.

Another option would be to make the Focus::id field pub(crate) (I have to do that anyway on my AccessKit branch), then replace Memory::has_focus with a new Context::has_focus function that checks both the memory and raw input. Then Response::has_focus can simply call Context::has_focus. Of course, I'd have to fix the widgets that directly call Memory::has_focus, but it would be more consistent that way.

@mwcampbell I like that approach!

@emilk On closer investigation, I don't think my suggested solution will work. The most obvious reason is that other functions in Memory call Memory::has_focus. So I would at least have to keep that function and make it internal or pub(crate). But also, in some cases where Memory::has_focus is used, we don't want the outcome to depend on whether the window has focus. For example, if you put a DragValue into keyboard editing mode, then move focus away from the window, then come back, you probably don't want the DragValue to switch to a button in the meantime. So I think I just have to document the difference between Response::has_focus and Memory::has_focus, or even add a second function in Response that takes global focus into account. Sometimes widgets really should check the global focus, e.g. when determining whether to render a border around a text edit.

Let's just go with added docstrings for now!


Website Design

Website shipped! http://avs.auto so we can consider this done until we want to do another pass.


Add SR-IOV support for Intel NICs

This is an initial PR to provide Intel SR-IOV support in Antrea:

API support added to configure Intel 700/800 series NICs in pod scope.
Intel SR-IOV VFs are meant to be configured as secondary interface.
Does not configure OVS flows. (VFRepresenter not supported)

Codecov Report

Merging #2151 (1a05c0d) into main (3b294ea) will decrease coverage by 20.70%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##             main    #2151       +/-   ##
===========================================
- Coverage   61.71%   41.01%   -20.71%
===========================================
  Files         262      133      -129
  Lines       19560    16669     -2891
===========================================
- Hits        12072     6837     -5235
- Misses       6236     9246     +3010
+ Partials     1252      586      -666

Flag
Coverage Δ

kind-e2e-tests
?

unit-tests
41.01% <0.00%> (-0.42%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.


Dynamic Sensitivity

It would be cool feature if the sensitivity could adjust itself depending on player's set volume.
Currently using this to achieve something similar with Spotify:
[Rainmeter]
Update=1000
AccurateText=1

[Metadata]
Author=Jack'lul

[Dummy]
Meter=STRING
X=0
Y=0

[getSpotifyPID]
Measure=Plugin
Plugin=Perfmon.dll
PerfMonObject="Process"
PerfMonCounter="ID Process"
PerfMonInstance=Spotify
PerfMonDifference=0

[isSpotifyRunning]
Measure=Calc
Formula=getSpotifyPID > 0 ? 1 : 0
IfEqualValue=0
IfEqualAction=!Execute [!DeactivateConfig "Monstercat-Visualizer\Song Information" "Spotify.ini"][!DeactivateConfig "Monstercat-Visualizer" "visualizer.ini""]
IfAboveAction=!Execute [!ActivateConfig "Monstercat-Visualizer\Song Information" "Spotify.ini"][!ActivateConfig "Monstercat-Visualizer" "visualizer.ini"]

[getSpotifyVolume]
Measure=Plugin
Plugin=SpotifyPlugin.dll
Type=Volume

[adjustVisualizerSensitivty]
Measure=Calc
Formula=[getSpotifyVolume]
DynamicVariables=1
IfCondition=([getSpotifyVolume] <= 10)
IfTrueAction=[!WriteKeyValue Variables Sensitivity 120 "#SKINSPATH#\Monstercat-Visualizer\@Resources\variables.ini"][!RefreshGroup "Spectrum"]
IfCondition2=([getSpotifyVolume] > 10) && ([getSpotifyVolume] <= 20)
IfTrueAction2=[!WriteKeyValue Variables Sensitivity 100 "#SKINSPATH#\Monstercat-Visualizer\@Resources\variables.ini"][!RefreshGroup "Spectrum"]
IfCondition3=([getSpotifyVolume] > 20) && ([getSpotifyVolume] <= 30)
IfTrueAction3=[!WriteKeyValue Variables Sensitivity 80 "#SKINSPATH#\Monstercat-Visualizer\@Resources\variables.ini"][!RefreshGroup "Spectrum"]
IfCondition4=([getSpotifyVolume] > 30) && ([getSpotifyVolume] <= 40)
IfTrueAction4=[!WriteKeyValue Variables Sensitivity 70 "#SKINSPATH#\Monstercat-Visualizer\@Resources\variables.ini"][!RefreshGroup "Spectrum"]
IfCondition5=([getSpotifyVolume] > 40) && ([getSpotifyVolume] <= 50)
IfTrueAction5=[!WriteKeyValue Variables Sensitivity 60 "#SKINSPATH#\Monstercat-Visualizer\@Resources\variables.ini"][!RefreshGroup "Spectrum"]
IfCondition6=([getSpotifyVolume] > 50) && ([getSpotifyVolume] <= 60)
IfTrueAction6=[!WriteKeyValue Variables Sensitivity 50 "#SKINSPATH#\Monstercat-Visualizer\@Resources\variables.ini"][!RefreshGroup "Spectrum"]
IfCondition7=([getSpotifyVolume] > 60) && ([getSpotifyVolume] <= 80)
IfTrueAction7=[!WriteKeyValue Variables Sensitivity 40 "#SKINSPATH#\Monstercat-Visualizer\@Resources\variables.ini"][!RefreshGroup "Spectrum"]
IfCondition8=([getSpotifyVolume] > 80)
IfTrueAction8=[!WriteKeyValue Variables Sensitivity 30 "#SKINSPATH#\Monstercat-Visualizer\@Resources\variables.ini"][!RefreshGroup "Spectrum"]

(This also disables visualizer when Spotify is not running - might also consider a feature like this?)
But it would be cool if user could specify 'min' and 'max' value and it would autoscale depending on volume!
And thanks for making this visualizer skin, it's awesome. 👍

Hey, thanks for your request.
On first glance your code seems pretty cool, but it's limited to Spotify. The big problem is player support right now, where not every player supports the volume variable and also not every player outputs the same value. So it's quite hard to do it consistently.
I'm gonna keep this issue open for now but if i can't find a proper solution i will close this issue. Maybe someone with some rainmeter knowledge can jump in here and propose a proper solution.

I know my plugin supports volume, but I am not sure what how many of the NowPlaying players support it and what the default value is in the ones that dont. If the default value is 100 then we can safely add it. The bigger issue will be potentially when the player is closed.

Ok, thats one first thing but how consistent are those values between the players? Because for example 50 in AIMP is not the same as 50 in Spotify.

Updated to better way of doing this:
MaxSensitivity = set at volume 0, kinda pointless
MinSensitivity = as the volume goes up makes sensitivity never go below this value
[Rainmeter]
Update=1000

[Variables]
MinSensitivity=30
MaxSensitivity=120

[Dummy]
Meter=STRING

[getSpotifyVolume]
Measure=Plugin
Plugin=SpotifyPlugin.dll
Type=Volume

[calculateVisualizerSensitivity]
Measure=Calc
Formula=((100 - [getSpotifyVolume]) / 100) * #MaxSensitivity#
DynamicVariables=1

[adjustVisualizerSensitivity]
Measure=Calc
Formula=([calculateVisualizerSensitivity] >= #MinSensitivity#) ? (([calculateVisualizerSensitivity] <= #MaxSensitivity#) ? [calculateVisualizerSensitivity] : #MaxSensitivity#) : #MinSensitivity#
DynamicVariables=1
OnChangeAction=[!WriteKeyValue Variables Sensitivity "[adjustVisualizerSensitivity]" "#SKINSPATH#\Monstercat-Visualizer\@Resources\variables.ini"][!RefreshGroup "Spectrum"]

I have decided to close this issue for now, because there is sadly no constant way to dynamically adjust the sensitivity via volume for now.
I will reopen the issue if there will be an easier way to do this in the future.


Rust improvements

[ ] Fix invalid JSON in header comments
[ ] Optionally emit top-level marshaling functions
[ ] Improve header comments

[ ] Only show how to deserialize JSON (no need to show going back to string)
[ ] Don't use extra empty lines between statements
[ ] Use actual top-level type names in sample

[ ] Optionally omit redundant rename attributes when property name and JSON name match (dense mode)

cc @krk @Phrohdoh

The invalid JSON mentioned is here and should be let json = r#"{"answer": 42}"#;.

@Phrohdoh would you like to submit a PR to improve the header comments? There's a lot of easy wins there.

To add:

The serialization code part isn't copy-pasteable currently as it imports serde_json but that part actually requires serde_derive. It would work if they copied all of the code though so maybe that's okay, but I imagine some people may not know that they need to import serde_derive in their library code. Playpen example of it compiling with the change
It looks like the header comment improvements can be ticked off

I'd submit a patch for the first point myself but when I cloned the repo and tried running tests without modification they took way too long on my machine (with only the rust fixtures). Unsure if that's a problem with my configuration or not but thought it's worth mentioning.

@Ryman FIXTURE=rust npm test will generate and test a couple hundred Rust programs. Do individual tests take longer than expected or the entire test suite or both?

@dvdsgl Is it possible that we're downloading and re-compiling all Rust dependencies for each test case?

@Ryman FIXTURE=rust npm test will generate and test a couple hundred Rust programs. Do individual tests take longer than expected or the entire test suite or both?

It was the entire rust test suit afaik, the first 4 or so tests ran... relatively quick then 20 or so more would take many many minutes more, I don't have access to my laptop where I can run it right now to check though. It definitely felt like it was compiling more than necessary.

@Ryman the test slowness is fixed now

@dvdsgl Hey, sorry for the delay, I looked into the compile times a little and some of your generated types, when passed to serde are creating 40k+ lines of code (post macro expansion, try using cargo-expand if you want to see) with 30k of them being in a single method which rustc chokes badly on in translation (you can see this on a nightly compiler by setting RUSTFLAGS=-Ztime-passes. I had hoped to look into improving the codegen for serde and it seems to be a known problem on the issue tracker but I haven't been successful this week.
I'd advise that you skip some of your tests such as this one unless you enable some "extra-tests" feature or something which CI would enable, it should make local development nicer :) Or maybe it could just be an error to try to quicktype pathalogical inputs? What do you think?

@Ryman yes, thank you for the analysis and we agree that we need to split up some of our test data that needlessly requires target languages to emit absurdly large types: #559

Closing this.  But please keep submitting Rust PRs!


LibWeb: Shadow Realm integration - part 2

Second stage of shadow realm integration into LibWeb sitting ontop of https://github.com/LadybirdBrowser/ladybird/pull/1927
The step after this is to change HTML::Script to operate on realm's instead of environment setting objects. After that, we should then be able to hook up the VM hook to actually initialize the shadow realm global object - which is enough for the test case of:
<script>
async function test() {
    const realm = new ShadowRealm()
    const aSync = realm.evaluate(`async () => 1 + 1`)
    aSync()
}

test();
</script>

To not crash :^)

Pre-review comment: I remember Luke Warlow mentioning in discord that the example there is supposed to throw, do we handle that yet? or is that later :)

Pushed rebase to fix de conflict


Fixed version check in wrong directory

If the library is built as a subdirectory, the current CMake code extracts the version number of the parent project instead (if available). Git command must be invoked in the current source directory.
The remaining occurrences of CMAKE_SOURCE_DIR in the project concern installer creation which is probably fine.

Hi @neojaw,
Thank you for your contribution! It seems like you need to rebase your branch to the last version of main. Or were you hoping to provide a patch to an older release version? Your PR currently contains 527 changes.

Hi @lola-masson, my PR was based on the latest main, it seems to me like @BigBoot did force pushes in your repo and now my fork is out of sync?
This branch is 1823 commits ahead of, 1919 commits behind ifm/ifm3d:main.

I'll try to rebase it...

Hi @neojaw yes you're correct we had to force push due to an issue with the sync from our internal repo. I can merge you're changes manually if you're ok with that?

Nevermind, already fixed it. Looks good now.


permission denied, mkdir '/usr/local/lib/node_modules/nw-builder/cache'

You're not supposed to write to root's directories. Many developers won't have root permissions in enterprises.
Latest Version: v0.37.4
Using v0.37.4 (sdk)
{ Error: EACCES: permission denied, mkdir '/usr/local/lib/node_modules/nw-builder/cache'
    at Object.fs.mkdirSync (fs.js:885:18)
    at mkdirsSync (/usr/local/lib/node_modules/nw-builder/node_modules/fs-extra/lib/mkdirs/mkdirs-sync.js:29:9)
    at mkdirsSync (/usr/local/lib/node_modules/nw-builder/node_modules/fs-extra/lib/mkdirs/mkdirs-sync.js:35:16)
    at Object.mkdirsSync (/usr/local/lib/node_modules/nw-builder/node_modules/fs-extra/lib/mkdirs/mkdirs-sync.js:35:16)
    at /usr/local/lib/node_modules/nw-builder/lib/index.js:298:12
    at /usr/local/lib/node_modules/nw-builder/lib/index.js:800:16
    at /usr/local/lib/node_modules/nw-builder/node_modules/lodash/lodash.js:4911:15
    at baseForOwn (/usr/local/lib/node_modules/nw-builder/node_modules/lodash/lodash.js:2996:24)
    at /usr/local/lib/node_modules/nw-builder/node_modules/lodash/lodash.js:4880:18
    at Function.forEach (/usr/local/lib/node_modules/nw-builder/node_modules/lodash/lodash.js:9344:14)
  errno: -13,
  code: 'EACCES',
  syscall: 'mkdir',
  path: '/usr/local/lib/node_modules/nw-builder/cache' }

use sudo if you are on linux, ex: sudo nwbuild -p win64 ./

use sudo if you are on linux, ex: sudo nwbuild -p win64 ./

You're not supposed to write to root's directories. Many developers won't have root permissions in enterprises.

I see where you're coming from that it is bad practice and an attack vector. I haven't run into this issue myself - I run Ubuntu using WSL. I think the solution would be installing in a directory which does not require sudo. You could use chmod to change the relevant permissions for the directory you install it in?

On second look, #289 may be related.

Closing this in favour of #623.


CVE fixes - Upgrade mpi-operator

What type of PR is this?
/kind bug

What this PR does / why we need it:
Upgrade dependencies to resolve CVEs of High severity:

https://www.cve.org/CVERecord?id=CVE-2023-45142
https://www.cve.org/CVERecord?id=CVE-2023-45288

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

@ChristianZaccaria Could you address this error?

sigs.k8s.io/kueue/pkg/util/testingjobs/mpijob

../../../../../pkg/util/testingjobs/mpijob/wrappers_mpijob.go:46:21: cannot use map[kubeflow.MPIReplicaType]common.ReplicaSpec{…} (value of type map[v2beta1.MPIReplicaType]"github.com/kubeflow/common/pkg/apis/common/v1".ReplicaSpec) as map[v2beta1.MPIReplicaType]*v2beta1.ReplicaSpec value in struct literal

/retest

/retest

FYI: Even if you don't comment /retest, the prow jobs are triggered by new push events.

/remove-kind bug
/kind cleanup


APPS-1280-fix-enum-symbol-parsing

This PR is use regex instead of symbolNames helper function in cwljava.

Oh, interesting. Is there a problem with the Java code for shortname?


Configcheck pods are not cleaned-up

Describe the bug:
Configcheck pods are not cleaned-up on success.
Expected behaviour:
Old succesful configcheck pods are deleted once the configuration is applied.
Steps to reproduce the bug:

Deploy a Logging CR and an Output object.
Edit the Output object with a valid configuration.

Environment details:

Kubernetes version (e.g. v1.15.2): 1.20.9
Cloud-provider/provisioner (e.g. AKS, GKE, EKS, PKE etc): RKE
logging-operator version (e.g. 2.1.1): 3.17.3
Install method (e.g. helm or static manifests): helm

References:

https://github.com/banzaicloud/logging-operator/blob/master/pkg/resources/fluentd/fluentd.go#L141
https://github.com/banzaicloud/logging-operator/blob/master/pkg/resources/fluentd/appconfigmap.go#L142

/kind bug

Configcheck secrets are not cleaned up too. I have ~5000 useless secrets in my logging-operator namespace...

Can you help me with a configuration that could help me reproduce this issue?

It looks like it's ok now. I'll reopen this issue if I found I'm still impacted. Thanks @pepov


Ruruku binary should know its version

At the moment a ruruku binary cannot tell its own version - this is no good. The ruruku binary should be able to tell its own version, as well as the one of the server it's connected to.

I think ruruku should even expose its version in the web interface.


Build TF 1.8 from source on Windows not working

Please make sure that this is a build/installation issue. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:build_template
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Windows 8.1 64
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary): 1.8
TensorFlow version: 1.8
Python version: 3.6
Installed using virtualenv? pip? conda?: pip & conda
Bazel version (if compiling from source): 2.1.0
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version: 9.0 7.1
GPU model and memory: NVIDIA GeForce GTX 760 compting capabilities 3.0 that's the reason why...

Describe the problem Hello, I've followed the instructions on this page: https://www.tensorflow.org/install/source_windows#gpu
And when I enter bazel build --config=v1 //tensorflow/tools/pip_package:build_pip_package
the result is:
PS P:\anaconda3\tensorflow>
PS P:\anaconda3\tensorflow> bazel build --config=v1 //tensorflow/tools/pip_package:build_pip_package
WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one o
f the standard rc files:
p:\anaconda3\tensorflow/tools/bazel.rc
WARNING: Ignoring JAVA_HOME, because it must point to a JDK, not a JRE.
INFO: Options provided by the client:
Inherited 'common' options: --isatty=0 --terminal_columns=120
INFO: Options provided by the client:
'build' options: --python_path=p:/Anaconda3/python.exe
INFO: Reading rc options for 'build' from p:\anaconda3\tensorflow\bazel.rc:
'build' options: --define framework_shared_object=true --define=use_fast_cpp_protos=true --define=allow_oversize_proto
s=true --define=grpc_no_ares=true --spawn_strategy=standalone --genrule_strategy=standalone -c opt
INFO: Reading rc options for 'build' from p:\anaconda3\tensorflow.tf_configure.bazelrc:
'build' options: --action_env PYTHON_BIN_PATH=p:/Anaconda3/python.exe --action_env PYTHON_LIB_PATH=p:/Anaconda3/lib/si
te-packages --force_python=py3 --host_force_python=py3 --python_path=p:/Anaconda3/python.exe --define with_xla_support=t
rue --define with_gdr_support=true --define with_verbs_support=true --action_env TF_NEED_OPENCL_SYCL=0 --action_env TF_N
EED_CUDA=1 --action_env CUDA_TOOLKIT_PATH=C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v9.1 --action_env TF_CUDA_V
ERSION=9.1 --action_env CUDNN_INSTALL_PATH=C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v9.1 --action_env TF_CUDNN
VERSION=7 --action_env TF_CUDA_COMPUTE_CAPABILITIES=3.0 --action_env TF_CUDA_CLANG=0 --action_env CUDA_PATH=C:/Program
Files/NVIDIA GPU Computing Toolkit/CUDA/v9.1 --action_env CUDA_COMPUTE_CAPABILITIE=None --action_env NO_WHOLE_ARCHIVE_OP
TION=1 --config=win-cuda --define grpc_no_ares=true --copt=-DGEMMLOWP_ALLOW_SLOW_SCALAR_FALLBACK --host_copt=-DGEMMLOWP
ALLOW_SLOW_SCALAR_FALLBACK --config monolithic --copt=-w --host_copt=-w --verbose_failures
INFO: Found applicable config definition build:win-cuda in file p:\anaconda3\tensorflow\bazel.rc: --define=using_cuda=tr
ue --define=using_cuda_nvcc=true
INFO: Found applicable config definition build:monolithic in file p:\anaconda3\tensorflow\bazel.rc: --define framework_s
hared_object=false
ERROR: Config value v1 is not defined in any .rc file
PS P:\anaconda3\tensorflow>
Provide the exact sequence of commands / steps that you executed before running into the problem bazel build --config=v1 //tensorflow/tools/pip_package:build_pip_package
Thanks for your help!
Best regards,
François
Any other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

@amahendrakar Hello, I've not read this doc enough, my bazel version was wrong. Now, I have the 0.10.0rc. Things are different but not better ...
Thanks for your help!
PS P:\anaconda3\tensorflow> bazel build --config=v1 //tensorflow/tools/pip_package:build_pip_package
WARNING: Config values are not defined in any .rc file: v1
Loading:
Loading: 0 packages loaded
ERROR: Skipping '//tensorflow/tools/pip_package:build_pip_package': error loading package 'tensorflow/tools/pip_package'
: Encountered error while reading extension file 'cuda/build_defs.bzl': no such package '@local_config_cuda//cuda': Trac
eback (most recent call last):
File "P:/anaconda3/tensorflow/third_party/gpus/cuda_configure.bzl", line 1142
_create_local_cuda_repository(repository_ctx)
File "P:/anaconda3/tensorflow/third_party/gpus/cuda_configure.bzl", line 995, in _create_local_cuda_repository
_get_cuda_config(repository_ctx)
File "P:/anaconda3/tensorflow/third_party/gpus/cuda_configure.bzl", line 747, in _get_cuda_config
_cuda_toolkit_path(repository_ctx)
File "P:/anaconda3/tensorflow/third_party/gpus/cuda_configure.bzl", line 282, in _cuda_toolkit_path
repository_ctx.path(cuda_toolkit_path).exists
Illegal char <:> at index 90: C:/users/francois/appdata/local/temp/bazel_francois/wkog3ss7/external/local_config_cuda/C
:Program FilesNVIDIA GPU Computing ToolkitCUDAv9.0
WARNING: Target pattern parsing failed.
ERROR: error loading package 'tensorflow/tools/pip_package': Encountered error while reading extension file 'cuda/build
defs.bzl': no such package '@local_config_cuda//cuda': Traceback (most recent call last):
File "P:/anaconda3/tensorflow/third_party/gpus/cuda_configure.bzl", line 1142
_create_local_cuda_repository(repository_ctx)
File "P:/anaconda3/tensorflow/third_party/gpus/cuda_configure.bzl", line 995, in _create_local_cuda_repository
_get_cuda_config(repository_ctx)
File "P:/anaconda3/tensorflow/third_party/gpus/cuda_configure.bzl", line 747, in _get_cuda_config
_cuda_toolkit_path(repository_ctx)
File "P:/anaconda3/tensorflow/third_party/gpus/cuda_configure.bzl", line 282, in _cuda_toolkit_path
repository_ctx.path(cuda_toolkit_path).exists
Illegal char <:> at index 90: C:/users/francois/appdata/local/temp/_bazel_francois/wkog3ss7/external/local_config_cuda/C
:Program FilesNVIDIA GPU Computing ToolkitCUDAv9.0
INFO: Elapsed time: 0,476s
FAILED: Build did NOT complete successfully (0 packages loaded)
PS P:\anaconda3\tensorflow> bazel version
Build label: 0.10.0rc1
Build target: bazel-out/x64_windows-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Sat Jun 5 11:32:18 +50010<PHONE_NUMBER>538)
Build timestamp:<PHONE_NUMBER>538
Build timestamp as int:<PHONE_NUMBER>538
PS P:\anaconda3\tensorflow>

@FB43
As per the configurations, please refer to this link which shows you would have to use cmake instead of bazel, is here any specific reason to use 1.8, could you use a later version of tensorflow.
For your second error:
Could you please refer to this link and let us know if it helps.

@Saduf2019 hello, sorry, when I was working I often missed those things as many people. Now, I'm retired but nothing changes!
So, I have Python 3.6, Bazel 0.10.0, MSVC 2015 update 3 (2014), Cmake v3.6.3, GCC 4.8, MSYS2, Chocolatey, Anaconda3 (where I want to build TF). And other things, of course.
The reason why I want to install TF 1.8 is that my GPU has 3.0 computing capabilities.
I need it to run some functions of the Visions of Chaos software (free and interesting).
If an other version could run (or be recompiled) for 3.0, I'll take it, I just want the better version for my GPU (not the moment for changing it...).
Now, I have the tools, but I'm lost.
What to do now?
If you can help me a little bit more, it will be much appreciated.
Thanks for all.
Best regards,
François

@Saduf2019 Hello, I opened a new issue to get some advices for changing my GPU. I think the results would be better.
Thanks for all.
François

@FB43
Please confirm if we may move this issue to resolved, as the GPU change is monitored and this would be a duplicate issue.


How can I add a new page to the navigation bar?

Thank you for provide this clean and elegant themes.
But I wander how can I add new pages such as about page to the navigation bar?
Just like this:

Should I add something to the theme?
And how can I route to mysite.com/newpage with certain ejs files?

how can I add new pages such as about page?

Run hexo new page Your_Page_Name, and you can get a new folder（your new page） in the source folder.
More: https://hexo.io/zh-cn/docs/writing.html

add to the navigation bar?

Checkout this doc: How to customize the navigation bar ?

Thanks a lot! That works~


add-Contributing file

add contributing.md file
attach in README.md

Rebased, and merged.
Thanks for your contribution !


Is not working on mobile?

Hi, I am testing in pc and mobile with firefox and it is working 100% in PC, but it doesnt works in mobile

Normally it works but it depends on the css you've made or the configuration... Nonetheless you'll have to provide me with a URL or a JSFiddle and the mobile platform's characteristics.


Parsing issues do not report the parsed file

Issues in parsing raised by ANTLR indicate messages looking like the following:
line 19:3 extraneous input '(variable' expecting {WS, AT_KW, PARAMETER_KW}
line 19:13 extraneous input 'oscar' expecting {WS, AT_KW, PARAMETER_KW}
<Java stack trace>

At no point is the file containing these lines indicated, making it difficult to locate the issue.

This should now be working properly.

It has improved, but there are still cases where the location of the issue isn't pointed out in any other detail than the file in which it occurred. This isn't enough.

Example of case where the reported error doesn't help enough: writing (cond 42).

Still an issue in 050e329f2a2e2367c2e4f1965190b0f6a5addf29. When the parser invalidates the input or when there is a Java error, it is still rather hard to figure out exactly what part of the narrative is causing the issue.


Integration Test - Release - 2019/06/04 19:01:47

Auto create for integration test. AnotherAuthorUpdatedArticleFlow

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


Add save_as_dot for logic circuits

The function save_as_dot is defined in src/IO/IO.jl, but not implemented. This patch simply adapts the equivalent function save_as_dot defined in ProbabilisticCircuits (https://github.com/Juice-jl/ProbabilisticCircuits.jl/blob/master/src/IO/CircuitSaver.jl) but for LogicCircuits.
Obviously this isn't the best approach to solving this issue, as ideally we should have these two save_as_dot functions call some other more general function. But this would require changing how nodes are printed (perhaps adding a printdot method for each node and simply calling it instead of having two different save_as_dot functions with a bunch of if and elses?) or changing how nodes are typed (in the sense disjunction and conjunction nodes would have a common ancestor, e.g. \bigveeNode and Prob\bigveeNode would be subtypes of DisjunctionNode or whatever).
There is another flaw to this implementation as well: structured nodes are unsupported. Since I'm only working (so far) with the regular Logical\DeltaNodes, and I'm not so familiar with this library yet, I'm choosing to keep it the way it is for now.
Added a test case for the function as well. Not sure the right way of doing it, so will be happy to fix if needed.

Codecov Report

Merging #6 into master will increase coverage by 0.82%.
The diff coverage is 92.15%.

@@            Coverage Diff             @@
##           master       #6      +/-   ##
==========================================
+ Coverage   60.82%   61.64%   +0.82%
==========================================
  Files          26       26
  Lines        1889     1940      +51
==========================================
+ Hits         1149     1196      +47
- Misses        740      744       +4

Impacted Files
Coverage Δ

src/IO/CircuitSaver.jl
89.41% <92.15%> (+4.11%)
:arrow_up:

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 10a1de9...c83bbf6. Read the comment docs.

The code looks good to me, made few small changes. Will wait for the tests.
Yeah, it makes lots of sense not to want duplicate code, so I made the get_nodes_level more generalized to take any circuit type (\Delta), and then later on probably can delete it from ProbCircuits repo.
Also we have a node2dag helper to get from a root node to array of nodes, so I replaced that part of code with it, if that was not the indented behavior let me know I can change it back.


Wrong IP used in LOAD request (Video not playing, castnow stuck on "Loading...")

InternalIp often returns a wrong local interface address (eg: vpn, virtual machine, docker container) used for the Api.load opts.path, address in a subnet for which there is no route on the WIFI router or on the default gateway.
The chromecast device it then just unable to reply ...
Maybe the IP used for the LOAD request should be displayed in the Loading or Load error message, and the --myip option mentioned.
I think it's also because of the wrong IP returned by InternalIp that the scanning often fails.
If it really does, mentionning here again the used IP and the --myip options would be great.
Thanks !

the ip used should be the ip for which there is a default gateway

Same problem here on MacOS (because of virtualbox it seems).
For now I just use: alias castnow="castnow --myip ipconfig getifaddr en0"

It seems internal-ip is now working well. I have all sorts of virtualization and vpns on my osx and internal-ip is able to find the correct wifi address. My question is, does castnow actually use that module ?


Broken Link

Link in the Note to develop code without projects and solutions is 404.
https://docs.microsoft.com/en-us/visualstudio/ide/develop-code-in-visual-studio-without-projects-or-solutions

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b057a09a-e208-8daf-58b0-3dfb3bb4ea0e
Version Independent ID: f891d20f-a2c8-3208-ed23-91dfef901eaf
Content: Solutions and projects in Visual Studio - Visual Studio
Content Source: docs/ide/solutions-and-projects-in-visual-studio.md
Product: visual-studio-dev15
GitHub Login: @gewarren
Microsoft Alias: gewarren

@prnadago This seems to be a glitch on the site. Can you try the link again? I think a 404 may have just flashed in front of me, too, but now it's working.

@prnadago We are tracking this site issue holistically, so I'll close this issue.

Oh yeah it's working now. Weird :/


Motion sensor won't get notifications

Hi, It seems Motion sensor won't trigger notification. Leak or contact sensor type works fine for me.

Turn on switch via Home will only change Contact Sensor State of Motion sensor but Motion Detected.

Turn on switch via homebridge will only change Contact Sensor State of Motion sensor and Motion Detected. Homebridge


PostgresAdapter.test.ts not targeting migrations.schema.default

While attempting to add a multitenant deployment option, I found that jest test deployments always go to public schema regardless of what is defined in the configOptions.
Adjust the migrations.schema.default schema:

breakpoint after const updateSQL: any = await liquibase(liquibaseOptions).run(updateCmd)

deployments still go to public schema:

I'm seeing the same behavior on deployments using "@sap/cds": "5.7.1", "cds-pg": "0.1.16", "cds-dbm": "^0.0.28"


fix: fixed foundry version to a working one

Latest foundry nightly is bugged with WETH9. Fix the version to the latest working one.

As said in comments
This is only a temporary fix waiting on https://github.com/foundry-rs/foundry/issues/9349 to be resolved


onSuccess fails

Shouldn't it be this.props.onSuccess. I'm getting an undefined exception

You are perfectly right, working on bug fix release now :-)
Next release will include tests as this is starting to shape up quite nicely!

New release is pushed


chore Update Sorensen (staging)

https://github.com/tv2/tv-automation-server-core/pull/121 but for staging.

Codecov Report

Merging #122 (f315df2) into staging (8a46872) will increase coverage by 15.68%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           staging     #122       +/-   ##
============================================
+ Coverage    66.73%   82.41%   +15.68%
============================================
  Files          267       12      -255
  Lines        18747     1012    -17735
  Branches      4252      213     -4039
============================================
- Hits         12510      834    -11676
+ Misses        6194      177     -6017
+ Partials        43        1       -42

Impacted Files
Coverage Δ

meteor/lib/collections/MediaWorkFlows.ts

meteor/lib/collections/PackageInfos.ts

meteor/server/api/logger.ts

meteor/server/api/ingest/packageInfo.ts

meteor/server/security/showStyle.ts

meteor/lib/collections/Users.ts

meteor/server/cache/CacheCollection.ts

meteor/lib/Rundown.ts

meteor/server/migration/0_25_0.ts

meteor/server/migration/api.ts

... and 245 more

Continue to review full report at Codecov.

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

This will be bumped again due to SOF-824.


"lessc" is  making trouble.

Its aksed to install npm and lessc <=1.4.0 .. I  am not able to install it.  However i installed a newer version  While compressing the less file the system showing  error in  base.html.

You should be able to run the following commands:
apt install npm
npm install<EMAIL_ADDRESS>


Compatibility with 0.9.0-dev changes

This pull request makes a number of necessary changes to bring the library
up to zig 0.9.0-dev.400+6c11e9bb0
Namely:

Removes unused parameters in functions and loops
Removes extern enums
Change of opaque syntax

It also fixes all the examples.
NOTE: one of the commits comments out the call to fetchSubmodules because I couldn't find the fix. Feel free to leave that commit out :^)

Can't test this right now because of https://github.com/ziglang/zig/issues/5188 so I'll try to set up CI with gh actions, to at least build it on a linux system.

Apparently CI doesn't work, likely because it doesn't have an X Window Server, so I'll merge this without further testing as it looks good to me. Before I do that though, can you further explain the fetchSubmodules change?

Sorry for the late reply.
The call to fetchSubmodules failed to compile for me on the first line of the multi-line string with: error: expected ',', found invalid bytes
I finally found the reason and it seems it was because the file was saved with CRLF End of Line Sequence (I'm on Windows) which leaves a CR that is no longer allowed in multi-line strings.
I reverted that change as a simple change of End of Line Sequence suffices to correct the issue.

Alright, good to go :)


OS X pathing issue

Ran into what I'm thinking is either a pathing or permission issue on OS X
source "/Users/hoover/GitHub/maya-module-installer/helloWorld.mel";
// Warning:     string $melPath = `match ": (.*)" $melPath`; //
// Warning: "/Users/hoover/GitHub/maya-module-installer/helloWorld.mel" line 241.48 : Redeclaration of variable "$melPath" shadows previous declaration at line 240. Previous value will be overwritten by explicit initializer. //
// Warning:     string $melPath = `substring $melPath 3 ($melSize-3)`; //
// Warning: "/Users/hoover/GitHub/maya-module-installer/helloWorld.mel" line 244.58 : Redeclaration of variable "$melPath" shadows previous declaration at line 240. Previous value will be overwritten by explicit initializer. //
// Warning: file: /Users/hoover/GitHub/maya-module-installer/helloWorld.mel line 82: fopen: unable to open file "/Users/hoover/GitHub/maya-module-installer\helloWorld.mod" for mode  "r". //
// Error: file: /Users/hoover/GitHub/maya-module-installer/helloWorld.mel line 278:
No valid module information found matching the current version/language/platform of Maya in /Users/hoover/GitHub/maya-module-installer\helloWorld.mod //

Hello, that backslash is throwing me off indeed. Could you confirm the file is definitely readable?

yep, changing the separator variable to a forward slash works man.

To be a 100% sure the path is working, could you restart Maya and see if you can see if it still prints "INITIALIZING HELLO WORLD" on start-up?

other than those warnings it looks to be working as expect.

Awesome. changes are pushed. I also got rid of the warnings while I was at it.
Thank you :)


Fix quick fix of placeholder/key

Fixes #66

It's a good idea to open an issue first for discussion.

[x] Tests pass
[ ] Appropriate changes to README are included in PR

You are having a run!


Preserve annotations in OCI images

If you copy an OCI image to a docker registry and copy it back, then the annotations in the image should be preserved. For example, an OCI image generated by Flatpak can be found at:
https://people.gnome.org/~otaylor/example-flatpak-oci-20170621.tar.gz
There are a couple of incompatibilities with skopeo in that image:

It uses org.opencontainers.ref.name rather than org.opencontainers.image.ref.name (probably an older spec version)
The ref name it uses "app/org.gnome.eog/x86_64/master" isn't accepted by skopeo even though it looks OK by the spec

But if you fix those manually, and copy to a docker registry and copy back (I used a local registry set up with https://hub.docker.com/_/registry/), then starting with an index.json:
{
    "schemaVersion" : 2,
    "mediaType" : "application/vnd.oci.image.index.v1+json",
    "manifests" : [
    {
       "mediaType" : "application/vnd.oci.image.manifest.v1+json",
       "digest" : "sha256:0c02d6e94d7c223b4f1e67ef0a194092a67f9115293f4a5e8e5f47305057dede",
       "size" : 2067,
       "annotations" : {
           "org.flatpak.installed-size" : "4427776",
           "org.flatpak.metadata" : "[Application]\nname=org.gnome.eog\nruntime=org.fedoraproject.Platform/x86_64/26\nsdk=org.fedoraproject.Platform/x86_64/26\ncommand=eog\n\n[Context]\nshared=ipc;\nsockets=x11;wayland;session-bus;\nfilesystems=xdg-run/dconf;host;~/.config/dconf:ro;\n\n[Session Bus Policy]\nca.desrt.dconf=talk\n\n[Environment]\nDCONF_USER_CONFIG_DIR=.config/dconf\n",
            "org.opencontainers.image.ref.name" : "latest",
            "org.flatpak.download-size" : "1866664"
      }
    }
  ]
}

It ends up as:
{
"schemaVersion":2,
"manifests":[
    {
	"mediaType":"application/vnd.oci.image.manifest.v1+json",
	"digest":"sha256:0d7b52181d395460b6dbc5d336d147618424d804f8a6047e136e71ce0e181700",
	"size":348,
	"annotations":{
	    "org.opencontainers.image.ref.name":"latest"
	},"
	"platform":{
	    "architecture": "amd64",
	    "os":"linux"
	}
    }
]
}

And similarly, the annotations are also dropped from the manifest that the index points to.

WRT annotations in the manifest, I think that’s expected: AFAIK none of the existing docker/distribution registries support OCI images directly, so the OCI manifest is converted into a schema2 manifest. (To be fair, right now even if a registry did support OCI, the code wouldn't try to use it; we try only schema2/schema1.) That manifest schema does not support annotations, so they are dropped during the conversion. Copying the image back to OCI/layout converts the manifest to OCI again, but the annotations are gone by then.
The annotations in the index are not even treated as a part of the OCI image in our current implementation, the “concept” of an image as currently implemented does not have any external annotations. The OCI transport only uses the index to look up a manifest file by name.  (I am not really sure what the semantics of index vs. image vs. annotation is supposed to be, perhaps @runcom knows. OCI annotations just seem horribly overgeneralized to me either way.)

It uses org.opencontainers.ref.name rather than org.opencontainers.image.ref.name (probably an older spec version)

Yes, https://github.com/containers/image/pull/278 .

The ref name it uses "app/org.gnome.eog/x86_64/master" isn't accepted by skopeo even though it looks OK by the spec

This seems to be a bug , please file it at https://github.com/containers/image . (We may have to break the transport syntax now that an arbitrary number of : is allowed in the .tag :(  )

For the purposes of Flatpak, the annotations in the index.json should not needed be if the manifest is preserved. The current code might look in the index.json for them, but it can be adjusted. Does it might make sense to copy the annotations back from the manifest to the index when creating one for an oci: destination? That seems to be a question for an image spec expert. (@vbatts?)
https://github.com/docker/distribution/pull/2076 is a PR to add OCI manifest support to the docker registry. It is apparently blocked on finalizing the image spec, and also may be out of date with respect to the current image spec, but if the issue is registry-side support would hopefully allow resolving this when completed.
(@runcom asked me to file this issue to track things)

(If anyone wants to experiment with OCI support in a docker/distribution registry, it should be necessary to only add the OCI manifest type to docker_image_dest.go:manifestMIMETypes; then a round-trip of an OCI image to/from the server should preserve the original manifest unmodified, or at most compress the layers if they are not compressed.)

@owtaylor preserving annotations ought to be done, but as for when they get into the index, that could vary for use-case. Presently the context of different annotations is confusing (on the index itself, or on the descriptors in the index, or on the image config itself).
For this reason it can vary the information that is wanting to be indexed.
As for the docker-registry, it is still up in the air how any of these annotations will even be exposed. I would venture to say they won't be at all. Historically community folks wanted to expose LABELS via the registry api and that never happened. But it would be very useful for projects like flatpak, because then their OCI images could re-use infrastructure like a docker registry.

@owtaylor @mtrmac @vbatts @vrothberg Is this fixed now?  Can we close this issue?

I don’t really think of annotations in the (manifest) “index” as part of the image (which has the manifest as the top-level object).  Unless the OCI registry standard deviates from docker/distribution enough to support this extra metadata (@vbatts ?), I don’t see how we could preserve them.

Flatpak doesn't care any more about annotations on the index (if it ever
did.) But annotations on the manifest have to be preserved. I claimed that
wasn't the case in the initial description, but I think it's likely working
now since we do use skopeo for uploading Flatpaks from OSBS.

Flatpak doesn't care any more about annotations on the index (if it ever did.) But annotations on the manifest have to be preserved. I claimed that wasn't the case in the initial description, but I think it's likely working now since we do use skopeo for uploading Flatpaks from OSBS.

Conversions from OCI to schema2 do discard annotations AFAICS; so it probably works only if the registry can natively accept OCI manifests.

The manifest annotations issue was likely fixed by:
https://github.com/containers/image/pull/338
In general,  I think this can be closed... though if/when pushing and
pulling image indexes as image indexes is supported (#400) I would  expect
that the image indexes would be literally persevered, included annotations.
(We don't need that for Flatpak, but it would be potentially problematical
for other uses.)

https://github.com/containers/skopeo/issues/400 seems to be something quite irrelevant.
https://github.com/containers/image/pull/400 OTOH, does involve somehow dealing with multi-arch OCI images, and that code does preserve the annotations I think. But that’s code, and functionality, that does not currently really exist, so keeping an issue filed against it does not quite make sense. So, closing.
Thanks!


v3.2.2

PRO-tier scaffolding in place.

Pull Request Test Coverage Report for Build 1895

15 of 16 (93.75%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 71.921%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

dist/middleware/route-ratelimit.js
15
16
93.75%

Totals

Change from base Build 1869:
0.1%

Covered Lines:
2015

Relevant Lines:
2606

💛  - Coveralls


[Snyk] Security upgrade node from 16 to 16-bullseye-slim

This PR was automatically created by Snyk using the credentials of a real user.Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Changes included in this PR

Dockerfile

We recommend upgrading to node:16-bullseye-slim, as this image has only 41 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Some of the most important vulnerabilities in your base image include:

Severity
Priority Score / 1000
Issue
Exploit Maturity

833
Integer Overflow or Wraparound SNYK-DEBIAN10-PYTHON37-3090928
No Known Exploit

833
Integer Overflow or Wraparound SNYK-DEBIAN10-PYTHON37-3090928
No Known Exploit

833
Integer Overflow or Wraparound SNYK-DEBIAN10-PYTHON37-3090928
No Known Exploit

833
Integer Overflow or Wraparound SNYK-DEBIAN10-PYTHON37-3090928
No Known Exploit

571
Out-of-bounds Write SNYK-DEBIAN10-TIFF-3058788
No Known Exploit

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

closing as we no longer use snyk, will confirm this is resolved with dependabot


Simple Weather button in Simple Calendar is not working.

Updated SImple Calendar wit hthe new version and getting this message.

Released 1.13.0 to support new SC version


Running Balance Column Always On

Name of Defective Feature
Running Balance Column in the Accounts screen
System Settings (Required)
ToolKit Version: 1.2.0
Operating System (Mac/Windows/Etc): Win10 - can check if Linux is impacted as well
Browser (Chrome/Firefox/Safari): Chrome
Browser Version: 60.0.3112.113, 61.0.3163.91
Other Extensions: Numerous - ones that are not server status extensions are Hangouts, ForecastFox, uBlock Origin, Stylish (not enabled for YNAB).
Export of Toolkit Settings (Bottom Left of Settings Page)

Settings Export
```
[{"key":"AccountsDisplayDensity","value":"1"},{"key":"AccountsEmphasizedOutflows","value":false},{"key":"AccountsStripedRows","value":true},{"key":"AdditionalColumns","value":true},{"key":"AdjustableColumnWidths","value":false},{"key":"AutoCloseReconcile","value":false},{"key":"BetterScrollbars","value":"0"},{"key":"CategoryActivityCopy","value":false},{"key":"ChangeEnterBehavior","value":false},{"key":"CheckNumbers","value":false},{"key":"ColourBlindMode","value":false},{"key":"CustomFlagNames","value":false},{"key":"DisplayTargetGoalAmount","value":"0"},{"key":"GoalWarningColor","value":true},{"key":"HideAgeOfMoney","value":true},{"key":"HideReferralBanner","value":true},{"key":"ImportNotification","value":"1"},{"key":"PrintingImprovements","value":true},{"key":"PrivacyMode","value":"0"},{"key":"RemovePositiveHighlight","value":false},{"key":"RowHeight","value":"1"},{"key":"RowsHeight","value":"1"},{"key":"RunningBalance","value":"0"},{"key":"ShowCategoryBalance","value":true},{"key":"SquareNegativeMode","value":false},{"key":"StealingFromFuture","value":false},{"key":"TargetBalanceWarning","value":true},{"key":"accountsClearSelection","value":false},{"key":"accountsDisplayDensity","value":"1"},{"key":"accountsEmphasizedOutflows","value":false},{"key":"accountsRowHeight","value":"1"},{"key":"accountsStripedRows","value":true},{"key":"activityTransactionLink","value":true},{"key":"betterScrollbars","value":"0"},{"key":"budgetBalanceToZero","value":true},{"key":"budgetProgressBars","value":"0"},{"key":"budgetQuickSwitch","value":false},{"key":"budgetRowsHeight","value":"1"},{"key":"calendarFirstDay","value":"0"},{"key":"categoryActivityPopupWidth","value":"1"},{"key":"changeEnterBehavior","value":false},{"key":"checkCreditBalances","value":false},{"key":"checkNumbers","value":false},{"key":"closeReconcileWindow","value":false},{"key":"collapseExpandBudgetGroups","value":true},{"key":"collapseSideMenu","value":true},{"key":"colourBlindMode","value":false},{"key":"compactIncomeVsExpense","value":false},{"key":"currentMonthIndicator","value":false},{"key":"daysOfBuffering","value":false},{"key":"daysOfBufferingHistoryLookup","value":"0"},{"key":"editButtonPosition","value":"2"},{"key":"enableRetroCalculator","value":true},{"key":"enlargeCategoriesDropdown","value":true},{"key":"exportTransactions","value":false},{"key":"goalIndicator","value":true},{"key":"goalIndicatorWarningColor","value":true},{"key":"googleFontsSelector","value":"0"},{"key":"hideAOM","value":true},{"key":"hideAccountBalancesType","value":"0"},{"key":"hideHelp","value":false},{"key":"highlightNegativesNegative","value":false},{"key":"importNotification","value":"1"},{"key":"incomeFromLastMonth","value":"0"},{"key":"l10n","value":"0"},{"key":"largerClickableIcons","value":false},{"key":"monthlyNotesPopupWidth","value":"1"},{"key":"navDisplayDensity","value":"1"},{"key":"options.dark-mode","value":true},{"key":"pacing","value":"0"},{"key":"popupCalculator","value":false},{"key":"printingImprovements","value":true},{"key":"privacyMode","value":"0"},{"key":"reconciledTextColor","value":"4"},{"key":"removePositiveHighlight","value":false},{"key":"removeZeroCategories","value":true},{"key":"reports","value":true},{"key":"resizeInspector","value":true},{"key":"rightClickToEdit","value":true},{"key":"runningBalance","value":false},{"key":"seamlessBudgetHeader","value":false},{"key":"showIntercom","value":true},{"key":"spareChange","value":false},{"key":"splitKeyboardShortcut","value":true},{"key":"splitTransactionAutoAdjust","value":true},{"key":"squareNegativeMode","value":false},{"key":"stealingFromNextMonth","value":false},{"key":"swapClearedFlagged","value":false},{"key":"toBeBudgetedWarning","value":false},{"key":"toggleSplits","value":true},{"key":"toggleTransactionFilters","value":"0"},{"key":"warnOnQuickBudget","value":false}]```

Steps to Reproduce the Behavior

Set "Running Balance" Dropdown to "Off"
Load YNAB
See Running Balance column in all accounts anyway.

Expected Behavior

I expected no running balance.
Actual Behavior

There was a running balance column in all accounts. Note, changing the dropdown to highlight negative balances in red does work, so it's not like the dropdown is being completely ignored; it's just ignoring the "off" setting.

I was seeing this in one of my Chrome browsers, and then I noticed the one with the problem was running an outdated Chrome. When I restarted Chrome to get the latest version, the problem went away.

Check that. Actually, restarting Chrome in general is what fixed the problem. When I enabled the popup calculator in the Toolkit options, it showed the running balance again. If I disable the popup calculator and restart Chrome, it's fixed again. Is there possibly something else going on here?

Have a look at the PR. It explains the problem.

Giving this a +1, I am having this problem as well and restarting chrome didn't help. Also tried turning off all toolkit options besides being enabled and still saw running balance.

I am also having this problem.  I've only tried turning it off and on and off again.  Still showing in all my accounts.

Until the next Toolkit release this will an issue. Not sure when that will be but hopefully it won't be too long.

Fix is available in release 1.3.0. Feel free to reopen if necessary.


KITTI zhou split has different number of training images from Monodepth2

Hi,
Thanks for sharing the awesome work. I use the kitti_zhou_split training split provided by you here. It contains 21880 training images from each left and right camera. But the same zhou split from Monodepth2 contains 19905 imageshere.
Can you explain why? or point me the mistakes i have.

Hi,
the original split from [Zhou et al., SfMLearner, CVPR 2017] contains 40,109 images, the split from [Godard et al., monodepth2, ICCV 2019] contains a subset of 39,100 image triplets. In the code I provide I basically use all left and right images, where at least one image (left or right) exists in Godard et al.'s split. This results in the number of image triplets you find here in this code.


About Us page updated, Responsiveness Fixed

Pull Request
Title
Updated the About Us page
Description
Updated the About Us page and made it fully responsive for all devices and dimensions
Added Interactive and sleek animations
Fixed the spacings
Related Issues
Fixes #346
Changes Made
New Features and bug fixes
Checklist

[x] I have tested the changes locally
[x] Documentation has been updated (if necessary)
[x] Changes are backward-compatible

Screenshots (if applicable)
Video Demo
https://github.com/user-attachments/assets/a6ecd3ed-670c-49bb-a691-a2cb4c39dade
These are the screenshots

Additional Notes

Footer

@VaibhavArora314 Ok I will fix it and create a new pr


Better Bibtex isn't automatically pinning citation keys despite the setting to do so after 1 sec

Debug log ID
ZNPERUAA-refs-euc/6.7.225-7
What happened?
Although I have set an auto pin delay of 1 sec, references aren't being automatically pinned (although manual pinning works). I don't understand why not.

I don't see a change to any item in the log.

I don't know why the auto-pinning wasn't working. Selecting all the references and choosing to "Refresh BibTex key" (even though the keys were already there) seems to have fixed the problem.

I believe autopin has been on the whole time. What exactly does pinning do?

I believe autopin has been on the whole time.

I can't tell what your scenario was without a log taken while the behavior occurred.

What exactly does pinning do?

It writes the key to the Extra field after which it will no longer change (without you forcing it). The benefit of doing that is that these keys will sync across machines and will show up in the Overleaf integration.
At some point Zotero will add a real citation key field (it's been in their plans for a while), and at that point it will migrate automatically out of the extra field.

I don't think there's anything else I can do right now?

I guess not, but when I was unable to insert references because of "invalid key" situation, the key was indeed in the extra field, which is strange.

I don't understand? If the key is in the extra field it has a key?

On you can know why your plugin wasn't finding it.

I find this response so strange. I'm saying I don't understand what you're saying and your response is that "you should understand because it is your plugin"?
I do not understand the situation you were describing, and I can't derive understanding from a log I don't have. I don't know what was happening at the time on a system I have no access to; the behavior isn't structural because all my tests in the test suite would fail. Without a log covering the problem or local replicability there is just not much I can do, and it isn't yet clear to me that we're actually talking about a BBT problem (see below).

I guess not, but when I was unable to insert references because of "invalid key" situation, the key was indeed in the extra field, which is strange.

If the key is in the extra field, it has a citation key, and
I don't know what you mean by "inserting references" in the context of BBT citation keys; if it is about inserting in Word, BBT citation keys play no role there.

BBT doesn't have the string "invalid key" anywhere, I don't know what "invalid key" would mean to BBT, and the only place that I see "invalid key" in the Zotero source has to do with syncing, and those keys are the technical item keys that Zotero assigns to items, not citation keys.

Sorry. These tools are so complex (Zotero has its plugins, Logseq has its plugins …) that I get confused. Your plugin is great and the fact that you’re doing this for free, on your own spare time, is amazing!

Ah you're inserting something in LogSeq. I don't know about that integration, if you get the author of that plugin involved maybe we can get to the bottom of this.

Are you going to get the author of the logseq integration involved? Otherwise we can close this issue.

Sorry for the confusion, but this issue is about auto-pinning not occurring. And as a matter of fact, I'm seeing that now. I had Zotero download a reference using the "Add Items by Identifier" toolbar icon. Better Bibtex still hasn't put the citation key in the Extra field for reasons that escape me. How can we troubleshoot?

Reproduce, send a log

It stopped being correctly installed. How could it appear under Tools > Plugins without a corresponding pane in Zotero's settings?
You can close this issue.

When you say

Better Bibtex still hasn't put the citation key in the Extra field

I assumed you have BBT installed. If it is not installed, it obviously won't do anything. Are you saying now you cannot install BBT?
I have a sense you are trying to talk about many things at once; I have no idea what you want(ed) help with. I'd love to help, but I am thoroughly confused on what problem you want addressed.

You can close this issue.

OK....