[bug] [v2] Some of the corrections made by the migration tool are incorrect.

Describe the bug
When using the migration tool, the following parts were incorrectly corrected, causing an error.

import { convertFileSrc } from '@tauri-apps/api/tauri' -> import { convertFileSrc } from 'core'
import { appWindow } from '@tauri-apps/api/window' -> import { appWindow } from 'webviewWindow'
(Related to 2.) appWindow -> not change(appWindow not defined)
import { dialog } from '@tauri-apps/api' -> not change

These have been corrected as follows.

Change to import { convertFileSrc } from '@tauri-apps/api/core'
Change to import { appWindow } from '@tauri-apps/api/webviewWindow'
Changed appWindow to getCurrent and other appWindow same changes.
Change to import { open } from '@tauri-apps/plugin-dialog'

For 1. and 2., we will probably need to update this process.
https://github.com/tauri-apps/tauri/blob/11aa7743e7a277ed9ec3e92040dc484afe77d261/tooling/cli/src/migrate/frontend.rs#L57-L59
I don't think the migration tool can handle 3. and 4., but I wanted to report it just in case.
Reproduction
git clone http://github.com/mikoto2000/scab-player
cd scab-player
npm i @tauri-apps/cli@next @tauri-apps/api@next
npm run tauri migrate
npm run tauri dev

Expected behavior
This error should not occur.
Full tauri info output
node@ea91fd36a6f2:/workspaces/scab-player3$ npm run tauri info

><EMAIL_ADDRESS>tauri
> tauri info

[✔] Environment
    - OS: Debian 12.0.0 X64
    ✔ webkit2gtk-4.1: 2.44.2
    ✔ rsvg2: 2.54.7
    ✔ rustc: 1.78.0 (9b00956e5 2024-04-29)
    ✔ cargo: 1.78.0 (54d8815d0 2024-03-26)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 22.2.0
    - yarn: 1.22.19
    - npm: 10.7.0

[-] Packages
    - tauri [RUST]: 2.0.0-beta.22
    - tauri-build [RUST]: 2.0.0-beta.17
    - wry [RUST]: 0.40.1
    - tao [RUST]: 0.28.1
    - @tauri-apps/api [NPM]: 2.0.0-beta.13
    - @tauri-apps/cli [NPM]: 2.0.0-beta.20

[-] App
    - build-type: bundle
    - CSP: default-src 'self'; connect-src ipc: http://ipc.localhost; media-src stream: http://stream.localhost asset: http://asset.localhost
    - frontendDist: ../build
    - devUrl: http://localhost:3000/
    - framework: React

Stack trace
no stac trace.

Additional context
No response

I opened a PR for this:

1 & 2: fixed
3: I added partial migration so import { appWindow } from '@tauri-apps/api/window' becomes import { getCurrent as appWindow } from 'webviewWindow', you still gonna need to do manual changes because appWindow will be a function and you'll need to add () after each call to it.
4: I couldn't reproduce but should be fixed as well

@amrbashir Thank you for fix and comment!
And sorry, there were some omissions in reporting some steps regarding the dialogues.
There may have been a problem with these steps.
1. Remove "rlib" in "Cargo.toml"
Added the following to Cargo.toml according to Upgrade from Tauri 1.0 | Tauri
[lib]
name = "app_lib"
crate-type = ["staticlib", "cdylib", "rlib"]

I got this error:
Compiled successfully!

You can now view scab-player in the browser.

  Local:            http://localhost:3000
  On Your Network:  http://<IP_ADDRESS>:3000

Note that the development build is not optimized.
To create a production build, use npm run build.

webpack compiled successfully
Files successfully emitted, waiting for typecheck results...
Issues checking in progress...
No issues found.
    Info Watching /home/node/scab-player2/src-tauri for changes...
warning: output filename collision.
The lib target `app_lib` in package `scab-player v0.1.0 (/home/node/scab-player2/src-tauri)` has the same output filename as the lib target `app_lib` in package `scab-player v0.1.0 (/home/node/scab-player2/src-tauri)`.
Colliding filename is: /home/node/scab-player2/src-tauri/target/debug/deps/libapp_lib.rlib
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
thread 'main' panicked at src/cargo/core/compiler/fingerprint/mod.rs:1103:13:
assertion failed: mtimes.insert(output.clone(), mtime).is_none()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The template created by npm create tauri-app@latest -- --beta did not include rlib, so I removed rlib.
2. Migrate tool is not change @tauri-apps/api to 2.x.x-beta.xx.
I change to 2.0.0-beta.14 manually.
(Is there any intention for the migration tool not to change this?)
I create minimum code(repository: mikoto2000/TauriMigrationExample).
App.tsx:
import { dialog } from '@tauri-apps/api'

import './App.css';

function App() {

  async function selectChannelBaseDirectory() {
    const _ = await dialog.open({
      title: "Select channel base directory",
      directory: true
    });
  }

  return (

      <button onClick={selectChannelBaseDirectory} >チャンネル選択</button>

  );
}

export default App;

From Migrate to Dialog Plugin - Upgrade from Tauri 1.0 | Tauri,
dialog is need migrate to plugin-dialog.
So, expected result is this(But I didn't change the migration tool):
import { open } from '@tauri-apps/plugin-dialog';

import './App.css';

function App() {

  async function selectChannelBaseDirectory() {
    await open({
      title: "Select channel base directory",
      directory: true
    });
  }

  return (

      <button onClick={selectChannelBaseDirectory} >チャンネル選択</button>

  );
}

export default App;

in the dialog example you provided,
import { dialog } from '@tauri-apps/api';

will change to
import dialog from '@tauri-apps/plugin-dialog';

so the rest of the code should work

@amrbashir
Got it, understood.
Thank you for the corrections!


⚠ Bofrost.lu has degraded performance

In 3921fd6, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1737 ms

Resolved: Bofrost.lu performance has improved in b198bf0 after 6 minutes.


Zh cn ethan

Chinese translation of Tutorial from 0. to 2.

Should not add zh-cn.mo file to git.

Manually merged in https://github.com/StarknetAstro/dojobook/pull/3


SSL Handshake Failure

Hello,
I am stuck on this requests error...
"requests.exceptions.SSLError: HTTPSConnectionPool(host='api.binance.com', port=443): Max retries exceeded with url: /api/v1/ping (Caused by SSLError(SSLError(1, u'[SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:590)'),)):
...this just started happening and I haven't changed my code at all. Can someone please help me fix this? I've seen that there have been related issues posted, but those solutions have not helped me. Thanks a bunch.
-M

Same problem here! And I didn't change any code since the last time it was working.

+1 pulled master branch, seems to be an invalid ssl cert

can solve this problem?


Improve ComputedNode accessibility

Objective

Enable modifying node size after layout.
Gain access to a node's content_size. UiSurface is a private type so content size can't be looked up.

Solution

Make ComputedNode fields public.
Add content_size to ComputedNode.

It seems weird that something "computed" should be  made public with the intention of being mutable. I have no experience writing bevy UI, so I don't have insight about this idea, but it is executed correctly.

It seems weird that something "computed" should be made public with the intention of being mutable

Yep, absolutely. That's why it was designed this way originally, but advanced users occasionally need an escape hatch, and this doesn't seem like a tripping hazard to me.


Skip parent error when reporting excess property checks

When we report an excess property error, the current error chain looks like this
    Argument of type '{ z: number; a: number; }' is not assignable to parameter of type 'T'.
      Object literal may only specify known properties, and 'z' does not exist in type 'T'.

As frequently noted by @fatcerberus, this gives the misleading impression that object types are sealed, since the way we printback a fresh object literal type is indistinguishable from a regular object type. It's also a waste of space since the top errorline prints back T when it's already in the EPC line, and the object literal source type is always anonymous (therefore long).
This PR skips the parent line when reporting EPC errors, so you don't see the "x is not assignable to y" part. The implementation is set up to handle the tricky case
declare function fn(a: { x: string }): void;
declare function fn(a: { y: string }): void;
fn({ z: 3, a: 3 });

where we want to print back two EPC errors:
// BEFORE
No overload matches this call.
  Overload 1 of 2, '(a: { x: string; }): void', gave the following error.
    Argument of type '{ z: number; a: number; }' is not assignable to parameter of type '{ x: string; }'.
      Object literal may only specify known properties, and 'z' does not exist in type '{ x: string; }'.
  Overload 2 of 2, '(a: { y: string; }): void', gave the following error.
    Argument of type '{ z: number; a: number; }' is not assignable to parameter of type '{ y: string; }'.
      Object literal may only specify known properties, and 'z' does not exist in type '{ y: string; }'.

// AFTER
No overload matches this call.
  Overload 1 of 2, '(a: { x: string; }): void', gave the following error.
    Object literal may only specify known properties, and 'z' does not exist in type '{ x: string; }'.
  Overload 2 of 2, '(a: { y: string; }): void', gave the following error.
    Object literal may only specify known properties, and 'z' does not exist in type '{ y: string; }'.

@typescript-bot pack this

Let's make sure this example doesn't regress and always reports on the discriminant.
export type Blah =
    | { type: "foo", abc: string }
    | { type: "bar", xyz: number, extra: any };

declare function thing(blah: Blah): void;

let foo = "foo";
thing({
    type: foo,
    abc: "hello!"
});

let bar = "bar";
thing({
    type: bar,
    xyz: 123,
    extra: 123,
});

@typescript-bot pack this

Suggestions on wording from a user who was previously confused by it
Priorities:

Indicate that the error is a sanity check, not a type violation.
Indicate that the object literal can be assigned to that variable, albeit not directly.
Show the user how to assign it, if there is a preferred way.

Warning: Property 'z' does not exist in type 'T'. Is this a mistake? To continue, cast the object literal to type 'T' or 'typeof var/Parameters<typeof func>[n]*', or save it to a new variable, before assignment.

Delete as appropriate. Do you have access to the variable/function name and arg pos?

It's a bit tricky to give clear instructions on how to assign it given the many scenarios. Simpler option might be:
Warning: Property 'z' does not exist in type 'T'. Is this a mistake? Can't assign this object literal directly, to continue, use a typecast, assign to an intermediate variable, or use an IIFE.
Really the important thing isnt how to assign but that the user understands that it is possible, to avoid misundersranding types.

@RyanCavanaugh Yeah I generally agree. No issues with going ahead with something along those lines.
I based my suggestion on the type casting error which is similar in feeling, but with a suggestion on how to fix it.
Conversion of type '{ c: number; }' to type 'O' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.   Property 'a' is missing in type '{ c: number; }' but required in type 'O'.(2352)
I think in the situation where you want to add properties, you are creating an object that conforms to some type standard, that is probably defined externally.
For simply object creation, you could extend this type with an intersection to creating your own expanded type.
Alternatively you could use satisfies and let TS infer the type of the new object. I was surprised to find that satisfies checks are subject to EPC too, I expect them to be treated like type cast, but this can be worked around by pushing the satisfies check into the next statement.
The other scenario that I can think of is abstract properties, but the way that this is handled is currently very permissive, as previously discussed, so no EPC checking here.
Playground
So the only scenario where EPC would come into play here is the satisfies approach.
Just thought I would lay that out incase it helps anyone.

this gives the misleading impression that object types are sealed, since the way we printback a fresh object literal type is indistinguishable from a regular object type.

Case in point.  In general, people see "X is not assignable to Y" and expect that to apply in all contexts.  That issue, incidentally, also highlights another way the current error is misleading: it says "object literal may only specify known properties", but many defect reports still involve object literals, just without the contextual typing required for EPC to work.


gitfast doesn't have to load the git plugin

The gitfast plugin does not depend on the git plugin, which defines a set of shell aliases. I don't like that many aliases, but I need gitfast. Could you help to prevent gitfast from loading the git plugin? One can always enable it by adding it in .zshrc.

#7152 gets rid of it. Try it out and +1 if it works.


Poor Perfomance with Disco Elysium

I'm GPU bounded with my GeForce GT 710.
But in Windows 7 i'm GPU bounded too, but the game works 3.5 times faster (6 fps vs 21 on minimals).
I think it's mostly driver's fault (just a guess), but may be you'll want to take a look at it.

DXVK is known to run poorly on Kepler GPUs, and especially poorly on GPUs with less than 3GB of VRAM, this is not (just) our bug and will not be addressed.

I've tried the game with dxvk on Windows. And there is no graphics again. Looks like NVIDIA didn't implement dxvk fix in windows driver.

i get the logo and then a black screen with dxvk. what is your config? (winetricks, native libs?)

I'll retest it on Windows soon. If i remember correctly, it just worked for me on Linux, no tricks, no libs but dxvk. Maybe some regression?


Webview does not display anything incrementally before fully downloaded/rendered

Bug description:
The component seems to wait to fetch the entire DOM and execute all the javascript before it displays. Is there no way to have it load incrementally/progressively as in Safari/Chrome?
I see this mentioned in #128 - which seems to be closed due to the default caching, but on initial load, it still seems only to display after the entire DOM has been rendered and thus appears to be incredibly slow, if not frozen at times (especially if a page is media heavy and includes video for example).
My main question: is there a reason it is unable to display before the DOM is fully rendered?
To Reproduce:
Load a remote URL into webview
Expected behavior:
The page displays while loading.
Screenshots/Videos:

Environment:

OS: iPhone 6s plus, iphone 11 simulator
OS version: 13.3
react-native version: 0.61.5
react-native-webview version: 8.0.3

Also experiencing this exact issue. While using the startInLoadingState prop, external sites are taking up to 10 seconds to load, and then pop in fully rendered.
I can remove the startInLoadingState prop and it renders slightly faster, but then the user is left without visual feedback

Also experiencing this exact issue. While using the startInLoadingState prop, external sites are taking up to 10 seconds to load, and then pop in fully rendered.
I can remove the startInLoadingState prop and it renders slightly faster, but then the user is left without visual feedback

@mharrison-nzme  thanks for your information, I removed startInLoadingState props and it did render faster, and just like you said, now I'm giving users a blank page with no feedback.

I also observed the same behaviour. The component seems to only display after fetching the entire DOM and executing all the JS. Has anyone found a way to load partially/incrementally/progressively like most browsers usually do?

We have the same issue. Does anyone know of a solution to this?

+1


fix missing config file

Fix missing config file :

After reviewing the changes I've found that it's not required for our setup. The Docker image should come with it installed, and adding more files than necessary doesn't align with our approach of keeping things simple by just handling the settings file for enabling search engines and setting response formats. We'll close this PR.


Ground state does not update after death

Running SpongeVanilla version 1.10.2-5.2.0-BETA-383 or higher results in the player 'onGround' state not updating after death (always true). This has not been tested with lower versions. Relogging will fix this issue.

Have you tested if the same thing happens on SpongeForge?

I have not.

@inferiormartin Any chance you could try reproducing it on the latest SpongeForge? If not, I'd appreciate if you could share some instructions on how to reproduce the problem (e.g. the steps to reproduce it, an example plugin, ...).

Well, it's just checking the player#isOnGround state on the MoveEntityEvent. That's it.

I cannot reproduce this. I used the following code on the latest SpongeVanilla:
@Plugin(id = "testplugin")
public class TestPlugin {

    @Inject private Logger logger;

    private boolean currentState;

    @Listener
    public void onMove(MoveEntityEvent event) {
        Entity entity = event.getTargetEntity();
        if (!(entity instanceof Player)) {
            return;
        }

        Player player = (Player) entity;
        boolean newState = player.isOnGround();
        if (currentState != newState) {
            this.logger.info("New state: " + newState);
            currentState = newState;
        }
    }

}

It will correctly display changes in player.isOnGround() even after death.

I've done another test, does the server create a new Player object after the player has died?

That's possible. You should never store references to the Player instance. Get the player instance using its UUID instead.


camlp5: fix install with ocaml 4.04

Motivation for this change
As reported in #25367, camlp5 doesn't work with ocamlPackages_latest.
I managed, with the help of the author of the software, to track down the problem to the shrink phase, during installation. The problem was that bytecode executables were stripped.
This commit fixes the problem but there might be a bigger issue that bytecode executables are not detected as such and thus incorrectly stripped. So maybe a better fix is possible.
Maybe some OCaml expert can help here (cc @vbgl).
Things done

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

[x] NixOS
[ ] macOS
[ ] Linux

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

I know no better fix; thanks.

@vbgl Could this fix be cherry-picked in the release-17.03 branch? Thanks!

Done in afa901d8c76682c10d7e51b1d6524a474e78c042.

@vbgl Thanks!


Rule application failed

The following rule failed to be applied:
rule lookup(A, foo(A) |-> V:Val _:Map) => bar(V)

where bar requires its input to be of sort Val.
But the following equivalent but ugly ones succeeded to be applied:
rule lookup(A, M) => lookupAux(M[foo(A)])
rule lookupAux(V:Val) => bar(V)

A minimal example.
Given a definition:
$ cat b.k
module B

imports INT
imports MAP

configuration <T>
  <k> $PGM:Cmd </k>
</T>

syntax Int ::= lookup(Key, Map) [function]
rule lookup(A, foo(A) |-> V:Val _:Map) => bar(V)

syntax Int ::= foo(Key) [function]
syntax Int ::= bar(Val) [function]

syntax Key ::= "kk"
syntax Val ::= "vv"

rule foo(kk) => 1
rule bar(vv) => 2

syntax Cmd ::= "run"
rule run => lookup(kk, 1 |-> vv .Map)

endmodule

It failed to apply the lookup rule:
$ cat 1.b
run

$ kompile --backend haskell b.k

$ krun 1.b
<T>
  <k>
    lookup ( kk , 1 |-> vv )
  </k>
</T>

But if we replace the original lookup rule:
rule lookup(A, foo(A) |-> V:Val _:Map) => bar(V)

with the following equivalent but ugly ones:
rule lookup(A, M) => lookupAux(M[foo(A)])
syntax Int ::= lookupAux(K) [function]
rule lookupAux(V:Val) => bar(V)

then, it succeeded:
$ krun 1.b
<T>
  <k>
    2
  </k>
</T>

Functions are not evaluated during matching, so when applying the rule
rule lookup(A, foo(A) |-> V:Val _:Map) => bar(V)

although the backend would generate a substitution for A, and apply that substitution to subterm foo(A), it would not evaluate foo in order to get the Map key. This is an intentional limitation; equation rules, including function rules, are applied by syntactic matching only.

You're right. My bad.


hotkeys not using explicit annotation and cannot be invoked in strict mode

When using angular hotkeys in strict mode there is an error thrown due to some dependencies not being explicitly annotated.

seems to have been addressed - my mistake!


Allow microseconds in datetimes and allow identity-function parsing.

Given that we are working toward supporting interpreter-based query execution, rather than just purely compilation-based ones, we should do our best to align our expectations of incoming data to the capabilities and use cases of interpreters.
Up to this point, we've had a couple of limitations that this PR helps us move away from:

The GraphQL Date and DateTime types' parse() functions always expected string inputs, because that's what was reasonable to get from a client "over the wire." However, in the case of interpreters, it's much more likely that the client is themselves running the interpreter, and therefore the argument validation functions (which depend on calling parse() on GraphQL type objects) may in fact be given an already-constructed Python date or datetime object. In such cases, parse() should simply return the input as-is, after validating that it is in fact a supported value (e.g. that the datetime is timezone-naive, the same requirement which exists for string-based inputs).
The GraphQL DateTime type had precision down to seconds rather than microseconds. While seconds are convenient in some cases (e.g. for use with OrientDB), Python datetime objects and datetime objects in many databases (e.g. PostgreSQL) go down to microseconds. Limiting precision to seconds for the sake of OrientDB was therefore disadvantaging interpreters and databases like PostgreSQL that could support higher precision.

In this PR, we allow microsecond-level precision for GraphQL DateTime query arguments, and we allow the parse() functions for Date and DateTime to accept the kinds of objects as input that they would themselves return, simply returning them as-is.

Big thanks 🙏  to our past selves for having extremely thorough unit tests on all the parsing and serialization stuff. This PR would have been 1000x more difficult to pull off safely without the exceptional test coverage we have.
TL;DR of the current state:

Implicit widening conversions (no loss of precision) from date to datetime are allowed, both in their string representations and as Python objects.
Datetime to date, or timezone-aware to timezone-naive datetime are narrowing conversions, and they remain disallowed since we do not want to implicitly lose precision.
We switched to ciso8601 for all our ISO 8601 parsing, and moved away from arrow. Since pytz was only required for Python 2, we were able to remove that dependency as well.
We clarified the schema spec for the date and datetime types, explicitly promising support for particular string formats while allowing implementations to support a broader range of date or datetime representations. Our implementation supports all of ciso8601's supported formats, but in principle if another implementation of our query protocol were defined in the future (e.g. in Rust or TypeScript), we'd consider it spec-compliant if it simply supported the guaranteed serialization formats — it would not have to support everything ciso8601 supports.

Big thanks 🙏  to our past selves for having extremely thorough unit tests on all the parsing and serialization stuff. This PR would have been 1000x more difficult to pull off safely without the exceptional test coverage we have.
TL;DR of the current state:

Implicit widening conversions (no loss of precision) from date to datetime are allowed, both in their string representations and as Python objects.
Datetime to date, or timezone-aware to timezone-naive datetime are narrowing conversions, and they remain disallowed since we do not want to implicitly lose precision.
We switched to ciso8601 for all our ISO 8601 parsing, and moved away from arrow. Since pytz was only required for Python 2, we were able to remove that dependency as well.
We clarified the schema spec for the date and datetime types, explicitly promising support for particular string formats while allowing implementations to support a broader range of date or datetime representations. Our implementation supports all of ciso8601's supported formats, but in principle if another implementation of our query protocol were defined in the future (e.g. in Rust or TypeScript), we'd consider it spec-compliant if it simply supported the guaranteed serialization formats — it would not have to support everything ciso8601 supports.

I had to upper-bound bandit due to this regression in bandit==1.7.0: https://github.com/PyCQA/bandit/issues/658
It seems like it's slated to be fixed in v1.7.1, so we should probably upgrade to it when that happens.

I had to upper-bound bandit due to this regression in bandit==1.7.0: https://github.com/PyCQA/bandit/issues/658
It seems like it's slated to be fixed in v1.7.1, so we should probably upgrade to it when that happens.


Partition functionality

Will do a close read of the code, but a first architectural suggestion for readability and maintainability would be to partition this into at least 3 modules:

model (all and only the code relevant to running the GCM)
utils (evaluations, helper fxns [e.g. Hz2Bark], etc)
viz (all the code related to plotting)

also, what may seem like a super nit; separate all module(i.e. top)-level code blocks by 2 lines of whitespace (and more generally take a quick readthrough of PEP8 (https://peps.python.org/pep-0008/) and maybe the Google Python style guide (https://google.github.io/styleguide/pyguide.html)

Thank you so much for taking the time! And for linking those resources. I'm definitely feeling out of my depth with some of this stuff, so your feedback is much appreciated!


Restic 0.8.3 seems to forget --limit-upload after 24 hours or so

Output of restic version
restic 0.8.3
compiled with go1.8.3 on linux/amd64
(This is on CentOS 7.4)
How did you run restic exactly?
RESTIC_REPOSITORY="b2:xxxxx-backups"
WHAT=/jbook/xxxx (This is 787GiB)
restic backup --limit-upload 500 $WHAT
What backend/server/service did you use to store the repository?
B2
Expected behavior
Honor the --limit-upload setting for the duration of the backup.
Actual behavior
For the first 24 hours or so, I can see (using the nethogs command) that restic stays at a little over 400. Then, after 24 hours or so (maybe exactly 24 hours for all I know) it either forgets about that limit or decides to ignore it, and bandwidth goes up to between 800 and 1200. This kills my ISP connection for any other work.
Steps to reproduce the behavior
I've stopped and restarted this thing about 10 times in 10 days. Once restarted, it honors the --limit-upload for a while, but then after a day or so it stops honoring it again and I have to CTL-C it again.
Do you have any idea what may have caused this?
I was hoping someone here could tell me.
Do you have an idea how to solve the issue?
None at all.
Did restic help you or made you happy in any way?
It's quite wonderful, and once this issues goes away I'll probably start naming my pets Restic.

Huh, that is very odd, thanks for the report! Does it happen all the time?
I need to run some long-term tests with the library we're using for limiting, https://github.com/juju/ratelimit

So far it's happened 10 times in a row, with 3 different backup sets.

I've opened an issue for the library we're using https://github.com/juju/ratelimit/issues/27

I was afraid of that.

Suspended it this morning before the 24 hours had passed. Just got home and resumed - it's at 1125.

I know what's happening: The rate limiting library remembers the time stamp when the process was started. Based on that timestamp it computes how much data is allowed for each second. When you suspend and resume the process, much time has passed in between, so the library allows for much data in the next segments.
I'll try to explain this to the authors and try to get it fixed ;)

Hm. I still cannot reproduce it.
@kurin is there anything in blazer that may explain this behavior?

You know what, this actually might be a blazer issue.  After 24 hours the initial auth token expires and blazer grabs a new one; it looks like when it attempts to do that, it fails to pass in client modifications, including modified round-trippers.

Oh, that'd explain it!


Change pooling augmenters to affect map arrays and add tests

Codecov Report

Merging #457 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #457      +/-   ##
==========================================
+ Coverage   95.94%   95.95%   +<.01%
==========================================
  Files          34       34
  Lines       11245    11250       +5
==========================================
+ Hits        10789    10794       +5
  Misses        456      456


Add files via upload

Please kindly provide the full name of your school on the first line of the file in your request

@viditpawar0 Pull request merged. Please start requesting the licenses in about an hour, to let the changes to propagate through our system. Thank you.


[KOGITO-5256] - Fix Knative Trigger creation

Many thanks for submitting your Pull Request :heart:!
See: https://issues.redhat.com/browse/KOGITO-5256
The creation of Knative Triggers was incorrect. The filter must rely on CE Type instead of Kogito Topic name.
Please make sure your PR meets the following requirements:

[x] You have read the contributors' guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains a link to the JIRA issue
[x] Pull Request contains a description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket
[x] Your feature/bug fix has a unit test that verifies it
[x] You've tested the new feature/bug fix in an actual OpenShift cluster
[x] You've added a RELEASE_NOTES.md entry regarding this change

@sutaakar, if you would check this PR, could you please make available the operator image for @mouachan to test it in his environment if you check this PR? Many thanks!!
/jenkins test

/jenkins test

Test failure unrelated, reported as https://issues.redhat.com/browse/KOGITO-5262

Many thanks, @sutaakar! @mouachan  were you able to test it?

Tested by QE and community user, merging!


[test] add area test for linux - [merged]

In GitLab by @perarnau on Mar 28, 2019, 10:46
Merges tests-area -> master
Add tests for area/linux that were disabled during the last refactor.
Includes some fixes on the way.

In GitLab by @perarnau on Mar 29, 2019, 08:41
assigned to @NicolasDenoyelle
By Swann Perarnau on 2019-03-29T13:41:18 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 11:13
added 1 commit
08abb866 - undo last commit
Compare with previous version
By Nicolas Denoyelle on 2019-03-29T16:13:01 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:38
Solved by adding after line 62:
while(!numa_bitmask_isbitset(nodeset, --allowed_last));
By Nicolas Denoyelle on 2019-03-29T15:38:30 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:58
added 1 commit
1dffe970 - 2nd fix swanns request after merge request
Compare with previous version
By Nicolas Denoyelle on 2019-03-29T15:58:47 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:59
added 1 commit
72547564 - slight simplification
Compare with previous version
By Nicolas Denoyelle on 2019-03-29T15:59:45 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 12:58
changed title from {-Tests area-} to {+[test] add area test for linux+}
By Swann Perarnau on 2019-03-29T17:58:18 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 12:58
changed the description
By Swann Perarnau on 2019-03-29T17:58:18 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:39
Can you check for merging now ?
By Nicolas Denoyelle on 2019-03-29T15:39:30 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:40
What I'm saying is that the switch/case with only breaks and a return in the default is a surprising code path. From a maintainability point of view, it makes the code more difficult to read.
Even just putting the test in a different function and just calling it is more readable.
By Swann Perarnau on 2019-03-29T15:40:15 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:41
changed this line in version 2 of the diff
By Nicolas Denoyelle on 2019-03-29T15:41:17 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:31
I updated the header so that mbind is not done inside user area_linux_mmap. Both are exposed as separate pieces.
However, linux.c will define a static area_linux_mmap_mbind which is the default in struct area_linux_ops and in newly created linux_areas.
See next merge request.
By Nicolas Denoyelle on 2019-03-29T15:31:00 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:41
changed this line in version 2 of the diff
By Nicolas Denoyelle on 2019-03-29T15:41:17 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:35
It is not reasonable to match and document each error from error.h in aml, because of maintainability, because some
error code names may be used for different purposes (i.e different blocks) etc...
Thus, in my opinion it is better to return a generic error AML_FAILURE and document the function header with the need
to check aml block specific error handler (i.e linux now) for further checking.
By Nicolas Denoyelle on 2019-03-29T15:35:00 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:41
changed this line in version 2 of the diff
By Nicolas Denoyelle on 2019-03-29T15:41:17 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:41
added 1 commit
5c19792e - fix swanns request after merge request
Compare with previous version
By Nicolas Denoyelle on 2019-03-29T15:41:18 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 12:58
mentioned in commit b9b7efcd4f04a76cd26b6acfaeb9cf3c839605b3
By Swann Perarnau on 2019-03-29T17:58:34 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 11:15
added 1 commit
0f656cd7 - typos
Compare with previous version
By Nicolas Denoyelle on 2019-03-29T16:15:09 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:27
There is no better options to check arguments here. This is falling in the case of few good values for numerous (~int max) bad values. Thus check if it is good else it is bad.
By Nicolas Denoyelle on 2019-03-29T15:27:56 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 11:11
Done!
By Nicolas Denoyelle on 2019-03-29T16:11:58 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 12:58
merged
By Swann Perarnau on 2019-03-29T17:58:34 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 10:42
Well, for a start, if the error code is literally the rename of the standard ones, it probably shouldn't have a buildingblock in its name.
By Swann Perarnau on 2019-03-29T15:42:16 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 08:42
@NicolasDenoyelle as a general rule, try to document what the merge request contains, either with commit messages or, if you intend for the merge to be squashed, a detail merge request description.
By Swann Perarnau on 2019-03-29T13:42:33 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 08:38
If that kind of error conversion becomes commonplace, we should probably think of a better way to handle it.
By Swann Perarnau on 2019-03-29T13:38:27 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 08:37
Not necessary.
By Swann Perarnau on 2019-03-29T13:37:33 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 08:36
I don't think that works if memsets are in action. numa_bitmask_weight is a popcount, not the position of the last bit.
By Swann Perarnau on 2019-03-29T13:36:58 (imported from GitLab project)

In GitLab by @perarnau on Mar 29, 2019, 08:35
Creative use of switch/case, but makes the "normal" control flow quite confusing. Why not just testing the error case ?
By Swann Perarnau on 2019-03-29T13:35:55 (imported from GitLab project)

In GitLab by @perarnau on Aug 6, 2019, 13:56
mentioned in commit b9b7efcd4f04a76cd26b6acfaeb9cf3c839605b3


update campaign_stats.md

Fixes #3089
Checklist

[x] I have made a material change to the repo (functionality, testing, spelling, grammar)
[x] I have read the [Contribution Guide] and my PR follows them.
[x] I updated my branch with the master branch.
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation about the functionality in the appropriate .md file
[ ] I have added in line documentation to the code I modified

Short description of what this PR does:

add 'additional resources' section

If you have questions, please send an email to Sendgrid, or file a Github Issue in this repository.

Hello @thepriefy,Thanks again for the PR! It's HACKTOBERFEST! We want to show our appreciation by sending                                              you some special Hacktoberfest swag. If you have not already, could you please fill out                                              this form so we can send it to you? Thanks!                                             Team SendGrid DX


Add interval parameter to the configuration file

This script should be ran in interval (i.e. every X minutes).
Therefore, we should keep the interval in the configuration file.

Done


Gradle / Maven API access in ReadMe

Hello!
Would it be possible to put the repo information in the ReadMe?
It had taken me way longer than I care to admit to figure out it was hosted here:
https://repo.fancyplugins.de/#/releases/de/oliver/FancyHolograms
Would it also be possible to have 2.0.0 pushed there? As of this issue, it only goes up to 1.1.0.

Hello!
Yes, think plugin doesnt have maven repo, so dev said use next way:

Clone GitHub repo
Build it, using gradle
Copy output plugin jar into .m2 local repo(if its not exist)
Now you can add plugin as dependency

Pushed it into the repo, sorry I forgot to do that.
I'll also put the repo info in the readme aswell, thank you.
If you have any issues with the maven repo, just let me know


Support for api servers behind proxy

Description
A first support for API servers that are reachable only through an HTTP proxy. When a HTTP proxy URL is set in the foreignclusters, the new k8s clients are configured to go through the HTTP proxy.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

[x] Existing
[x] New Unit Tests
[x] End to End with clusters behind proxy (Manually)

/test

/rebase test=true

/rebase test=true

/rebase test=true

/rebase test=true

/rebase test=true

/test

/test

/test

/rebase test=true

/test

/test

/test

/rebase test=true

/merge


Remove version: Google.Chrome.Canary version 127.0.6503.0

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

URL: https://dl.google.com/release2/chrome/acniuhb36gsrdpqzes4ceovucmla_127.0.6503.0/127.0.6503.0_chrome_installer.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 912)


[map] The OpenStreetMap background is either offset or has a problem

Apparently, there is an issue with the alert view: the background map is not displayed correctly.
Here is how it renders:

I've heard suggestions it's because of a recent release of one of the dependencies (probably the ones related to OpenStreetMap). Could someone have a look? :pray:

Fix with new platform version


Added Dockerfile for CUDA compatibility, including test file

Set cuda architecture to ensure that docker file compiles with CUDA on the latest pytorch docker image

@teenaxta could you please share instructions how to run this model in docker? Thanks

For people that run RTX 3060.
Dockerfile.txt
Build with the following command
docker build -t groundingdino:dev .


Added hyperlink

I have no skills in .rst

👍 Merged in 7612f55e47c2f0572b8bcd38ae960622015b90e5

@RobbieClarken Instead of showing the URL, I was thinking something that looked like this.
A python client for retrieving data from an EPICS Channel Archiver.

Updated as suggested. If you are interested, Sphinx has a good page on the reStructuredText syntax.


suggestion: refetch/remove unrefd

Thansk for the great lib ^-^!
Minor suggestion ~
Currently at:
https://github.com/DamianOsipiuk/vue-query/blob/098d08b50d13e44c77b56981ec79b8934d23fb98/src/vue/useBaseQuery.ts#L79
it looks like everything is getting toRefs, maybe it would be a nice idea to skip out on reffing refetch and remove from the reactivity pool since they are both functions.
It makes up for an unusal way to call them.
const query = useQuery({})
query.refetch.value() vs query.fetch()
From the useQuery docs:
refetch: (options: { throwOnError: boolean, cancelRefetch: boolean }) => Promise<UseQueryResult>

    A function to manually refetch the query.
    If the query errors, the error will only be logged. If you want an error to be thrown, pass the throwOnError: true option
    If cancelRefetch is true, then the current request will be cancelled before a new request is made

remove: () => void

    A function to remove the query from the cache.

Thanks for suggestion.
It's already planned for v2 to avoid breaking changes.
https://github.com/DamianOsipiuk/vue-query/issues/124

Awesome looking forward


Update Plugins to stop relying on env variables

After https://github.com/grafana/grafana-aws-sdk/pull/121/files is merged and released, we should update the plugins to not depend on env variables to support multitenancy. Note that this isn't just bumping the version to 0.23.0, they also should use ReadAuthSettings to get the auth settings for an instance and pass that along to GetSession(link a reference to doing that in cloudwatch once its merged)

[ ] Athena
[ ] Redshift
[ ] Timestream
[ ] CloudWatch
[ ] X-ray
[ ] TwinMaker
[ ] SiteWise
[ ] OpenSearch

Closed as Done


refactored to use System, vexflow included

Hi @jaredjj3, I decided to include vexflow tgz to make progress.
Fixes #54
Fixes #42

I hope you like it. We will also have to decide now what to do next? Suggestions?

Great! I'll take a look this weekend.

I hope you like it. We will also have to decide now what to do next? Suggestions?

I have open some issues with missing features. My suggestions on what to do next.

I'm happy to see the deleted code, LGTM :)
Continuing to hunt down the missing features is the right move here. When we have enough of them done, maybe we can think about how everything is architected. But for now, let's keep implementing features.


Nested Dependent tasks are run multiple times

I'd like to reopen this issue https://github.com/microsoft/vscode/issues/43076 as it's basically the same thing except that my task setup is slightly different.
My abridged tasks.json
{
	"tasks": [
		{
			"label": "dev",
			"dependsOn": ["yarn watch", "yarn dev"],
			"isBackground": true
		},
		{
			"label": "yarn watch",
			"dependsOn": ["start container"],
			"isBackground": true
		},
		{
			"label": "yarn dev",
			"dependsOn": ["start container"],
			"isBackground": true
		},
		{
			"label": "start container",
		}
	]
}

Starting "dev" causes "start server" to start twice, they conflict with each other, and then both fail.
My workarounds are

Remove the "dependsOn" property from "yarn dev". This way I can run "dev", wait for the watch to start, then run "dev" again. No different to manually starting the server before running "dev" though.
Globally install "concurrently" and merge the two watch tasks into one.

I don't have a root-level package.json (or equivalent) for this project.

VS Code Version: 1.63.0-insider (user setup)
OS Version: Windows_NT x64 10.0.22000

Same root cause as https://github.com/microsoft/vscode/issues/118238, except this one has a work around:
{
	"tasks": [
		{
			"label": "_dev",
			"dependsOn": ["yarn watch", "yarn dev"],
			"isBackground": true
		},
		{
			"label": "dev",
			"dependsOn": ["start container", "_dev"],
			"dependsOrder": "sequence",
			"isBackground": true
		},
		{
			"label": "yarn watch",
			"isBackground": true
		},
		{
			"label": "yarn dev",
			"isBackground": true
		},
		{
			"label": "start container",
		}
	]
}


Don't compile locales in tests by default

Since we don't compile locales in development and rails assets:precompile, then it should be default that locales aren't compiled in tests either. The old behaviour can be brought back by passing in compile_locales: true to ReactOnRails::TestHelper.ensure_assets_compiled.

This change is

@peterzhu2118 see #1300.

if using the old way, with a custom command, the i18n rake task is run, and that does nothing unless config.i18n_dir.

I haven't realized that the locales aren't compiled when config.i18n_dir is not set. I had config.i18n_dir set in my initializer, the locales aren't compiled in tests when I remove this configuration. I'm not sure if this PR is useful anymore.

Closing because not necessary since there is no performance gain.


No module named "azureml"

Hi - full disclaimer, I havent followed the article to the letter.
I have re-built it using Tensorflow instead of pytorch. I created the yml file and my training.py script.
When I tried to train it ono some CPU cluster, the job failed, stating "no module Azureml".
the reason is that ( I believe) that whenever I call "run.get_context()", i need Azureml to find "run"
Thanks,
Eyas

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

ID: 23f9d033-9007-7b0a-d651-88d5d3846b2a
Version Independent ID: c6efa8cc-8594-698b-21eb-5e4d9ad24bbd
Content: Tutorial: Train your first machine learning model - Python - Azure Machine Learning
Content Source: articles/machine-learning/tutorial-1st-experiment-sdk-train.md
Service: machine-learning
Sub-service: core
GitHub Login: @aminsaied
Microsoft Alias: amsaied

@eyast  Thanks for reaching out. We will investigate and update the thread accordingly.

@eyast the error indicates the Azure ML SDK is not installed correctly on the machine. You might need to follow the step from part 1 of this tutorial to setup your local machine and try again.

@eyast We will now proceed to close this thread. If there are further questions regarding this matter, please tag @RohitMungi-MSFT in your reply.


Test commit

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #
Test URLs:

Before: https://develop--aem-boilerplate-commerce--hlxsites.aem.live/
After: https://scbeta17--aem-boilerplate-commerce--hlxsites.aem.live/

@dpatil-magento to debug on why cypress build did not trigger after repo movement


Update EdgeConnect samples

Description
Update samples for EdgeConnect:

switch API version
add sample for K8s automation
add sample for provisioner mode

How can this be tested?
not. File review will suffice.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 64.01%. Comparing base (d1c57d5) to head (da02caf).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##           release-1.3    #3734   +/-   ##
============================================
  Coverage        64.01%   64.01%
============================================
  Files              374      374
  Lines            20392    20392
============================================
  Hits             13054    13054
  Misses            6037     6037
  Partials          1301     1301

Flag
Coverage Δ

unittests
64.01% <ø> (ø)

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


qtbase: Fix timezone DST calculation

In Qt5 DST calculation for timezone info generated in yocto is broken. Fix is backported from Qt 6.2.
For example, for America/Los_Angeles
for Nov 1, 2021 it's already showing winter time, while in reality winter time starts on Nov 7, 2021.
In desktop generated time zone info is a little bit different, so this bug is not hit on desktop.
Here there is a test project and two timezone files for LA included: one is taken from Mint distro and another is from yocto.
dt-test.zip
Output with normal Qt5 (bug) which is affected with yocto TZ where Nov 1 is already in winter time:
$ ./dt America/Los_Angeles.yocto
QDateTime(2021-10-31 05:00:00.000 PDT Qt::TimeZone America/Los_Angeles.yocto )
QDateTime(2021-11-01 04:00:00.000 PST Qt::TimeZone America/Los_Angeles.yocto )
QDateTime(2021-11-07 04:00:00.000 PST Qt::TimeZone America/Los_Angeles.yocto )

Output with normal Qt5 which is not affected with Mint TZ where Nov 1 is still in summer time:
$ ./dt America/Los_Angeles.mint
QDateTime(2021-10-31 05:00:00.000 PDT Qt::TimeZone America/Los_Angeles.mint )
QDateTime(2021-11-01 05:00:00.000 PDT Qt::TimeZone America/Los_Angeles.mint )
QDateTime(2021-11-07 04:00:00.000 PST Qt::TimeZone America/Los_Angeles.mint )

Output with patched Qt5 with yocto TZ:
$ ./dt America/Los_Angeles.yocto
QDateTime(2021-10-31 05:00:00.000 PDT Qt::TimeZone America/Los_Angeles.yocto )
QDateTime(2021-11-01 05:00:00.000 PDT Qt::TimeZone America/Los_Angeles.yocto )
QDateTime(2021-11-07 04:00:00.000 PST Qt::TimeZone America/Los_Angeles.yocto )

We caught this bug in Dunfell. Also the same bug in Qt 5.12.11, so I assume all Qt 5 has this bug.

It's this change https://codereview.qt-project.org/c/qt/qtbase/+/343933 in dev and 6.2, can you please ask upstream to backport it to 5.15 as well?

I afraid that open source 5.15.2 will not be changed, it's locked. Even if they will change they can do it in commercial release if not already fixed it there (can't check as I don't have commercial license at the moment).

I was asking because the commit in 6.2 looks very different, can you explain the differences? Is 5.15 code that different from 6.2?

Yes, in Qt 6 the timezone was reworked. You can see this two files from 5.15.2 and 6.2.1 in this archive:
qtimezoneprivate_tz.zip
In yocto we hit this bug because of the format of timezone info which needs to use calculatePosixDate() and calculateDowDate() and they had a bug in 5.15.2 (calculated wrong). So, for this patch I take the relevant parts in those two functions from 6.2.1 and used in 5.15.2
In desktop linux distributions zone info these two functions are not used, so normally desktop users are not affected by this bug. Moreover, it's only pops up twice per year, when DST is changing.

Just as example, this is clear bug (5.15.2) when dow will be treated as Mon in Qt world if it's Sun or Mon in zone info world:
        if (dow == 0)
            ++dow;
        return calculateDowDate(year, month, dow, week);

while it should be set to 7 for Qt to treat it as Sun

Added to master-next with small modification (Upstream-Status, adding to nativesdk-qtbase as well). Thanks

Thank you!

Merged, thanks


S3 database location support

Maybe the best way to integration test this is to set a workspace in the structured template to use s3 instead of hdfs, that will test most of the code outside of the controller.


Reload data method.

Hi,
Would it be possible to have a method to reload the dropdown picker? Something similar to tableView's reloadData method. So that when the datasource changes, to call it and to update dropdown's options.
Otherwise, very simple and easy to use control. Thanks!

Just realised it will update the options when reassigning to items.
dropdown.items = @[@"Orange"] does the tricks.

Yes, we designed TPSDropDown like UISegmentedControl component from UIKit. You right, you can reload items when you reset it. If you still have any questions, please, give us know. Thanks


Added target attributes to social icon in index.html

added target attribute to social media icon

Please merge pull request ASAP


Be less greedy in test selection expansion

resolves #2891
Problem
Let's say I have two models (model_a + model_b) and a source table (my_src.my_tbl). There's a unique test defined on a column in model_a, plus two relationships tests—one to model_b, one to my_src.my_tbl—for a total of three tests.
YAML
version: 2

sources:
  - name: my_src
    tables:
      - name: my_tbl

models:
  - name: model_a
    columns:
      - name: id
        tests:
          - unique
          - relationships:
              to: ref('model_b')
              field: id
          - relationships:
              to: source('my_src', 'my_tbl')
              field: id

Today, the following command will select all three tests to run:
$ dbt test -m model_a

That's because dbt test selection is always greedy today, and it performs what I call a "magic jump" (the actual function is named expand_selection). Put simply, dbt says: I see that you've selected model_a, I see that the task is test, so really I'm going to select all tests that are first-order children of model_a. (Doesn't that sound more like --select model_a+1 --resource-type test? Too bad!)
The upshot is, that's really nice syntax if what you're after is dbt run -m model_a && dbt test -m model_a (or someday soon: dbt build -s model_a.) But in the scenario outlined above, since the relationships tests are first-order children of model_a, they get run too—even if model_b is missing! And this puts people in all kinds of awkward situations.
In v0.19.0, we offered a resolution to this conundrum in the CI context with dbt test --defer: If model_b is missing in my sandbox schema, but present in the comparison/production schema, use that one instead! But we could still do a better job here of making test selection intuitive, and making it work outside of CI/deferral contexts, too.
Proposal
Test selection should be less greedy when it comes to multi-parent tests. In particular:

Include a multi-parent test if and only if all its parents are selected (not current behavior)
Exclude a multi-parent test if any parent is excluded (current behavior)

To accomplish this, the PR adds a more formal notion of "greedy" expanded selection:

A greedy property to the SelectionCriteria class, which is set to False for inclusion and True for exclusion. That way, TestSelector.expand_selection can always be greedy for exclusion ("any parent"), but inclusion can be more cautious ("all parents").
A test that would be included greedily/indirectly (1+ parent is selected) is instead kept at arm's length, either until all its parents make an appearance (included), or until all selection criteria have been sorted through and a parent is still missing (not included).

In order to make selection expansion more consistent, this PR also moves expansion out of the test task and into the default selector logic. This way, dbt ls -s [criteria] --resource-type test should always return the tests that would be executed by dbt test -m [criteria].
Per the changes in this PR, here's what happens in various scenarios:

dbt test: Run all tests.
dbt test -m model_a: Run just the unique test. Don't be greedy.
dbt test -m model_a model_b: Run the unique test + the relationships test between model_a + model_b. We "expand" to the relationships test because both parents are selected.
dbt test -m model_a source:*: Run the unique test + the relationships test between model_a + my_src.my_tbl
dbt test --exclude model_b: Skips any tests that are first-order children of model_b. Exclusion should be greedy!
dbt test -m model_a+: Run all tests. All three tests are selected directly, as children of model_a. There's no magic jump / expansion needed. (In a CI context, it's common to dbt test -m state:modified+, so deferral-for-tests still has a role to play.)

Brain teasers [updated!]:

dbt test -m model_a,test_name:unique: Just the unique test on model_a
dbt test -m tag:special,test_name:relationships:

If I've tagged the relationships test, or the column it's defined on, then this will run. In either case, the test itself is tagged 'special' (we can check this in the manifest).
If model_a + model_b are both tagged 'special', their relationships test will run.

Questions

Does any of the scenarios above feel weird, unexpected, or unintuitive?
Should expansion treat source parents differently from model/seed/snapshot parents? Generally speaking, dbt assumes that sources are always present in the database, so we could argue that it's fair to greedily expand selection to tests with one selected parent and another unselected source parent. Concretely: In the scenario above, should dbt test -m model_a also run the relationships test between model_a + my_src.my_tbl?

Checklist

[x] I have signed the CLA
[x] I have run this code in development and it appears to resolve the stated issue
[x] This PR includes tests, or tests are not required/relevant for this PR
[ ] I have updated the CHANGELOG.md and added information about my change to the "dbt next" section.

Do you mind rebasing before merging? I'm hoping that will make all checks green :)

Thanks @gshank @kwigley!
Tagging @drewbanin because I know he has a few thoughts :) and I want to give you a chance to air 'em if you'd like!
In effect, with this PR, test selection boils down to:
(A test node has been selected OR all of a test node's direct parents have been selected) AND NOT (a test node has been excluded OR any of a test node's direct parents has been excluded)

do we know what DBT version this commit will be included in?

@ags2121 This will be in v0.21. You can try it out with v0.21.0-rc1, which we released yesterday :)

thanks! I'm seeing this PR tagged in the 0.20.0 release here under the test section:
https://github.com/dbt-labs/dbt/releases/tag/v0.20.0
was this PR not included in 0.20.0 then?

@ags2121 So sorry! I was getting this PR confused with #3833, which is in v0.21.0-rc1. This PR indeed shipped in v0.20 :)

ah great! thanks 👍


MQTTnet.Extensions.WebSocket4Net uses several outdated and possibly vulnerable dependencies

Describe the feature request
The Library should not use outdated or vulnerable dependencies.
Currently not maintained dependencies:

WebSocket4Net
SuperSocket.ClientEngine.Core
System.Net.Security
System.Security.Cryptography.X509Certificates (High Risk Vulnerability: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-0057)

Which project is your feature request related to?
MQTTnet.Extensions.WebSocket4Net
Describe the solution you'd like
Outdated dependencies should be replaced by ones that are actively maintained.
Describe alternatives you've considered
None
Additional context
Dependency Graph of the Library:

It seems that WebSocket4Net is no longer maintained. The latest release is from 2018. So, I am afraid there is not much we can do about it. The only reason for having this extension is that the web socket implementation in the .NET Framework does not support several encryption algorithms.
For me the only option is to get rid of that extension completely. Or do you have another suggestion?

I don't know what the Library WebSocket4Net does, I just found out about the vulnerability through our toolset. I don't really have a suggestion apart from using a different library or creating necessary code to implement the missing features.
Is there an alternative way to use mqtt via websocket?

Starting with version <IP_ADDRESS> of this library the library WebSocket4Net will no longer be used because the extension library is no longer provided.


[Proposal] Contribute to a benchmark

Hi,
I'm leading a benchmarking project => https://github.com/the-benchmarker/web-frameworks
The purpose of this project is to compare performances (other indicators will come), based on a fairest, as we can, comparison for rust frameworks (comparing on the same version, for example).
Do you mind that I (or any member) add tide  ? :heart:
Regards,

We had a discussion about this recently about techempower's benchmark, and decided we'd rather wait for now - it would be nice to make an initial splash, sort of as marketing, but tide is still in a good amount of flux and perf is not top of mind atm.

I can understand this. The scenario is very simple for us => https://github.com/the-benchmarker/web-frameworks/blob/master/CONTRIBUTING.md (will be changed in the future).
No extra work are asked, we are taking care of updates ...
However, if you think it is too early regarding tide, I propose to close this issue, for now, and let you re-open it when time will come


Audubon Core Maintenance Group call 20:00 UTC, Wednesday, April 14, 2021

The Audubon Core Maintenance Group will have an online meeting at 20:00 UTC Wednesday, 2021-04-14. That corresponds to 4:00 PM Wednesday Eastern (US) Daylight Time (New York), 3:00 PM Wednesday Central (US) Daylight Time (Chicago), 10:00 AM Hawaii Standard Time (Honolulu), 9:00 PM Wednesday, British Summer Time (London), 10:00 PM Wednesday, Central European Summer Time (Amsterdam), and 6:00 AM Thursday Australian Eastern Standard Time (Canberra).
At this meeting, we will discuss action items and timeframes for adopting atomic terms necessary to define segmentation in audio, video, and still images. We will also discuss what still needs to be done on the still image and sound examples guides, and when we might consider them "finished" and ready to be announced.
Meeting details:
Join Zoom Meeting
https://vanderbilt.zoom.us/j/95770093410
Meeting ID: 957 7009 3410
Find your local number: https://vanderbilt.zoom.us/u/acKWFRh7P
Add to Google Calendar
Download Outlook .ics calendar invitation

This is a reminder that the Audubon Core Maintenance Group is meeting soon (Wednesday April 14) at 20:00 UTC. For local times, connection details, and agenda items, see https://github.com/tdwg/ac/issues/196

The notes from this meeting have been uploaded to https://github.com/tdwg/ac/blob/master/historical/2021-04-14-meeting-notes.pdf


Validate the generated repo against their schema

@larioj check it out.

Just one minor comment. How did you test this changes?

@larioj I manually ran validate-packages.py and gen-universe.py. Both "Mesosphere repo validation" and "ci" should run those scripts too.


Image upload is not working in Safari

Hi!
I was testing the plugin in a Mac when I noticed that the image upload isn't working for Safari Version 8.0 (10600.1.25) in Mavericks OSX .
I've uploaded a video to show you the problem. I tried it in the github editor and in my own implementation and both have the same error. I've been trying to find the possible origin of the problem but couldn't figure it out.
I would distinct two problems;

[x] Drag and drop not working
[x] Images are displayed as small but are full size images from the server

Do you know where it could be the problem ?
Thanks and again , awesome work !

I've hacked image drop support into my Medium Insert install. Here's some code for those who care:
// medium is your medium instance
// you need to init medium-insert before this also

medium.subscribe('editableDrop', function(e, element) {
  if (e.dataTransfer.files.length < 1) {
    return true;
  } else {
    return handleImageDropped(medium, e, element);
  }
});

var handleImageDropped = function(e, element) {
  var data, file, fileUploadOptions, imagePlugin;
  data = e.dataTransfer.files;
  imagePlugin = $.data(element, 'plugin_mediumInsertImages');
  file = $(imagePlugin.templates['src/js/templates/images-fileupload.hbs']());
  fileUploadOptions = {
    url: imagePlugin.options.uploadScript,
    dataType: 'json',
    acceptFileTypes: /(\.|\/)(gif|jpe?g|png)$/i,
    formData: imagePlugin.options.formData,
    dropZone: null,
    add: function(e, data) {
      $.proxy(imagePlugin, 'uploadAdd', e, data)();
    },
    done: function(e, data) {
      $.proxy(imagePlugin, 'uploadDone', e, data)();
    }
  };
  if (new XMLHttpRequest().upload) {
    fileUploadOptions.progress = function(e, data) {
      return $.proxy(imagePlugin, 'uploadProgress', e, data)();
    };
    fileUploadOptions.progressall = function(e, data) {
      return $.proxy(imagePlugin, 'uploadProgressall', e, data)();
    };
  }
  file.fileupload(fileUploadOptions);
  file.fileupload('add', {
    files: data
  });
  return false;
};

Where to write this hacked code?


[ZEPPELIN-572] pyspark interpreter doesn't work on yarn-client

What is this PR for?
Set spark.yarn.isPython to be true to distribute pyspark libraries to workers when master is yarn-client
What type of PR is it?
Bug Fix
Is there a relevant Jira issue?
ZEPPELIN-572
How should this be tested?
You need yarn cluster to test this PR.
Simple way to test this PR would be running below code in paragraph and see if it throws error.
%pyspark
print(sc.parallelize([1, 2]).count())

And you should be able to see that spark.yarn.isPython is set to true in Spark UI > Environment > Spark Properties only when you set spark.master as yarn-client.
Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

+1

Tested, +1

LGTM

LGTM

Although release branch 'branch-0.5.6' is created by https://issues.apache.org/jira/browse/ZEPPELIN-567, I think this change worth to apply 0.5.6. Shell we merge it into both master and 'branch-0.5.6'?

If there're no more discussions, i'm merging it into 'branch-0.5.6' and 'master'

Sure.

Since 0.5.6-incubating rc1 is in vote alreay, i'm merging it into master only. we can merge it into branch-0.5.6 anytime we want.

Looks great, thank you. It definitely belongs to 0.5.6, will merge it there.

This PR have apply in 0.5.6 ?  spark.yarn.isPython=true must be set in zeppline-env.sh

@darionyaphet 0.5.6 includes this patch

Hi @Leemoonsoo It seem not effective .
I build Zeppelin using command :
 mvn package -Pspark-1.5 -Dspark.version=1.5.0  -Pyarn -Ppyspark -DskipTests
When I using yarl-client to startup pyspark job I found it's not work .
I must add ZEPPELIN_INTP_JAVA_OPTS="-Dspark.yarn.isPython=true" in conf/zeppelin-env.sh

Are you sure you are setting master to yarn-client?
On Wed, Apr 6, 2016 at 8:27 PM -0700, "yaphet"<EMAIL_ADDRESS>wrote:
Hi @Leemoonsoo It seem not effective .
I build Zeppelin using command :
 mvn package -Pspark-1.5 -Dspark.version=1.5.0  -Pyarn -Ppyspark -DskipTests
When I using yarl-client to startup pyspark job I found it's not work .
I must add ZEPPELIN_INTP_JAVA_OPTS="-Dspark.yarn.isPython=true" in conf/zeppelin-env.sh

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-zeppelin/pull/605#issuecomment-206680628

@felixcheung Yep , I'm using yarn-client

Hi all,
I can confirm, using release 0.5.6 and external Spark 1.5.1 cdh 5.5, I must add to zeppelin-env.sh ZEPPELIN_INTP_JAVA_OPTS="-Dspark.yarn.isPython=true" with master yarn-client
Maybe it's better to add it in the documentation?
Cheers,
Luca

@H4ml3t Sorry for the confusion, I also confirmed that this commit is not included in 0.5.6 binary package by checking source code in http://www.apache.org/dyn/closer.cgi/incubator/zeppelin/0.5.6-incubating/zeppelin-0.5.6-incubating.tgz. Thanks for reporting, I will update the doc


Old version on cocoapods

Hi,
The version available on cocoapods is 1.0.0. Can you update to 1.1.1 please ?
Thank you

Apologize for the delay. Just pushed the new version to CocoaPods now.


Don't enable xtensa-lx/spin

Nothing seems to use it and the spinlocking mutex implementation doesn't exactly belong in xtensa-lx so I'm planning to remove it from there.

Let's hold off merging this for a bit, I want to be 200% sure I'm not breaking the whole HAL.


how get mairesse file

how you obtain data in mairesse.csv file

@SenticNet

The link to the generator is given in the pre-processing section of readme.


typo in restore docs

Closes #1758

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/d0981393f4ff5e012578549689a7eee3135d0cc2/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/d0981393f4ff5e012578549689a7eee3135d0cc2/


Prefix management commands

The update_index management command is already clashing with haystack's.
AFAIC wagtail management commands could be prefixed with 'wt_' to prevent this in the future.

Thanks for pointing this out!
Django uses argparse which supports subcommands. So it may be possible to have a syntax like python manage.py wagtail update_index
Another possibility could be to add new subcommands to our wagtail command for these. Eg wagtail manage update_index or just wagtail update_index

:+1:

I like the suggestion of python manage.py wagtail update_index, it's easy to remember.
If people want shortcuts, they can always add some alias in their shell's configuration. It's no more than alias wt='python manage.py wagtail'

We've decided to go with manage.py wagtail update_index, with deprecations.


Clarifying template documentation

In the "developing template engines" example, adjusting code to return template errors to the callback. This clarifies the first argument is used for errors (which is standard notation, but non-obvious in the example).

Great. Arigatou gozaimasu!


[4.4] Can't compile template_release for Windows with mono enabled

Tested versions
4.4 mono master (https://github.com/godotengine/godot/commit/02b16d2f544e323b7b7f57e6e992b0b8e5d8b954)
System information
Godot v4.4.dev.mono - Linux Mint 22 (Wilma) - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 Ti (nvidia; 535.183.01) - Intel(R) Core(TM) i9-14900K (32 Threads)
Issue description
Looks like https://github.com/godotengine/godot/pull/88803 broke release template compilation for Windows when the mono module is enabled.
Tested building on Linux Mint 22 (based on Ubuntu 24.04), Ubuntu Server 22.04 and Windows 10.
template_release with platform=windows always fails, building template_release for Linux works fine.
Editor is building fine for Windows and Linux.
After reverting https://github.com/godotengine/godot/pull/88803 locally, building works again as expected.
Steps to reproduce

run this command: scons p=windows arch=x86_64 module_mono_enabled=yes target=template_release
notice error message

Minimal reproduction project (MRP)
no MRP, clone latest master and try building

My bad, I only tested building the templates for Android and Linux where char_t = char. It's only on Windows that char_t = char16_t so I missed this.
It looks like the coreclr_initialize and coreclr_create_delegate always use char on every platform (unlike the hostfxr APIs that use char_t).


Unicode issue when migrating data from Python to Mimir

The following code is adding no data, just deleting irrelevant columns, but triggers a unicode error when exporting data back into Vizier/Mimir
# Get object for dataset with given name.
ds = vizierdb.get_dataset('shipments')

projection = [ "IMO_CODE", "PORT_OF_DEPARTURE", "DATE" ]

# Iterate over list of dataset columns and print column name
for col in ds.columns:
    print col.name
    if col.name not in projection:
        ds.delete_column(col.name)

# Update existing dataset with given name.
vizierdb.update_dataset('shipments', ds)

The script uses the following dataset: https://github.com/UBOdin/mimir/blob/master/test/data/cureSource.csv and produces the following error
UnicodeEncodeError:('ascii', u'P\ufffdGGSTALL, AUSTRIA', 1, 2, 'ordinal not in range(128)')

This should work now.
As a side note: the list of columns in variable ds changes as you delete columns. Thus, your code will likely create a dataset that contains more than the three columns in the projection list. Also, since the dataset has multiple columns with the same name ds.delete_column(col.name) will raise an exception at some point. An alternative is to use the column index when deleting the column:
Get object for dataset with given name.
ds = vizierdb.get_dataset('shipments')
projection = [ "IMO_CODE", "PORT_OF_DEPARTURE", "DATE" ]
Iterate over list of dataset columns and print column name
col_index = 0
for col in list(ds.columns):
print col.name
if col.name not in projection:
ds.delete_column(col_index)
else:
col_index += 1
Update existing dataset with given name.
vizierdb.update_dataset('shipments', ds)
I also added a simple 'Filter Columns" operator to Vizual that could do the projection.


More robustness for exception handling

As reported in #51, there are several cases where exceptions are raised without descriptive messages, and that do not match OsbsException.
This commit makes several improvements:

The osbs.api.OSBS API functions are now decorated by @osbsapi, which
ensures exceptions raised will match OsbsException.
Exceptions while handling chunked HTTP responses now correctly raise
OsbsNetworkException or OsbsException as appropriate.
Configuration errors now also raise OsbsException, and there are some
test cases for this.
The command-line interface describes network errors more fully.

I really like this, awesome job!

Thanks. OK, @wraps added, and now repr() is used when chaining up to OsbsException.


Updated parameterization template

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

#sign-off


go fmt code

format code

Codecov Report

Merging #1730 (272bbf3) into dev (3291924) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev    #1730   +/-   ##
=======================================
  Coverage   13.56%   13.56%
=======================================
  Files         109      109
  Lines       10658    10658
  Branches      152      152
=======================================
  Hits         1446     1446
  Misses       9089     9089
  Partials      123      123

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 3291924...272bbf3. Read the comment docs.

Codecov Report

Merging #1730 (272bbf3) into dev (3291924) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev    #1730   +/-   ##
=======================================
  Coverage   13.56%   13.56%
=======================================
  Files         109      109
  Lines       10658    10658
  Branches      152      152
=======================================
  Hits         1446     1446
  Misses       9089     9089
  Partials      123      123

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 3291924...272bbf3. Read the comment docs.


Fix issue with module overrides - [merged]

In GitLab by @Asacolips on Apr 23, 2023, 16:27
Merges fix/module-overrides -> master

Refactored how module overrides for the sheet config are handled. With
the new setup, the overrides are only applied for GM users. Those
settings are then saved to the system settings which are used by
player clients.

In GitLab by @Asacolips on Jun 11, 2023, 14:52
mentioned in commit cef8a985f96eea48a1b56d5981ecbe5540eed8c9

In GitLab by @Asacolips on Apr 23, 2023, 17:26
added 1 commit
8cd5b53d - Bugfixes
Compare with previous version

In GitLab by @Asacolips on Jun 11, 2023, 14:51
added 1 commit
cbf08ee3 - Update manifest
Compare with previous version


Make more base nodes thread safe (WIP)

Ongoing work to make more of the base nodes thread safe.

Great work.
There's something I'm not very fond of: non-group processing has to pay the cost of acq-rel. And it's hard to tell how bad that it versus the alternatives without benchmarking on various platforms. However, I'd still suggest that dirty, xform_dirty, etc. were treated as non-atomics, relaxedly during regular processing. Such dual identities could be achieved via type-punning; e.g.:
union {
    SafeFlag atomic;
    bool regular;
} xform_dirty;

For SafeNumeric we already have SAFE_NUMERIC_TYPE_PUN_GUARANTEES() that could be leveraged. We could have a similar one for bool.
Not a blocker for this PR, but I strongly suggest to have it considered.

@RandomShaper It makes sense, it would be good if you want to do this as a subsequent PR (for Control, Node2D and Node3D).

Thanks!


[BUG] VM cannot fully utilize the defined Resource Quota (Memory Limit)

Describe the bug
When you are deploying Virtual Machine in namespace, and put the VM Memory size same as is in the Namespace Resource Quota, it will not deploy the Virtual Machine.
To Reproduce
Steps to reproduce the behavior:

Set up Project + Namespace Resource Quota - Memory Limit for some amount of MiB (in this example 24576 MiB)
Create Virtual Machine in the same Namespace with same size of Memory (in this example 24 GiB)
Virtual Machine is in state Off with error
1. Dismiss it failed to create virtual machine pod: pods "virt-launcher-vmname-2kqnr" is forbidden: exceeded quota: default-r5pw6, requested: limits.memory=26101153793, used: limits.memory=0, limited: limits.memory=24Gi

Expected behavior
Virtual Machine is created with 24 GiB (showing in UI 24 Gi)
Additional context
Apparently the Pod also contains management processes which require memory too, but those are not count towards the VM's allocated memory. The easy fix is to leave about ~400MiB per VM available, but it is not documented.

Harvester has mentioned the VM memory overhead on document https://docs.harvesterhci.io/v1.3/rancher/resource-quota/#overhead-memory-of-virtual-machine.
I will update it with more details.

Besides the document PRs to explain the causes and workarounds, further enhancments will be done via:
Have a more user-freindly UI to show what's used and what's left.


fix(container) throw when key is undefined or null

Early detection of invalid registration calls improves the development experience.
Fixes #17

my change repeats this a several times:
if (key === null || key === undefined)
  throw new Error('key cannot be null or undefined.');

let me know if you'd prefer to see this refactored to use a method call- ie:

validateKey(key);  // <-- guarding the public api
. . .

function validateKey(key) {
  if (key === null || key === undefined)
    throw new Error('key cannot be null or undefined.');
}

No need to refactor. Since we need the container to be as fast as possible, I'm ok with inlining it and not having the extra function call.


Use pebble notices instead of retrying until the workload is up.

Issue
We have extra complexity of adding retries using tenacity to wait until the workload is ready. We also block the hook execution queue until its up or we've exhausted all retries.
Solution
A better solution would be to replace the retry logic with pebble notices to unblock the hook execution and be notified with a custom pebble notice event when our workload is up. Then, we could reflect that in our charm's status.
We'll define a pebble service workload-ready that is disabled by default. When we try to start/restart the pebble workload service, we'll also start the workload-ready service. What that will do is keep trying to ping our pebble check ready which will report if the workload is ready or not. Once that is up, workload-ready will fire a pebble notice which will be observed by our worker to stop that service (to prevent a continuous unnecessary loop of "up" notices).
Future enhancements
Currently, the way we implement notices is to notify that the workload is up after it has started, but doesn't fire notices when the workload goes down.
Testing Considerations

git clone https://github.com/canonical/tempo-worker-k8s-operator.git
git clone https://github.com/canonical/tempo-coordinator-k8s-operator.git
cd tempo-worker-k8s-operator
in requirements.txt, replace cosl>=xx with cosl@git+https://github.com/canonical/cos-lib@OPENG-2871
add git as part of the build-packages in charmcraft.yaml
charmcraft pack
cd tempo-coordinator-k8s-operator
run TEMPO_WORKER_CHARM=/path/to/tempo-worker-k8s_ubuntu-22.04-amd64.charm tox -vve integration

Decided to drop this and instead wait for juju 3.6 stable so we can use the check-failed and check-recovered events to achieve the same.


Improve FreeBSD support

Detect JAVA_HOME automatically as advised by man javavm if not set
Avoid a compile-time error on FreeBSD 10.3-RELEASE along with clang if the
OS-specific include directory is not passed to the preprocessor, BSD/OS is dead for 15 years+ and does not correspond to modern BSDs like FreeBSD or OpenBSD. See config.sub.

Both compiles now perfectly on FreeBSD 9 and 10 in 32 bit and 64 bit, Java 7 and Java 8.
Error with clang (FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512, Target: x86_64-unknown-freebsd10.3, Thread model: posix):
configure:11640: JAVA_HOME was set, checking to see if it's a JDK we can use...
configure:11645: checking if '/usr/local/openjdk8' is a JDK
configure:11706: cc -c -g -O2  -I/usr/local/openjdk8/include conftest.c >&5
In file included from conftest.c:21:
/usr/local/openjdk8/include/jni.h:45:10: fatal error: 'jni_md.h' file not found
#include "jni_md.h"
         ^
1 error generated.
configure:11706: $? = 1

Working library:
$ file ./target/native-build/target/lib/libjansi-1.7-SNAPSHOT.so
./target/native-build/target/lib/libjansi-1.7-SNAPSHOT.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, not stripped

@chirino Can you have a look please? I'd like to upstream everyhting into Jansi associatd with FreeBSD.

Thanks!

@chirino Thank you. Looking forward to the next release to solve fusesource/jansi-native#5.

Just cut 1.14


Minor citation style improvement

The citation now follows the usual Google Scholar style (displaying the "Journal" as Arxiv, and categorizing the paper as @article which seems to be better in Latex). Also, I added a note which redirects to the project page~

Great!


Reorganise registers into 125 blocks

The new 1.5 version of the integration uses the pysolarman library which is stricter with the protocol. In this case, we were requesting more than 125 registers at a time, so it failed on the new update. So we need to restructure the requests to only request a max of 125 registers.

well, that is good to know.
thanks you for the heads up!

Thanks for your work.
So you've created a new config file that will work with the new integration or is this still a work in progress?

I just updated a bit the one we had to properly conform to the modbus
protocols l. It works for me currently as before the update.
El sáb, 9 sept 2023 16:07, Jay Bee @.***> escribió:

Thanks for your work.
So you've created a new config file that will work with the new
integration or is this still a work in progress?
—
Reply to this email directly, view it on GitHub
https://github.com/StephanJoubert/home_assistant_solarman/pull/393#issuecomment-1712520075,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABPWJDW3HDN7MOWLGZQ47LXZRZY7ANCNFSM6AAAAAA4QNWRNI
.
You are receiving this because you authored the thread.Message ID:
@.***>

The new 1.5.1 does not work on my KStar. I need to roll back pronto to the old 1.4.3. How do I do this?

Can there be an update to include inverter time in the definitions?
I'd like to keep track for when the inverter time is out of sync so that I can update it.
I have automations that are dependent on exact timings.
Thanks.

Could be.
I think the inverter time is stored in the registers 3239 to 3244, but the doc says it's stored in BCD code (??). That means each part of the date/time is stored in a a different register, so a helper template would also be needed to merge all those numbers back into a date/time. That helper can't be included in the definition file.

I remember converting it to 24hr time when I used pysolarmanv5 to query the inverter before using the solarman integration. I just don't want to make a mess of the KStar definition now that it's in blocks of 125, which I don't really understand.

Do you guys know how to WRITE values to the Kstar, specifically I'd love to be able set it to charge with different current values  or not do anything at all. My hardware hack was using External relays and contactors but would much prefer to just control the inverter directly, I can do this from the solarman website but I cant user HA automations with the website which is why I have the separate contactors and relays. I was hoping there would be some enitities where I could enter values in or some sliders and toggles for the different modes etc.

Do you guys know how to WRITE values to the Kstar, specifically I'd love to be able set it to charge with different current values or not do anything at all. My hardware hack was using External relays and contactors but would much prefer to just control the inverter directly, I can do this from the solarman website but I cant user HA automations with the website which is why I have the separate contactors and relays. I was hoping there would be some enitities where I could enter values in or some sliders and toggles for the different modes etc.

You need the Solarman 1.5.1 integration to write to the inverter. That integration does not work for me so I have no experience of it as I still use 1.4.3
You can use pysolarmanv5 with a Python wrapper and write your own routines. I have not attempted that yet so I wouldn't know how to help you. Maybe someone else can on the pysolarmanv5 GitHub page.


Feat/e2e testing for article sorting

✨ Codu Pull Request 💻
Pull Request details

Add Playwright tests for sorting on the article page

Run test for three sorting modes -  "Newest", "Oldest" and "Top"

Like count added to ArticlePreview

I was required to pass the like count to the component, so If it non-zero, I display it on the Article preview with the heart icon.

I also added the count as a data attribute, so we can easily remove this if you dont like how it looks.

Any Breaking changes

None

@JohnAllenTech, this one good to go?


ISD-2788 Add mas database integration

Add mas-database integration to provide postgresql to MAS. The charm will block until this integration is established.
This PR also introduce the concept of charm state with multiple components, each can be instantiated separately.
Currently the charm only create a second instance of DatabaseObserver and a new charm state component MASConfiguration that stores the datasource.
This PR also reworks how charm state is created and validated. I removed the inject_charm_state decorator and replace it with a validate_charm_state decorator that only does exception handling and setting the unit to the correct state.
Initializing the charm state components is now done explicitly in each hook methods, and the exceptions raised from that is caught and handled by the decorator. Otherwise it will flow naturally and make the charm go into an error state.
Checklist

[x] The charm style guide was applied
[x] The contributing guide was applied
[x] The changes are compliant with ISD054 - Manging Charm Complexity
[x] The documentation is generated using src-docs
[x] The documentation for charmhub is updated.
[x] The PR is tagged with appropriate label (urgent, trivial, complex)

Many things in one PR :eyes: Is it expected to have charm configurations related to MAS?

Many things in one PR 👀 Is it expected to have charm configurations related to MAS?

@amandahla I have plans to move some charm config like enable_password_config to the MAS charm state since it only concern MAS. In the future we might also look at adding config to allow users to modify the oidc subject claim so that if they switch oidc providers the local users can still be detected.


incorrect polish translations

these translations are not correct.
unfortunately i can only read a bit of polish,
but i am not a fluent speaker, and i don't have
any developer friends speaking polish.
i think removing these translations is better
than to have the misleading ones.

ah, sorry, i just saw #206, closing this one


old metric not send to "remote_write"  when set out_of_order_time_window at version 2.39.1

What did you do?
as https://github.com/prometheus/prometheus/releases said,  2.39.0 support "TSDB: Add support for ingesting out-of-order samples. This is configured via out_of_order_time_window field in the config file"
i download 2.39.1, wish to use pushgateway to send old metric which is 1 day older than current time

so set "out_of_order_time_window: 1d",   and also config the "remote_write",

so prometheus should finally send these old metrics to my remote DB

for example current time is October 27 14:24,  i want to send metric with timestamp 10/26 14:24

i found prometheus can receive these metric, and can query at "http://<IP_ADDRESS>:9090/graph",

but "remote DB" does not receive any metric

after debug, i found at the function "func (w *Watcher) readSegment(..)" of file prometheus/tsdb/wlog/watcher.go, it do the follow check
for i, s := range samples {
    if s.T > w.startTimestamp {
        if !w.sendSamples {
            w.sendSamples = true
            duration := time.Since(w.startTime)
            level.Info(w.logger).Log("msg", "Done replaying WAL", "duration", duration)
        }
        samplesToSend = append(samplesToSend, s)
    }
}

and the value of w.startTimestamp is set at "(w *Watcher) loop()" which is started by "(w *Watcher) Start()"
func (w *Watcher) loop() {
	defer close(w.done)
	// We may encounter failures processing the WAL; we should wait and retry.
	for !isClosed(w.quit) {
		w.SetStartTime(time.Now())
 ......
	}
}

the call stack is follow:
github.com/prometheus/prometheus/tsdb/wlog.(*Watcher).Start (prometheus/tsdb/wlog/watcher.go:184)
github.com/prometheus/prometheus/storage/remote.(*QueueManager).Start (prometheus/storage/remote/queue_manager.go:740)
github.com/prometheus/prometheus/storage/remote.(*WriteStorage).ApplyConfig (prometheus/storage/remote/write.go:214)
github.com/prometheus/prometheus/storage/remote.(*Storage).ApplyConfig (prometheus/storage/remote/storage.go:84)
github.com/prometheus/prometheus/storage/remote.(*Storage).ApplyConfig-fm (:1)
main.reloadConfig (prometheus/cmd/prometheus/main.go:1220)
main.main.func21 (prometheus/cmd/prometheus/main.go:969)

so the reason "why remote DB which is set by remote_write can't receive old metric  when config out_of_order_time_window at same"  is:

Watcher.startTimestamp is set to time.Now() which is Watcher's goroutine start time
but when we config out_of_order_time_window, so it should be  time.Now() - out_of_order_time_window

there are several cases need to consider:

at start time

set "out_of_order_time_window"
not set "out_of_order_time_window", so conf.StorageConfig.TSDBConfig is nil

after start, sometimes later,

add or modify "out_of_order_time_window", then reload using "curl -X PUT http://<IP_ADDRESS>:9090/-/reload"
remove "out_of_order_time_window", then reload using "curl -X PUT http://<IP_ADDRESS>:9090/-/reload"
add a new "remote_write", or modify a "remote_write"
"remote_write" is not change

when reload,  we need to consider which is better:

baseTime is still old "Watcher's goroutine start time", then   Watcher.startTimestamp = old-start-time - new_out_of_order_time_window
baseTime change to  reload trigger time, then  Watcher.startTimestamp  =  time.Now() - new_out_of_order_time_window

according to the code of "func (rws *WriteStorage) ApplyConfig(conf *config.Config)" at storage/remote/write.go,

if some RemoteWriteConfig not change, it only NewWriteClient and update "newQueues[hash] = queue", not NewQueueManager and not add to newHashes
so we can't use function "NewQueueManager" for reload case

func (rws *WriteStorage) ApplyConfig(conf *config.Config) error {
//......
	for _, rwConf := range conf.RemoteWriteConfigs {
		hash, err := toHash(rwConf)
		// ......
		c, err := NewWriteClient(name, ..)
		//.......
		queue, ok := rws.queues[hash]
		if externalLabelUnchanged && ok {
			// Update the client in case any secret configuration has changed.
			queue.SetClient(c)
			newQueues[hash] = queue
			delete(rws.queues, hash)
			continue
		}
		newQueues[hash] = NewQueueManager(...)
		newHashes = append(newHashes, hash)
	}
        //.......
	for _, q := range rws.queues {
		q.Stop()
	}

	for _, hash := range newHashes {
		newQueues[hash].Start()
	}

	rws.queues = newQueues
	return nil
}

my current solution is modify 3 place, but maybe there are better ways:

add function "(t * QueueManager) setOutOfOrderTimeWindow" to file storage/remote/queue_manager.go

func(t * QueueManager) setOutOfOrderTimeWindow(ms int64) {
	t.watcher.SetStartTime(time.Now().Add(time.Duration(-ms *time.Millisecond.Nanoseconds())))
}

modify "func (rws *WriteStorage) ApplyConfig(conf *config.Config)" at storage/remote/write.go to

func (rws *WriteStorage) ApplyConfig(conf *config.Config) error {
//......
	for _, q := range newQueues { //add these 5 lines of "for"
		if conf.StorageConfig.TSDBConfig != nil {
			q.setOutOfOrderTimeWindow(conf.StorageConfig.TSDBConfig.OutOfOrderTimeWindow)
		}
	}

	for _, hash := range newHashes {
		newQueues[hash].Start()
	}
//.........
}

modify "func (w *Watcher) loop()" tsdb/wlog/watcher.go, change "w.SetStartTime(time.Now())" to

	if w.startTimestamp == 0 {
		w.SetStartTime(time.Now())
	}

What did you expect to see?
if set "out_of_order_time_window" ,  prometheus should send old metric to "remote_write"
What did you see instead? Under which circumstances?
both v 2.39.1 and master code at 2022-10/27 has this problem
when set  "out_of_order_time_window: 1d" and "remote_write", old metric can't send to  "remote_write" DB
System information
Ubuntu 20.04.5 LTS
Prometheus version
both prometheus 2.39.1  and current master(2022-10-27 13:58) has this problem

prometheus, version 2.39.1 (branch: heads/v2.39.1, revision: dcd6af9e0d56165c6f5c64ebbc1fae798d24933a)
  build user:       ..
  build date:       20221027-01:18:21
  go version:       go1.19.1
  platform:         linux/amd64

prometheus, version 2.39.1 (branch: main, revision: fa6e05903fd3ce52e374a6e1bf4eb98c9f1f45a7)
  build user:       ....
  build date:       20221027-04:54:19
  go version:       go1.19.1
  platform:         linux/amd64

Prometheus configuration file
global:
  scrape_interval:     15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "Pushgateway"
    static_configs:
    - targets:
      - '<IP_ADDRESS>:9091'
storage:
  tsdb:
   out_of_order_time_window: 1d
remote_write:
  - url: "http://<IP_ADDRESS>:9050/prometheusremotewrite"

Alertmanager version
No response
Alertmanager configuration file
No response
Logs
No response

Hello @jian2008,
This indeed looks like something we need to dive in. This week is the PromCon so everyone is a bit busy. I'll try to get to this as soon as I get some time back.

hi @jesusvazquez
ok,  thanks!

Hi @jesusvazquez,
Do you want to fix this issue ASAP?

Hello, I'm blocking some time to look into this today.
Some early thoughts: The out-of-order feature introduced a new type of write log called write behind log (WBL) so I need to see if we need to extend the QueueManager to have two watchers or if we can go with one of your proposed solutions. Need to familiarize with this bit of code first.

I'm going to try to write a test as our baseline to effectively confirm that its failing today and then we use it for validating our solutions.
Once we have the test we can then agree with the TSDB maintainers on what is the best solution for this.

Looping in @cstyan and @csmarchbanks since things here are closely tied to remote write.

Lots of time has gone by with no update, and I'm fairly sure people are using remote-write with out-of-order data; can we close this?

IIRC there was still some issue related to OoO and remote write, I will confirm with @jesusvazquez

We're doing a mentorship on OOO so I'm adding this to it. I think the issue is present when you chain up prometheus doing remote write but I need to double check that.

Hello from the bug scrub!
@jesusvazquez what was the result of your double-checking?