Merge improvements

@marckohlbrugge hi would you like to merge back?

My intent wasn't to merge back (these changes were made quite hastily without extensive testing or much consideration), but if you feel like they are decent improvements then sure!

I spend some time thinking about it and came up with something that looks a bit better.
You might want to check https://github.com/eljojo/telegram_bot/commit/da10e201d0dcab83ff315ce642b0aa91ec3cc711
Basically, you can pass options to the initializer:
bot = TelegramBot.new(token: 'abc', logger: Logger.new(STDOUT), offset: 123, timeout: 20)

Also, for #get_updates, if you don't pass a block you simply get an array with the updates.
You can also pass a hash with options to #get_updates like so:
messages = bot.get_updates(timeout: 30, offset: 123)

Have you found any other use case that the gem is not handling?
How has your experience been using the gem and making bots?

PS: I added better examples in how to use the gem here: https://github.com/eljojo/telegram_bot#what-else-can-it-do

Changes look great!

Have you found any other use case that the gem is not handling?
How has your experience been using the gem and making bots?

One issue I ran into was handling multiple bots in one Heroku worker. The problem was that get_updates was looping so it could only handle one bot at a time. With this new functionality though, I expect to be able to loop through all the different bots and for each do a single get_updates call. Or I might switch to using web hooks instead if the number of bots becomes too large.
(I'm creating a web UI for people to create their own bot without coding.)

oh I see your problem.
I think creating a web ui is a great idea!
I've kind of been planning the gem for a use case like that. if you notice, for example, each message is not really attached to a single bot ( https://github.com/eljojo/telegram_bot/blob/master/lib/telegram_bot/message.rb ), so they become more or less immutable structures and you can, besides passing them around, use them with different bots.
Going back to the get_updatess blocking problem.
Looping over get_updates does the job, but it means that you can process messages for just one bot at the time.
I've been thinking lately about the actor model and I guess for this case it might make sense. I'd like to check how thread-safe persistent connections with excon are, but an idea would be to have one "Actor" (or thread) per bot, which in turn has a persistent connection to the api.
Maybe it'd complicate things too much and the simplest approach would be to just set up the webhooks.
What I like about having a running process that queries the api instead of using webhooks is that I can keep more things in memory. For example, I'm building an internal bot for my company that spawns virtual machines. The bot has a persistent connection to our virtual machines API and it just shares it in memory. Doing something like that with webhooks would mean that we need to connect each time to the api, which would slow things down.
I've also been playing around with the concept of "sessions", which are just ruby objects that keep a conversation with a specific user at least for a while, so when replying you have more context.
What do you think about all of this? How would a good solution be for you?


Add "tarball" target to Makefile

This target can be useful to build release tarballs.
Output example:
# make tarball
>> building release tarball
 >   logstash_exporter-0.1.2.linux-amd64.tar.gz

Also I removed NOTICE file from list because it doesn't exists in repository.

@christoe I thing this can be merged.
By the way, this should also be used to release the binaries via CircleCI. Any thoughts?

This repo is dead, use the below fork  #35


Add base technology discovery rules to all conversions

@shawn-hurley maybe, though it's pretty quick since it's just XML. I was thinking of adding a flag to disable adding it though


debugging a process which creates a daemon child process, the deamon is killed when stop debugging

Debugging a App with a daemon child process，but when I stop debug，the daemon is killed。 So I guess vscode find child processes and send SIGKILL to child. How can I do sth to prevent kill the daemon?
code:
    process.title = "main-process"
    if (fs.existsSync(sockPath)) {
        client = new Client({sockPath: sockPath});
        handleClientEvent(client);
    } else {
        let sp = exec.spawn('node', [path.join(__dirname, './child.js')], {
            detached: true,
            execArgv: []
        });
        sp.unref();
        detectionServer()
    }

VS Code kills the debuggee (and child processes) only if it has started it.
I suggest to use an "attach" debug configuration.
Here VS Code attaches to an already running process and at the end of the debug session it detaches without killing anything.

But the daemon is created by the master process, if use "attach" configuration, I should start the daemo manually, is that so?

Just add an argument "--debug=12345" to the spawn call where you launch your demon.
How did you start debugging in your original setup?

Can I listen a signal in daemon to prevent killing the daemon process? I do not want the daemon dead.


build.rs cargo::rustc-check-cfg spurious error with MSRV 1.56

Problem
The check for the cargo:: (double colon) syntax should apply only to directives that the MSRV would understand.
Steps
Cargo.toml:
[package]
name = "derive-deftly-macros"
version = "0.13.0"
edition = "2021"
readme = "README.md"
authors=["Ian Jackson<EMAIL_ADDRESS>         "and the contributors to Rust derive-deftly"]
license = "MIT"
description="Macros that implement the derive_deftly crate"
homepage = "https://gitlab.torproject.org/Diziet/rust-derive-deftly"
repository = "https://gitlab.torproject.org/Diziet/rust-derive-deftly"
rust-version = "1.56"

# After editing this file, you will probably need to run
#   maint/update-bizarre
# to update the "bizarre" testing versions in tests/pub-export/bizarre-*

[features]
case = ["heck"]
expect = ["sha3", "syn/full"]
meta-as-expr = ["syn/full"]
meta-as-items = ["syn/full"]

[dependencies]
indexmap = ">=1.8, <3"
itertools = ">=0.10.1, <0.14"
proc-macro-crate = ">=1.1.3, <4"
proc-macro2 = "1.0.53"
quote = "1"
sha3 = { version = "0.10", optional = true }
strum = { version = ">=0.24, <0.27", features = ["derive"] }
syn = { version = "2.0.53", features = ["extra-traits"] }
void = "1"

heck = { version = ">=0.4, <0.6", optional = true }

[lib]
path = "macros.rs"
proc-macro = true

build.rs:
fn main() {
    println!(
        r#"cargo::rustc-check-cfg=cfg(derive_deftly_dprint)
cargo::rustc-check-cfg=cfg(feature, values("bizarre"))"#
    );
}

Expected output: it compiles.
Actual output:
error: the `cargo::` syntax for build script output instructions was added in Rust 1.77.0, but the minimum supported Rust version of `derive-deftly-macros v0.13.0 (/volatile/rustcargo/Rustup/Derive-Deftly/derive-deftly/macros)` is 1.56.
Switch to the old `cargo:rustc-check-cfg=cfg(derive_deftly_dprint)` syntax (note the single colon).
See https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script for more information about build script outputs.

Possible Solution(s)
Accept cargo:: syntax unless the directive that follows :: is one that a compiler which only supports : would understand.
Notes
Unknown diretives are ignored, so cargo::rustc-check-cfg is completely fine.  I htink no version of rust that would understand rustc-check-cfg at all, doesn't understand ::.
Version
cargo 1.80.0-nightly (34a6a87d8 2024-06-04)
release: 1.80.0-nightly
commit-hash: 34a6a87d8a2330d8c9d578f927489689328a652d
commit-date: 2024-06-04
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Debian 10.0.0 (buster) [64-bit]

It turns out that while 1.56 ignores this, it was made deprecated somewhere between that and 1.76.

I think it makes sense being a hard error since it might be a typo hard to catch. As suggested from the error message, developers are able to just switch to the single colon version. There is also a feature release schedule mix between rustc-check-cfg and :: syntax, so the behavior. We can't travel back to patch 1.76, so I feel like it would be a wontfix.
Anything blocking you from switching to the single colon cargo:rustc-check-cfg?

See https://github.com/rust-lang/cargo/issues/13868. If there is any documentation improvement can be done, let us know.

Anything blocking you from switching to the single colon cargo:rustc-check-cfg?

Not if it's going to be supported indefinitely.
One problem I have is that I accidentally broke the MSRV of my crate.  I have CI tests that test with 1.56, which didn't detect this.  Normally Rust's stability guarantee would mean that if 1.56 works, so would 1.76.  But that's not the case here.
How many different Rust versions do I need to test with in CI. if I want to know that all versions since my MSRV will work?  Which versions should I choose?

One problem I have is that I accidentally broke the MSRV of my crate. I have CI tests that test with 1.56, which didn't detect this. Normally Rust's stability guarantee would mean that if 1.56 works, so would 1.76. But that's not the case here.

That is unfortunate. For Cargo.toml we intentionally allow unknown fields to reduce the risk of breaking things in future releases. We missed the scenario that people will opt-in a new syntax from 1.77 in a package with an older MSRV. It's always hard if we allowed a wildcard like syntax from the beginning then we made some change breaking people.
This is a useful reminder that emitting errors should follow pretty much the same compatibility practice as changes to Cargo.toml and config.toml when developing. Thank you for this bug report. I've opened #14150 for such a principle.

Unknown diretives are ignored, so cargo::rustc-check-cfg is completely fine.

This isn't strictly true.  There were no "unknown directives" but anything that wasn't a known directive was instead a metadata KEY.  Even if this means that the KEY will be :rustc-check-cfg.
With cargo::, especially moving metadata keys under cargo::metadata=, unknown keys are now a hard error.  Maybe this can be softened like we do with "unknown manifest field" warnings.   However, that won't completely solve your problem, see below.

Normally Rust's stability guarantee would mean that if 1.56 works, so would 1.76. But that's not the case here.

This is actually fairly common.   Say we add an unstable Cargo.toml field.  Before we add it, it will be an "unused manifest key" warning. When we add it, it is an error saying that the feature is unstable.  We then stabilize it and it i\s now valid to use it.  Having features a hard error on stable is important for users to identify when a field with major semantic meaning is being unused.  If it doesn't have major semantic meaning, we warn instead of error so people can use the feature without an MSRV bump, like with [lints].
If you only test your MSRV and its from before we made a field unstable, then you can run into this.  It would be great if we provided diagnostics to let you know when use of a feature would violate your MSRV.  It looks like we are in this case, so I'm a bit confused at how this broke you.  @ijackson is there something I'm missing as to how you accidentally broke your MSRV?
One thing thats a little different with this build script situation compared to most Cargo.toml changes is that we took existing, valid cargo:KEY=VALUE when KEY starts with :, and changed its meaning.  The error was there for a period of time to raise visibility of this changed meaning so we didn't start re-interpreting people's program without notification.
In the case of check-cfg, it doesn't have meaning in old versions.
As the hard error aligns with other uses hard error in build scripts and other places, I propose we close this.


chore(requirements.txt): unpin versions

Play nice with py packages already installed in the jupyter environment

unpin except for fastai which Yilin said has to stay pinned because the latest version introduced breaking changes


server.js acceptance tests are not all cleaning after themselves

test("get'ing a tile with default style should return an expected tile",  function(done){

If changed to test.only fails to cleanup after itself (and it's not the only one...)

This was fixed in https://github.com/CartoDB/Windshaft/pull/311


Add Vue example project

Adds an example project for demonstrating the Vue integration. The project was generated with Vue CLI so the directory structure should be familiar, and it abstracts a bunch of stuff to do with webpack and other tooling. It also has a nice parity with create-react-app.
There are a couple more buttons in the Vue example – a watch error and an error within Vue's nextTick callback. Both of these get extra metaData indicating where the issue arose.
(There is also a commit that fixes some untidy things in the React example that I spotted while duplicating reusable bits)

Above mentioned docker issue is a failed copy to clipboard from Vue when run in docker.


[Bug report] After calling deleteWithIds, the image is moved to "Recently Deleted" instead of being completely removed.

Version
v.3.2.3
Platforms
Android, iOS
Device Model
iPhone Xs（iOS16.3.1）iPhone 15 ProMAX（iOS17.5）
flutter info
[✓] Flutter (Channel stable, 3.13.9, on macOS 14.2 23C64 darwin-arm64 (Rosetta), locale zh-Hans-CN)
    • Flutter version 3.13.9 on channel stable at /Users/apple/Library/Flutter/flutter_3.19.3
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision d211f42860 (1 year, 2 months ago), 2023-10-25 13:42:25 -0700
    • Engine revision 0545f8705d
    • Dart version 3.1.5
    • DevTools version 2.25.0
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

[!] Android toolchain - develop for Android devices (Android SDK version 35.0.0)
    • Android SDK at /Users/apple/Library/Android/sdk
    • Platform android-35, build-tools 35.0.0
    • ANDROID_HOME = /Users/apple/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.11+0-17.0.11b1207.24-11852314)
    ! Some Android licenses not accepted. To resolve this, run: flutter doctor --android-licenses

[✓] Xcode - develop for iOS and macOS (Xcode 15.4)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15F31d
    • CocoaPods version 1.16.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2024.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.11+0-17.0.11b1207.24-11852314)

[✓] VS Code (version 1.95.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.102.0

[✓] Connected device (4 available)
    • iPhone 15 Pro Max (mobile)     • 770ED060-AFCE-4CE5-A128-F94205178663 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-17-5 (simulator)
    • iPad Air 13-inch (M2) (mobile) • 28EB3FDD-EB4C-4D7C-8B22-9CF0EC06F4EF • ios            • com.apple.CoreSimulator.SimRuntime.iOS-17-5 (simulator)
    • macOS (desktop)                • macos                                • darwin-arm64   • macOS 14.2 23C64 darwin-arm64 (Rosetta)
    • Chrome (web)                   • chrome                               • web-javascript • Google Chrome 131.0.6778.205

[✓] Network resources
    • All expected network resources are available.

How to reproduce?
I found after calling deleteWithIds, the image is moved to "Recently Deleted" instead of being completely removed.
But the documentation clearly states that it should be completely deleted.
Logs
No response
Example code (optional)
final PMFilter filter = FilterOptionGroup(
          createTimeCond: DateTimeCond(min: DateTime(1900, 1, 1), max: maxDate),
          orders: [const OrderOption(asc: true)]);
final List<AssetPathEntity> paths = await PhotoManager.getAssetPathList(
          type: RequestType.image, onlyAll: true, filterOption: filter);
final _path = paths.first;
final total = await _path.assetCountAsync;
final List<AssetEntity> entities =
          await _path.getAssetListPaged(page: 0, size: total);

List<String> deleteIds = [];
for (final entity in entities) {
     deleteIds.add(entity.id);
}
final deleteRes = await PhotoManager.editor.deleteWithIds(deleteIds);

### Contact

_No response_

The behavior is system-controlled.


I've just changed it back to having a single EnableAll at the top, but would be nice to have it per type as well.


Reimplement DIA-Post for HRD as a new MET-TC tool named tc-rmw.

Reimplement DIA-Post tool from HRD to convert model output to storm-relative coordinates.

  - This would be a new tool in MET, perhaps named "tc-rmw".

  - Create a new tool in MET to read a model output file, define a point of interest, and convert the user-configurable field in RMW space (optionally, could get location info from ATCF).

  - That's centered on the lat/lon of interest and do an azimuthal average over multiple heights and radii.

  - Optionally, normalize by the radius of maximum winds.

  - Optionally, potentially normalize the y-axis as well.  This is NOT typically done, but theoretically you could normalize by max inflow level (from Evan K).

  - Tangential wind and radial wind would need to be derived.

  - Write the output to a NetCDF file.

  - This tool should process multiple output times in a single run... up to the the number of output times contained in the track.
[MET-1085] created by johnhg

Charge 277046

Original JIRA attachment location:
https://sdg.rap.ucar.edu/jira/browse/MET-1085?filter=12903
HWRF_PBL_scheme_Review20190126.pdf

Initial beta version ready for validation.
Remaining tc_rmw tasks have been added in issues 1172, 1173, 1174, 1175.


Remove CA.pem file and edgesec-common debian output

The CA.pem file was used for the old packages that are no longer included in the edgesec repository. @mereacre, can you confirm that the CA.pem file is no longer needed?
The /etc/edgesec/config.ini file is now included in the edgesec package, as all other executable/binary packages that reply on /etc/edgesec/config.ini are gone. This means we can delete the edgesec-common package.

CA no longer nedded.


New version: Attractors v1.2.5

Registering package: Attractors
Repository: https://github.com/JuliaDynamics/Attractors.jl
Created by: @Datseris
Version: v1.2.5
Commit: 345cdf3ace698cf7aef3856d4e01a8c8d508093a
Git reference: HEAD
Description: Find attractors of dynamical systems, their basins, and continue them across parameters. Also tipping points for analytic systems.

grrr please close this!


New exe

I uploaded a new mod menu exe version here:
shorturl.at/inpU6

Man, don't you have anything to do?


NavigationAgent colliding with walls when rounding corners and avoiding collisions

Godot version
v3.5.beta4.official [b6968ab06]
System information
Linux
Issue description
The NavigationAgent takes "shortcuts" and travels outside of the navigation mesh when it turns around things. This then causes it to collide with static geometry. It's especially problematic with corners of walls but it also happens with round things like trees. This also happens when it tries to avoid colliding with dynamic obstacles.
The issue can be mitigated by reducing target_desired_distance, but it also causes the NavigationAgent to get stuck (around 0.2 it seems) and will only give it's current position as the next_location. I don't necessarily want such robotic movements either. It also doesn't help for collision avoidance. NavigationAgents frequently run out of the navigation mesh and thus into walls in order to "avoid" collisions.
Basically, the NavigationAgent shouldn't leave the navigation mesh.
Steps to reproduce

The partially transparent red enemy is seeking the green player. Yellow is the next_location. Even though the enemy only has a 0.5 radius the navigation here is baked with 0.9. As you can see, the enemy is well outside the navigation mesh and about to collide with the corner of the gray cube.
Minimal reproduction project
No response

@xix-xeaon could you please provide MRP?

Without a minimal reproduction project here are my guesses what is wrong here with navigation or expectations.
The navigationmesh is baked with the agent_radius and agent_height setting from the NavigationMesh Resource in the NavigationRegion3D. The NavigationAgent3D radius has nothing to do with it and only counts for the RVO avoidance.
The RVO avoidance does not consider navmesh bounds or level geometry. This is a known, real issue.
See https://github.com/godotengine/godot-proposals/issues/4522 what could solve it.
The best workaround for now is to place manual NavigationObstacles for the agents that use avoidance.
Shortcuts are encountered if the target_desired_distance is too large for the baked navmesh settings. The path itself is usually far more detailed when baked with default settings. Agents skip multiple pathindex on each physic tick and NavigationAgent.get_next_location() call when the distance is set way to high.
With current 3.5 NavigationAgent update_navigation() code agents can get stuck in an endless update loop when the distances are set too small for the current NavigationMesh bake detail and the used distance check functions. They constantly think they need to refresh the path but the NavigationServer is unable to provide a better path with more detailed pathpoints for such small distances so agents start to run in small circles.
The NavigationAgent.target_desired_distance is not intended as a parameter to simulate steering behavior around corners. User custom movement code is. Same for smoothed pathpoints to get more realistic curve movement around corners if wanted.
Also there is a limit of 1 update for an agent each physics frame. Multiple calls to NavigationAgent3D.update_navigation() do nothing and are blocked until the next physicsframe. If users call update_navigation multiple times in a frame, e.g. cause a script runs in _process(), only the first call goes through. I guess this was done cause the agent position needs to be synced with physicsspace.

Can be closed due to no MRP and response and this is clearly not a bug but a setup issue explained above. The desired distance is set way to high which creates all these mentioned problems and that the avoidance does not follow navmesh is documented.


WIP: Move block CMS5

This has been here in draft for a couple of weeks... Do you intend to continue working on this PR?

I'm going to close this PR for now. Feel free to open a new one once the work is complete and you're ready for it to be reviewed.


Crash after upgrading to Geolocator 2.0.0+

After upgrading to Geolocator 2.0.0 or higher from 1.1.1, I experience a crash on app startup.
I am using an Activity called SplashActivity to display a splash screen.  Then, in OnCreate, I just start the MainActivity.
The error below indicates it is something to do with my SplashActivity, but I am not sure how to fix this.  I copied SplashActivity below since it is so small.
Any ideas?
[ERROR] FATAL UNHANDLED EXCEPTION: System.NotSupportedException: Unable to activate instance of type ConnectMobileCapture.Droid.SplashActivity from native handle 0xca90001d (key_handle 0x412e03e0). ---> System.MissingMethodException: No constructor found for ConnectMobileCapture.Droid.SplashActivity::.ctor(System.IntPtr, Android.Runtime.JniHandleOwnership) ---> Java.Interop.JavaLocationException: Exception of type 'Java.Interop.JavaLocationException' was thrown.
SplashActivity.cs
namespace ConnectMobileCapture.Droid
{
    [Activity(Theme =<EMAIL_ADDRESS>//Indicates the theme to use for this activity
             MainLauncher = true, //Set it as boot activity
             ScreenOrientation = Android.Content.PM.ScreenOrientation.Portrait, // Start in portrait mode?
             ConfigurationChanges = Android.Content.PM.ConfigChanges.Orientation & Android.Content.PM.ConfigChanges.ScreenSize, // Indicate that we will handle orientation and screensize changes (by ignoring them)
             NoHistory = true)] //Doesn't place it in back stack
    public class SplashActivity : Activity
    {
        protected override void OnCreate(Bundle bundle)
        {
            base.OnCreate(bundle);
            //System.Threading.Thread.Sleep(3000); //Let's wait awhile...
            this.StartActivity(typeof(MainActivity));
            this.Dispose();
        }
    }
}

Are you compiling against API 23?

Yes, I am compiling against API 23.
I started looking through some more commit logs and I see a PermissionsReadme.txt that indicates you are required to add an override called OnRequestPermissionsAsyncResult().  Do I need to do that, or is that something just the Geolocator plugin needs?
Thanks,Matt
Date: Wed, 13 Jan 2016 10:13:19 -0800
From<EMAIL_ADDRESS>To<EMAIL_ADDRESS>CC<EMAIL_ADDRESS>Subject: Re: [Xamarin.Plugins] Crash after upgrading to Geolocator 2.0.0+ (#179)
Are you compiling against API 23?
—
Reply to this email directly or view it on GitHub.

Yes, this needs to be integrated into the app. Take a look at the readme on Geolocator. It explains everything.

I apologize, but I must be missing something.
The app was working with API 23 and Geolocator 1.1.1.  The only change was upgrading Geolocator.  I can roll back to 1.1.1 and it starts working again.
In the Permissions readme, I see that I need to add the OnRequestPermissionsResult() override method to each of my Actions.  I did that.
Other than that, I don't see anything that mentions changes that need to be made by me (other than adding ACCESS_COARSE_LOCATION & ACCESS_FINE_LOCATION, which I already had).  I see that it says it automatically adds needed android permissions and it checks for permissions before StartListening.  However, the app never gets to the point where it creates the Geo object.
I put a breakpoint on the first line of OnCreate in my MainActivity and it does not hit before the crash.  So, the crash is after I call StartActivity(typeof(MainActivity)) and before MainActivity OnCreate.
I will create a stripped down project tomorrow and try to narrow down what might be causing this.
Thanks for helping.

The largest change is that I also have a dependency on the CurrentActivity plugin with is API 14+, as is the Permissions Plugin. You should see a MainApplication in there. A small repo would be nice that I can test though.

OK, I have a little more information.  Hopefully this can help to narrow down the issue.
I created a new project with only the Geolocator plugin and it works as it should.
I created another project and mimicked my actual solution, this time adding a Splash Screen activity.  With the splash screen, it crashes.  So, it doesn't like something there.
I'm new to git, so hopefully this works. I created a test repo with the crashing code.
https://github.com/mhirons/TestCode

Remove your: this.Dispose(); in your SplashActivity. That is causing the issue and is not needed.

I really appreciate that you helped me out on this, even though it ended up being my own fault and not related to Geolocation or any other plugins.


Release Google.Analytics.Admin.V1Alpha version 1.0.0-alpha05

Changes in this release:

Commit 6904fb8: fix: add https://www.googleapis.com/auth/analytics.edit OAuth2 scope to the list of acceptable scopes for all read only methods of the Admin API docs: update the documentation of the update_mask field used by Update() methods

Created release for Google.Analytics.Admin.V1Alpha-1.0.0-alpha05

Doc upload failed - changing this to published.


chore: auto-start backend

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#153
#152
#151  👈
#150
#149
#148
#147
#146
#145
#144
#143
#142
#141
#140
#139
#138
#137
#136
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @NathanFlurry and the rest of your teammates on  Graphite


C/C++ source/header files support

Any plan to support alternate of  C/C++ source code - header files?
E.g.:
$ alt ./foo/bar/faz.c
./foo/bar/faz.h

$ alt ./fizz/bang.hpp
./fizz/bang.cpp

+1, I gave alt a try hoping to get exactly this behavior.
Perhaps, even slightly generalized: I'd love to be able to cycle through same-basename files of whatever differing extensions, e.g.:

Cargo.toml → Cargo.lock → Cargo.toml
FooDoc.md → FooDoc.html → FooDoc.md
watched_template.j2 → watched_template.json

... etc, etc. This has gazillion handy uses.

On closer look, this isn't what's happening here:
https://github.com/uptech/alt/blob/4575feb0727c52a0920aeb79056304a86304c53c/src/main.rs#L110-L117
Line 114 filters out candidates having similar is_test_file-ness; which is unfortunate.
Will you guys at @uptech be welcoming a patch which implements the above (without, of course, breaking the already working test/impl flow) ?

Yes, we would welcome a patch.
@ulidtko The original intent was for it to be general like this. The filter on tests files etc was intended to just be a performance improvement significantly limiting the similarity comparisons that had to be done.
So if we can figure out a way to do this while still keeping the performance and still supporting the other use cases. Yeah I think we would want to support this use case.

I just released a new major version of this, v4.0.0 which I believe should help this scenario.


Added link to ClickHouse to the list of bindings

Now ClickHouse has integration with H3:
https://github.com/yandex/ClickHouse/pull/4724 https://github.com/yandex/ClickHouse/pull/5805

Coverage remained the same at 100.0% when pulling b03ee29ba98b20cdcc744ceb9c78d148936b978a on alexey-milovidov:patch-1 into d768a74fd4c6359e2cfcaabf479ea23eddbbb9ac on uber:master.

Hi, thanks for adding this! I have two asks before merging: please reorder the ClickHouse section to be above ECL to maintain alphabetical ordering. Before we can merge your changes, we need you to agree to the Contributor License Agreement: https://cla-assistant.io/uber/h3 (For some reason the CI check that would prompt for that didn't run on this pull request, we're looking into that.)

Ok.


fix(core): necessary operations before doing copy

Add necessary operations before doing copy

ensure source file
ensure target parent path

Thanks a lot!


Prepull custom images

Hi
I have some quite large docker images (around 7GB in size), and I would suggest an option to prepull custom images during node boot so that the first deploy of a pod will be quick. I'm fully aware that this would lead to a longer boot time for a node. A node should not be reported as ready before all custom images are pulled completely. A config in the cluster.yaml file might look like
worker:
  nodePools:
    - name: poolname
      prePullImages:
        - "repo:label"
        - "repo2:label"

Pulling from a private repo like AWS ECR should be supported.
Any thought on this feature request?
PS, I understand that there has been some discussion regarding prepull of images vs baking custom AMIs.

republish to ecr?

@redbaron . Sorry, I'm not sure I understand what you mean by republish to ecr?

Are these custom images running cluster services or your own apps? If it's your own apps, what is the use case to preload rather than waiting on app deploy/update? Helm for example waits for deploys to happen so just trying to figure out what the intention is here.

These are custom images driving my own services and workloads. I will try to explain the motivation and use case.
Pulling a 7GB custom image from ECR to a node takes approx 4-5 minutes Including unpack), slightly dependent on the node type. Imagine that I have a service (pods) that is scaled by a horizontal pod autoscaler rule, and by the time the hpa would like to add one pod for the service, a new node was just added to the pool (by node auto scaling). The pod scheduler would then try to put the pod on the newly started node, and this will lead to a 4-5 minutes delay for the pod to become ready (due to image pulling delay).
So in this case it would actually been better if the new pod was scheduled to a existing node, already having the image, to quickly increase the service capacity.
Or as I suggest the image could be prepulled during node startup, and then the service capacity would be increased quickly regardless of which node the new pod is scheduled to run.
Does this make sense?

I think there are these cases for up scaling:

Lack of resources which means cluster scales up

if preloading it won't take any time off scaling because the instance still has to download the images
without preloaded the instances start up quicker

New pod fits on one of the existing instances

if preloaded it means the pod can start quicker but if not and we are scaling up and down a lot all instances eventually naturally end up with the image (at least in the short term, see below caveat)
if not preloaded it means the image takes some time to download

I'm not sure in 2 if the scheduler is clever enough to launch pods on instances which had the image before. The big caveat is that images can be garbage collected by k8s so without a pod using the image I believe it can get deleted.

IMHO running apps is not a concern of kube-aws. Are you going to redeploy your cluster when your all image updates? It doesn’t make sense.
As a hack You can solve it by creating your own pre-puller in the form of DaemonSet which runs your image, but not the app. Let's say you override entrypoint to be /bin/bash -c ‘sleep infinity’
Real solution would be:
Not to have 7GB images. When you build image do install and remove unnecessary bits in the same RUN command, if you separate them, they are committed to different layers and total image size doesn’t shrink.
If you can not avoid 7GB images, try to move RUN commands which create most of data to the top, and overall move most frequently changed parts to the bottom and least frequently changed paths to the top. This will help with layers reuse, so that when new version of the image is pulled, only small number of layers are actually downloaded.

Thanks for the feedback
@redbaron , I'm not going to reload my cluster for a service update. The image I would like to prepull is a "base image". Changes to services will be applied as a small additional image layer of only a few megabytes.
The base image is highly optimized when i comes to size by concatenating RUN commands in the dockerfile. Also download, install and removal of any intermediate install files are concatenated to avoid extra layers in the image.
The use case of ours is maybe a little special. We need to use the AWS Auto Scaling features to scale our cluster worker pools, the Kubernetes cluster autoscaler doesn't work well with our use case. I will try to explain why.
When I deploy a service pod I would for the most times use a very small CPU request in the pod sepc, maybe as small as 100m CPU. Many of the several hundreds of services we intend to deploy to our cluster, has a very low request rate (hence low idle load). But when a service gets a request the pod will usually consume a complete host core (or whatever I cap the pod at with CPU resource limit) for as long as it takes to process the request (can be milliseconds to seconds). Once in a while one or some of the services get a dramatic increase in load that might last for hours, that lead to a considerable horizontally scaled out pod.
So it does not make sense to us to request say 500m CPU for each service pod, usually they just stay there idle for 90% of the day consuming not CPU at all on the underlying host. So we in practice overbook the host CPUs dramatically. The Kubernetes cluster autoscaler will not understand that some of the services are under heavy load, as the real node load is not used to calculate the need for new nodes. Kubernetes will only add a node if it don't find room to add a pod to any nodes based on the pod resource request (which in our case is way smaller then the real load, when the service actually have to do work). It's a calculated risk that not all services get under heavy load at the same time ;)
So by using AWS Auto Scaling we can scale out the nodes based on actual node CPU load, regardless if a node theoretically might fit more pods according to the sum of pod CPU requests for pr node. This, in combination with podAntiAffinity and preferredDuringSchedulingIgnoredDuringExecution, will usually result in new pods landing on any newly added nodes, if hpa decides to scale out pod.  Which without image prepull will not have the base image in place.
Ideally the Kubernetes cluster autoscaler should look at both sum of resource requests AND real load on nodes when deciding if a pool needs to scale out with more nodes. And the scheduler should look at node loads not only if the node theoretically have room for a pod (based on pod resource requests), when deciding which node to put a new pod.
I'm not sure if I'm any of this make sense. It would be easier to explain this by speaking, and maybe a demo. ;)

@paalkr Thanks for the detailed feedback 👍
First of all, I agree with you that the AWS native auto scaling fits your use-case.
However, on the other hand, I guess you can still utilize k8s' cluster-autoscaler in combination with horizontal-pod-autoscaler(HPA) and pod anti affinity instead.
My idea is that you set cpu request to a minimum amount enough for idling, say 100m, and enable HPA on your replica set to trigger scaling with a threshold of, say, 90% of the requested amount 100m. Also don't forget to provide a pod anti affinity not to make pods in the replica set collocated into a node. This way, once pods in your replica set start consuming cpu more than requested 100m, hpa will auto-scales pods into different nodes, which in turn triggers cluster-autoscaler to add more nodes.
Also, my guess is that utilizing the AWS native auto scaling here would still require you to enable HPA anyway, or your replicas will end up at the same number. However, if you enable HPA in the first place, cluster-autoscaler would work IMHO.

Regarding your original request of pre-pulling images, my preference is "baking them into AMIs"
#505. So that we don't need to wait until cluster-autoscaler is improved to allow having "spare capacity" for faster pod autoscaling https://github.com/kubernetes/contrib/issues/2251.
In other words, you'd need to wait for the CA improvement to achieve rapid auto-scaling of pods with your possible Low-CPU-Request/HPA/Pod-Anti-Affinity/Cluster-Autoscaler/Image-Pre-Pulling setup.
What do you think?

Hi @mumoshu ,
This is complicated, that's for sure, with many moving parts in actions ;) We do relay on HPA for scaling our pods, which works quite well. The "problem" for us handling the scaling out for more nodes when some pods get under heavy load. If you sum the requested amount of CPU pr node, there wouldn't be no need for adding more nodes to the cluster. But if you sum the real CPU load of the cluster nodes you would see that real CPU-load is so high at all nodes that more nodes definitely should be added to the pool.
The nice thing is that you will see the node real load by running top nodes. But unfortunately this information is not evaluated by the K8s cluster autoscaler, if I'm not mistaken. K8s cluster autoscaler only operates by the sum of resource requests pr node, not the nodes actual CPU load.
An AWS CloudWatch alarm hooked up to our ASG CPU utilization will on the other hand kick in, and scale the pool if needed based on real node CPU metrics. For the time being we're quite happy with how AWS ASG auto scaling works though. Especially as we are using spot fleet for some worker pool. Spot Fleet capacity can sins a while ago (https://aws.amazon.com/blogs/aws/new-auto-scaling-for-ec2-spot-fleets/) be adjusted (AutoScaled) based on CPU metrics for the fleet, without the fleet being recreated.

Hi @paalkr, thanks as always for the detailed reply.

If you sum the requested amount of CPU pr node, there wouldn't be no need for adding more nodes to the cluster.

This is becoming more and more my education but then, how do you scale your PODS after the AWS native autoscaling added NODES?

We do set the AWS CPU AutoScaling threshold at a level that will ensure the pool scales out say at 35% real ASG CPU load. This will make sure we do have some free capacity in the worker pool (for any service/deployment to scale within normal load). We also assumes (by historical data) that not all deployments/services will be under heavy load at the same time. So by using the 35% threshold the worker pool will almost always be in advance of the pods scaling, and have free capacity when some pods get a spike in load.
HPA evaluates the real pod CPU utilization, and decides to scale out the pods if a deployment/service get under heavy load. The pod anti affinity will try to spread the load on all nodes. As the ASG threshold is breached more capacity/nodes are added to the worker pool. Any new pods will then end up at these new nodes due to the fact that we have pod anti affinity and that the scheduler places new pods on nodes with the most free resources (it least I'm under the impression that the scheduler behaves like this). And in this context having the base image for our pods/service in place (pre-pulled) will improve the speed of pod auto scaling/initial startup time.
I'm not sure if my English is good enough to precisely describe the use case, but I'm trying my best ;)

@paalkr Thanks again for the reply.

and have free capacity when some pods get a spike in load.

So basically,

You're using AWS-native autoscaling instead of cluster-autoscaler just for adding nodes earlier(in advance/before a spike comes)
cluster-autoscaler can be used for your use-case onc https://github.com/kubernetes/contrib/issues/2251 is resolved

right?

I'm not sure if my English is good enough to precisely describe the use case, but I'm trying my best ;)

So am I :)
Revisiting your original question, for me @redbaron's idea of creating a pre-puller daemonset seems to work for you today.
I guess we can even support automating deployments of the pre-puller daemonset once #509 comes to reality.
What do you think?

@mumoshu , thanks :)

So basically,
You're using AWS-native autoscaling instead of cluster-autoscaler just for adding nodes earlier(in advance/before a spike comes)
cluster-autoscaler can be used for your use-case onc kubernetes/contrib#2251 is resolved
right?

Probably

Revisiting your original question, for me @redbaron's idea of creating a pre-puller daemonset seems to work for you today.

The idea of a DeamonSet to pull the image is maybe not the optimal solution, as the node will be rendered "ready" before the pull process are finished.
Plugin seems like a feature that we might be able to use to get our desired functionality implemented.

Thanks @paalkr!

as the node will be rendered "ready" before the pull process are finished.

Good point 👍 It must be true.
I wish I could add a generic mechanism to "inject" your custom dependencies (backed by systemd unit, ExecStartPre of a systemd service, k8s job targeted to the node?, etc.) which delays a node from becoming "ready" until those dependencies are met.
Option 1
worker:
  nodePools:
    - name: poolname
      prePullImages:
        - "repo:label"
        - "repo2:label"

This is your original idea which would work very well with this specific use-case
Option 2
worker:
  nodePools:
    - name: poolname
      prewarm:
      - command: bash
        args:
        - -c
        - |
          docker pull repo:label
          docker pull repo2:label

would be a bit more generic.

@mumoshu , thanks!
Any of the options would work as I see it, as long as custom repo credentials (ECR AIM or any other private repo logins) applied to a node is respected, so the docker pull isn't blocked.
Your suggestion is more generic then mine, and can probably be used to solve other custom needs as well.

@mumoshu , @paalkr don't we have custom systemd unit files support now? there can be a unit file which does docker pull, if you make it RequiredBy=kubelet.service then then node will be joining kube with image pre-pulled

@redbaron @paalkr Wow, thanks. I've been completely forgotten about the feature...
Untested but I guess something like this would work
worker:
  nodePools:
  - name: pool1
     customSystemdUnits:
     - name: prepull.service
       command: start
       enable: true
       content: |
         [Unit]
         Description=Docker images pre-puller
         RequiredBy=kubelet.service
         [Service]
         Type=oneshot
         RemainAfterExit=yes
         ExecStartPre=/bin/bash -c "for img in repo:label repo2:label; do echo pulling \$img; until /usr/bin/docker pull \$img; do echo retrying...; sleep 1; done; done; echo successfully pulled all the images"
         ExecStart=/bin/true

@redbaron @mumoshu
Thanks! Clever suggestion. I'd never come to think that I could use a custom Systemd service to prepull the images. I will try out this suggestion and report back.

Hi @paalkr, did it work for you? 😄

Hi @mumoshu . Not during my first try. I have to look at the command and see if I made any typos.

Hi @mumoshu
The service failed as you can see from the screen shot

Can you please direct me to where the log file is stored?

@mumoshu ,
BTW, I understand why the kube-node-label.service failed in this particular case. The above screen shot is from a spot fleet node, and the kube-node-label.service is referring the AWS resources (like auto scaling group and launch configuration) which is not available for a spot fleet ;)

Hi @paalkr, I guess you can journalctl -u prepull.service > prepull.service.log to save full log of the service.

@paalkr

kube-node-label.service is referring the AWS resources (like auto scaling group and launch configuration) which is not available for a spot fleet ;)

Thanks for the good catch!
Probably we're missing a validation to disallow the combination of spot fleet + awsNodeLabels.

@mumoshu ,
Thanks
So I have a syntax error in the pull command. This is from the log file
I missed the ; after the latest done command. I'll give it another shot right now.
May 17 04:43:33 ip-10-1-44-242.eu-west-1.compute.internal bash[1208]: /bin/bash: -c: line 0: syntax error near unexpected token `echo'
May 17 04:43:33 ip-10-1-44-242.eu-west-1.compute.internal bash[1208]: /bin/bash: -c: line 0: `for img in xxxxxxxxxx.dkr.ecr.eu-west-1.amazonaws.com/ags/105:base_wa_ags_1.2.1; do echo pulling \$img; until /usr/bin/docker pull \$img; do echo retrying...; sleep 1; done; done echo successfully pulled all the images'
May 17 04:43:33 ip-10-1-44-242.eu-west-1.compute.internal systemd[1]: prepull.service: Control process exited, code=exited status=1

Thanks for the good catch!
Probably we're missing a validation to disallow the combination of spot fleet + awsNodeLabels.

Thanks. You are probably right. I haven't seen any problems as of yet caused by these small issue though.

@paalkr I'm looking forward to your result 👍

I haven't seen any problems as of yet caused by these small issue though.

Good to know 👍
I'd appreciate it if you could submit an another github issue to track that anyway.

@mumoshu ,
More syntax errors it seems, any suggestions? I must admit that Linux is not my native "language" ;)
The  image is valid, and I just xxx-ed out our AWS account part of the repo for the sake of posting this comment.
Looks like the img variable is never populated with the image reference, I'm I right?
May 17 05:21:56 ip-10-1-43-176.eu-west-1.compute.internal systemd[1]: /etc/systemd/system/prepull.service:3: Unknown lvalue 'RequiredBy' in section 'Unit'
May 17 05:21:56 ip-10-1-43-176.eu-west-1.compute.internal systemd[1]: /etc/systemd/system/prepull.service:7: Ignoring unknown escape sequences: "for img in xxxxx.dkr.ecr.eu-west-1.amazonaws.com/ags/105:base_wa_ags_1.2.1; do echo pulling \$img; until /usr/bin/docker pull \$img; do echo retrying...; sleep 1; done; done; echo successfully pulled all the images"
May 17 05:21:56 ip-10-1-43-176.eu-west-1.compute.internal systemd[1]: Starting Docker images pre-puller...
May 17 05:21:56 ip-10-1-43-176.eu-west-1.compute.internal bash[1313]: pulling $img
May 17 05:22:01 ip-10-1-43-176.eu-west-1.compute.internal bash[1313]: Error parsing reference: "$img" is not a valid repository/tag
May 17 05:22:01 ip-10-1-43-176.eu-west-1.compute.internal bash[1313]: retrying...
May 17 05:22:02 ip-10-1-43-176.eu-west-1.compute.internal bash[1313]: Error parsing reference: "$img" is not a valid repository/tag

@paalkr Could you try replacing all the \$img to just $img?

@mumoshu
The command works, but unfortunately authentication doesn't
May 17 06:11:54 ip-10-1-43-19.eu-west-1.compute.internal bash[1224]: unauthorized: authentication required
I was afraid this would be the result. I guess that the command is not picking up the ECR secret, wich of course make sense. Do we need to pull using rkt or something?

@paalkr If I remember correctly, in a k8s cluster, k8s automatically obtains docker-login creds from ECR for you. In this case though, we'd need to obtain creds ourselves.
Could you run something like docker_login=$(docker run coreos/awscli aws ecr get-login); $docker_login in the beginning of the script to run an appropriate docker login?

@redbaron , @mumoshu
Thanks a lot for all the good help and suggestions. I got the prepull service to work by adding this to my cluster config. Nice :)
      customSystemdUnits:
      - name: prepull.service
        command: start
        enable: true
        content: |
          [Unit]
          Description=Docker images pre-puller
          RequiredBy=kubelet.service
          [Service]
          Type=oneshot
          RemainAfterExit=yes
          ExecStartPre=/bin/bash -c "docker_login=$(docker run quay.io/coreos/awscli:master aws ecr get-login --region eu-west-1); $docker_login; for img in XXXXXXXX.dkr.ecr.eu-west-1.amazonaws.com/ags/105:base_wa_ags_1.2.1; do echo pulling $img; until /usr/bin/docker pull $img; do echo retrying...; sleep 1; done; done; echo successfully pulled all the images"
          ExecStart=/bin/true


update Spanish translation

@wavebeem, hello again, I modified the Spanish translation a bit:

Fixed some typos
Fixed some translation errors
New website elements translated

Thanks! I really appreciate it


Cyclic Sort in C++

Description
In this, we will get a brief idea about the Cyclic Sort
Domain
C/CPP
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign


Modifying the default resolver created by @Model directive still has reference to not required parameters

How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
18.16.0
Amplify CLI Version
12.7.0
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
I moved the appsync resolvers and appsync functions to amplify/backend/api/<api_name>/stacks/CustomResources.json and replaced parameters as listed below since these values are by default passed to customResources as per this link https://docs.amplify.aws/cli-legacy/graphql-transformer/resolvers/#custom-resolvers
"referencetotransformerrootstackGraphQLAPI20497F53ApiId" -> "AppSyncApiId",
"referencetotransformerrootstackS3DeploymentBucket7592718ARef" -> "S3DeploymentBucket",
"referencetotransformerrootstackS3DeploymentRootKeyA71EA735Ref" -> "S3DeploymentRootKey",
"referencetotransformerrootstackenv10C5A902Ref": "env",
Still I see that the amplify/backend/api/<api_name>/build/cloudformation-template.json contains the the unused parameters and it gives an error on amplify push saying parameters are not present.
As a workaround, I added the parameters to amplify/backend/api/<api_name>/parameters.json with some default value and then the amplify push passed.
Expectation: I was expecting cloudformation-template.json file to be modified as per the changes in customResources.json.
Describe the bug
I see that the amplify/backend/api/<api_name>/build/cloudformation-template.json contains the the unused parameters and it gives an error on amplify push saying parameters are not present.
Only when, I added the parameters to amplify/backend/api/<api_name>/parameters.json with some default value, the amplify push passed.
Expected behavior
I was expecting cloudformation-template.json file to be modified as per the changes in customResources.json.
Reproduction steps

amplify init
amplify add api - select graphql to create appsync resource
Update the generated schema.graphql with the basic schema as below type Foo @model (queries: null, mutations: null, subscriptions: null) @auth(rules: [{ allow: public }]) { id: ID! @primaryKey name: String! @index(name: "byName", queryField: "fooByName") description: String }
amplify api gql-compile
Move the generated appsync function, resolvers, parameters, outputs from amplify/backend/api/<api_name>/build/stacks/Foo.json file to amplify/backend/api/<api_name>/stacks/customResources.json
Move the amplify/backend/api/<api_name>/build/stacks/Foo.json file to amplify/backend/api/<api_name>/stacks/Foo.json file and make the resources as Empty Resource
Update the parameters in amplify/backend/api/<api_name>/stacks/customResources.json to   "referencetotransformerrootstackGraphQLAPI20497F53ApiId" -> "AppSyncApiId", "referencetotransformerrootstackS3DeploymentBucket7592718ARef" -> "S3DeploymentBucket", "referencetotransformerrootstackS3DeploymentRootKeyA71EA735Ref" -> "S3DeploymentRootKey", "referencetotransformerrootstackenv10C5A902Ref": "env"
amplify push -y
Getting error that the parameters are not present referencetotransformerrootstackGraphQLAPI20497F53ApiId, referencetotransformerrootstackS3DeploymentBucket7592718ARef, referencetotransformerrootstackS3DeploymentRootKeyA71EA735Ref

Project Identifier
No response
Log output

# Put your logs below this line

Additional information
No response
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

Hey @ckgupta :wave: thanks for raising this! I'm going to transfer this over to our API repo for better assistance 🙂


Allow plugins to modify default QF output

The generated code could potentially look quite a lot cleaner if Lombok annotations were used where possible.
Since this could obviously lead to issues, and not everyone will want this, a flag would be needed.
Example:
public class Animal {
    private int age;

    public Animal(int age) {
        this.age = age;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

Could be decompiled as:
@AllArgsConstructor
public class Animal {
    @Getter
    @Setter
    private int age;
}

This could also make longer classes more readable.
Another useful feature would be annotating methods with illegal throws with @SneakyThrows, assuming that is what the original developer used, therefore removing some compilation errors, and making the code (possibly) more accurate.
Of course, you don't want to get too generous. AllArgsConstructor should only be used when the constructor only sets all of the applicable fields in the class, and annotations should generally only be used when the behaviour and access modifiers are completely unchanged.

This relates to #122 - external framework support and non-pure-java would be better as plugins (ideally including IntelliJ @NotNull support)

I agree. This will not be a first party feature, but we want to make code simplification and such like this possible through plugins, once that system matures.

I feel like the new issue title makes it sound too similar to #122 - maybe Annotation Processor Plugins or something?

Since annotation processing is a subset of modifying the default code output, it still works here- the issues mainly help organize what we prioritize working on, so it still works 😛


[Bug] npm run dev error : ERR_PACKAGE_PATH_NOT_EXPORTED

Version
<EMAIL_ADDRESS>Reproduction link
https://github.com/creativetimofficial/notus-nextjs
Operating System
macOS Monterey
Device
Macbook pro 16
Browser & Version

Steps to reproduce
1.Go to https://github.com/creativetimofficial/notus-nextjs
2.Download code
3.unzip
4.npm install
5.npm run dev -> error
What is expected?
Run
What is actually happening?
error when "npm run dev"
node:internal/modules/cjs/loader:535
throw e;
^
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/node' is not defined by "exports" in /Users/seungyuncho/Downloads/notus-nextjs-main/node_modules/postcss/package.json
at new NodeError (node:internal/errors:393:5)
at throwExportsNotFound (node:internal/modules/esm/resolve:358:9)
at packageExportsResolve (node:internal/modules/esm/resolve:668:3)
at resolveExports (node:internal/modules/cjs/loader:529:36)
at Module._findPath (node:internal/modules/cjs/loader:569:31)
at Module._resolveFilename (node:internal/modules/cjs/loader:981:27)
at Module._load (node:internal/modules/cjs/loader:841:27)
at Module.require (node:internal/modules/cjs/loader:1061:19)
at require (node:internal/modules/cjs/helpers:103:18)
at Object. (/Users/seungyuncho/Downloads/notus-nextjs-main/node_modules/tailwindcss/lib/util/processPlugins.js:12:36) {
code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}

Solution
Additional comments
I use node LTS18.12.1
And NVM 8.19.2 version

I created another issue


Hide deleted branches when listing by "checked out" order

Fixes #6

@eldano Can you take a look at the PR?

@san650 I left one comment but it works as I expected. Thanks :)

@eldano merged! Thanks for the review!


feat(backend): add simple media proxy with http-proxy-middleware

proxy that redirects https://editor.serlo.org/media/… to our bucket so we can persist the URL even when we move to bucket / object or want to add additional access restrictions. More Background.
For PE-200 and PE-193.

Merged for testing, still open for feedback :)


Fix typo in README regarding the extension configuration.

Fixes #52. Thanks again for the feature @jaredsburrows and your cool talk at the Gradle Summit.

@vanniktech Thank you for the quick fix. Thanks for watching it!


permissions: Allow record reviewers to also read/update request

closes #24 #25
possibly closes #15 (to be tested)
Update the request permission policy to allow users who can_manage a record to also view the associated curation request.
There is also some renaming in this PR, which adds some noise. Maybe easier to compare the README instead of permissions.py. ~Could be solved by merging #22 and rebasing~

Community manager view:

Record creator view:


feat: add support for targetting specific workspaces

fixes #1126

some things require chen. see my remarks.
also, please add proper unit tests

Happy to do the changes. I would think some integration tests would be required for this change as it is not really feasible to test it in isolation due to the logic effectively sitting on the npm ls side.
I agree with the requirement of testing. I spent some time initially before making the PR going through the existing unit and integration tests and it is not very clear to me how we should go about adding tests for new functionality. For example, I do not see tests for several of the CLI options (such as --short-PURLs).
Could you provide a bit of a guide regarding how we should lay out tests for new functionality going forward as well as a brief of how the existing integration tests work and how they are structured. I intend on making additional PRs in the future for other issues and features so this would be very beneficial for me (and I'm sure other community members).

@MalickBurger for integration tests,

you would add new setups here, if needed: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/demo
Then, add the appropriate npm ls ... run here: https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/.github/workflows/npm-ls_demo-results.yml
have the npm ls ... result data gathered via a CI (Github action/workflow).
you can dispatch the action in your repo here: https://github.com/MalickBurger/cyclonedx-node-npm/actions by dispatching the workflow (you might need to enable workflows for your repo)
download the action artifacts and add them here: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results
remove unnecessary data via https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results/_duplicates-cleaner (might require a back-merge or rebase to pull the scripts in)

since you are planning on adding conditional parameters in the npm ls call, you need to incorporate this in the existing testing processes somehow.

@MalickBurger, for adding additional integration tests,

you would add new setups here, if needed: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/demo
Then, add the appropriate npm ls ... run here: https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/.github/workflows/npm-ls_demo-results.yml
have the npm ls ... result data gathered via a CI (Github action/workflow).
you can dispatch the action in your repo here: https://github.com/MalickBurger/cyclonedx-node-npm/actions by dispatching the workflow (you might need to enable workflows for your repo)
download the action artifacts and add them here: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results
remove unnecessary data via https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results/_duplicates-cleaner (might require a back-merge or rebase to pull the scripts in)

since you are planning on adding conditional parameters in the npm ls call, you need to incorporate this in the existing testing processes somehow.

Looking at this, could you provide some testing support for an existing argument that is passed to npm ls by the plugin which I could then base my additional tests on? It would be easier and cleaner for a code maintainer to set these up so there is a standard to follow going forward for community members.

@MalickBurger, for adding additional integration tests,

you would add new setups here, if needed: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/demo
Then, add the appropriate npm ls ... run here: https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/.github/workflows/npm-ls_demo-results.yml
have the npm ls ... result data gathered via a CI (Github action/workflow).
you can dispatch the action in your repo here: https://github.com/MalickBurger/cyclonedx-node-npm/actions by dispatching the workflow (you might need to enable workflows for your repo)
download the action artifacts and add them here: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results
remove unnecessary data via https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results/_duplicates-cleaner (might require a back-merge or rebase to pull the scripts in)

since you are planning on adding conditional parameters in the npm ls call, you need to incorporate this in the existing testing processes somehow.

Looking at this, could you provide some testing support for an existing argument that is passed to npm ls by the plugin which I could then base my additional tests on? It would be easier and cleaner for a code maintainer to set these up so there is a standard to follow going forward for community members.

will do. just bare with me, it may take a while

will do. just bare with me, it may take a while

I am currently working on a solution. Will ping as soon as I have something for you.

@MalickBurger ,
I've overhauled the integration tests.
It would currently be enough to add your tests, showcasing that the intended parameters are sent to npm-ls. This could be done here: https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/tests/integration/cli.args-pass-through.test.js
you might add something like
// region workspace
['workspace not supported npm 6 ', `6.${rMinor}.${rPatch}`, ['--workspace my-ws'], [...npm6ArgsGeneral]],
['package-lock-only npm 7', `7.${rMinor}.${rPatch}`, ['--workspace my-ws'], [...npm7ArgsGeneral, '--workspace my-ws']],
['package-lock-only npm 8', `8.${rMinor}.${rPatch}`, ['--workspace my-ws'], [...npm8ArgsGeneral, '--workspace my-ws']],
['package-lock-only npm 9', `9.${rMinor}.${rPatch}`, ['--workspace my-ws'], [...npm9ArgsGeneral, '--workspace my-ws']],
['package-lock-only npm 10', `10.${rMinor}.${rPatch}`, ['--workspace my-ws'], [...npm10ArgsGeneral, '--workspace my-ws']]
// endregion workspace

merged in the latest master, fixed some merge conflicts.
did another round of review. result: there are open questions and issues


Implement OpenSearch core branching strategy

Description
Ensure MAJOR_VERSION.x branch exists, the main branch acts as source of truth effectively working on 2 versions at the same time.
Related META issue
https://github.com/opensearch-project/opensearch-plugins/issues/142
Current Behavior
Currently plugins follow a branching strategy where they work on main for the next development iteration, effectively working on 2 versions at the same time. This is not always true for all plugins, the release branch or branch pattern is not consistent, the lack of this standardization would limit multiple automation workflows and alignment with core repo. More details on META ISSUE
Proposed solution
Follow OpenSearch core branching. Create 1.x and 2.x branches, do not create 2.0 as a branch of main, instead create main -> 2.x -> 2.0. Maintain working CI for 3 releases at any given time.

Hey @qreshi can you please post an update and make the necessary changes to align with core branching strategy.
Thank you
@dblock @CEHENKLE @bbarani

I was blocked on Common Utils before. I'll proceed with updating Notifications now.

Upgrading main to 3.0 is currently blocked on https://github.com/opensearch-project/OpenSearch/issues/3615

Since the issue linked above is still ongoing and we can't upgrade to 3.0 on main, I'll update the version tag for this issue for tracking. I'd like to make sure main is on the most up-to-date development version before closing this issue out.

Current blockers:
https://github.com/opensearch-project/opensearch-build/issues/2886
https://github.com/opensearch-project/opensearch-build/issues/2868

Above have been unblocked, but now Notification needs to be on 2.5. For that to occur, PA and Security needs to be here

Closing as all branches are now up-to-date.


Fork

Added example of using fork to create work. Pretty neat to see how the executor insulates the implementation from the algorithm.

This looks like a pretty cool example. One question -- is there any reason to prefer mmap over shmalloc for allocating shared memory? It's been a long time since I've needed to use either.

I think mmap is recommended because it has a somewhat simpler interface for forked processes. I didn't have any other preferences in mind when I used it.

Yeah, after looking at some Stack Overflow examples, I think you're right.


Modify snapshot_nodes table's signature type to text

#95
Change snapshot_nodes table's signature column type to text.
And add test data

@taeyeon-Kim
I think so too, cause we can see changes without having to check the sql file directly.
I'll change it this way :)


PKEY on view table should be collection+key

Previously, view state's primary key was just the key column. This meant an instance with multiple collections would overwrite each other if those collections used the same key value (as you might expect them to).
Now, view state's primary key is two columns: collection and key. This is more in line with Brook's Redis implementation.
Changes:

Removed PRIMARY KEY from key field during table creation
Added unique constraint to collection and key fields during table creation
Upsert happens on conflict of collection and key together
Added a test to prove upsert behavior (☝ )
Made collection the first field during table creation for consistency

@jeffgrunewald I removed the integration test phase of CI since mix test.integration isn't setup. Your Divo tests run during regular mix test.

Thanks. Probably just copy-pasted that CI yaml from another project; since this library's whole purpose is the edge interface, I just ran all my regular test environment tests as divo integrations. Sorta surprised that wasn't causing problems before...


Allow updating Sphinx-Substitution-Extensions and update dependencies

This PR allows newer version of Sphinx-Substitution-Extensions to be fetched by poetry. Because poetry doesn't allow version overrides this is very important as it allows the update for the dependent subprojects. From what I was able to observe, the old substitution versions don't work with replacements with myst in the code blocks, while the new ones (2024.10.17) do.
https://pypi.org/project/sphinx-substitution-extensions/#toc-entry-8
Fixes #1290

Thanks @tnozicka! It should have been fixed by https://github.com/scylladb/sphinx-scylladb-theme/pull/1264/files
It will be possible to update once we release the next theme release.


Only first-section is showing in the right sidebar

Describe the bug
When I'm adding the second section, it's not showing on the right sidebar, instead of showing like below
Screenshot
And below is the markdown code

# Anofie

Writing documentation is boring? Hah, let's see

> {success} Here is an example of danger alarm message

---

- [First Section](#section-1)

## Overview

LaRecipe is simply a code driven package provides an easy way to create beautiful documentation like this for your product or application inside your Laravel app. However, the usage of LaRecipe is not limited to creating documentation only 😏. See an example.

> {info} Here is an example of danger alarm message

- [Second Section](#section-2)

## Second Section

LaRecipe is simply a code driven package provides an easy way to create beautiful documentation like this for your product or application inside your Laravel app. However, the usage of LaRecipe is not limited to creating documentation only 😏. See an example.

> {info} Here is an example of danger alarm message

Okay, I got my mistake, I found the link to Lareceipe sample docs files.
https://github.com/saleem-hadad/larecipe-docs
All the sections should be at the top-
- [First Section](#section-1)
- [Second Section](#section-2)

## Overview

LaRecipe is simply a code driven package provides an easy way to create beautiful documentation like this for your product or application inside your Laravel app. However, the usage of LaRecipe is not limited to creating documentation only 😏. See an example.

> {info} Here is an example of a danger alarm message

## Second Section

LaRecipe is simply a code driven package provides an easy way to create beautiful documentation like this for your product or application inside your Laravel app. However, the usage of LaRecipe is not limited to creating documentation only 😏. See an example.

> {info} Here is an example of a danger alarm message

` ``

Thank you
Larecipe Rocks!!!

Yeah, that's correct 💃


Integration with eventlog-live

https://github.com/mpickering/eventlog-live has a similar purpose but with a slightly different focus on RTS aspect of GHC pipeline. In the end, an ideal GHC inspection tool need all the information in a unified place for the user's sake. Consider making integration or at least sharing library functions with the project.

logcat is the corresponding part and will be further integrated.


Fetch GTM id via Ajax

Hi!
First of all, thanks for a great plugin!
I have a feature request about fetching the GTM id via Ajax (it doesn't seem to be possible at the moment?). I would like it to work as in vue-analytics where you can do an Ajax call when defining the id, would that be possible to implement? :)

@mikaelkarlsson-se you can load the ajax request first and after the response, init the Vue-GTM plugin. I have done it that way myself.


Change POST request to GET request

This PR changes the POST request in the API to be a GET request. It is not necessary to merge this, but I am documenting these changes in PRs as we are going through our explorations. That way we can merge the options we want at that stage, and not lose the work.

Superseded by https://github.com/epiverse-connect/epiverse-search-backend/blob/main/search_api_endpoint.py


KeeAnywhere not works with Temporary Access and Secret Keys

I'm using Keepass 2.37 and KeeAnywhere 1.4.1.  I have an issue when I try to use KeeAnywhere in order to use a kdbx file stored on s3 bucket.
After Access and Secret Keys, when I click on 'Test' I obtain the following error message:
"Connection Failed"
I want give you some additional information.
The Amazon subscription where my user is connecting has an Identity Provider configured in order to allow all users to use SAML authentication method.
To generate own temporary Access and Secret Keys each Federated user using the procedure described at link
https://aws.amazon.com/it/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/
The Access and Secret keys are working fine if used with AWS SDK, the AWS CLI or Console tools but not working in the KeeAnywhere case.
Can you help me here?

You cannot use your S3-URL in "File" "Open URL" directly. You have to create an Account for your S3-Storage in "Tools" - "KeeAnywhere Settings...".

Yes, I'm talking about KeeAnywhere settings.
After clicked on Add and selected Amazon S3 I need to insert the Access and Secret keys.
After done that, when I click on test I obtaining "Connection Failed".
(I have correct the original explanation)

I have the same issue.  My account uses assume role with SAML assertion (See link: https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html), with a federated login.  I login to my standard company single sign on solution, use a federation broker which contacts Amazon to exchange the SAML assertion for a temporary access token and secret access token.  They should be identical, just that the credentials should expire after a one hour timeout.  They are written to the .aws/credentials file - the same one that the AWS cli tool uses and that works just fine (including S3 access).  However, after entering them into the Access Key and Secret Access Key from "Amazon S3 Account Configuration" and selecting the correct region and pressing Test, I get "Connection failed!".
Any ideas?  Thanks in advance.

This is my first attempt to modify C# and Visual Studio, but PR #182 attempts to address this.


How insert row working

I need to create a custom form for inserting a new row along with setting some default value and adding some validation but I am unable to found any sample example or documentation demonstrating the same. If you any documentation to explain this customization please let's know.  I am looking for following things

setting default value while inserting a new row
validation for values
the custom save function where I will put my logic to save data
the custom update function when user update any column value

check this, use editable.defaultValue

check this, use editable.validator

did you plan to use embed insertRow feature?? If not, I think you can control everything by yourself

we dont support update, only have cell edit feature.

BTW, https://github.com/AllenFang/react-bootstrap-table/tree/master/examples/js have all examples.

Thanks

while inserting if the value is blank toast message is shown...can we customize that toast message?

@EktaDevop when the insert, the rowkey must have value.  There's some way to customize message https://github.com/AllenFang/react-bootstrap-table/blob/master/examples/js/advance/insert-error-handle-table.js#L26-L29
However, this is not a good way, in react-bootstrap-table2 will be more easy to custom message even the way to show message.
But react-bootstrap-table2 still in development

thank you !
I am talking about the error message that you are showing if while inserting value is empty "Form validate errors, please checking!" i want to customise this message

@EktaDevop sorry for lately reply, try to assign a string value to options.insertFailIndicator. thanks


How to fix the left swipe function in UITableViewCell ?

Is there a way to fix the left swipe function in UITableViewCell ? or I can only do is to disable the swipe function ？

no one replay... it's not good third party tool
Please use  https://github.com/John-Lluch/SWRevealViewController

https://github.com/aryaxt/iOS-Slide-Menu/issues/242


BUG: Infinite recursion in getParticipantPaths when using NgZone

I have proposed a fix in https://github.com/daily-co/daily-react/pull/34

Expected behavior

getParticipantPaths should not infinitely recurse

Describe the bug (unexpected behavior)
When using React in an Angular controlled application, global objects are monkey-patched with 'zone-aware' properties that Angular uses for change detection. This extends to objects like MediaStreamTrack.
getParticipantPaths uses a circular-reference unaware check to get nested paths, so it errors out as the zone properties are  infinitely referencing themselves.
The solution is to make getParticipantPaths aware of circular references and not cause a max call stack error

Steps to reproduce

Run Daily SDK in an Angular app that has react components mounted
Create a call
Someone joins the call
See maximum call stack exceeded

Screenshots

Image of the debugger catching the beginning of the infinite recursion

Minified error from the getPaths function when a user joins the call

System information

Device:
OS, version:
Browser, version:

Additional context

Thanks for filing the issue and the patch! We're looking into to.

The fix is included in 0.19.1.
Thanks for your support, @stewartmcgown!


.gravity() doesn't accept a function

I'd like to be able to adjust the effect of gravity based on the data bound to a force layout on a per-node basis, but it seems like gravity doesn't take a function, unlike charge and link strength.

I would love this feature also, and my solution was very similar to @rpoconn . Why the insistence on handling it in the tick function when, as @blq points out, so many of the other parameters accept functions? It seems there is an issue with doing it the recommended way, as @rpoconn suggests, he tried it as recommended but wasn't able to get it to work satisfactorily that way.

The new d3.forcePosition in d3-force, part of D3 4.0, allows position.strength to be specified as a function or a constant, satisfying this feature request. The x and y coordinates representing the focus may also be specified as functions.
And of course the new d3.forceSimulation is modular so you can also compose whatever custom forces you desire!


Date recorded in habit_record.json is one day after the current date.

Hi, really cool project, thanks!
There is one problem with dijo on my mac: the date recorded in habit_record.json is one day later than the current date (and the date shown on dijo UI), not sure why this happened.
The dijo UI shows July 22:

The json content shows July 23:

Fix for this bug was released with v0.2.0!
Let me know if the issue persists, timezones are weird.


Translating URIs on import

Fixes https://jira.duraspace.org/browse/FCREPO-2180

I just rebased to fix the options variable name that Travis was complaining about.

This looks good. It seems that the source command-line argument only applies to importing. I wonder if this argument (and any such others) should include in their Option description that it only has effect on import?

@awoods I've updated the source option name to be "source", and the description to be "Source (URI) data was exported from, when importing to a different Fedora URI".

@escowles, this is ready to go... shall I squash or you?

@awoods I'll squash.

@awoods Squashed!


fix incomplete sub_path canonicalization

Signed-off-by: tabokie<EMAIL_ADDRESS>What problem does this PR solve?
Issue Number: tikv/raft-engine#75
Problem Summary:
Sub path is not canonicalized, this will cause trouble when creating sibling directory for a symlink.
What is changed and how it works?
What's Changed:
Concatenate sub path before canonicalize.
Related changes
Check List
Tests

Unit test

Release note
None

/bench (test)

@tabokie why this one is closed?

@yiwu-arbug This turns out not to be the exact cause for tikv/raft-engine#75:
By default we use data-dir/raft-engine as raft engine path, data-dir/raft as raftdb path. The user manually links data-dir/raft to another disk and expects TiKV to automatically create a sibling directory for storing raft engine.
But it's related if we decide to use existing raftdb directory as raft engine path. I might reopen this later.

Ping @Connor1996

/merge


Package request: pdfannots2json

Project description
The Zotero Integration community plugin of Obsidian requires the pdfannots2json executable to do it's job to the fullest.
Metadata

homepage URL:
source URL: https://github.com/mgmeyers/pdfannots2json
latest release: https://github.com/mgmeyers/pdfannots2json/releases
license: mit
platforms: unix, linux, darwin, ...

I added a pull request to add a flake.nix file to the project. Tested.

Addressed by https://github.com/NixOS/nixpkgs/pull/284847


ARROW-12728: [C++] Implement count_distinct/distinct hash aggregate kernels

This reuses the Grouper to add kernels for count_distinct and distinct. The implementation for distinct is very simple and not particularly efficient, leveraging Concatenate to build the output list. Neither kernel handles larger-than-memory processing.

Actually, if we want to keep the distinct kernel, either the grouper could be adjusted to build the output list directly, or we should use Take instead of Concatenate.

Changed to use Take() to assemble the final results instead of Concatenate().

@lidavidm needs rebase

Rebased, thanks for the heads up.


Support DiagnosticRelatedInformation

VSCode just introduced the concept of DiagnosticRelatedInformation. We are really interested by this feature, since our language server is able to provide diagnostics with extra locations (flows / call stacks / siblings / ...).
Would be great to standardize in the LSP.

@henryju Please see #260.


Run integration tests for PRs

Unbreak the integration tests syntax.
Follow-up to https://github.com/sashabaranov/go-openai/pull/820.

Ping @sashabaranov @tylergannon @eiixy

Ping @sashabaranov @tylergannon @eiixy

I've already added it here. #819
https://github.com/sashabaranov/go-openai/blob/290bc29284bf65e879d76fee57f15c7d4aaaebef/api_integration_test.go#L223

Thank you for the PR!


Dashboard pages

Dashboard pages
I am working to find agreement on the Dashboard pages.
Visualization design notes

Use the Vega theme Vox for Vega-lite visualizations

Note that this will be adjusted in later versions of this application

Figma Resources

Design System file
HRA Dashboards file

Milestone Details

Title: US#7: Implement Dashboard for HRA
User role: Clinicians, researchers, funders
User activities: Track the evolution and usage of the HRA using data, code, and portal usage statistics in aggregate and divided by portal (e.g., HuBMAP or SenNet) or PEDP survey results.
Added value: Enable evidence-based decision making by providing insights into the atlas' construction and usage (e.g., gaps in data, application areas, user demographics, equitable access).

Dashboard page UI is now ready for development!
Good morning, @bherr2! Attaching approval documentation for the general Dashboards page UI. I will follow up with UI details, expected behavior notes, and links to local components. Thanks!
Figma design file:

Dashboards UI

Dashboard page UI details
Dashboard pages house collections of visualizations about the quality and coverage of the HRA. MVP1 has five categories/pages:

Data
Usage
Diversity & Inclusion
Publications
Experimental Data

Figma Resources

Design file: HRA Dashboards
HRA Design System

Local Components

Navigation header
Mobile menus
Splash content container: Title, description, paper
Metrics containers
Visualization containers

Two aspect ratios: 4:3 and 3:1
Tooltips appear on hover over the information icon
If using Vega-lite, use the Vega theme Vox

Pattern Library Notes

All dashboard pages have the same layout and always display the same from the top down:

Navigation header
Splash content container
Metrics containers

Note: Only 3 categories of metrics containers and no more than 12 individual metrics per dashboard. This is so that responsive design is possible for all breakpoints. This is iterative and could change.

Visualization containers

Note: Use the aspect ratio that looks best for the visualization

Footer

UI details comment edited with more information and Figma links. Thanks so much!

I have contacted development about this change via Slack. Thank you team!

Wrong issue, disregard!


Wrapped HoC functional components don't properly typecheck props

Flow version: 0.99
Assuming we have the following in a libdef:
type ThemeProps<T> = {
  theme: T
}

declare function withTheme<Theme, Config: {}, Instance>(Component: React$AbstractComponent<Config, Instance>): React$AbstractComponent<$Diff<Config, ThemeProps<Theme | void>>, Instance>;

Expected behavior
When wrapping a functional component with a HoC, the props are no longer typechecked properly. Flow should error in this case:
type Theme = {
  accent: string
}

type Props = {
  ownProp: string,
  theme: Theme
}

const MyFuncComp = (props: Props) =>

const WrappedFuncComp = withTheme(MyFuncComp)

// Y u no error?
const fickle = <WrappedFuncComp ownProp={3} />

Actual behavior
Flow doesn't produce any errors. It did so up until version 0.99, which is when this broke. Manually adding a type annotation to const MyFuncComp: React.ComponentType<Props> is a temporary workaround, but it feels like this is something Flow should be able to handle on its own (and it used to).
This works fine with class components.

Link to Try-Flow

Haven't checked if the test case can be simplified any further.

Same issue here with Flow 0.99

looks like passing Props explicitly to withTheme makes it error out:
const WrappedFuncComp = withTheme<*, Props, *>(MyFuncComp)

Should we close this issue? I suspect this has been fixed since I last opened it (solely assuming this from the fact the issue has been inactive for a while).


How to use embedding at service time for face recognition

Consider a real-time face recognition system in the following situations:

there is only one known person (the one that we want to recognize), for which we have N (~10) pictures.
there are different people. For each of them we have N pictures. Only one of them is the valid one

Now, at service time, what is the best approach to perform recognition in both cases? Is it correct to take the embeddings related to the valid person, compute the mean and compare it with embeddings coming from new images, using a distance threshold for the decision? Are there smarter and more robust ways?

Hey FSetragno,
Have you found the solution about using pre-trained face embedding in real face recognition task?
Actually, I tried use the same way  posted at
https://www.pyimagesearch.com/2018/06/18/face-recognition-with-opencv-python-and-deep-learning/  (k-nearest neighbor)
and
https://www.pyimagesearch.com/2018/09/24/opencv-face-recognition/  (linear SVM classifier)
First of which used KNN clustering method, and second used the linear SVM classifier. However both of them gave the poor performance with my own pre-trained face embedding model instead of dilb face embedding model.

In my specific case I don't have many samples for each identity, so I am not sure that a classification task would work. I am looking for a quick solution that would work with very few samples. So far I tried with just a distance measure and a threshold but maybe there are smarter solutions...

Dear @FSetragno I am also searching for solutions to the same problem. I am using face_recognition repo based implementation to detect the unknown person but some times I am getting the unknown face embedding vectors whose euclidean distance is very close to the known face embedding vector.
If you found any solution please share with me.


Port / refactor dom-bind.html unit tests

From @cdata on August 8, 2016 21:0
Polymer 1.0 test suite here: https://github.com/Polymer/polymer/blob/master/test/unit/dom-bind.html
Auxiliary elements part 1: https://github.com/Polymer/polymer/blob/master/test/unit/dom-bind-elements1.html
Auxiliary elements part 2: https://github.com/Polymer/polymer/blob/master/test/unit/dom-bind-elements2.html
Make sure to update with <test-fixture> for elements used across multiple tests.
Copied from original issue: PolymerLabs/alacarte#38

Need to merge from existing PR.

Resolved in https://github.com/Polymer/polymer/commit/7457da10c0039d380d169923d539aa9a74c78a17


Fix SSL error on kubelet check startup when talking to probes endpoint

What does this PR do?
This PR fixes a bug where the probe configuration would fail to use the latest prometheus URL on startup
Motivation
When running the check locally via agent check kubelet -l debug with the DD_KUBELET_TLS_VERIFY env var set to false, the following output could be observed:
2024-02-27 16:27:13 UTC | CORE | DEBUG | (pkg/collector/python/kubeutil.go:62 in GetKubeletConnectionInfo) | cache hit for kubelet connection info
2024-02-27 16:27:13 UTC | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:135 in LogMessage) | - | (connectionpool.py:1019) | Starting new HTTPS connection (1): <IP_ADDRESS>:10250
2024-02-27 16:27:13 UTC | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:135 in LogMessage) | - | (http.py:503) | No Authority Information Access extension found, skipping discovery of intermediate certificates
2024-02-27 16:27:13 UTC | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:135 in LogMessage) | - | (probes.py:55) | Unable to collect query probes endpoint: HTTPSConnectionPool(host='<IP_ADDRESS>', port=10250): Max retries exceeded with url: /metrics/probes (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1006)')))
2024-02-27 16:27:13 UTC | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:135 in LogMessage) | - | (connectionpool.py:1019) | Starting new HTTPS connection (1): <IP_ADDRESS>:10250
2024-02-27 16:27:13 UTC | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:135 in LogMessage) | - | (connectionpool.py:474) | https://<IP_ADDRESS>:10250 "GET /healthz?verbose=True HTTP/1.1" 200 57
2024-02-27 16:27:13 UTC | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:135 in LogMessage) | - | (connectionpool.py:1019) | Starting new HTTPS connection (1): <IP_ADDRESS>:10250
2024-02-27 16:27:13 UTC | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:135 in LogMessage) | - | (http.py:503) | No Authority Information Access extension found, skipping discovery of intermediate certificates
2024-02-27 16:27:13 UTC | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:135 in LogMessage) | - | (probes.py:55) | Unable to collect query probes endpoint: HTTPSConnectionPool(host='<IP_ADDRESS>', port=10250): Max retries exceeded with url: /metrics/probes (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1006)')))

And the probes check is not run / no probes metrics show up.
With this change, that error no longer shows up, and the metrics appear as expected.
Additional Notes

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Changelog entries must be created for modifications to shipped code
[ ] Add the qa/skip-qa label if the PR doesn't need to be tested during QA.

/merge


how to add brush tool to control side bar

My interface has brush tool in 4 dot on control side bar.I want to show it on the main control side bar what will be the procedure for it

Reduce number of controls, by specifying exact type for labels in labels constructor (in a task or a project)
No one of your labels should have any type.


Add travis and coveralls

Proposal
Add .travis.yml, coveralls npm task, travis and coveralls badges to README.md
I can provide you with the necessary PR for that but you gotta take few setup steps.

Seems like a good idea; I'd take PR / setup links for those

Preparation
Skim through:
https://docs.travis-ci.com/user/deployment/npm/
https://github.com/nickmerwin/node-coveralls
node-coveralls is zero effort, so the only thing you will need to do, is manually hit some switches
on https://travis-ci.com and https://coveralls.io
If you want autodeployment to npmjs you need to do travis setup npm from machine where you can publish to npm (need npmjs authToken from ~/.npmrc)
Demo is here: https://github.com/nhz-io/jest-webpack-alias/tree/travis-coveralls
The PR does not contain badges. You will need to get them from travis and coveralls

Implemented most of this; thanks!


Update package.json to run sagas(plural).spec.js

The tutorial advises to create a sagas.spec.js (plural) file.

Ups. Didn't see this. I fixed it the other way around ;)

Thanks (And sorry for being late)


README.md: add link to CONTRIBUTING.md#submitting-pull-requests

The page was not linked from README and was not easily reachable.

@thaJeztah @tiborvass PTAL

@tiborvass PTAL

ping

ping


pkg/{eventqueue,ipcache}: small performance improvements

read per commit basis

This change is

test-me-please

Coverage decreased (-0.03%) to 44.557% when pulling 5655f4a42ee2fd314d6101c85c4144384d1fc15d on pr/performance-improvs into 57fa7a626db1246f769557821ec721caf4d3d1e7 on master.

test-me-please


Update nodejs version?

@kytrinyx @rchavarria is there a reason we're running node 0.10 on Travis?  It's on 5.6 now.

Hah. No, that would be because I don't know the first thing about javascript.

You say that like it's a point of pride 😉

Nooooo, imagine me sighing and throwing my hands in the air. I am going to have to learn javascript properly, maybe even soon. Exercism is going to require a technical overhaul before too long. We're starting to see the effects of all the duct tape on performance.

Anecdotally my local JS group have been using exercism.io once a month, and
it does tend to bog down. Don't know if that is what you're seeing.
On Thu, Feb 25, 2016 at 6:08 PM Katrina Owen<EMAIL_ADDRESS>wrote:

Nooooo, imagine me sighing and throwing my hands in the air. I am going to
have to learn javascript properly, maybe even soon. Exercism is going to
require a technical overhaul before too long. We're starting to see the
effects of all the duct tape on performance.
—
Reply to this email directly or view it on GitHub
https://github.com/exercism/xjavascript/issues/165#issuecomment-189025456
.

I'm seeing a number of things. One of the features ('5 a day') was taking the database down when certain users logged on (not even sure which users). I temporarily removed the feature, and will look at reimplementing it. The side is really slow, some pages more than others, and it's a combination of a number of things: unoptimized database stuff, too many calls to the database, very little caching for critical bits of data, probably not gzipping javascript and CSS, lots of unnecessary bloat pretty much everywhere, very inefficient code (due to experiment after experiment in order to figure out what exercism is all about in the first place).


Added missing line in reading-writing of excercise express routing

Code was missing for the code in Unit 5 part 3 of the Build a web API with Node.js and Express section.
To handle requests, the app.js file missed the line app.listen(...).  You can test that when you run node app.js  in a terminal and then opened another one to run any of the client's files, the server throws an error because wasn´t able to find the endpoint.
There is not any statement on the exercise that specified that the student had to add that missing line of code, even though, it said that you have to fill all the code for the routings.

Thanks a lot for the fix, we'll merge it ASAP 👍

Yeahhh, Thanks!!!! My First PR 😂
El vie., 31 jul. 2020 a las 12:34, chris<EMAIL_ADDRESS>escribió:

Merged #3 https://github.com/MicrosoftDocs/node-essentials/pull/3 into
main.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/node-essentials/pull/3#event-3609327674,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNBJXNTRVIXHOPATZM7AW3R6LXDBANCNFSM4PHFPGRQ
.


Remove internal (unknown) props from those that are passed to div

Use of destructuing to remove internal props from this.props (labeling them as ignored to be explicit), so that unknown props are not passed to the div

This is to fix #164

Hey Tony,  Good call on this PR, I was weary of merging in the previous one for the reasons you mentioned.
However I'm not sure what the use case for that.

Is it a common practice to pass props straight to div? Would it make sense to have an htmlProperty prop instead of removing non-html specific props?
If we still do this, would we want to leverage propTypes in any way?

@Kureev would you have any input here?

I've done it for a number of projects, usually for the properties I've called out (className, style) but also in case the developer wanted to add data attributes and the like. You never know how someone will use the component, so usually best to offer the flexibility when it's easy to.
As long as you take care of your own internal props, the onus is on the developer to manage the props they pass to it. PropTypes would then serve as self documenting for the props internal to the component itself.

@kirjs check my comment on the diff

So based on the feedback on the rest usage, can we merge this as-is?

Ok, this looks pretty good, I'm still not a fan of using destructuring here, but it works which is more important.
Thanks a lot for your PR, I'll test and publish it later today.

Though it's worth major version, so 9.0.0