anki: 2.1.15 -> 2.1.40 (fixes #112849) [DRAFT for others to pick up]

Motivation for this change
#112849
Things done
I tackled some of the required changes, mostly owing to upstream's directory reorganization. However, I then noticed that upstream has switched to a new build system (bazel). Right now I unfortunately don't have the time to deal with the changes required by this switch.
Note that at the moment, this pull request is not fit for merging! The main executable does not start.

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

Result of nixpkgs-review pr 112921 at 9501094a run on x86_64-linux 1

1 package failed to build:

ankisyncd

2 packages built:

anki
mnemosyne

1 suggestion:

warning: unused-argument
Unused argument: fetchpatch.
Near pkgs/games/anki/default.nix:7:3:
  |
7 | , fetchpatch
  |   ^

Result of nixpkgs-review pr 112921 at 9501094a run on aarch64-linux 1

1 package failed to build:

ankisyncd

2 packages built:

anki
mnemosyne

1 suggestion:

warning: unused-argument
Unused argument: fetchpatch.
Near pkgs/games/anki/default.nix:7:3:
  |
7 | , fetchpatch
  |   ^

I'm picking this up. Trying to fight Bazel and its obscurities, atm.
Just to let other people know.

Any luck? I may try it as well...

For what it's worth, a while back I spent some time getting 2.1.44 working by taking out Bazel altogether. It was incredibly frustrating, and at some point I chose to build some stuff manually and pull other stuff out of the binary build because I just couldn't any more.
I am in no way proud of this, but if anyone wants to look at it, it's in my overlay. This is not a place of honor, etc etc.

@yuuyins unfortunately I am stuck at a point where Bazel complains about unspecified targets and I really have no idea how to debug the thing without taking a deeper dive into the query language or whatever else.
A quick rundown of my work so far:

attempted to build on NixOS outside of Nix evaluation, by direct invocation of Bazel
plugged-in Tweag-made rules for getting Nix-supplied binaries
replaced CC, Rust, Python, Node and Yarn toolchains with binaries provided through Nix

Now, at this point all issued related to dynamic linking and whatnot seem to be fixed, and the build progresses well for a while until:
error: Error loading target specification: Could not find specification for target "". Use `--print target-list` for a list of built-in targets

ERROR: /home/tlopez/.cache/bazel/_bazel_tlopez/29596eeeaeb1c96a789bf8decf5825e8/external/io_bazel_rules_rust/cargo/cargo_build_script_runner/BUILD:3:13: output 'external/io_bazel_rules_rust/cargo/cargo_build_script_runner/libcargo_build_s\
cript_output_parser--359502323.rlib' was not created
ERROR: /home/tlopez/.cache/bazel/_bazel_tlopez/29596eeeaeb1c96a789bf8decf5825e8/external/io_bazel_rules_rust/cargo/cargo_build_script_runner/BUILD:3:13: Compiling Rust rlib cargo_build_script_output_parser (1 files) failed: not all output\
s were created or valid

and I swear, I have no clue what this means. I don't know if I got lost in something silly, or I have some methodological issue that prevents me from discovering the cause, or I have to blame the fact that I usually work on these things late at night, but I cannot get past this.
I am sorry to say that the last time I worked on this was on August 1st, then other things got in the way and I couldn't dedicate much time to solve the issue. Maybe I should really get back to it.
If you want to give it a try, I can send you the Bazel recipes that I came up with, so that you don't have to go through hell from the beginning. Mind you, I tried to build inside  a simple FHS environment as suggested by the NixOS wiki but to no avail. I don't know, maybe it's still  a viable approach, but I wanted to get a cleaner solution anyway.
One thing to note and that made me go a little crazy: the folks at Ankitects, for who knows what reason, use custom Bazel rules and a lot of precompiled binaries pulled directly from their own repos. And they are not always a mirror of upstream rules. For example, their Rust ruleset comes with the persistent worker functionality that is their own addition (although their default build rule explicitly disables it). They make extensive use of replacement patterns to substitute upstream rules with their custom Bazel rule repos without changing the name, so it's not super obvious where the custom rules are actually used in stead of the upstream ones.
I hope someone well-versed in Bazel could help. I'll try to resume the efforts, sorry for the hiatus.
 Maybe purging Bazel out of the way is a viable and most sane solution.

@nessdoor Your progress looks similar to mine. I also tried the FHS approach, and I'm honestly kinda impressed you made it so far as to get Yarn working. I guess I've just not had the cognitive bandwidth to wrap my head around Bazel enough to use the Tweag rules.
I haven't worked on this since… June, so my memory's a bit fuzzy, but as I recall I only ended up copying the fluent.proto into the repository because it seemed the way it's handled would change in 2.1.45 so figuring out how that's done by hand didn't seem worth the effort.
The main thing that should really be improved (other than my terrible uncommented Bash) is the line
cp -rv ${anki-bin}/bin/aqt_data/web $pp/aqt/data/web

I remember spending a bunch of effort trying to figure out how those files are built, but I was also just trying to solve a problem, and this solved my problem. It's quite clearly unacceptable as a real solution, though.
Oh, since I don't think I actually have a license on that repo yet, let me just state for the record that to the extent possible under law, I've licensed the pkgs/anki subdirectory CC0 and waived all copyright and related or neighboring rights to the pkgs/anki subdirectory. Just in case anyone's concerned, I'll fix that properly later.

Ok, sorry for the delay, other things got in the way.
@ArdaXi I took a look at your solution. I see that you perform not many compilations, but just copy files around, run some Python UI builders, compile the protobuf stub and that's it. Is it a feature-complete Anki 2.1.44 what you obtain?
Anyway, I don't know the details about aqt/data/web because it's the first time I hear of Sass, I just see that there is an upstream ruleset (again, mirrored by the Anki team) that performs the generation.
Another thing: apparently, they switched to mdbook-toc for compiling the manual, so the old asciidoc recipe is no longer valid. mdbook-toc is apparently still missing from Nixpkgs, so its merge would be a minor blocker for this PR. But it's a small utility, it wouldn't be too difficult to get the PR under way.
It's crazy the level of complexity that got into this application. Plus, there aren't many Bazel builds in Nixpkgs from which we can take inspiration, so even the integration step Nix-Bazel will be an interesting one.
That being said, I think I will get back to debugging the build right now. I hope to achieve something in the coming days. If not, I'll go hunting for a Bazel enthusiast to ask for help.

@nessdoor Well, it is a Python application at the core still, so there's not a huge amount of compilation involved, no. The Rust section does need it, see rsbridge.nix. You can tell it's the Sass stuff where I gave up...
I can confirm that that code is running on my system and I've been using it daily since then. UI scaling doesn't work very well (in the app settings, Wayland scaling is fine) but beyond that I've had zero issues.

If it's maintainable enough and the inputs can be overridden with not too much arcane magic, then once the manual and Sass compilation are fixed maybe you can attempt a PR? I don't think we have a reason to cope with the upstream Bazel build if not for: 1. maintainability 2. philosophy.

Bypassing Bazel like this is bound to create maintainability issues down the line, since we're always going to be one step behind. I'm really not sure it's feasible to try and make it work within Nixpkgs though, at least in the short term.
I'd obviously like to see this get in and I'm not terribly concerned on how, but I'm afraid my available time/energy to figure out the rest of the build is a bit limited. I was just really happy when after hours of work my Anki wasn't blurry any more...

heavy heavy curses
https://github.com/bazelbuild/rules_rust/issues/64#issuecomment-687704649

Final update: it works.
I'll test the thing a little more, clean up the build process, try to port it to the Nixpkgs framework and then open a PR that supersedes this one.
I hope these steps will be less painful.
I am very sorry for the wait.

@nessdoor thanks for your work on this, I'm trying to access the IPFS hash but it doesn't seem to be on the network (atm anyways) - is there any other way to share this? maybe on github itself?

@samm81 hello, thank you for notifying me!
I put my node temporarily offline because of power and money conservation, sorry, I didn't think about the patch!
In any case, I put an updated patch at the following gist. It's against the upstream release 1.47.
While I'm at it, a quick update: unfortunately, I was unable to make it run under the system Nix builder. I had to take away the handy recursive Nix invocations, but something broke in the resulting environment.
I was lazily waiting for the Nix release as to have 2.4 available in unstable, so that I could try and run the daemon with the experimental recursive invocation support enabled, but now that I think about it, I can have that already with the current unstable. Will try over the weekend.
Anyway, after applying the patch, be sure to edit the store paths inside rules_nodejs.patch as to reflect the hashes in your Nix store. Not very reproducible, but should get you going. I've been daily-driving the resulting Anki for 2 months now (sigh, I am awful), and I can't see any issue with it.

@nessdoor thank you for getting back to me so quickly - I downloaded and applied the patch, but am not sure where the entry point to the build is - `find . | grep .nix' gives:
./nix/node/nixpkgs_node.nix
./nix/rust/rustenv.nix
./nixpkgs-tools.nix

none of which look like entry points

@samm81 you can use one of the upstream entrypoints (shell scripts in the top directory and under scripts).
Actually, this is a Bazel build, so you need to have Bazel available.
You can see the build commands by reading the upstream entrypoints.

More than a year later, spurred by the discussion happening in NixOS/nixpkgs#78449, I decided to start investing a little bit of my free time on this, again. The latest versions of Anki have switched build system to a combination of a custom meta-builder written in Rust + Ninja.
For now, I just started writing a Nix expression that goes like this:
{ lib, stdenv, fetchurl, ninja, rustPlatform, ... }:

let
  src = fetchurl {
    url = "https://github.com/ankitects/anki/archive/refs/tags/${version}.tar.gz";
    sha256 = "sha256-H/DMMWZBFSTlf6qauT2hbkOXXKb2KXsx+Y7LSwvfnjI=";
  };
in stdenv.mkDerivation {
  pname = "anki";
  version = "2.1.55";
  inherit src;

  cargoDeps = rustPlatform.importCargoLock {
    lockFile = ./Cargo.lock;
    #outputHashes = {};
  };

  # Compile the custom meta-build system
  buildAndTestSubdir = "build/runner";

  nativeBuildInputs = with rustPlatform; [
    cargoSetupHook
    cargoBuildHook
    ninja
  ];

  # Set build root to $out
  BUILD_ROOT = "";
  # Activate optimizations
  RELEASE = "1";
  # Use the Python interpreter from Nixpkgs, otherwise the build system will try
  # downloading it
  PYTHON_BINARY = "";
}

I noticed that by setting certain environment variables, some of the build steps that automatically download stuff are inhibited. I guess our best bet is to generate a sane build.ninja by toying around with the custom meta-builder, and then invoke our Ninja hooks on that.
For now, consider my new efforts even less than a draft.

I picked this up over in #221229
Thank you for the initial start and thoughts, @nessdoor, I started from that for my PR, and it was helpful!

Thank you for leading this story to an end (hopefully), glad to have been of any help. Really looking forward to a fresh, sleek, source-built Anki package, finally.


macOS DNS issues with Go <1.20

The enterprise environment (macOS + Cisco VPN + internal DNS) I work in has issues with various tools that rely on golang's native http-client (deck, kubectl, terraform, etc) where the DNS resolution is handled improperly when cross compiling for macOS. This has since been corrected by golang in version 1.20.
Does this project have a timeline to update from golang 1.18 to 1.20?
Quick disclaimer: I'm not a golang developer so some details above might be slightly off. As far as I know, this has been a wider community issue so I've included more detailed writeups below.

https://danp.net/posts/macos-dns-change-in-go-1-20/
https://github.com/golang/go/issues/12524
https://go-review.googlesource.com/c/go/+/446178

Hi @pdelre ,
I just opened a PR to bump Go to 1.20: https://github.com/Kong/deck/pull/898

Bumping this thread to know when there will be a release with Go version 1.20 version

Bumping this thread to know when there will be a release with Go version 1.20 version

This will probably happen either this week or the next.

@GGabriele I can see there is a tag for v1.20.0 but there is not release for it (https://github.com/Kong/deck/releases). Any plans to have the tag released this week or next?

This appears resolved in v1.21.0 and works as expected with decK v1.23.0 (69aa892)


I use springboot rest api to response a image,if set MediaType.IMAGE_JPEG_VALUE  will be request twice，method invoke twice

I use springboot rest api to response a image,if set MediaType.IMAGE_JPEG_VALUE  will be request twice，method invoke twice

Please use StackOverflow for general questions about Spring Boot, this issue tracker is dedicated to the spring.io application.
Thanks!


so: 0.4.8 -> 0.4.9

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/samtay/so/releases.
meta.description for so is: "A TUI interface to the StackExchange network"
meta.homepage for so is: "https://github.com/samtay/so"
meta.changelog for so is: ""
Updates performed

Rust version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.4.9 with grep in /nix/store/kggr93gph4b79r1jm0lkcb1np8hxs9i9-so-0.4.9
found 0.4.9 in filename of file in /nix/store/kggr93gph4b79r1jm0lkcb1np8hxs9i9-so-0.4.9

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
so

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/kggr93gph4b79r1jm0lkcb1np8hxs9i9-so-0.4.9 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A so https://github.com/r-ryantm/nixpkgs/archive/494711ab254f6e717e6487dffdce44d732ee090b.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/kggr93gph4b79r1jm0lkcb1np8hxs9i9-so-0.4.9
ls -la /nix/store/kggr93gph4b79r1jm0lkcb1np8hxs9i9-so-0.4.9/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

so

Maintainer pings
cc @mredaelli for testing.

Result of nixpkgs-review pr 188733 run on x86_64-linux 1

1 package built:

so


Fix historic governments migration

Comma got dropped in https://github.com/alphagov/whitehall/pull/1987
while fixing another typo :(
This doesn't cover @jamiecobbett's comment about capitalisation, as that needs some agreement first. Just fixes the broken migration itself.

:+1:


Add tests for ethapi

Tests for ethapi module methods.

Codecov Report

Merging #455 into develop will decrease coverage by 0.56%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #455      +/-   ##
===========================================
- Coverage    44.36%   43.80%   -0.57%
===========================================
  Files          168      171       +3
  Lines        11637    11874     +237
===========================================
+ Hits          5163     5201      +38
- Misses        6063     6248     +185
- Partials       411      425      +14

Impacted Files
Coverage Δ

app/store_migration.go
0.00% <0.00%> (-70.74%)
:arrow_down:

cmd/lachesis/config_migrations.go
65.78% <0.00%> (-34.22%)
:arrow_down:

app/config.go
31.57% <0.00%> (-18.43%)
:arrow_down:

gossip/store_migration.go
71.42% <0.00%> (-6.35%)
:arrow_down:

app/store.go
29.41% <0.00%> (-4.71%)
:arrow_down:

integration/assembly.go
62.22% <0.00%> (-1.61%)
:arrow_down:

evmcore/tx_pool.go
76.16% <0.00%> (-0.83%)
:arrow_down:

gossip/apply_genesis.go
67.30% <0.00%> (-0.70%)
:arrow_down:

utils/migration/migration.go
81.39% <0.00%> (-0.43%)
:arrow_down:

gossip/store.go
66.29% <0.00%> (-0.38%)
:arrow_down:

... and 16 more

Continue to review full report at Codecov.

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


[Bug]: Add import quick fix adds import ignoring the comments

Description
https://github.com/ballerina-platform/ballerina-lang/assets/15815199/2e2bc732-9ce0-42c1-998e-ead3799cc39f
Steps to Reproduce
No response
Affected Version(s)
2201.7.0
OS, DB, other environment details and versions
No response
Related area
-> Editor
Related issue(s) (optional)
No response
Suggested label(s) (optional)
No response
Suggested assignee(s) (optional)
No response

I'm not sure whether this was done intentionally to ignore the commented-out code on the top. But it feels weird in a case like above


Watcher does not reload filters when they are changed

When using the watcher and you change the filter it does recognize the change, however they are never applied.

Not sure why this is happening but, without looking at it, I'm suspecting the watcher is ignoring hidden files and the .filters directory is hidden. Actually, any file starting with a dot is treated as a hidden file.

Not sure why this is happening but, without looking at it, I'm suspecting the watcher is ignoring hidden files and the .filters directory is hidden. Actually, any file starting with a dot is treated as a hidden file.

The watcher is recognizing the change in the hidden file, however when the generator is run, it will not use the new filter, but use a cached one (the one first loaded when the command was run).

I was able to reproduce the issue even with the current generator version where we keep templates separately and filters also separately from template files

after few hours of debugging I'm sure problem is here
https://github.com/asyncapi/generator/blob/master/lib/filtersRegistry.js#L39
If I read file like fs.readFileSync(filePath, 'utf8') it shows new content, but require brings initial module and not the new one.

after finding where the issues is, finding fix was easy
interesting read about modules cache -> https://bambielli.com/til/2017-04-30-node-require-cache/
will provide PR soon


plugin-react-refresh: fix global variable 'exports' leak

Changes

Place the exports variable global variable into a scope to prevent it from being leaked globally.

Before tests:

After tests:

Testing

Updated the snapshot to reflect added scope.
Docs

No documentation update.

oh wow, great catch! Tested myself and lgtm


Environment Variables Not Working on Now/Zeit Deploys

Using the latest Nuxt starter kit (1.0.0-rc11), I tried testing environment variables on Zeit's Now deployment services and it's not working.
nuxt.config.js
  env: {
    apiUrl: process.env.API_URL || 'http://local.dev/api'
  }

On deployment, it's never setting apiUrl to the environment variable API_URL.
I have verified that the environment variables work in a basic app that is deployed with Now, so I think there is something weird going on with Nuxt.js and Now, or perhaps something SSR related that I'm unaware of?
The environment variables work when I deploy a static site to netlify though.
Any ideas?
It's pretty easy to reproduce, just install the latest nuxt.js starter kit, add an env var and then deploy with Now.

Closing this one for now unless someone else has this problem. I've moved over to Heroku for now.


Transitive dependency resolution non-repeatable with version ranges

A third-party library uses an open-ended version range to resolve a dependency (in this case, on jackson-databind).
Recently, a 2.9.0-SNAPSHOT was released for jackson-databind, which in combination with the third-party library above, made previously working builds non-repeatable, because the same build was now pulling in a -SNAPSHOT dependency to a non-binary compatible version.
I don't believe the third-party library should be defining their transitive dependencies this way (see https://github.com/maxmind/GeoIP2-java/issues/77 for my discussion with them -- perhaps someone from the gradle team could weigh in with their thoughts). However, I think Gradle could do more in this type of situation to ensure build repeatability (I don't know what).
I also don't think this issue is limited to snapshots. Even if my build did not enable snapshots, as soon as jackson 2.9.0 was released, I would have run into the same issue.
The third-party lib POM is:
https://github.com/maxmind/MaxMind-DB-Reader-java/blob/master/pom.xml#L40
which pulls in Jackson-databind with a version range [2.7.0,).
(Edit: it used to, MaxMind updated it to a fixed version, though they say the change is temporary)
Expected Behavior

Builds should be repeatable

Current Behavior

Builds are not repeatable if a transitive dependency uses a version range that may cause different deps to be included depending on external releases

Context

My build was working. Then a build of the same code version stopped working, with failing tests due to binary incompatibility. Upon further investigation using the dependencyAnalysis tool, it was determined that a new non-binary compatible snapshot build was being pulled in.

Steps to Reproduce (for bugs)
Here is a simple build.gradle for reproduction:
repositories {
  mavenCentral()
  maven {
    url "https://oss.sonatype.org/content/repositories/snapshots"
  }
}

apply plugin: 'java'

dependencies {
  compile("com.maxmind.geoip2:geoip2:2.8.0") {
    // workaround https://github.com/maxmind/GeoIP2-java/issues/77
    //exclude group: 'com.fasterxml.jackson.core'
  }
}

task wrapper(type: Wrapper) {
  gradleVersion = '3.1'
}

Your Environment

Build scan URL:  https://scans.gradle.com/s/jjq3xdqmhhd6i

@eriwen I wouldn't classify this as a bug. Repeatable builds in the face of version ranges is a missing feature, which could e.g. be solved with a lock file or something similar.
@rocketraman For the time being, you can force the version of the transitive dependency to a stable one. You can also write some code which makes your build fail if any dynamic or changing dependencies are used. See the ResolutionStrategy documentation for further details.

For the time being, you can force the version of the transitive dependency to a stable one.

Agreed, this is an ok solution until builds can be repeatable by handling this situation.

You can also write some code which makes your build fail if any dynamic or changing dependencies are used. See the ResolutionStrategy documentation for further details.

This would be useful, so that the build can fail-fast when one needs to apply the workaround above. I know this is not a support forum, but can you provide an example of this? The documentation does not have one.

You can use ResolutionStrategy.eachDependency() and inspect the version of the requested module. If it contains things like ( or + or -SNAPSHOT, you fail the build. Hope that helps :)

Thanks @oehme. We are aware of the need to make transitive dependencies deterministic, and I'd like to track that somewhere else than this issue.
Given that there's a workaround here, I will close this. Please reopen @rocketraman if you desire further discussion.

For future reference, can you provide a link to whichever issue was created to track deterministic dependencies?

For future reference, can you provide a link to whichever issue was created to track deterministic dependencies?

@eriwen Ping

@rocketraman I'm sorry, I wish I could, but I'm legally not allowed to under the particular open-source partnership this is a part of. Will let you know once we can announce it.

^^ that seems lame and opaque.  I've not heard of such a partnership which claims to be "open source" and legally forbids transparency of viewing issues.  Seems kind of mental to me.

^^ that seems lame and opaque.

I agree that this comment was vague. In fact there is no such partnership, the comment was intended for a different issue.

I've not heard of such a partnership which claims to be "open source" and legally forbids transparency of viewing issues. Seems kind of mental to me.

There are partners who pay us for improving Gradle for everyone, but don't want to be named or don't want us to make a big fuss about it before it is ready. These partnerships are improving the tool that you are using for free. So your comment of such a partnership being "mental" is odd, to say the least.
I'd appreciate if you'd drop the needlessly rude and hurtful language in the future.

I'm still trying to figure out why my build isn't repeatable without any code changes.

GroovyDoc puts timestamps into its output by default. You can disable that.

@oehme thanks for the tip on timestamps, I didn't mean to come off as rude.  I was only making an observation.  Your statement can apply to pretty much all popular freely licensed and open sourced software.  I still think it's unwise to keep an issue relating to a desired open source feature in a closed and opaque issue tracker.  It makes me not want to contribute if that's how this project operates in general (i.e. all open issues are closed in favor of a "private" issue tracker).  I encourage you as maintainers to develop and track issues more in the open.

We didn't close this issue in favor of some internal one. We closed it because it was not a bug and because there was a workaround for the issue described. There is no ticket for the broader topic of "repeatable dynamic versions" yet, but you are very welcome to open one. We did not open one ourselves because we don't have the capacity to work on it or discuss it at this point.
That being said, there is a great community plugin for dependency locking (which is one way to solve "repeatable dynamic versions").

We didn't close this issue in favor of some internal one. We closed it because it was not a bug and because there was a workaround for the issue described.

@oehme  As far as I know, no one was asking why this issue was closed. That was clear. @eriwen stated:

I'd like to track that somewhere else than this issue.

So would we. This is what we were asking for. Now that its clear this place does not currently exist, we can move forward :-)
Thanks for the link to the community plugin also.

FYI - I think this is a relevant issue for the community plugin:
https://github.com/nebula-plugins/gradle-dependency-lock-plugin/issues/78

And for future Google searchers, this was eventually implemented in Gradle core: https://docs.gradle.org/current/userguide/dependency_locking.html.


CLIP Pretrained Weights

Thanks for your great work? Could you please share the pretrained rn50 weights which were used for transfer learning? Or, could your please give us a direction where to find and download it?

I guess I got it. Share it here,
https://openaipublic.azureedge.net/clip/models/afeb0e10f9e5a86da6080e35cf09123aca3b358a0c3e3b6c78a7b63bc04b6762/RN50.pt


More control over outlines

I've got a game using toon-rp that has screen-space outlines enabled and I'm running into issues with it and grass. The grass needs to perfectly blend with the terrain, but the grass seemingly can either have outlines, or be in the transparent queue which causes it to not have outlines but will have outlines render above the grass
Grass with outlines:

Grass with render queue as overlay:

Is there a way to have it so the grass doesn't have outlines, but still renders above other object's outlines? If no, could such a feature be implemented in the future?

You can try using the outlines in the "After Opaque" mode: https://github.com/Delt06/toon-rp/wiki/Screen‐Space-Outline#after-opaque
It will also require keeping the grass in a transparent render queue.

Glad to hear it worked.
Generally, I am not planning on improving screen-space outlines, as the RP focuses on inverted hull outlines. Dependening on the geometric complexity of your scene, you might wanna look into them instead, they provide many more settings, including per-layer filtering of what objects to have outlines, better thickness, etc.


Control protocol content header

In #33 we decided upon one frame for header information.
In this issue, we can discuss the content of that header frame.

AFAIK, the current proposal is to include

message type
conversation ID
message ID

I think we should be able to use fixed-length byte sequences for all of those, which would allow us to decode this header by length/position.
I suggest to include the items in the above order, as that is presumable in decreasing order of importance.
Question 1: If we include a conversation ID, do we also need the message ID, or would it be sufficient to track request/response/response/... patterns/sequence by conversation ID alone?
Question 2: What should we use as conversation/message ID? uuid was proposed, but might be wastefully long?
Question 3: Do we want to include a timestamp? If yes, maybe folded into the message ID (e.g. UUID7 or UUID5), in which case we would include the message ID?

Question 1: If we include a conversation ID, do we also need the message ID, or would it be sufficient to track request/response/response/... patterns/sequence by conversation ID alone?

If we have a conversation ID, we do not need a message ID for tracking responses etc.
However, we loose the option to identify every message (and the timestamps in the message IDs).

Conversation ID

2 Bytes should be sufficient, as it is only relevant for the requesting party, which should not open more tan 65000 conversations at once.

2 Bytes should be sufficient, as it is only relevant for the requesting party, which should not open more tan 65000 conversations at once.

Don't we want conversation IDs to be unique for ~a whole session? That would make it ~trivial to filter e.g. all messages belonging to one conversation out of a log file/database.

There are two ideas:

The conversation_id of a response is message_id of the original message
The conversation_id of a response is the conversation_id of the original message (so it is chosen by the sender)

COAP follows the second idea:

Token
Every request carries a token (but it may be zero length) whose value was generated by the client. The server must echo every token value without any modification back to the client in the corresponding response. It is intended for use as a client-local identifier to match requests and responses, especially for concurrent requests.
Matching requests and responses is not done with the message ID because a response may be sent in a different message than the acknowledgement (which uses the message ID for matching). For example, this could be done to prevent retransmissions if obtaining the result takes some time. Such a detached response is called "separate response". In contrast, transmitting the response directly in the acknowledgement is called "piggybacked response" which is expected to be preferred for efficiency reasons.

(https://en.wikipedia.org/wiki/Constrained_Application_Protocol#Token)

edit: If I computed correctly using https://kevingal.com/apps/collision.html, 16 bits of ID, at 100 concurrent conversations (1 per device, order of magnitude estimate, e.g. 33 new conversation per second at 3 second average conversation duration), gives us a 7.3% probability of a collision! Waay to high imo

I thought, that a Component (let's say a Director) has an internal conversation counter, so it can have 65000 (256*256) conversations until it starts from zero again.
So only if a conversation lasts longer, than you start 65000 other ones, then you have a collision.

Here is the COAP protocol definition: https://www.rfc-editor.org/rfc/rfc7252
I read their concept:

Messages have a message_id and a token
A server must respond to a request with the same token
There are confirmable and non-confirmable messages.
Confirmable messages require either an Acknowledgement or a Reset. In either case, this response has the same message_id as the request has. The request is sent, until either response arrives.
An answer to a non-confirmable message has a new message_id.
If it takes some time to respond to a confirmable message, the server sends an ACK (same message_id, no token) and later the response with the content (new message_id, original token)
Message_ids are used for duplicate detection and responses to confirmable messages.

AFAIK, the current proposal is to include

I proposed to include the content formatting type (json, avro, binary), not the message type. However, we can think about the message_type in the header.

edit: If I computed correctly using https://kevingal.com/apps/collision.html, 16 bits of ID, at 100 concurrent conversations (1 per device, order of magnitude estimate, e.g. 33 new conversation per second at 3 second average conversation duration), gives us a 7.3% probability of a collision! Waay to high imo.

Oh, I see one difficulty with the conversation_id: If both endpoints send each other a message with the same conversation_id (as both chose the same ID due to some circumstance), they will interpret the others message as a response, not a new request.
Did you mean that?
We could mitigate that, if the message type differ (request type is different from response type).

Here is the COAP protocol definition: https://www.rfc-editor.org/rfc/rfc7252
I read their concept:
* Messages have a message_id and a token

* A server must respond to a request with the same token

* There are confirmable and non-confirmable messages.

* Confirmable messages require either an Acknowledgement or a Reset. In either case, this response **has the same message_id** as the request has. The request is sent, until either response arrives.

* An answer to a non-confirmable message has a new message_id.

* If it takes some time to respond to a confirmable message, the server sends an ACK (same message_id, **no token**) and later the response with the content (new message_id, original token)

* Message_ids are used for duplicate detection and responses to confirmable messages.

These points look useful/applicable in our situation. Token is basically our conversation id (in role).

I proposed to include the content formatting type (json, avro, binary), not the message type. However, we can think about the message_type in the header.

With "message type" I mean the command verbs (#29). We need to have those somewhere, I thought the content header would be the logical place.
Serialisation information will also be important, in case we use more than one scheme.
Just for correctness, avro can use either json or binary within, but I assume you mean self-made schemes here.

Oh, I see one difficulty with the conversation_id: If both endpoints send each other a message with the same conversation_id (as both chose the same ID due to some circumstance), they will interpret the others message as a response, not a new request.
Did you mean that?

Basically, yes. We can't use sequential codes because two Components might be on the same "offset" concurrently. If we use random ones, we have a certain risk of collision, i.e. two nodes accidentally choosing the same ID via RNG.
I'm not sure message type helps us with this, because message type is not a "random" variable.

I'm not sure message type helps us with this, because message type is not a "random" variable.

It helps: If I receive a "response type message", I know, it is the response to my request with the same conversation_id. "If I receive a "request type message", I know it is a new request and I have to return a response with the same conversation_id.
For example Acknowledge and error are response message types.
GET/SET/CALL are request message types.

Is your argument that by having two kinds of messages, this improves the odds of a collision by a factor of 2?

I'd say there are no collisions anymore:
Yes, several messages with the same conversation Id might arrive, but only those of "response type" are a response to my request. As the original sender sets the conversion ID, it can determine, what it gets back (just using "free" id's).
All the other messages with the same if have to be requests, and therefore this I'd is not relevant for the Components under scrutiny.

So if Co1 sees/routes two "response type" messages from N1->N2 and from N2->N1, which could have the same conversation id, what happens then?

I see the conversion ID as a help for the end points of a conversation (especially the requesting one).
The Coordinators routing do not care, whether the routed message is of one or another conversation.
For logging purposes: you need the combination of recipient/sender and conversation Id to get the "full conversation Id".
I see it difficult to achieve collision less conversation Id without a central authority.
I see, that the stream logging is very important to you (I did not think about it).
Oh: logging has another difficulty: you have to combine the logs of all Coordinators to get a full message log.

I see, that the stream logging is very important to you (I did not think about it).

I'm thinking of the poor folks that have to troubleshoot future messaging/routing problems. :-D

I see it difficult to achieve collision less conversation Id without a central authority.

Yes, just like you can't achieve collisionless git hashes. What you can do is lower the probability of a collision until you're comfortable (number TBD, but less than 7% :-p)

In my test system I use the conversation_id more and more, but not the message_id.
We could include the timestamp in the conversation_id and the message_id consists of the conversation_id and a temporal offset to the begin of the conversation. So:

The conversation_id is a timestamp plus a few random bytes (see the discussion about unique ids): unique.
The message_id is not additional to the conversation_id, but contains it and a temporal offset (a few bytes)
Example structure for complete ID part of the header (contains both IDs): "Timestamp", "Random bytes", "Message offset".

Advantages:

The temporal offset does not require a large byte count, such that the combination of both IDs has a low byte count (instead of two independently unique IDs).
Timestamp of every message can be calculated.
Easy ordering of messages in a conversation
You can identify the beginning of a conversation (temporal offset 0) easily from the ID itself (not from the message type)

Disadvantage:

The message timestamp has to be calculated.

At a first glance: sounds reasonable.

With the resurfaced links in #16 my proposal for the content header:

UUIDv7 as conversation id, maybe with the first 12 bits of random code used for sub millisecond resolution
4 bytes (number of bytes TBD) offset from the conversation id timestamp in milliseconds (e.g. first message has 0, response has some value different from 0). The UUIDv7 plus this offset is the message id (timestamp can be calculated).
Alternatively instead of the offset, we could have a one byte counter: Each response (of the same conversation_id) increases it by one. Advantage: more simple ordering, disadvantage: timestamp of response is not known.
Last: 1 Byte for the Serialization scheme

Talking about PyMoDAQ in combination with LECO, we considered it good to send binary data, therefore it is good, that we have that byte indicating the serialization scheme.

Regarding the serialization scheme byte: We could allow a certain range (let's say 127-255) for user defined applications


How to read local .gsheets file?

How to read local .gsheets file?

Hi. AFAIU https://fileinfo.com/extension/gsheet, they are text files with a link to the sheet.
Reading such files is currently not supported but sounds like it might be simple to add.
Would you like to contribute (maybe you can provide some pointers and/or an example)?

sure. i will take this up and try to implement it.


Provide a check for duplicate telemetry data

I think it would be helpful for teams to have a way to check that the information which we send to the interop server does not contain duplicate data. It wouldn't necessarily be built in to the server, but could be a script provided in the repo.
I am suggesting this as an enhancement, but it is not something my team is counting on.

You are correct, this is not something we provide right now. During development and testing, you can verify your data with a little work.
A GET /api/telemetry API endpoint is available. It is only available to superusers (i.e., the admin account), so it isn't documented in the primary interop documentation, but you can use it during development and testing to verify the data that has been sent.
We also have a method that deduplicates telemetry logs. It isn't accessible from outside the server, but with a little extra work, the server could be modified to warn you about duplicate data.

There are many scripts like this which may be useful for teams. It's one of my personal goals to decrease the effort required by student teams, and to enable them to focus on topics of innovation. Unfortunately this type of thing is not something we presently have time to provide or maintain. In terms of interop, we are currently focused on core system requirements needed at competition and we expect this to take all of our time between now and June. We are also overhauling all other systems used at competition (from SRIC to grading to banquet presentations). If in the future we have more contributors then we can consider supporting such tooling.
I recommend looking at create_teams.py which demonstrates how to write a standalone script that can connect to the database and use the model methods (like the dedupe method prattmic@ mentioned). If you set it up correctly, it could be as simple as:
flight_periods = TakeoffOrLandingEvent.flights(user)
uas_period_logs = UasTelemetry.by_time_period(user, flight_periods)
uas_logs = list(itertools.chain.from_iterable(uas_period_logs))
deduped_uas_logs = list(itertools.chain.from_iterable(
        [UasTelemetry.dedupe(logs) for logs in uas_period_logs])
# Compare logs

Thanks for the reply.
If I have read the code correctly, teams can use the evaluate_teams endpoint in auvsi_admin to check their telemetry rate. This endpoint is already implemented, so it could be used to check the data rate of desuped telemetry logs, but does not provide the direct telemetry logs.


[1.x] BWC - fix mixedCluster and rolling upgrades (#775)

This commit fixes mixedCluster and rolling upgrades by spoofing OpenSearch
version 1.0.0 as Legacy version 7.10.2. With this commit an OpenSearch 1.x node
can join a legacy (<= 7.10.2) cluster and rolling upgrades work as expected.
Mixed clusters will not work beyond the duration of the upgrade since shards
cannot be replicated from upgraded nodes to nodes running older versions.
Signed-off-by: Nicholas Walter Knize<EMAIL_ADDRESS>Co-authored-by: Shweta Thareja<EMAIL_ADDRESS>

start gradle check


[New] MediumMultilineInput and LargeMultilineInput Elements

feat: New MediumMultilineInput and LargeMultilineInput Elements

I have read the Contributing Guide - https://github.com/RocketChat/Rocket.Chat/blob/develop/.github/CONTRIBUTING.md#contributing-to-rocketchat doc
I have signed the CLA - https://cla-assistant.io/RocketChat/Rocket.Chat
Lint and unit tests pass locally with my changes
I have labeled the PR correctly with the related package
I have run visual regression tests (if applicable)
I have added tests that prove my fix is effective or that my feature works (if applicable)
I have added necessary documentation (if applicable)
Any dependent changes have been merged and published in downstream modules

Proposed changes (including videos or screenshots)

Larger Multiline Input Elements will open new possibilities for Rocket.Chat App Developers.

Added New MediumMultilineInput and LargeMultilineInput elements to fuselage-ui-kit.

Added the new elements to the storybook.

Input With Medium Multiline Plane Text Input

Banner

https://user-images.githubusercontent.com/70485812/178167410-3837a459-824c-4be3-b14f-93be3f66814f.mp4

Modal

https://user-images.githubusercontent.com/70485812/178167421-04e53647-4466-4408-8b45-55038c7885d2.mp4

Input With Large Multiline Plane Text Input

Banner

https://user-images.githubusercontent.com/70485812/178167501-4a9b1c3a-bff4-4d68-8283-43f3f0f72696.mp4

Modal

https://user-images.githubusercontent.com/70485812/178167504-5d57ea78-39f1-4ad9-a9c8-bf0f907f7a3a.mp4

Issue(s)

#765
Further comments

The motivation behind extending and adding larger input components to fuselage-ui-kit was to add the Code Review feature and New Issues feature in the GitHub App
https://github.com/RocketChat/fuselage/discussions/744

@MartinSchoeler @ggazzo can you guys please take a look at this PR and suggest any changes

@dougfabris @tassoevan Can you guys please take a look and suggest any changes ?

@gabriellsh Can you please take a look and guide me with this PR. Feel free to message me over Rocket.Chat Open Server samad.khan  whenever you find time :)

@ggazzo I have updated the parameters for PlainInputTextElement and have replaced the previous parameters by multilineSize. Can you please take a look :sweat_smile: ?

@ggazzo can you please take a look at this again ? I have made changes according to review comments.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Add  background interaction

Add background interaction to make it possible to interact with the calendar view even when the bottom sheet is open;
Add .fowardToRoot to propagate touches to the first non-PanModalPresentable view controller in the presentation stack;
Convert touch point to the appropriate coordinates in the correct view;

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


extend wait strategy for spark docker containers

Signed-off-by: Pawel Leszczynski<EMAIL_ADDRESS>
Problem
Integreation tests randomly without any leading, generic cause.
Closes: #ISSUE-NUMBER
Solution
Hypothesis: We run integration tests in docker and close docker containers when a log entry Shutdown hook called.* is collected. However it is still possible that OpenLineage event is sent at the same time and stops from being delievered.
Solution: Extend LogMessageWaitStrategy to wait and extra time after shutdown hook log is collected.

Note: All schema changes require discussion. Please link the issue for context.

[ ] Your change modifies the core OpenLineage model
[ ] Your change modifies one or more OpenLineage facets

If you're contributing a new integration, please specify the scope of the integration and how/where it has been tested (e.g., Apache Spark integration supports S3 and GCS filesystem operations, tested with AWS EMR).
Checklist

[x] You've signed-off your work
[x] Your pull request title follows our guidelines
[ ] Your changes are accompanied by tests (if relevant)
[ ] Your change contains a small diff and is self-contained
[ ] You've updated any relevant documentation (if relevant)
[ ] You've updated the CHANGELOG.md with details about your change under the "Unreleased" section (if relevant, depending on the change, this may not be necessary)
[ ] You've versioned the core OpenLineage model or facets according to SchemaVer (if relevant)

I run integration tests 5 times on circle-ci and a single run out of five failed which means this does not solve the problem.
The failing tests were alterTable and testInsertIntoDataSourceDirVisitor.


build deb packages using debuild

debuild automatically creates a ddeb package with debug symbols

This means lavinmq-debug is gone, but instead all binaries are built with --debug, which now gives full stack traces. FYI @jage


Choose format of master light curve

decide on the format of the combined master light curve for each object - also JSON to start. need to include metadata about the object and the data cubes that went into it

currently, master light curves are stored in a google cloud storage bucket, in a json file named by PIC.
next step is to choose more robust format, with the following considerations:

append new light curves to the master as they are uploaded. currently, the entire master light curve for a star is rebuilt each time a new light curve segment for that star is added.
should still have a way to rebuild master light curves from source light curve segments, or add all segments not already in the master, in case notification server is down and some were missed.
need to figure out how to store metadata with master light curve about which light curve segments are included (another column(s) for each entry? repetitive but would work)

@oguyon @joshwalawender @mimming I think this relates to both what is best t use on GCE as well as how we thinking the master lightcurves will be updated/used.


When filtering on /rotation/changes/ and /rotation/speculation/, update the number of cards.

Number of cards in and out appears in the table header, but currently does not change when filtering.

Oops, typo in the commit message.


live-common 21.33.0

https://github.com/LedgerHQ/ledger-live-common/releases/tag/v21.33.0

LL-9216 be less strict on breaking on non user accounts
LL-9196 Update vtc explorer url
LL-9198 crypto-assets list update
LIVE-1123: low amount user shouldn't be able to set everything he want
LIVE-825 - Update market API to have an AND logic on filters instead of OR logic
LIVE-1186 Update Polkadot Nano app min version to v10.9160.1
LIVE-1338 Remove Algorand JS impl from experimental mode
LIVE-1337 Add check for recipient not equal to sender on crypto.org
LIVE-886 (Market): add sparkline variation + fix issue in countervalues

should be good


[docs] add usage examples to extensions

We need usage examples in the READMEs for all our extensions:

https://github.com/PromiseKit

Open for two years and no takers. Open source doesn't work really, init?


Missing "nice" error message NO_REPOS_CONFIGURED

I attempted to run makedash.js without adding any GitHub repositories to the config.yaml. Because this isn't allowed, I should have gotten an error message explaining what I need to change and why. Instead, I got this output in my terminal:
Internal errors are by definition a bug in Measure, and should be reported.
The error was detected at line 170:39 of 'lib/loads.js'.
This should never happen, and I am halting in abject failure.

I would be willing to write the nice error, to fix this bug. However, I like the way that many of the error messages explain why the user's action isn't allowed, and I'm not sure why a repo is required to create the dashboard.
(My use case (why I'd prefer to make a dashboard without configuring a repo, for now): I'm planning to write a couple of widgets that track a user's contributions across all of GitHub so that we can track all contributions by our employees to open source projects. Eventually, we'll also care about our company's organization and repos, but that's not our first priority. Given that, I'd be happy to make a dashboard with the users that I've crawled, without configuring a repo, if that wasn't a necessary part of the code. However, if it would be difficult to change the Measure code to accommodate that, I can configure a repo and just ignore it for now.)

Thanks so much for the quick response and getting that bug fixed!
I've been working on the ghcrawler code and I am currently able to queue up a user and retrieve all of their events (on my local- it's a WIP so I haven't pushed the code up to ghcrawler yet). The API supports this (Check out https://api.github.com/users/stuartlangridge/events). Unfortunately, it doesn't support webhooks for users/events like it does for repos and orgs, but I can just run the crawler manually on a regular interval. So, I am able to get contributions across GitHub for a given user, unrelated to a repo. (Also, even without my new code, you can queue up a user via ghcrawler's browser dashboard, it just won't crawl that user's events without my code change.)
Once I have that user info, if I run Measure's makedash.js, that new user does get populated into dashboard/contributor/newUser.html
So my plan is to now write some new widgets that grab and filter the user event information in the mongodb to give us the user contribution info we want. Is that what you meant when you said 'if that happens, then we could alter Measure to be able to track contributions for a user and not within specific repositories, but we'd need to do work to make that happen; it wouldn't work automatically if ghcrawler started supporting it.' or is there also other work that needs to happen? Thanks for your help!

To explain: Measure will make user pages for all the users it finds in the database, howsoever they got there. So if you have some other way of getting user data into MongoDB (for example, as you note, by poking ghcrawler to fetch from the Github user data API) then Measure will happily create user pages for all those users. However, this won't be terribly well integrated into the rest of Measure, because there's no way to add a user list to config.yaml, and to provide that way we'd need to write that code to read the new userlist and prompt for how to run ghcrawler to use it, and depend on a version of ghcrawler which understands it.
There's also the concern that Measure assumes that its data is consistent; that is, that user data got there because it was fetched as a consequence of fetching repository data. So, for example, the "Repositories contributed to" widget on a contributor page is populated by reading repository data filtered by user, not user data itself; this means that this widget will not contain data for repositories which the user did contribute to but which we don't have data for because they aren't listed in github_repositories in config.yaml.
In summary, therefore, it's perfectly reasonable to get extra user data into MongoDB, and to write your own widgets to read that data and display it as part of a Measure dashboard; the whole system is designed exactly so that you can write your own custom widgets to display the data you've got in the ways that are most useful to do! But those widgets are not likely to get into the upstream distribution without a bunch of work in the dependencies and thinking through the consequences. Of course, they don't have to; widgets that you find useful are useful to you and that's sufficient, and there's no need to contribute them back upstream if they won't work for others. I hope that explains our thoughts in more detail?

That does explain your thoughts well, thank you!
Ideally, we would love to contribute our widgets to Measure so that other Open Source programs can use them to track their employee contributions (with the larger goal of getting more companies involved in giving back to the OS projects they use). And I see your hesitations based on the current limitations of the code.
I agree that there would be a lot of work for these users that are not crawled through repos to use any of the widgets that currently exist. But, I'd already been thinking about where these users would live in the database and where their widgets would be in the Measure codebase. Based on what you said, I'm thinking that a possible solution would be for any user crawled as a User (not through a repo or org) to go into its own mongoDB collection, let's call it repolessEmployee for the moment. And then, when the Measure dashboard is made, instead of being in contributor, they could go into a new folder called repolessEmployee that would make html files containing the widgets we're interested in for these users. (And an index page that would contain totals for all employees added together, and links to the individuals)
Assuming that the changes are made to ghcrawler to allow this setup, (including, potentially, queueing an array of GitHub IDs) is that a contribution that you would be happy to merge in? The main issue I see is that some people would be in both contributor and repolessEmployee, which could be confusing. It also creates a sort of divide as we're dealing with 2 almost entirely different datasets, but with good documentation and maybe a small change to Measure's home page, I think we could explain it and make Measure a tool for OS programs that care about more types of contributions.

Hi @stuartlangridge I just wanted to check in because I haven't gotten a response to my last question and thought you might have missed it. Let me know if there's anything you'd like more clarity on.


4.18 kernel support

Adding support for kernel 4.18 is the most frequently requested feature because of older RedHat LTS versions. Adding support for 4.18 needs work on few fronts:

We need to switch from using ringbuffers to perf buffers.
We need to ensure we can pull BTF symbols in a productized way. (since BTF will not be present on 4.18)
There might be issues with reading the iovec structures.

Thanks for reopening, I accidentally moved the issue in the wrong column in the project, to completed instead of in progress.

Recent RHEL 4.18 kernels are heavily backported and provide the necessary infrastructure required by Beyla. We have decided to provide supports only for these select RHEL kernels rather than vanilla 4.18, as it covers most people still on that kernel version.
See https://github.com/grafana/beyla/pull/1169 for further context.


Share page component updates to new "𝕏" icon

What is the context of this PR?
Old component had the old twitter bird icon. New component has the new SVG for "𝕏" icon. Additional change has been made to fix alignment issues between the different icons. Now all icons are in line
How to review this PR
Go to share page, and check icons are in line, and the new twitter "𝕏" icon can be seen.
Checklist
This needs to be completed by the person raising the PR.

[x] I have selected the correct Assignee
[x] I have linked the correct Issue

Team has been consulted. Whilst twitter documentation is unclear and their marketing material is even more (the main page is still www.twitter.com but the page title is X and the logo is X), the decision has been made that the hyperlink text should be kept as twitter.


HTTP Error 500 when publishing openid url

Gitea version (or commit ref): 1.5.0
Git version: 2.1.14
Operating system: Debian GNU/Linux Jessie
Database:

[ ] PostgreSQL
[x] MySQL (5.5.60-0+deb8u1)
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[ ] Not relevant

Log gist:

2018/10/18 16:26:18 [I] [SQL] update user_open_id set show = not show where id = ? []interface {}{3}
2018/10/18 16:26:18 [...g/security_openid.go:120 ToggleOpenIDVisibility()] [E] ToggleUserOpenIDVisibility: Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'show = not show where id = ?' at line 1

Description
After I added my OpenID access using my configuration panel (Profil / Configuration / Security), I wanted to publish on my public profile the OpenID URL. After clicking on the button, I see a HTTP Error 500.
Screenshots

Hmm, seems to be issue with "show" being a keyword in MySQL and not being quoted in the SQL syntax.

I guess changing this line:
https://github.com/go-gitea/gitea/blob/801843b0115e29ba2304fa6a5bea1ae169a58e02/models/user_openid.go#L96
to something like x.Exec("update user_open_id set \"show\" = not \"show\" where id = ?", id) should help.

@strk I will be happy to submit a PR, but I cannot test it properly since I don't have MySQL setup at the moment.

On Thu, Oct 18, 2018 at 06:32:43PM +0000, Filip Navara wrote:

@strk I will be happy to submit a PR, but I cannot test it properly since I don't have MySQL setup at the moment.

There are integrations tests running as part of the testsuite,
maybe you could try to add tests for OpenID usage ?
(challenging task, mind you!)

also I guess @simmstein would be up to test your PR ?

Of course! I just need a binary beause it's the way I choose to use gitea.


Can't install ballerina using installer on windows

Description:
Can' t install ballerina using the installer on windows.

Steps to reproduce:
Affected Versions:
1.0.0
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

downloaded installer was corrupted.  Downloading and trying again worked.


WIP: Untested S3 loader stubs

Heavily based/copied from the same code in hdfs
No tests possible until we have decided on a place to put appropriate files
for download.
Note: Loader for (set of) http URLs would look identical, replacing
s3.Object(bucket, key).get()['Body'].read()
->
urllib.request.urlopen(url).read()
(or the py2 equivalent)

The existing S3 tests use the distributed-test bucket.  You may have access to this.

I have read access only. It would be the natural place to put test data.

Are you logged in to the aws console under your continuum-dev account?  console.aws.amazon.com
I'm not very familiar with how to manage permissions on AWS.  Attempts to add you and the group have been unfruitful.  All of the aws-dev group has permissions though (perhaps that includes you?)  I imagine that others might have more ability here.

I do have a condinuum-dev account, and I thought this key was from there, but I don't know how to check. I do have write access to blaze-data with it. I'll ask around on Monday to sort it out.

Test fails, issue with read_bytes when lazy=True

What is the status of this?

@mrocklin : help requested here, I don't know why this isn't working. The futures seem to stay pending.

avro reader requires fastavro: should be hard dependency, or gracefully ignored if not present?

Gracefully ignored please.  I recommend putting it into travis.ci, not putting it into requirements.txt, and using pytest.importorskip('fastavro') in test files.

Closing in favor of #162  and #159


Feat/collect keys sorted

I have to question the utility of this. For one, there's no way of getting the same for secondary indexes. Secondly, I don't know where would it be useful, except in tests.

In my case it is useful to create a hash over all elements in the list. Without an stable order, it would create a different hash on each try.  It also enables you to create a paginated list.


Add the ability to arbitrarily set the expiry of a token

Currently JwtProvider configures the expires_at at a set time based on the expires_after_sec configuration value.
We should add the ability to either not expiring the token, or to set an arbitrary expiration time (or duration)

Fixed in #30


Fix document HTTP API examples

Description
Create collection / log response (to be tested)
Upstream PRs

3.10:
3.11: arangodb/enterprise-preview:3.11-nightly
3.12: arangodb/enterprise-preview:devel-nightly
3.13: arangodb/enterprise-preview:devel-nightly

/generate-commit

Hey @Simran-B! just checking if you pinged me by mistake here? Happy to review, however I don't own this part of documentation

@aMahanna Yeah, my bad! Please ignore

/generate-commit

/generate-commit


tweaked classify_tweet function and split it to sub functions for convenience

after checking the latest tweets and seeing I classified a few of them wrong, I tweaked my classification function.
@atalyaalon I recommend deleting all of the twitter rows in news_flash table and let the script have a fresh run, in order to fetch all of those misclassified tweets

@sagivharel make sure you pass the CI test

@Mano3 @atalyaalon Anyone of you understand the CI error? It doesnt seem relate to any changes I made in the code...


Read entity-field in server error messages

Adapt error message class to the new JSON error message format,
and use the entity-field to throw more meaningful exceptions where applicable.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 22 Jan 2011 at 1:23

Original comment by<EMAIL_ADDRESS>on 23 Jan 2011 at 6:40

Changed state: Accepted

Original comment by<EMAIL_ADDRESS>on 26 Apr 2011 at 9:52

Changed state: New
Removed labels: Milestone-2.4

Original comment by<EMAIL_ADDRESS>on 31 Jan 2011 at 5:19

Added labels: Milestone-2.4
Removed labels: Milestone-2.3

Original comment by<EMAIL_ADDRESS>on 12 Mar 2011 at 7:59

Added labels: Priority-Low
Removed labels: Priority-High


PdfViewer.data: dispose issue when recalled as disposed not finished.

Hi there!
First of all, congratulations for the efforts made to produce a such rich and malleable package.
I'm facing a specific issue with the PdfViewer.data class:
On a layout, I display a list of PDF items, associated with the display of the selected PDF via its Uint8List content.
The problem I'm having is that if I move too quickly from one pdf to another in the list, I get a crash exception which seems to be due to a dispose maybe not yet finished inside the package:
first the debug stops in the dispose function in the file pdfrx_web.dart :
@override Future<void> dispose() async { _document.destroy(); onDispose?.call(); }
And then crashes:
══╡ EXCEPTION CAUGHT BY ANIMATION LIBRARY ╞═════════════════════════════════════════════════════════
The following TypeErrorImpl was thrown while notifying listeners for AnimationController:
Unexpected null value.
When the exception was thrown, this was the stack:
dart-sdk/lib/internal/js_dev_runtime/private/ddc_runtime/errors.dart 296:3       throw
errors.dart:296
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/operations.dart 606:18  nullCheck
operations.dart:606
packages/pdfrx/src/widgets/pdf_viewer.dart 1170:59                                [_makeMatrixInSafeRange]
pdf_viewer.dart:1170
packages/pdfrx/src/widgets/pdf_viewer.dart 1611:26                                set value
pdf_viewer.dart:1611
packages/pdfrx/src/widgets/pdf_viewer.dart 1355:7                                 update
pdf_viewer.dart:1355
packages/flutter/src/animation/listener_helpers.dart 161:11                       notifyListeners
listener_helpers.dart:161
packages/flutter/src/animation/animation_controller.dart 908:5                    [_tick]
animation_controller.dart:908
packages/flutter/src/scheduler/ticker.dart 261:12                                 [_tick]
ticker.dart:261
packages/flutter/src/scheduler/binding.dart 1397:7                                [_invokeFrameCallback]
binding.dart:1397
packages/flutter/src/scheduler/binding.dart 1240:11
binding.dart:1240
dart-sdk/lib/_internal/js_dev_runtime/private/linked_hash_map.dart 21:7           forEach
linked_hash_map.dart:21
packages/flutter/src/scheduler/binding.dart 1238:16                               handleBeginFrame
binding.dart:1238
packages/flutter/src/scheduler/binding.dart 1155:5                                [_handleBeginFrame]
binding.dart:1155
lib/_engine/engine/platform_dispatcher.dart 1423:5                                invoke1
platform_dispatcher.dart:1423
lib/_engine/engine/platform_dispatcher.dart 287:5                                 invokeOnBeginFrame
platform_dispatcher.dart:287
lib/_engine/engine/initialization.dart 177:36
initialization.dart:177
dart-sdk/lib/_internal/js_dev_runtime/patch/js_allow_interop_patch.dart 188:27    _callDartFunctionFast1
js_allow_interop_patch.dart:188
The AnimationController notifying listeners was:
AnimationController#bf22f(⏭ 1.000; paused)
════════════════════════════════════════════════════════════════════════════════════════════════════
RethrownDartError: RenderingCancelledException: Rendering cancelled, page 1
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 329:10  createErrorWithStack
errors.dart:329
dart-sdk/lib/_internal/js_dev_runtime/patch/core_patch.dart 265:28            _throw
core_patch.dart:265
dart-sdk/lib/core/errors.dart 120:5                                           throwWithStackTrace
errors.dart:120
dart-sdk/lib/async/zone.dart 1386:11                                          callback
zone.dart:1386
dart-sdk/lib/async/schedule_microtask.dart 40:11                              _microtaskLoop
schedule_microtask.dart:40
dart-sdk/lib/async/schedule_microtask.dart 49:5                               _startMicrotaskLoop
schedule_microtask.dart:49
dart-sdk/lib/_internal/js_dev_runtime/patch/async_patch.dart 181:7
Note 1: I'm using statefull widget context and I get the UInt8List data change from didUpdateWidget function.
Note 2: everything works fine if I let each pdf load finish before selecting another pdf.
Thank you in advance for your kind feedback.
Ben.
EDIT: Sorry, I forgot to put my project details:
Project details
Flutter sdk: 3.24.2
Dart sdk: 3.5.2
pdfrx version: ^1.0.84

Hello @espresso3389,
I saw you flagged the ticket as "bug".
Does it mean that you were able to reproduce the issue?
Or do you need addtionnal context information?

No, I could not reproduce the issue. But the behavier seems to be a bug.

Hello,
I took some time to try to reproduce my issue in a more generic context.
Unfortunately I wasn't able to get the exact same issue.
Perhaps because on our app, we are working in a mobx context which performs rebuilds on specific blocks based on observable variables...
While for this test I used classic setState() to update local variable for rebuild.
However, I still encountered specific uncaught crashes.
In the attached .zip file:
widget_pdfrx_viewer_testing.zip
you will find 3 files :

widget_pdfrx_viewer.dart: a pdf viewer component based on a use of the PdfViewer.data class (feeded with the pdf Uint8List content)
widget_pdf_testing_local_like.dart: an interface that lists pdf files with the viewer of the selected file.
The list and pdf content to display are based on a "local" mode for datas feeding
widget_pdf_testing_client_server_like.dart: an interface that lists pdf files with the viewer of the selected file.
The list and pdf content to display are based on a "client/server" mode for datas feeding.

NOTE :  For the pdf file list, the layouts use local files. So to work with the layouts in your context, you will have to put your own local file paths in the variable "List pdfMediaList" :

Specific crash :
In the use of those interfaces, I faced a specific crash on the widget_pdf_testing_local_like.dart layout :
On a multipage pdf, if I display for example page 2, and then I select in the list a pdf that only has 1 page, then the app crashes on the "_guessCurrentPage()" function in the file "...\Pub\Cache\hosted\pub.dev\pdfrx-1.0.84\lib\src\widgets\pdf_viewer.dart" :

Common crash :
A common crash with the use of both layouts (local and client/server) :
If you click too quickly on different files in the list, you end up with a crash on the "_makeMatrixInSafeRange(Matrix4 newValue)" function in the same file "...\Pub\Cache\hosted\pub.dev\pdfrx-1.0.84\lib\src\widgets\pdf_viewer.dart"

This last one is more like the issue I'm facing in our app, even if in our specific case the crash occurs in the "dispose()" function in the file "...\Pub\Cache\hosted\pub.dev\pdfrx-1.0.84\lib\src\web\pdfrx_web.dart"

So that's it, I hope you will be able to check this on your side ;)
cordially,
Ben.

@BenDevExatech
I've tested with pdfrx 1.0.96 and the following code and could not cause any crashes:
  List<String> pdfMediaList = [
    r"D:\pdfrx\example\viewer\assets\hello.pdf",
    r"D:\pdfrx\example\viewer\assets\rotate-test.pdf",
    r"D:\pdfrx\example\viewer\assets\single.pdf",
  ];

import 'package:flutter/material.dart';

import 'widget_pdf_testing_local_like.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});
  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(),
      body: WidgetPdfTestingLocalLike(),
    );
  }
}

@espresso3389
Hello,
Ok, I checked few days ago with the 1.0.93 and I still got the crash.
I will check tomorrow with the 1.0.96 or 1.0.97 (I'm in France so for now it's time to go to bed ;) )


Kernel panic on newest commit in qemu.

The panic is broadcasted over serial and is as follows:
*** LYRE PANIC ***

The Lyre kernel panicked with the following message:
Exception Double fault triggered (vector 8)

CPU context at panic:
  RAX=000008000057ffe5  RBX=0000000000000000
  RCX=0000000000000004  RDX=0000000000000009
  RSI=000008000057ffe5  RDI=0000000000000013
  RBP=000006ffffffff00  RSP=000006fffffffef8
  R08=000000000040089e  R09=000008000067e05a
  R10=000006fffffffef8  R11=000000004101ad69
  R12=0000000000000000  R13=0000000000000000
  R14=0000000000000000  R15=0000000000000000
  RIP=000000004101ad67  RFLAGS=00000206
  CS=004b DS=0053 ES=0053 SS=0053
  CR2=fffffffffffffff8  CR3=0000000024a9b000
  ERR=0000000000000000

And of course they're too retarded to respond.


go.sum: update for go 1.16

As of go 1.16, build commands no longer modify go.sum by default,
instead they report an error if a requirement or checksum needs to be
added or updated.
Update the go.sum file to have up-to-date requirements and checksums.

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
📝 Please visit https://cla.developers.google.com/ to sign.
Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.
What to do if you already signed the CLA
Individual signers

It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ Googlers: Go here for more info.

@googlebot I signed it!


Image.normalizedDifference error when using add_landsat_ts_gif function

Here is the code I used
Map.add_landsat_ts_gif(roi=roi,label=label, start_year=1985,
bands=['NIR','Red', 'Green'],
font_color='white',
frames_per_second=1,
progress_bar_color='blue',
nd_bands = ['NIR', 'Red'],
nd_threshold = 0.2,
out_gif = 'Kamatsu.gif',
download = True
)
and here is the error message for the normalizedDifference
Please wait ...
The GIF image has been saved to: G:\My Drive\CFLUX\DayCentAU\Miniconda\Notebooks\Kamatsu.gif
Generating URL...
Collection.first: Error in map(ID=0):
Image.normalizedDifference: No band named 'NIR'. Available band names: [vis-red, vis-green, vis-blue].
The input gif file does not exist.
The input gif file does not exist.
Adding GIF to the map ...
The provided file does not exist.
The timelapse has been added to the map.

The timelapse module changed quite a bit the past months. I forgot to update the normalizedDifference function. It has been fixed now. Please update the package and try again.

The visualization with normalizedDifference  shows 1 color


Add support for Omnia Plant Timeseries API

Added on GitLab by @smolvik1 2019-06-18

https://github.com/equinor/omnia-timeseries-sdk-python
https://github.com/equinor/omnia-timeseries-python


[Bug Fix] all TimeTransforms for falsey values

Following up on @HonahX 's comment on https://github.com/apache/iceberg-python/pull/276

CI failure related to: https://github.com/apache/iceberg-python/pull/279

@syun64 Thanks, let me poke someone to get it in 👍

No problem, and thank you! :)

@syun64 The other PR is in 👍 Can you rebase?

of course!

Thank you for the reviews @Fokko @HonahX . Could I ask for your help in merging it in? :)

@syun64 Sorry I was interrupted by other things. Merging!


[test] Add unit tests with jest

#20 added a test for the readme.
More tests to be added.
It remains to be decided how we're going to do this later, because tests cost money. (they only cost a fraction of a cent, we all pay electricity and with our time, so it shouldn't be a big issue but still.) Open source model tests only?


Ambiguous argument in from_data (in example + documentation)

Hi all,
First of all, thank you very much for your work, I really appreciate it to be able to use ndArrays as output/input in my code, as I use both C++ and python for my project.
I just wanted to point out that something may be a bit ambiguous in your example, and in the documentation, regarding the manipulations of ndArrays in C++ : the stride attribute.
The stride is expressed in terms of bytes, of course, that seems clear in the file "wrap.cpp"
But, when reading the files fromdata.cpp and ndarray.cpp; I see this:
// Create an array in C++
int arr[] = {1,2,3,4} ;
// Create the ndarray in Python
np::ndarray py_array = np::from_data(arr, np::dtype::get_builtin() , p::make_tuple(4), p::make_tuple(4), p::object());
As there are 4 elements in your buffer, and each element is assumed to be 4 bytes in size, it may be a bit less ambiguous to use p::make_tuple(sizeof(int)) instead of p::make_tuple(4) in the stride argument.
Of course, this is nothing important, but it would be easy to modify it, or to modify the documentation of the from_data method in order to understand easily that strides is expressed in byte.
Because here is what say the documentation :

the shape of the ndarray as Python object
the strides of each dimension of the array as a Python object

Again, this is is only an advice not a real issue at all, because I find myself having some trouble exporting data because of my misunderstanding of the stride argument in the first place.
Thank you again for your work.

Thanks; very good point.  I've fixed a couple of examples where this was especially bad (including the one you brought up in fromdata.rst), but a quick glance shows the documentation to be in worse shape than I had realized, and it'll probably be a while before I can get around to really cleaning it up.


Typo in intersect_classify_common_impl.hpp

"break" statement is missing near line 254.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 15 May 2010 at 5:24

I believe the example in issue 17 triggers this error (but not only this one).

Original comment by<EMAIL_ADDRESS>on 17 May 2010 at 2:33

This is definitely an error, however I was wondering whether you have a test
case that triggers the incorrect
behaviour?

Original comment by<EMAIL_ADDRESS>on 17 May 2010 at 4:47

Changed state: Accepted


x/build/cmd/relnote: RELNOTE in Gerrit comments are missed after Gerrit UI change in July 2020

Similarly to #40106, another effect of the Gerrit UI switch from change messages to patchset comments is that that when "RELNOTE=yes" is posted in a comment (rather than in the commit message), it is not picked up by the relnote command today.
For example, CL 258957 has a comment that contains "RELNOTES=yes", yet it's not picked up by relnote.
Unlike #40106, relnote uses maintner to very quickly scan over all CLs covering a time period of 6 months rather than the Gerrit API, so the fix is not going to be as straightforward. There are different paths that come to mind:

Support for inline comments can be added to the maintner data model. This is already tracked in #24863. (It may have a significant effect on the amount of data being recorded, but measurements haven't been done yet. Also see #37603.)

Another option is to modify relnote to use the Gerrit API. It should be possible to write a search query to find the relevant CLs. If such a search query is possible, this might be a much smaller volume of work.

Find an effective replacement for the x/build/cmd/relnote command and delete it.

/cc @cagedmantis @toothrot

Sent CL 272907.
I went with the following approach:

Another option is to modify relnote to use the Gerrit API. It should be possible to write a search query to find the relevant CLs. If such a search query is possible, this might be a much smaller volume of work.

If maintner is modified in the future to track inline comments in the future, relnote can go back to not needing to use Gerrit API directly. But it's fine either way.


Log base on commit date-order

Fix the behavior of graveler's Log to use commit iterator which walks the tree based on the commit creation date.

Codecov Report

Merging #1156 (be66fcd) into master (50ddb89) will decrease coverage by 0.01%.
The diff coverage is 71.18%.

@@            Coverage Diff             @@
##           master    #1156      +/-   ##
==========================================
- Coverage   47.08%   47.07%   -0.02%
==========================================
  Files         190      190
  Lines       14749    14773      +24
==========================================
+ Hits         6945     6954       +9
- Misses       6881     6894      +13
- Partials      923      925       +2

Impacted Files
Coverage Δ

graveler/graveler.go
37.83% <ø> (ø)

graveler/ref/rev_parse.go
93.75% <ø> (ø)

graveler/ref/resolve_ref.go
73.33% <66.66%> (ø)

graveler/ref/commit_iterator.go
69.84% <70.00%> (-4.36%)
:arrow_down:

graveler/ref/commit_walker.go
90.47% <100.00%> (+0.23%)
:arrow_up:

config/logger.go
64.28% <0.00%> (-10.72%)
:arrow_down:

catalog/mvcc/cataloger_create_branch.go
81.53% <0.00%> (-3.08%)
:arrow_down:

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 50ddb89...be66fcd. Read the comment docs.

Codecov Report

Merging #1156 (be66fcd) into master (50ddb89) will decrease coverage by 0.01%.
The diff coverage is 71.18%.

@@            Coverage Diff             @@
##           master    #1156      +/-   ##
==========================================
- Coverage   47.08%   47.07%   -0.02%
==========================================
  Files         190      190
  Lines       14749    14773      +24
==========================================
+ Hits         6945     6954       +9
- Misses       6881     6894      +13
- Partials      923      925       +2

Impacted Files
Coverage Δ

graveler/graveler.go
37.83% <ø> (ø)

graveler/ref/rev_parse.go
93.75% <ø> (ø)

graveler/ref/resolve_ref.go
73.33% <66.66%> (ø)

graveler/ref/commit_iterator.go
69.84% <70.00%> (-4.36%)
:arrow_down:

graveler/ref/commit_walker.go
90.47% <100.00%> (+0.23%)
:arrow_up:

config/logger.go
64.28% <0.00%> (-10.72%)
:arrow_down:

catalog/mvcc/cataloger_create_branch.go
81.53% <0.00%> (-3.08%)
:arrow_down:

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 50ddb89...be66fcd. Read the comment docs.


Client side Thrift callback not notified correctly for a void method with RetryingRpcClient (#780)

See: https://github.com/line/armeria/issues/780

Could you write test code for this on com.linecorp.armeria.it.client.retry.RetryingRpcClientTest?
Think you can use DevNullService.Iface for testing.

Thanks a lot, @LiYing2010 !


refactor speedtest chart

Leverage prometheus and modern speedtest CLI for collecting data.  See the following for reference:

https://github.com/jeanralphaviles/prometheus_speedtest
https://github.com/topics/speedtest
https://github.com/topics/speedtest?l=python
https://pypi.org/project/prometheus-speedtest/
https://github.com/m-kraus/prometheus-speedtest
https://github.com/nlamirault/speedtest_exporter
https://github.com/naa0yama/speedtest_exporter
https://www.speedtest.net/insights/blog/introducing-speedtest-cli/
https://github.com/brennentsmith/internet-speed-logger/blob/master/Dockerfile
https://github.com/pschmitt/docker-ookla-speedtest-cli/blob/master/Dockerfile

Fixed by #214


the performance

You tested the request is the data flow and deserialization  performance compare with protobuf？

Not sure why do you try to compare with protobuf?
As far as I remember GraphQL specs doesn't say anything regrading the format of the response. And by default all server implementations provide json response.

Closing due to inactivity

A little off-topic. By your comment, @sav007, can we conclude that we can use any de-/serializer?
My concern is limited to MsgPack only.


[T2A2][W14-A2] Ellango Vesali

Ready for review

Ready for review

Accepting this PR without a review because another of your PRs for this tutorial was reviewed in detail.


Missing @polymer/iron-validator-behavior

Looks like this dependency is missing in this repo. Super awesome web component by the way!

This might be on my end, I'll reopen if necessary, sorry!


Copy Feature

Added Copy feature for a Python Code

This change is

@NiteshKoushik Thank you for your contribution! This has been implemented as part of https://github.com/cockroachdb/docs/pull/17213.

@NiteshKoushik Thank you for your contribution! This has been implemented as part of #17213.

Thank you.


error seed': 42

Hi! I'm OpenDevin, an AI Software Engineer. What would you like to build with me today?
user avatar
bana mali danışmanlık firması için web sitesi tasarla ve çalıştır. Detaylı ve kapsamlı bir çalışma olsun.
assistant avatar
Starting new task...
assistant avatar
Oops. Something went wrong: gemini does not support parameters: {'seed': 42}. To drop these, set litellm.drop_params=True or for proxy: litellm_settings: drop_params: true
assistant avatar
Oops. Something went wrong: Expecting CmdRunAction or AgentEchoAction for Action

Thanks for the report.
This is probably a result of this line being included in codeact_agent.
Maybe we can just remove the seed, since we don't use a seed in any of our other agents? WDYT @xingyaoww ?

@neubig Sounds good! Submit #830 for this.


Pull Request: Add Hotkey for Preset Color / Color Preview from Home Screen / Global Dark Mode Setting

Hello,
I stumbled on your repo earlier today, and I think your work is great! I have a bunch of magic home controlled LEDs, and I've found your code to be exactly what i've been needing. I'd love to contribute.
Here are some ideas, I have and how i'd go about implementing them.
Please let me know if you have more information that might help.

Hotkey Colors

Add a button in the color picking menu picker.vue, to save the current color and brightness. (Possibly up to 5 'presets')
Add a button to the device.vue, to save an additional hotkey. OR have presets work with '(Hotkey) + (1-5)'.
Plan:
Store preset settings into 'store' vue variable. ( store.state.Leds.leds[LEDkey].presets["1-5"] )
Use hotkey.vue to record additional hotkeys for presets.

Color Preview in Home menu, to the left of the devices name.

Add an 'icon' that shows the current RGB setting into device.vue
Plan:
in device.vue add a css box with the RGB value for each device.

Dark Mode Setting

Add an addition settings button to change background-color for each page to black.
Plan:
I have this implemented with css styles on each page, set to dark mode.
This css will be changed from a button in Footer.vue, calling a function to modify the css style of each page.

Looking forward to hearing from you!

Hi,
these ideas are great and you can surely make the pull request. One thing that I think could be done with dark mode is OS support.

This has been implemented.


improve performance of require-jira-issue.sh

If you have a repo with a lot of activity, a branch can quickly fall behind. After a certain number of commits (about 1000) the shell loop will be too slow to run in the 5s timeout, so its not possible to merge from upstream branch intoyour own branch and push it.
Using a delimiter in the git log, and then awk means all the commits can be considered by a single command pipeline.
1000 commits timing:
previous:  5.32s (too much)
new: 0.052s (quick enough)
also... handle case of new repository.

@larsxschneider - any interest in this?

Thanks @time4tea ! That's a smart way to tackle the problem 👍 🎉 😊
I am busy for the next two weeks but I'll integrate your changes afterwards!

@time4tea: I approved your change if it was possible for you to rework your change that it fits with the latest changes in master and the JIRA REGEXP could be parametrized

Sorry I am too busy to change this, but please do feel free to change as you see fit.


Features/2828/tools project links

Displayed Quay.io link and other links
dockstore/dockstore#2828
Set up the ImageProviderService for search.service.ts allowing the
tools data to merge with the images (quay.io and other links) before
pushing the data into the Akita 'store' state.
Modified the filterEntry method in search.service.ts to return a tuple
in order to unit test without side effects.

Waiting for test pass

Unrelated but interesting, the hit['source'] isn't actually a tool or workflow as certain fields are missing


Add performance option

By creating this pull request you agree to the terms in CONTRIBUTING.md.
https://github.com/Infineon/.github/blob/master/CONTRIBUTING.md
--- DO NOT DELETE ANYTHING ABOVE THIS LINE ---
CONTRIBUTING.md also tells you what to expect in the PR process.
Description
I would like to add a new options which by enabling it  shall demonstrate how muc of a real time an optiga related function call consumes.
Context
Raspberry Pi 3B

The changes for all the affected commands are verified.