Monitor Execution Breakdown

Currently, the execution of different types of monitors in alerting is abstracted and varied at the level of running the monitor itself. Different monitors are performing some common tasks in different ways. There is also a hard coupling between execution of monitors with data sources for reads and writes.
We need to define and standardize the set of steps that all monitors must run in their execution. Standardizing execution and breaking it down will make the plugin more flexible and take it in a direction to use monitors more flexibly such as passing configurable parameters for read and write data sources involved in monitor execution. This paradigm also would enabled Alerting plugin to evolve into a service which allows users to submit their own alerts by giving more control over what to run in the execution.
There would be default “no-action” implementations provided for each step which needs to be overridden by monitors if applicable to them (think findings logic being applicable only to doc level monitors)

Fetch queries from query index

Initialize alerts and findings indices from monitor config

Load data source from config/default and run queries

INPUT

Source index + last run context (DL)
Source index + time range (BL, QL)
Findings index (TODO)

4a. Update last run context (sequence no. or time range)

Exec delegate monitors [TENTATIVE](if we intend to support more complex workloads of data demanding more complex queries and trigger conditions, chaining alerts, propogating data from one monitor to another, this could be a useful hook. Open to discusison)

Persist findings

Parse Triggers

Exec triggers

Exec actions (alerts)

Persist alerts

11.Persist updated metadata (sequence nos./time range)


BLD: Move config.h creation to setup stage

Hi @HaoZeke,
I decided to spend some time to actually move config.h creation to setup stage (with existing getarch, etc.) anyway. It was too annoying to work with manually created files.
This refactor is separate from your config.h work. It's a rework of my previous config.h generation attempt, and it relies on run_commands that are executed in the setup stage.

Looks much cleaner, are the run commands guaranteed to be executed in order in the configuration stage?

Looks much cleaner, are the run commands guaranteed to be executed in order in the configuration stage?

In my opinion - yes. They're always executed line by line.


Do not hardcode vagrant network details

Description
Allows for overriding the default vagrant/libvirt network details.
Why is this needed
Lets us use the vagrant and compose setup in a sort of hybrid mode with a real hw machine as machine1 instead of the VM.
How Has This Been Tested?
Ran vagrant up and verified defaults still work and overrides do in fact show up.
How are existing users impacted? What migration steps/scripts do we need?
A way to test with real hardware while using the vagrant setup for the services.

The use of downcase seems odd when the hardcoded MAC in the Vagrantfile was using upppercase. But if it all works, then presumably the code that uses that value doesn't care.

Yeah, but the hardcoded mac in ../compose/.env is lowercase so I decided to keep it that way.

To use a dedicated adapter (real hardware, and not everybody can tinker(!) the surrounding network to isolate VLANs etc..) one has to switch to public networking and add the hardware.
I am doing this for quite a while now:
    provisioner.vm.network "public_network", ip: PROVISIONER_IP, bridge: ENV['MYTINK_BRIDGEDEV'],

and if the real MACHINE_1 shall get network/internet access:
    provisioner.vm.provision "shell", name: "iptables", inline: <<-SCRIPT.gsub(/^ {6}/, "")
      set -x
      /usr/sbin/iptables --policy FORWARD ACCEPT
      /usr/sbin/iptables -t nat -A POSTROUTING -s #{MACHINE1_IP} -j MASQUERADE
    SCRIPT

the policy could be more strict, but "it works".
('Philipp' from chat)


test: submitbridgecall batch

Summary by CodeRabbit

New Features

Enhanced bridge call functionality to support multiple tokens and amounts, improving transaction flexibility.

Tests

Added new tests to verify the submission of bridge calls with varying numbers of tokens.

mg


Add placeholder to search input in Select component

Add option to set a placeholder in the search field providing a better ux when the select already has preloaded data.

Why can't we use the existing searchPrompt()?

Why can't we use the existing searchPrompt()?

I thought about it but I believe that choicesjs will always display a message under the search field when there are no preloaded items, so I thought it best to add one more configuration option.

Can we hide the prompt? Then just displaying the placeholder instead should be fine maybe?

Can I do that, do you think it would be a better ux just display the input with placeholder inside?

We shouldnt need to add any more methods to the class to do this

Thanks


Android Gradle not working

Does anybody successfully ran ktlint with android?
i always have
Skipping task ':app:ktlint' as task onlyIf is false.
:app:ktlint SKIPPED

configuration same as in readme

Take a look here. I doubt that problem is Android-related, though (do you have ktlint.onlyIf { ... } somewhere in your build.gardle by any chance). ktlint task doesn't really care about anything but source code location.
Let me know If it doesn't help (in which case please provide a test project or at least a build.gradle). Thank you.

Thanks. My problem was inaccessible classpath.
Somehow SKIPPED is only debug information(with --debug flag ofc) i had with actual Error: Could not find or load main class error.
I'm not a master of android plugin configurations manipulation, but something unobvious happens there.
Accessing 'tools only classpath' with buildconfig hack is an easy path, but be aware of different classpaths for different build.gradles. I had dependency in root buildscript, and it was inaccessible from child scripts.

@dsvoronin I guess, sooner or later, I'm gonna have to create a designated plugin to alleviate these kind of problem. Anyway, thanks for the heads-up!


fixed RegisterToken wrong expires_at default

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


Fix sign-in so that it is not dependent on identity services

We need to catch the error that psu_identity will throw if there is a network error.

Blocked by: https://github.com/psu-libraries/psu_identity/issues/12

This should be done in conjunction with #382

Per @ajkiessl, this should be considered for potential development this round. I've moved it up the list on the project board.


Fix passing target-cpu and codegen-units to dependencies

Fixes https://github.com/pacak/cargo-show-asm/issues/355
Changes
This PR fixes passing target-cpu to the dependencies using RUSTFLAGS  instead of cargo rustc args.
Other arguments

user-supplied codegen flags - okay with cargo rustc args.
asm syntax - okay with cargo rustc args.
target-cpu - should be passed as RUSTFLAGS to compile deps with target-cpu.
debuginfo - probably don't affect deps, so okay with cargo rustc args.
codegen-units - probably should be passed as RUSTFLAGS to be applicable for deps, but I am not sure. Please check this. If passed with RUSTFLAGS may overwrite user-specified codegen-units in RUSTFLAGS.

Notes

RUSTFLAGS are prioritized over cargo rustc args, so cargo asm --native or cargo asm --target-cpu=CPU will now overwrite user-specified target-cpu in RUSTFLAGS.
Using write!(...).unwrap(); to &mut String seems to be fine and already used in code.

Makes sense. Initially I thought that it doesn't really matter how dependencies are compiled, but your example with benchmarks is pretty convincing.
As far as codegen units are concerned - I'm setting them to 1 just to make life easier figuring out what .s file we should be using. I submitted changes to rustc (https://github.com/rust-lang/rust/pull/122597), but things are stuck behind cargo giving access to this info (https://github.com/rust-lang/cargo/issues/13672). There are some flags to cargo that would make it print the right invocation of rustc so we can run it directly and access the output.
debuginfo - used to attribute asm lines to rust lines, won't change the compilation result...
Anyway, I think your change is good to be merged as is. Thanks again for your contribution :heart:


chromadb not working adding collection

What is the issue?
I'm trying to test the sample in getting Generate embeddings , but the chromadb seems adding collection not working
OS
Windows
GPU
Nvidia
CPU
Intel
Ollama version
ollama version is 0.1.48

Ollama logs, application logs, sample code, examples of failures will make it easier to diagnose the problem.

Ollama logs, application logs, sample code, examples of failures will make it easier to diagnose the problem.

that the problem there is not log or any I tried only the sample code this code, it will not finish the loop
`import ollama
import chromadb
documents = [
"Llamas are members of the camelid family meaning they're pretty closely related to vicuñas and camels",
"Llamas were first domesticated and used as pack animals 4,000 to 5,000 years ago in the Peruvian highlands",
"Llamas can grow as much as 6 feet tall though the average llama between 5 feet 6 inches and 5 feet 9 inches tall",
"Llamas weigh between 280 and 450 pounds and can carry 25 to 30 percent of their body weight",
"Llamas are vegetarians and have very efficient digestive systems",
"Llamas live to be about 20 years old, though some only live for 15 years and others live to be 30 years old",
]
client = chromadb.Client()
collection = client.create_collection(name="docs")
store each document in a vector embedding database
for i, d in enumerate(documents):
response = ollama.embeddings(model="mxbai-embed-large", prompt=d)
embedding = response["embedding"]
collection.add(
ids=[str(i)],
embeddings=[embedding],
documents=[d]
)`

Just tested, it works. You need to start Ollama desktop client on Windows and pull the model mxbai-embed-large with ollama pull mxbai-embed-large, and then execute the script


fix(relation-transformer): relation field nullability in object and input type

Description of changes
Refactor the impact of non-nullable field with relation directive on the generated connection fields in object definition and input types.

Connection fields(foreign keys) will always be nullable in the UpdateInput type, which is consistent to other non-nullable fields.
The non-nullable field with @hasMany should not force the connection fields to be non-nullable as the fields are in the child type. They should be only non-nullable if a non-nullable @belongsTo field is defined in the child.

Issue #, if available
Fix https://github.com/aws-amplify/amplify-codegen/issues/461

Description of how you validated changes
Checklist

[x] PR description included
[x] yarn test passes
[x] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #817 (2c0b0c6) into main (6a7b9f3) will increase coverage by 0.14%.
The diff coverage is 66.52%.

@@            Coverage Diff             @@
##             main     #817      +/-   ##
==========================================
+ Coverage   63.14%   63.28%   +0.14%
==========================================
  Files         278      282       +4
  Lines       18125    18363     +238
  Branches     4375     4459      +84
==========================================
+ Hits        11445    11621     +176
- Misses       6093     6132      +39
- Partials      587      610      +23

Impacted Files
Coverage Δ

...-graphql-auth-transformer/src/utils/definitions.ts
100.00% <ø> (ø)

...on-transformer/src/graphql-function-transformer.ts
93.54% <ø> (ø)

...l-http-transformer/src/graphql-http-transformer.ts
96.21% <ø> (ø)

...searchable-transformer/src/cdk/create-cfnOutput.ts
100.00% <ø> (ø)

...transformer-core/src/transformer-context/output.ts
2.43% <0.00%> (-0.35%)
:arrow_down:

...graphql-transformer-core/src/utils/schema-utils.ts
18.18% <0.00%> (-4.55%)
:arrow_down:

...graphql-elasticsearch-transformer/src/resources.ts
100.00% <ø> (ø)

.../graphql-transformer-core/src/util/sanity-check.ts
16.38% <0.00%> (-0.19%)
:arrow_down:

...ansformer-core/src/transformer-context/resolver.ts
5.69% <9.09%> (-0.16%)
:arrow_down:

.../src/graphql-transformer/transformer-options-v2.ts
14.76% <14.76%> (ø)

... and 65 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Unable to resolve dependency:  Xamarin.iOS (Xamarin, Mac)

I am writing a Xamarin.iOS app using Visual Studio for Mac.
When I try running my app, I get this error:
Unable to resolve dependency:  Xamarin.iOS
I think I'm supposed to use: <AssemblySearchPath path="{path to Xamarin.iOS}" in my obfuscar.xml file, but I can't actually find the correct path to use on my Mac. Can anyone help?

Fixed.
Include:  in the obfuscar.xml file.


Finland OverflowError: math range error

Run python3 fit_every_country.py

....
Finland
Fitting...
Traceback (most recent call last):966568
  File "fit_every_country.py", line 11, in <module>
    fit_country(country, save_to_json=True)
  File "/workspace/epidemic-simulator/fit_any_country.py", line 48, in fit_country
    res = scipy.optimize.minimize(cost_function, x0, method="Nelder-Mead")
  File "/workspace/.pip-modules/lib/python3.7/site-packages/scipy/optimize/_minimize.py", line 589, in minimize
    return _minimize_neldermead(fun, x0, args, callback, **options)
  File "/workspace/.pip-modules/lib/python3.7/site-packages/scipy/optimize/optimize.py", line 580, in _minimize_neldermead
    fxe = func(xe)
  File "/workspace/.pip-modules/lib/python3.7/site-packages/scipy/optimize/optimize.py", line 300, in function_wrapper
    return function(*(wrapper_args + args))
  File "/workspace/epidemic-simulator/fit_any_country.py", line 22, in cost_function
    K_d_0=K_d_0, K_d_plus=0)
  File "/workspace/epidemic-simulator/epidemic.py", line 44, in calculate_epidemic
    x, y, z, d = fsolve(equations, (x_n, y_n, z_n, d_n))
  File "/workspace/.pip-modules/lib/python3.7/site-packages/scipy/optimize/minpack.py", line 147, in fsolve
    res = _root_hybr(func, x0, args, jac=fprime, **options)
  File "/workspace/.pip-modules/lib/python3.7/site-packages/scipy/optimize/minpack.py", line 225, in _root_hybr
    ml, mu, epsfcn, factor, diag)
  File "/workspace/epidemic-simulator/epidemic.py", line 31, in equations
    s = (y-y_n)/dt - (K_c(v)*x*y - K_r(y) * y - K_d(y)*y)
  File "/workspace/epidemic-simulator/epidemic.py", line 20, in K_r
    return K_r_0 - K_r_minus/(1+math.exp(-100*(y - C)))
OverflowError: math range error

Fixed in #8


Refactor storage engine and unit test per upstream interface changes

Refactor storage engine per upstream interface changes
Removed LiteTestContextBase.java
LiteTestCaseBase implements getTestConext which returns a new JavaContext.

Hi @pasin, code is fine, but it is no longer merge-able. Can you do local merge?


Streaming video with custom loops not working on Android

Hi,
Please see https://contentresponder.com/streaming-video-with-custom-loop-163/
It is a HLS streaming videojs video with abloop plugin. Works fine on Windows and iOS. Works on Android with a standard mp4 video. Only the combination of "streaming video (.m3u8) + abloop + android" is the issue.
But as soon as I enable the abloop plugin, video breaks with the error "the media playback was aborted due to a corruption problem or because the media used features your browser did not support chrome".
If I comment out just the line of the plugin....
plugins: {
//abLoopPlugin: {}
}

... then video loads fine on Android, but no loop feature, of course.
Why is just that one line causing the video to crash on Android devices?
Appreciate your help.

Issue resolved. Had to add the following lines for it to work on Android.
videojs.options.hls.overrideNative = true;
videojs.options.html5.nativeAudioTracks = false;
videojs.options.html5.nativeTextTracks = false;
videojs.options.enableLowInitialPlaylist = true;


Blob container binding analyzer misidentifies JSON binding expression as a container

When moving a function app from in-process to the isolated process worker I ran into the following error on a BlobInput binding that used a JSON expression property from a queue trigger:

It appears to be caused by the analyzer added for this issue: https://github.com/Azure/azure-functions-dotnet-worker/issues/1276
Here is a sample function that reproduces the error-
Project File
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <RootNamespace>function_create</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.18.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Storage" Version="6.0.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs" Version="6.0.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues" Version="5.2.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.13.0" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext" />
  </ItemGroup>
</Project>

Function Code
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

class TestFunction
{
    [Function("TestFunction")]
    public static void Run(
        [QueueTrigger("test-queue", Connection = "AzureWebJobsStorage")]QueuePayload payload,
        // blob input is bound to the path found in the queue item JSON payload
        [BlobInput("{BlobPath}")]Stream blobStream,
        FunctionContext context)
    {
        var log = context.GetLogger("TestFunction");
        log.LogInformation($"C# Queue trigger function processed: {payload.BlobPath}. {blobStream.Length} bytes.");
    }
}

class QueuePayload
{
    public string BlobPath { get; set; } = string.Empty;
}

Thanks for finding this bug, we didn't test the analyzers with expressions so we missed this use case. In the mean time, you should be able to use Sdk 1.12.0 (the only difference is that 1.13.0 has the new analyzers)


App crashes at startup

Bevy version
main branch 9ef840e
Relevant system information
`AdapterInfo { name: "NVIDIA GeForce RTX 3060 Ti", vendor: 4318, device: 9353, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "522.06", backend: Vulkan }`

`SystemInfo { os: "Windows 10 Home", kernel: "19044", cpu: "AMD Ryzen 7 5800X 8-Core Processor", core_count: "8", memory: "31.9 GiB" }`

What you did
Created a new project with the following code
use bevy::prelude::*;
fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .run();
}

This is the Cargo.toml
bevy = { git = "https://github.com/bevyengine/bevy", rev = "9ef840e" }

What went wrong
The app crashed right after the window opened with the following error
thread 'main' panicked at 'called glDebugMessageCallback but it was not loaded.', E:\rust\.cargo\registry\src\github.com-1ecc6299db9ec823\glow-0.12.0\src\gl46.rs:4234:5

Additional information
A workaround is to add the following when setting up DefaultPlugins
.set(RenderPlugin {
    wgpu_settings: WgpuSettings {
        backends: Some(Backends::PRIMARY),
        ..Default::default()
    },
    ..default()
}),

Here are two relevant discord threads
https://discord.com/channels/691052431525675048/1073274796697198622
https://discord.com/channels/691052431525675048/1073786235996352632

We should investigate changing the default WgpuSettings to the workaround.

We just moved to enabling all backends. What I find odd is that it claims to be using the Vulkan backend but hits this panic about GL. I wonder why. Perhaps some probing is done. That has the potential to panic? @cwfitzgerald?

This is https://github.com/gfx-rs/wgpu/issues/2540

Summarizing discussions on this from discord:
This appears to be because it tries to load libEGL.dll and libGLESv2.dll, which means that if it can't find them locally, it also tries searching in your PATH for them, and because Angle is common there's a chance that those are somewhere in your PATH. (https://github.com/google/angle)
The problem is that it's finding old versions of those dlls (because people package Angle once and don't bother updating it...) and trying to use them (and they're so outdated they don't support glDebugMessageCallback, they only support glDebugMessageCallbackKHR) which seems to be the root cause of this crash.

This is now fixed after an update for glow.


Dynamic LDP containers

Use "catch-all" routes which points to a new LdpApiService, which itself redirects to LdpResourceService, LdpContainerService or ActivityPubCollectionService depending on the @type.

Method
LDP resource
LDP container
ActivityStreams collection

GET *
ldp.resource.get
ldp.container.get
activitypub.collection.get

POST *
ldp.resource.post
ldp.container.post
(If defined by ControlledCollectionMixin)

PUT *
ldp.resource.put
-
-

PATCH *
ldp.resource.patch
ldp.container.patch
-

DELETE *
ldp.resource.delete
ldp.container.delete
-

Allow to create and delete LDP containers via API (with an optional title and description). New tests have been added for that.
New resourcesWithContainerPath option for the LdpService. If true, the URI of all new resources will include the container path, otherwise it will use the root container path (default: true)
The auto-generated slug of ressource use the uuid/v4 library instead of MongoDB-like ObjectID. The previous method generated unique but easily guessable slugs.
Use node-fetch instead of supertest for all API tests.

Todo

Automatically detect blank nodes on semantic data provider

Breaking changes :warning:

The dereference option has been removed. Blank nodes are now automatically found (on 4 levels of depth).
The VoID endpoint doesn't return blank nodes anymore (the data provider will be updated to automatically find blank nodes)
The disassembly option has been removed. Use the new DisassemblyMixin, along with the ControlledContainerMixin, if you still need this feature (which will later be moved to the frontend)
The undocumented ResourceWatcher bot has been removed. Use ControlledContainerMixin instead.
The ldp.resource.get action now always return the semantic representation, even for binaries. The forceSemantic param is thus not necessary anymore. Binaries are handled by the LdpApiService. New tests have been added for that.
API routes with catchAll: true are always handled last. This requires a modification of Moleculer's ApiGateway (see this Moleculer issue: https://github.com/moleculerjs/moleculer-web/issues/335). If you don't use SemApps CoreService, you must add this method to the service using the ApiGateway mixin or the catch-all route of the LDP service will be handled before other endpoints like VOID, SPARQL, etc.

  methods: {
    optimizeRouteOrder() {
      // Overwrite optimization method to put catchAll routes at the end
      this.routes.sort((a, b) => (a.opts.catchAll ? 1 : -1));
      this.aliases.sort((a, b) => (a.route.opts.catchAll ? 1 : -1));
    }
  }

When the frontend GET the binary through the API, it is returned as a binary.
No changes have been made about the Location header.


File output can move to NULL state with "Can't change input format at runtime"

Starting a 'file' output, on a mixer with no inputs, can intermittently cause the output to fail with the message "Can't change input format at runtime".
I can't work out what's changing at runtime, or how to prevent it.

Closing as this is a stale issue.


Unify differences between multi and multi sub

Some code is like:
multi sub hello($name) {say "hi $name"}
Other code is like:
multi hello($name) {say "hi $name"}
I'm not sure what is going on here, but this is something that should be decided upon. I think multi sub makes sense because you always clarify multi method in classes. And yet, I've never seen a proto sub. I've only seen proto by itself.
Thoughts?

It defaults to sub, so you can omit it. In core, though, we always add it anyway. Makes it easier to grep 'sub blah' the source.

Judging by
> grep -I -r 'multi sub ' doc/ | wc -l
278
> grep -I -r 'multi [^sm]' doc/ | wc -l
50

plain multi case is less common. For the reasons of consistency we can edit such cases to full form. It is quite easy job too, if you have a good editor and some time on board.

I think consistency in the docs is a worthwhile goal

I do not agree. You don't learn how to deal with complexity by reading code that does it's best to hide it. If we prefer one style we should prefer the shorter version because lazyness is a programmers virtue.

@gfldex Whether the docs show multi sub or just multi, I still think consistency should be the goal.
Programmers can learn complexity by reading real world code / books / tutorials. The docs should feel as if they're all written by one person, no? Hence unifying the comment styles, etc.

So how about unifying on multi alone, only using multi sub long-hand when explaining that it is long-hand.

I just read in the docs that one reason why --> is preferred over returns is for consistency in the docs.
So someone at some time deemed consistency in documentation worthwhile. Whoever wrote that 😸

@WildYorkies, you can read https://github.com/perl6/doc/issues/1024#issuecomment-264660360 - it explains the choosing of "-->" and there are more reasons: It is more universal(you can use it for constant values) and there are no plans about deprecation, TimToady likes it, etc. The consistency made only one thing in that issue: the issue was opened because of that.
If the docs don't clearly say about possible deprecation and constant values, it is bad. Though, I take a peek now and as for me, it is still explained.
About this issue itself. I'm agreeing with @awwaiid, we can use multi, though it is slightly more work to do.
I don't think that "it is easier to grep" is a nice reason to do otherwise. I mean, why the feature of omitting was added in the first place, if nobody uses it because of greping?

What about examples that are contrasting sub vs. method, e.g.:
    multi sub    shift(Array:D )
    multi method shift(Array:D:)

Also, what about 'proto sub'? should we also drop the sub there?
(I can write a test for this, but would like feedback on these items first)

WIP on the coke/multi branch

@coke, I am working on some new definitions https://github.com/perl6/doc/issues/1494 - here, so, please, ping me somewhere after your work will be finished, so I could follow the changes painlessly.

My work is in s branch

Can't delete comments on mobile. Please ignore previous comment.

Don't worry, I have already looked into your branch and did appropriate changes.

https://github.com/perl6/doc/search?q="multi+sub"

@coke are you still working on this? Should we attempt to merge the branch?

Haven't touched it in some time. I think the question from last August is still unanswered.

Also, what about 'proto sub'? should we also drop the sub there?

Yes.

What about examples that are contrasting sub vs. method

In that case it would be better to leave them that way and either whitelist them in the test.

Coming back here, and trying to summarize: a single form, "multi" or "multi sub/method" should be used in the "defined as" part of the docs.
My answer here: in general, we try to use the same form, or as close as possible, as defined in the source. That's the kind of consistency we aim for in the documentation. Since multi sub is preferred in Rakudo, well, we should do the same here. In general, however, creating an issue with 100 (or whatever) tasks is not very actionnable. So the way to solve this is to create, as tagged, an author test that deals with this, and at least fails for pages that are changed.

I'm checking  @coke's branch and it seems to be about using multi sub (or multi) everywhere, not only in definitions, which, anyway, are difficult to single out (maybe we should fix that, too). So this is even more difficult to do, and not clear it's really desirable (other than to keep it consistent with source).

Stole the test and applied it in 0bbff3737, with an exception allowed if we are trying to showcase multi sub explicitly.

multi sub cleaned up, passing xt/examples-compilation.rakutest

proto sub was a much faster cleanup - added test, cleaned up doc/, closing ticket.


provisiond: implement cryptography primitives for resource identification

fixes #83

The signature now verify that a reservation is authentic and hasn't been tempered with. But it still doesn't verify that a resource ID pointed to by reservation is actually owned by the user. For example a VolumeID in a container reservation.

This is correct this is not in the PR yet. keep in mind this is still a draft and more things needs to be added.

The node can't use the ID to point to a reservation, hence it can't figure out what u pointing to (volumeID to actual volume path) unless the node start tracking all active reservation locally in some sort of dict.

This is exactly the idea, see https://github.com/threefoldtech/zosv2/issues/83#issuecomment-515235594 for more detail

Ok I took time to read you again @muhamadazmy and all your point are valid.
The way I wanted to generated new workload ID based on the reservation won't work, cause I then create an indirection between the reservation ID and the workload ID that I cannot resolve without storing the mapping somewhere (we don't want state in the node)
So really the only solution I have is to directly use the reservation ID as workload ID, so the mapping is direct and doesn't requires to store any stage.
I just need to double check how are the reservation ID will be generated (I think BCDB will be the done doing that)

In my last batch of commits I updated the tnodb_mock so he's the one generating reservation ID. This is going to map better with own bcdb works. The generated id now looks like r-$id where $id is an incremental int. We can change it later on.
But one thing to keep in mind is this id needs to be relatively short, this is because since we use the reservation ID as container name, the ID cannot be too long (not sure how much) cause containerd create a unixsocket with the tenant namespace+container name
the tenant namespace being the user ID, it is already 44 chars long
Most probably the same kind of limitation applies for the volumes name in btrfs, which is now also the reservation ID.
The rest of the commits are some clean up and update of tfuser to map the new flow.

The generated id now looks like r-$id where $id is an incremental int. We can change it later on.

Incremental IDs in a distributed ecosystem, this gonna be really hard or almost impossible to implement

Incremental IDs in a distributed ecosystem, this gonna be really hard or almost impossible to implement

As far as I know this is how BCDB works. But like I said, this is implement like this to allow us to make progress now. We'll have to adapt once BCDB is live.


Android Support

The component doesn't resize itself when keyboard is shown :cry:
Edit: seems to be an issue with RN https://github.com/facebook/react-native/issues/3468

Looking into this.

So, I tried using keyboardDidShow and keyboardDidHide event instead, and it looks pretty good.

p.s. unrelated but android's vanilla layoutAnimation has a nice bouncy effect. Maybe we could have the layoutAnimation's params as a props?

You should probably update the Readme.md. I initially didn't even consider this package because I didn't think it supported Android based on the statement, "Plug and play iOS react-native keyboard spacer view." found in the readme.


german umlaute (ü, ä, ö) are replaced when file is saved

german umlaute (ü, ä, ö) are replaced by � when file is saved.

in write_file(..) in utils.py
with open(filepath, 'w', encoding='utf-8') as dest:
worked for me

I have fixed this issue 51f67ab276c45298ca9d586548d53da9bec22575.


Wireshark Disector

Add a Wireshark Disector as a module to the main project so it is easily discovered for the UDP network protocol.
https://github.com/real-logic/Aeron/wiki/Protocol-Specification

Sorry for bringing this up. I was looking for a Wireshark dissector the other day and stumbled upon this issue. After that, I found the following dissector, which apparently is now a part of Wireshark.
Do I understand this correctly that this particular dissector is good enough and should be generally used for analyzing the Aeron protocol?


Is ENclose missing a call to EN_deleteproject?

When the legacy API functions are used, a default project is created with a call to EN_createproject in either ENopen or ENinit. This allocates both memory and an error manager to the project. When an analysis is completed the API client would call ENclose, which simply calls EN_close, to reclaim all memory allocated to the network objects created for the default project. However, there is no call after that to EN_deleteproject  to free the memory allocated to the project and close the error manager.
Can someone please check that this is indeed a bug. If it is, then the fix is simply to add EN_deleteproject(_defaultModel) to ENclose .

EN_createproject & EN_deleteproject does not exist in DLL file. Maybe we need to include these functions in epanet2.c ?

@Mariosmsk I think you mean to say the creation and deletion functions don't appear in the legacy version of the toolkit, that is the functions defined in epanet2.h that all begin with EN and not EN_. The reason is that the single threaded legacy-type functions use a predefined global Project Handle (_defaultProject) declared at the top of epanet2.c. Thus there is no need to use functions to create or delete it.
The original issue raised here is no longer relevant so this issue can remain closed.


Automated Package Upgrade

:tada: This PR is included in version 7.7.371 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Error in read-only environment, EROFS: read-only file system, mkdir '/workspace/cache/validations.json.lock'

https://github.com/OpenZeppelin/openzeppelin-upgrades/blob/e914ea305bdb4e9bd1afd917ba2a223dc1d9c0ff/packages/plugin-hardhat/src/utils/validations.ts#L14
I believe the error is caused by the above function.
I am using Google App Engine to host my deploy function (which will deploy an upgradable contract to Matic). It works fine with I tested in in my local Mac environment. However, when I trigger the login in Google App Engine, I see this error. I would like to ask if there is any solution for this?
[Error: EROFS: read-only file system, mkdir '/workspace/cache/validations.json.lock'] {
 errno: -30,
code: 'EROFS',
syscall: 'mkdir',
path: '/workspace/cache/validations.json.lock'
}

The plugin needs a writable file system at the moment.

Is there a way to change the folder instead? For example, instead of creating on "/workspace/cache/validations.json.lock", create on "/workspace/tmp/validations.json.lock"


feat: deployment update dryrun option

This PR was initially created for the dry run of the deployment update.
Currently pause and await the deployment version enhancement.


[SPARK-33565][PYTHON][BUILD] Configure Python3.9 in python run-tests.py

What changes were proposed in this pull request?

Remove temporary workaround in run-tests
Move the workaround to python/run-tests.py

Why are the changes needed?
As the note mentioned:

Python 3.9 was temporarily removed as its default Python executables to test because of Jenkins environment issue. Once Jenkins has Python 3.9 to test, we should remove this change back and add python3.9 into python/run-tests.py script.

This cleanup will also help to user only run python/run-tests.py with python3.9 and also pypy3 as default.
Does this PR introduce any user-facing change?
It marks python3.9 and pypy3 as default test runner python executors.
How was this patch tested?
CI passed, and PySpark test are still running under python3.9 and pypy3.

'''
Running PySpark tests. Output is in /__w/spark/spark/python/unit-tests.log
1289
Will test against the following Python executables: ['python3.9', 'pypy3']
'''

Merged to master.


All calls with MSGraphClient return 403

Category

[ ] Question
[ ] Typo
[x] Bug
[ ] Additional article idea

SPFx 1.4.1.
Using the MSGraphClient gives a  403 exception since a few days:
Error: 403: Access is denied. Check credentials and try again.

In the manifest we still have the same permissions as before.
We also didn't change any code at all!
See also: https://github.com/SharePoint/sp-dev-docs/issues/1934#issuecomment-394306890

The permissions listed in the manifest are used only to provision a permission request that needs to be approved by the tenant admin. It doesn't mean that these permissions are automatically granted. If the tenant admin revoked previously granted permissions, your code could indeed stop working without any changes to it.
To verify the permissions you have to access the Microsoft Graph either:

see the contents of the JWT token used when calling the MS Graph API using a tool like jwt.io, or
see the API management page in the SharePoint tenant admin site

This issue started yesterday morning without any changes to code or permissions granted. We have the same thing on 4 different tenants, all with calls from MSGraphClient. I've tried re-authorizing the addin (full reinstall including all permissions re-approved) but no luck. It's a breaking issue, we can not continue development right now... If there is a change in code we'd love to know so we can update and continue our project.

@waldekmastykarz  same as @justdevelopment  said.... we are also blocked.

Have you verified your access token and if the granted permissions match the permissions required by the particular MS Graph API you're calling?

As the others already said: there was no change to anything: no change to the permissions granted, no change to the permissions required, no change to the code, no change to MS Graph API called.
Code and granted permissions that were working together last week stopped working without any changes.

Seems like whatever is happening behind the scenes is not requesting the proper permission scopes or something similar.
When I check the token for authorization (using http://jwt.calebb.net/) it's not as we request. The only scope in there is "People.Read user_impersonation", we definitely have a lot more in our manifest, CA etc. This code was working 100% last week, no changes made by us.

We're also seeing this behaviour with a set of SPFx code which is unchanged. Checking the token from SPFx it is only returning the basic login scope. We've tried across several tenants and even removed and retrusted the API in the Tenant Admin UX. All with no changes to this behaviour. Seems to have only been happening since Monday morning (4/6/2018)

I am seeing this exact same issue. No code change, no permissions revocation. All requests to the graph now return 403.
The only additional thing I have seen is, as others have noted, that the token issued only contains the scope "People.Read user_impersonation" which suggests that the scopes added via the manifest are no longer being respected and only the default scope is enabled.

Thanks for reporting, we'll start an investigation right away. Have reported this forward as it seems to be an issue in the underlying platform. We'll get it sorted out asap, but it will take a while still as the capability is currently in preview, so there's no Support for it through official channels yet and the majority of the engineers are in the Pacific areas.

Same thing for me,  SPFx Extension that worked friday and this week it suddenly stopped working,  returning 403 while trying to access Mail.ReadWrite scope.
tried reinstalling and reauthenticating the apirequest in tenantadmin but no luck.

@VesaJuvonen
I understand that it's still in preview, but since day one when SPFx 1.4.1 came out the documentation had this title & headline:

So from the beginning you could either decide to use the already marked as deprecated client or the new one (which was still in preview) - there is no real "in-between"/perfect solution here in my opinion....so the choice for every new project was pretty obvious for us ;)
I don't write this to blame you, just want to tell you "our side" so you can understand why most of us "expect" the new client to work :)

Deprecation means that it's supported but we are not investing in that option anymore. It does not mean that it's not supported. We need to still fix certain things around MSGraphClient until we can ship that to be ready for production usage. We absolutely understand the inconvenience this will cause for our ISVs and customers so trying to solve the situation as fast as possible.
Now - in this case, we have not yet identified the root cause of what has happened. We definitely should not break you without any warning even though capability would be "only in preview".

Same issue with MSGraphClient here, without updating anything it stopped working. Thanks for investigating the issue @VesaJuvonen

OK, sorted out the issue.  It should be fixed now, and it might take 1 hour for your tokens to expire and then work.  The problem had to do with someone removing the scopes associated with the app.  We are taking measures to ensure that can't happen in the future.

@patmill @VesaJuvonen
Confirmed. It's working again - thanks for your commitment guys!
Btw: The other one was introduced around the same time frame, maybe a little later and is still not working: https://github.com/SharePoint/sp-dev-docs/issues/1934
(I will close as soon as some of the other guys give feedback :) )

@patmill @VesaJuvonen
It is also working for me! Thanks for your quick fix!

Confirm also working for me. Thank you for the quick fix.

Thanxs for the quick fix, awesome work =)


Add Chinese docs for Karmada

What type of PR is this?
/kind documentation
What this PR does / why we need it:
Add Chinese docs for Karmada.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:

Please update the menu to Chinease.


fix(crashlytics, android): improve reason field handling in recordError

Description
Replace this paragraph with a description of what this PR is doing. If you're modifying existing behavior, describe the existing behavior, how this PR is changing it, and what motivated the change.
Related Issues
closes #10246
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[ ] All existing and new tests are passing.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] The analyzer (melos run analyze) does not report any problems on my PR.
[ ] I read and followed the Flutter Style Guide.
[ ] I signed the CLA.
[ ] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change.
[X] No, this is not a breaking change.

This PR shouldn't be approved. It's "school" way of patching the issues. And it doesn't fixes the iOS issue. @Lyokone  @pr-Mais


GRPC benchmarks for large data  ~ 656K KB between python and java are way off

Hello @LesnyRumcajs
I have a use case where I need to develop a service capable of handling large payload sizes ranging from 600KB to 1MB. I'm currently deciding between using Java or Python for this task. To make an informed decision, I conducted benchmarking tests using python_grpc_bench and java_quarkus_bench. Surprisingly, the results showed that the Python implementation performed well or even comparably to the Java implementation.
I ran the benchmarks on a Linux machine and while this doesn't seem to be a critical issue, I wanted to inquire if you have also experimented with larger payloads for these benchmarks and if you encountered any challenges or noteworthy observations. Your insights would be valuable in guiding my decision-making process. Thank you!
my machine configuration -
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz

0                                             bus                 Motherboard
/0/0                                         memory         32GiB System memory
/0/1                                          processor      Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz
/0/100                                     bridge             440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled)
/0/100/7                                  bridge             82371AB/EB/MB PIIX4 ISA
/0/100/7.1        scsi1                storage          82371AB/EB/MB PIIX4 IDE
/0/100/7.1/0.0.0  /dev/cdrom  disk               Virtual CD/ROM

Sample payload size ~ 24KB json file
Sample payload attached here -
Result
==> Running benchmark for java_quarkus_bench...
Waiting for server to come up... ready.
Warming up the service for 5s... done.
Benchmarking now...
		done.
		Results:
		    Requests/sec:	218.12
==> Running benchmark for python_grpc_bench...
Waiting for server to come up... ready.
Warming up the service for 5s... done.
Benchmarking now...
		done.
		Results:
		    Requests/sec:	215.17
-----
Benchmark finished. Detailed results are located in: results/231907T133929
-----------------------------------------------------------------------------------------------------------------------------------------
| name                        |   req/s |   avg. latency |        90 % in |        95 % in |        99 % in | avg. cpu |   avg. memory |
-----------------------------------------------------------------------------------------------------------------------------------------
| python_grpc                 |     185 |         3.98 s |         6.61 s |         7.59 s |         8.80 s |   15.11% |     58.72 MiB |
| java_quarkus                |     183 |         4.06 s |        11.30 s |        14.57 s |        20.51 s |   41.71% |     169.9 MiB |
-----------------------------------------------------------------------------------------------------------------------------------------
Benchmark Execution Parameters:
03e7e70 Mon, 17 Jul 2023 20:22:42 +0200 GitHub [feat] updated micronaut to 4.0 (#370)
- GRPC_BENCHMARK_DURATION=20s
- GRPC_BENCHMARK_WARMUP=5s
- GRPC_SERVER_CPUS=1
- GRPC_SERVER_RAM=512m
- GRPC_CLIENT_CONNECTIONS=50
- GRPC_CLIENT_CONCURRENCY=1000
- GRPC_CLIENT_QPS=0
- GRPC_CLIENT_CPUS=1
- GRPC_REQUEST_SCENARIO=complex_proto
- GRPC_GHZ_TAG=0.114.0
All done.

Hey @yawningphantom
Using 1 CPU for both the server and the client is too low. It's good for checking if the service works at all.
Looking at your specs, I recommend setting GRPC_CLIENT_CPUS to perhaps 5. Moreover, Java tends to perform significantly better when on at least 2 CPUs. I'm not sure your CPU is powerful enough to do such test, though. In general, I tend to use at least 3 cores of client per 1 core of server, but you may try. See https://github.com/LesnyRumcajs/grpc_bench/blob/master/example_benchmark.sh
Does it help?

Hey @LesnyRumcajs
Thanks for the reply, I had ran the benchmark for both   where  only GRPC_CLIENT_CPUS=5 and one where both client and server cpu's are 5. And still did not see any major difference between python and java which seems a bit weird.
Not sure why is that the case.
==> Running benchmark for java_quarkus_bench...
Waiting for server to come up... ready.
Warming up the service for 10s... done.
Benchmarking now...
		done.
		Results:
		    Requests/sec:	9.98
==> Running benchmark for python_grpc_bench...
Waiting for server to come up... ready.
Warming up the service for 10s... done.
Benchmarking now...
		done.
		Results:
		    Requests/sec:	9.98
-----
Benchmark finished. Detailed results are located in: results/231907T051744
-----------------------------------------------------------------------------------------------------------------------------------------
| name                        |   req/s |   avg. latency |        90 % in |        95 % in |        99 % in | avg. cpu |   avg. memory |
-----------------------------------------------------------------------------------------------------------------------------------------
| java_quarkus                |      10 |       67.29 ms |       80.64 ms |       99.35 ms |      134.18 ms |   24.43% |     148.6 MiB |
| python_grpc                 |      10 |       53.15 ms |       61.81 ms |       67.81 ms |       77.80 ms |    7.58% |     32.92 MiB |
-----------------------------------------------------------------------------------------------------------------------------------------
Benchmark Execution Parameters:
03e7e70 Mon, 17 Jul 2023 20:22:42 +0200 GitHub [feat] updated micronaut to 4.0 (#370)
- GRPC_BENCHMARK_DURATION=60s
- GRPC_BENCHMARK_WARMUP=10s
- GRPC_SERVER_CPUS=1
- GRPC_SERVER_RAM=5120m
- GRPC_CLIENT_CONNECTIONS=10
- GRPC_CLIENT_CONCURRENCY=20
- GRPC_CLIENT_QPS=10
- GRPC_CLIENT_CPUS=5
- GRPC_REQUEST_SCENARIO=complex_proto

==> Running benchmark for java_quarkus_bench...
Waiting for server to come up... ready.
Warming up the service for 5s... done.
Benchmarking now...
		done.
		Results:
		    Requests/sec:	0.95
==> Running benchmark for python_grpc_bench...
Waiting for server to come up... ready.
Warming up the service for 5s... done.
Benchmarking now...
		done.
		Results:
		    Requests/sec:	0.95
-----
Benchmark finished. Detailed results are located in: results/231907T051324
-----------------------------------------------------------------------------------------------------------------------------------------
| name                        |   req/s |   avg. latency |        90 % in |        95 % in |        99 % in | avg. cpu |   avg. memory |
-----------------------------------------------------------------------------------------------------------------------------------------
| java_quarkus                |       1 |       64.77 ms |       82.63 ms |       85.83 ms |       85.83 ms |    3.89% |    145.53 MiB |
| python_grpc                 |       1 |       62.92 ms |       76.76 ms |      114.02 ms |      114.02 ms |    1.54% |     15.75 MiB |
-----------------------------------------------------------------------------------------------------------------------------------------
Benchmark Execution Parameters:
03e7e70 Mon, 17 Jul 2023 20:22:42 +0200 GitHub [feat] updated micronaut to 4.0 (#370)
- GRPC_BENCHMARK_DURATION=20s
- GRPC_BENCHMARK_WARMUP=5s
- GRPC_SERVER_CPUS=5
- GRPC_SERVER_RAM=5120m
- GRPC_CLIENT_CONNECTIONS=10
- GRPC_CLIENT_CONCURRENCY=20
- GRPC_CLIENT_QPS=1
- GRPC_CLIENT_CPUS=5
- GRPC_REQUEST_SCENARIO=complex_proto
- GRPC_GHZ_TAG=0.114.0
All done.

@yawningphantom You imposed rather harsh limits on the client.GRPC_CLIENT_QPS=1 means that the client will send only one request per second, which you can confirm in the results. If that or 10 is your expected load then it may be that Python is a better choice for you. Python will definitely be outperformed with higher loads, though, as you can confirm in the results


Add cargo rustdoc for passing arbitrary flags to rustdoc

Quite useful for doing cargo rustdoc -- --no-defaults to get a doc package with private items.
This is similar to cargo rustc, except that the flags passed to cargo rustdoc are applied to both the main package and dependencies.
A friend of mine was looking for this feature, couldn't find a way to do it without directly calling rustdoc. This would probably be useful for using the full configurability of rustdoc in cargo-applications.
r? @alexcrichton

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

conceputally, :+1: from me.

cc @brson, @wycats, a new Cargo subcommand, but it fits well within the pattern of cargo rustc so I'm fine landing without an RFC.

sgtm

So, I actually want the subcommand to pass the rustdoc flags to all dependencies. Rustdoc output would be weird if only one crate was compiled with a set of flags.
For cargo rustc it makes sense to limit it to the final crate, since it's mostly for tweaking linker args and whatnot. But for cargo rustdoc we want to finally get a uniform chunk of documentation, which means the flags should be passed down.
I thought this PR did do that, turns out it doesn't, I'll see if I can make it work so that the args are passed to upstream deps too.

I would personally not want to land this with subtly different behavior than cargo rustc when both commands seem quite similar. Even with rustdoc I can imagine there are use cases of only passing flags to the top-level crate rather than all dependencies, although I'd certainly believe that it's more rare.
Configuration of rustdoc for all crates in the dependency graph is certainly desired, but I think that wants a more principled solution than just an extra command which passes all the flags everywhere. E.g. this is a recipe for all projects having their documentation building step be something like cargo rustdoc -- <ten obscure flags>, where instead the options could be stored in the manifest (for example) and the idiom would still be just cargo doc.

Alright, fixed so that it mirrorrs rustc

E.g. this is a recipe for all projects having their documentation building step be something like cargo rustdoc -- , where instead the options could be stored in the manifest (for example) and the idiom would still be just cargo doc.

So there are multiple use cases here. One is for the default build, and one is for specialized builds. For example, cargo build might be the default, but I may want to occasionally be able to run cargo rustc -- -C codegen_units=10 or something during development. Or cargo rustc -- -Z extra-plugins=plugin -L /path/to/plugin -D foo. These aren't part of the build step, these are tweaks I'm running during development. Editing a file seems ... unwieldy.
I'd prefer if we had both a cargo-config based solution, and a terminal-based solution. The simplest one seems to be allowing cargo rustc and cargo rustdoc to have a --flag-all flag, which passes the provided flag to all deps (instead of the top one), and overrides any rustc-flags/rustdoc-flags in the cargo config.

Yes I agree that passing custom flags shouldn't always involve editing files, but I was mostly just saying that this should follow cargo rustc, discussion for this kind of feature probably shouldn't happen on this PR and it would likely require an RFC.

(addressed)

:umbrella: The latest upstream changes (presumably #1991) made this pull request unmergeable. Please resolve the merge conflicts.

Updated.
It occurred to me that there's no reason for us to not allow multiple targets for cargo rustdoc, so I removed that restriction entirely.

The restriction for only one target actually mirrors cargo rustc to ensure that the custom flags are targeted at only one target instead of accidentally at many. I believe it's possible to have many targets in one package with e.g. many binary targets. Could the restriction be re-added?

But why would someone care about flags applying "accidentally" to many? These are docs, not code. It makes some sense to want to avoid applying the wrong extra link args, but the rustdoc flags are pretty benign.
Besides, it's not possible to filter targets for docs in the current framework. (https://github.com/rust-lang/cargo/blob/master/src/bin/rustc.rs#L82, https://github.com/rust-lang/cargo/blob/master/src/bin/doc.rs#L69). Could be fixed though.

This is inconsistent with cargo rustc, which this is intending to mirror, so it needs to reject the situation where multiple targets may apply. Although it may be less harmful in the documentation than compile case, it's still important that these commands maintain consistency.
For filtering, that's why I was saying that the --bin and --lib flags will need to be added to cargo rustdoc.

:umbrella: The latest upstream changes (presumably #1828) made this pull request unmergeable. Please resolve the merge conflicts.

@Manishearth What's the status of this? I'd love to use this for internal documentation.

Bit busy right now. I'm not really sure how to add the other flags, and sort of disagree that we need to.

@Manishearth would you like me to take this over? To add the new flags you'd want to change the compile filter being used and construct it in a manner similar to the other subcommands.

Sure, take it over. I don't have a lot of continuous time to work on things, and this is at the back of my queue :)

Rebased in #2129


Make Tree#createUpdated usable

Currently, Tree#createUpdated is not usable as new TreeUpdates cannot be constructed and createUpdated(repo, nupdates, updates) only accepts a single TreeUpdate as updates.
This pull request allows to new TreeUpdate() and turns updates into an Array<TreeUpdate>.
Usage is, e.g., as follows:
#!/usr/bin/env node

const Git = require("nodegit");

(async () => {
  const repo = await Git.Repository.init("test", 1);
  const odb = await repo.odb();
  const emptyTree = await repo.getTree(await odb.write("", 0, Git.Object.TYPE.TREE));
  const oid = await odb.write("test\n", 5, Git.Object.TYPE.BLOB);

  const update = new Git.TreeUpdate();
  update.action = Git.Tree.UPDATE.UPSERT;
  update.filemode = Git.TreeEntry.FILEMODE.BLOB;
  update.id = oid;
  update.path = "directory1/file";

  const update2 = new Git.TreeUpdate();
  update2.action = Git.Tree.UPDATE.UPSERT;
  update2.filemode = Git.TreeEntry.FILEMODE.BLOB;
  update2.id = oid;
  update2.path = "directory2/file";

  const treeOid = await emptyTree.createUpdated(repo, 2, [update, update2]);
  console.log(treeOid);
})();

@rafaelgieschke sorry about taking so long to look at this. This is great! Could you provide some tests to ensure functionality now and in the future please?

Perfect, thanks!

@johnhaley81 Thanks for looking at this. I added a simple test.

Hey @rafaelgieschke and @johnhaley81. I was curious if this change is ready to be merged? It looks like it might have been forgotten.

@stewartlord Yes, this and #1255 should be ready to be merged.

This would be great! Any chance it can be rebased and get merged?


Refactor Results and Installer

:tada: This PR is included in version 2.10.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


DatePicker can't have value 00:00

I have a DatePicker with no Calendar but only the time:
        <MatDatePicker NoCalendar="true" EnableTime="true" DateFormat="H:i" Enable24hours="true" @bind-Value="Effort" />

And I bind a new DateTime() with the goal that the time is shown as 00:00. But it always shows 00:01.
DateTime? Effort { get; set; } = new DateTime();
I also tried to create new DateTime with passing the concrete default values in:
DateTime? Effort { get; set; } = new DateTime(2000, 1,1,0,0,0);

This would result in a time of 20:00
Is there some default value who kicks in as soon as this value is 00:00?

Hi
Thanks for using MatBlazor.
As far as I can tell this has been fixed since you posted your issue. I updated your example with current syntax here and it seems to work: https://blazorfiddle.com/s/4usu2qsg
Please create a new issue if this is still a problem for you.


Revert #8755

What is the purpose of the change
See https://github.com/apache/dubbo/issues/8752#issuecomment-1313479077
Brief changelog
Verifying this change

Checklist

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #10938 (a8e9aa0) into 3.1 (00dad5f) will increase coverage by 0.01%.
The diff coverage is 66.66%.

@@             Coverage Diff              @@
##                3.1   #10938      +/-   ##
============================================
+ Coverage     64.86%   64.87%   +0.01%
  Complexity       14       14
============================================
  Files          1421     1419       -2
  Lines         58892    58878      -14
  Branches       8646     8645       -1
============================================
+ Hits          38199    38200       +1
+ Misses        16675    16664      -11
+ Partials       4018     4014       -4

Impacted Files
Coverage Δ

...stry/client/ServiceDiscoveryRegistryDirectory.java
42.40% <50.00%> (ø)

.../dubbo/registry/integration/RegistryDirectory.java
46.09% <50.00%> (-0.71%)
:arrow_down:

.../apache/dubbo/rpc/protocol/dubbo/DubboInvoker.java
63.23% <100.00%> (+2.42%)
:arrow_up:

...c/protocol/dubbo/ReferenceCountExchangeClient.java
67.24% <100.00%> (+2.72%)
:arrow_up:

...org/apache/dubbo/rpc/protocol/AbstractInvoker.java
66.97% <0.00%> (-3.67%)
:arrow_down:

...a/org/apache/dubbo/monitor/dubbo/DubboMonitor.java
88.09% <0.00%> (-2.39%)
:arrow_down:

...ng/zookeeper/curator5/Curator5ZookeeperClient.java
68.39% <0.00%> (-1.89%)
:arrow_down:

...adata/store/zookeeper/ZookeeperMetadataReport.java
72.34% <0.00%> (-1.07%)
:arrow_down:

.../dubbo/remoting/transport/netty4/NettyChannel.java
74.52% <0.00%> (-0.95%)
:arrow_down:

...java/org/apache/dubbo/remoting/api/Connection.java
78.33% <0.00%> (-0.84%)
:arrow_down:

... and 15 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


TranslatableSubscriber: what about using protected instead of private

Thanks to injection, it is easy to replace TranslatableSubscriber by our custom Subscriber.
But if we want to benefit from the original Subscriber, it is difficult to use extends.
For instance:
class myCustomTranslatableSubscriber extends \Knp\DoctrineBehaviors\ORM\Translatable\TranslatableSubscriber {
...

In this case we need to copy 80% of original code because of private properties and private methods.
If we just need to customise one method, we can not override just one. We must copy all private methods and properties.
What is the reason to restrict so severely ?
Could not we use "protected" instead ?

This is a very simple class, why not just duplicate the very simple logic that exists here...

@calumbrodie I think this discussion shouldn't be about effort ... but about design.
I'm in favor of changing from private to protected properties to make extending easier at this point.

Sorry my mistake I was confusing this class with Knp\DoctrineBehaviors\ORM\Translatable\CurrentLocaleCallable.

The best design is the one allowing open/closed principle.
The behavior should be modifiable without having to modify the class, nor extending it.
I should have put the class final to make it explicit.
If it was final, we would be forced to refaoctor it so that it is reusable by composition f.e.
Now, to be pragmatic, we could allow some methods or properties to be overridable, but not dumbly search and replace all private with protected.
If you have a good use case, we can maybe make an exception,t but I tend to agree with @calumbrodie  in that custom behaviors could have their own class, at the cost of duplication.
But I prefer having closed classes in the lib and you having to maintain a duplicate than me having to maintain BC on all the classes :)

@docteurklein (hello you from 2015!) I have a good case for you!
Related to this issue, I have to add just a third argument on the private method isTranslatable, but I can't just override this method because it's private...

helllooooo @EVDW :) :)
maybe a simple solution would be to copy the trait contens into your won class and change the visibility to public ?
cheers :)


Added isConnected method to Connection.js

I have added isConnected() method to Connection.js . Now its easy to check whether you are connected to database or not.

I have worked on diverse tools for development (PHP,Java,C#) and isConnected() method is a common perception to be used for check whether the connection is still connected. I was working on some other project today and found it missing so i added

Thank you, that is very appreciated. I appreciate that other tools have differing APIs, and acknowledge that each project can have it's own opinion as to what type of API it should present to the user.

Sure , thank you for your time


Execute other bash scripts/commands with interactive output (e.g. vim) from kscript

This is a really small sample script i want to convert into kscript (Not probably, but see this is a proof of concept)
echo "#!/bin/sh \n" > $1
chmod u+x $1
vim $1

I have written a library that allows executing commands: https://github.com/MaaxGr/KotlinUtils/blob/master/src/main/kotlin/de/maaxgr/kotlinutils/BashUtil.kt
And here is use the library to execute shell commands from kscript:
exec("echo $content >> $fileName")
exec("chmod u+x $fileName")
exec("vim $fileName")

fun exec(cmd: String) = BashUtil.executeCommand(cmd) { println(it) }

Unfortunatly can't to to insert mode and safe vim. Probably this interactivenes is impossible, because it's all running in the JVM. But is there a native better working method for executing (interactive) commands in the library?

You can read from the command line, but I'm not sure if the JVM stdin (which is used internally) supports more complex console stuff such as vim.
λ kscript 'val (a, b) = readLine()!!.split(" "); println(a)'
hey you
hey

You can read from the command line, but I'm not sure if the JVM stdin (which is used internally) supports more complex console stuff such as vim.
λ kscript 'val (a, b) = readLine()!!.split(" "); println(a)'
hey you
hey

Okay probably JVM stdin is this limitation yeah. It seems that kscript is not the right choice for really low level linux-scripting stuff like changing directories in user context, open other programs like vim etc.
Would be too nice if there is something with the same possibilities as bash, just with a more readable syntax as kotlin.
For my use current use case i will use bash now.
Thanks for your answer. Issue resolved from my side.

Okay probably JVM stdin is this limitation yeah. It seems that kscript is not the right choice for really low level linux-scripting stuff like changing directories in user context, open other programs like vim etc.
Would be too nice if there is something with the same possibilities as bash, just with a more readable syntax as kotlin.
For my use current use case i will use bash now.
Thanks for your answer. Issue resolved from my side.

something with the same possibilities as bash

Writing shell application like bash, csh, tcsh, etc. is very different than scrip interpreter.
One could develop ksh shell in Kotlin/Native for example. That application would take STDIN and produce STDOUT and STDERR like other shells. Also it may use kscript as its scripting language if you want.
In the mean time you can use console mode of Kotlin.

something with the same possibilities as bash

Writing shell application like bash, csh, tcsh, etc. is very different than scrip interpreter.
One could develop ksh shell in Kotlin/Native for example. That application would take STDIN and produce STDOUT and STDERR like other shells. Also it may use kscript as its scripting language if you want.
In the mean time you can use console mode of Kotlin.

Indeed @C06A, to enable a more bash-like experience you would need to swap bash against another interpreter. The most advanced approach JVM solution in this space is afaik https://ammonite.io/ (which is written in scala).

Indeed @C06A, to enable a more bash-like experience you would need to swap bash against another interpreter. The most advanced approach JVM solution in this space is afaik https://ammonite.io/ (which is written in scala).


Failed to transfer caffe's prototxt .

  Thank you for good job!
  I have used  mxnet-ssd\mxnet\tools\caffe_converter to convert  caffe's ssd300  deploy.prototxt to  mxnet's json file. The output is:
 google.protobuf.text_format.ParseError: 758:3 : Message type caffe.LayerParameter has no field named norm_param.

  Do I use it correctly?

You cannot convert caffe model directly.
Caffe-ssd has non-official caffe layers, my impl has non-official mxnet layers, thus conversion could be cumbersome using mxnet converter.


Implement exact sampler

Closes #158
This works around

https://github.com/Qiskit/qiskit-terra/issues/9657
https://github.com/Qiskit/qiskit-aer/issues/1810
https://github.com/Qiskit/qiskit-aer/issues/1811

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

17 of 17 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.09%) to 88.208%

Totals

Change from base Build<PHONE_NUMBER>:
0.09%

Covered Lines:
2072

Relevant Lines:
2349

💛  - Coveralls


update README

@ktakattack @csr @smartclash  We probably want to add a nice looking screenshot of the bot welcoming 2 users in the README.md file. I would have made a screenshot right now to include it, but we don't have an official bot yet.  I don't want a bot with the name test-bot to end up in the readme :)

Great idea! Yes, for sure. I think we should do this tomorrow once things are finalized.


the agent due to an RPC failure. Code 0.

Hello everyone, I have such a problem, the terminal does not start. There are a bunch of different errors, here one of them is the termination of the agent due to an RPC failure. Code 0. What should I do? I have already installed Google dns, disabled antiviruses, enabled all Windows services, I did everything / help !!!! My English is bad, help me for God's sake

It looks like your report is missing some important information, See this wiki page for more info on how to report actionable terminal issues.
/label "needs more info" integrated-terminal


GitHub Actions housekeeping

Updates actions/setup-python
Uses v2 instead of master for actions/checkout

All other versions are fine 👍

Thank you!


Add new "markdown" Twig filter and update documentation accordingly

Adds new "markdown" Twig filter which is handy when using Markdown from data sources directly within a template.
Changes proposed in this pull request:

Add new "markdown" Twig filter
Update documentation accordingly

@Narno please review :eyes:

Hello @FunkyM, thanks a lot for your contribution.
Why don't use the default filter markdown_to_html available since version 2.12 of Twig?

Hello @FunkyM, thanks a lot for your contribution.
Why don't use the default filter markdown_to_html available since version 2.12 of Twig?

Reasoning behind it:

Twig docs state that The markdown_to_html filter is part of the MarkdownExtension which is not installed by default. Install it first thus it adds another dependency
The MarkdownExtension uses a different Markdown parser/converter than Cecil which could result in different rendering
Using the same Markdown converter ensures consistency of Markdown input and HTML output with Cecil's content conversion

If you favor using the MarkdownExtension than it would also make sense to switch to it's Markdown conversion library in Cecil to prevent the possibility for rendering inconsistencies/differences.
Hope this was helpful.

Closed by #880.
Thanks a lot @FunkyM! :+1:


Fix nload output corrupting a few seconds after starting

See https://github.com/rolandriegel/nload/issues/3

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

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

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

I'll let CI test the build for me (since I use this in an overlay).
I have tested the effectiveness of the patch itself on NixOS.

@GrahamcOfBorg build nload

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: nload
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: nload
Partial log (click to expand)
make[1]: Leaving directory '/build/nload-0.7.4'
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/wj98jglp5z4pdjh6dzhfscl80i7ify8d-nload-0.7.4
shrinking /nix/store/wj98jglp5z4pdjh6dzhfscl80i7ify8d-nload-0.7.4/bin/nload
gzipping man pages under /nix/store/wj98jglp5z4pdjh6dzhfscl80i7ify8d-nload-0.7.4/share/man/
strip is /nix/store/dxf1m7dhc4qb655bdljc1fsd74v1nag3-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/wj98jglp5z4pdjh6dzhfscl80i7ify8d-nload-0.7.4/bin
patching script interpreter paths in /nix/store/wj98jglp5z4pdjh6dzhfscl80i7ify8d-nload-0.7.4
checking for references to /build in /nix/store/wj98jglp5z4pdjh6dzhfscl80i7ify8d-nload-0.7.4...
/nix/store/wj98jglp5z4pdjh6dzhfscl80i7ify8d-nload-0.7.4

The last tagged release is from 2012 but the upstream repo contains a number of bugfixes from 2018 (one of these is applied in this PR). We should consider upgrading the package to the latest git revision.


test: use new Cypress version to enable Test Replay feature in Cloud

Description
An important feature of the Cypress Cloud becomes available with Cypress version 13. So, this PR is updating the docker image to the currently latest version.

📚  View the storybook of this branch here

@ctschacher this is one test failing, is it expected as it will be fixed in another PR?

Linking https://github.com/gravitee-io/gravitee-api-management/pull/5074#issuecomment-1695265253

@ctschacher this is one test failing, is it expected as it will be fixed in another PR?

Right, I don't think that failing test is related to this PR. It seems flaky but I'm on it to investigate that failure and most likely have another PR to fix it.


Control loaded content in test function

Currently all content is always loaded.

When testing a scenario in editor, or when start a new local quest, only the activated content will be used.
This request would be to add a better UI input in Editor I suppose.
I will move this to "later", as current behaviour already allows testing.


library concepts not fully defined

problem statement

handledProps aren't defined formally in the README, and their usage + context are not fully articulated

discussion
i filed 1601 in hopes to better understand how RSUI wires all of this up.  my understanding has progressed only as far to know that this transform adds a static-ish exports to a component which can be used somehow at runtime to aide in the propagation of props down the component tree.
anyway, this isn't critical or anything, I just thought that I'd share as an interested user that the README didn't get me fully there!

@cdaringe Yes, I need more docs. Thanks for a notice

@cdaringe I've updated README recently, I think now it will be easier understand what the plugin actually does. Sorry, that it took a long time :cry:

Oh nice!  Thx!


Side panel proposal

Hey guys, thanks for the amazing work you are doing here. I truly appreciate it :)
I had a similar concern, which Jose pointed out was being discussed here.
Given that it's stiiiill not merged, I have a UX proposal for your consideration:
PROBLEM: It was my experience, learning Ash framework using their Livebook tutorial series, that most of the output felt too verbose, and it was a detriment in the top to bottom reading & learning experience. I often would rapidly scroll up and down avoiding the code results, and I see this particular issue is not being addressed by the current implementation.
(POSSIBLE) SOLUTION:  Add a block feature flag that indicates how a particular block should render by default (settable also on a per Livebook basis). This way Livebooks authors can decide as a blank statement, how the document should be read, but also giving the reader the possibility to revert the author's decision.

By choosing "Sidepanel" on the added options to the dropdown on the image above, what I'm intending to happen is: when you press (re)evaluate, still print something downwards, but make it as minimal as possible while still making it expandable on command.
To achieve this, you'd need a new toggle state for what I'm calling bottom results. For that, here's a solution that comes in handy, even if you don't implement the proposed solution to the original problem (Reader can hide output):

With all this in place, when running an evaluation that had "Sidepanel" as it's output option, readers would see something like this:

Originally posted by @fceruti in https://github.com/livebook-dev/livebook/issues/2109#issuecomment-1748349712

I moved the discussion here to avoid side tracking the PR.

I don't think this fits into the purpose/design of the side panel, so I would consider it separately. We can do one of the following:

Have a new View, where code cells are always half-width and outputs are on the right.
Make all outputs collapsible (similarly to how we collapse sections).
Have per-cell configuration that says if the output should be collapsed. Though in most of such cases it's likely the output is just not relevant and the cell could just return a less verbose value.

Which one is better depends on the actual problem we are trying to solve, 1. makes a better use of wide screens, especially that code usually that wide. 2. is more specific to the use case where we want to run everything and collapse all outputs, then only expand outputs that we are interested in.

I am more inclined towards 1. If you want to collapse outputs, we should rather have custom kinos. I would not necessarily make it a property of Livebook.

Improving upon 1, I'd suggest create a bigger waist where the code/result goes. Something like this:

I was just thinking about the possibility of side panels, but for documentation. The hover docs and notices are nice, but it would be cool to allow displaying docs on the side as well (and an implementation of K in the vim emulation to pull up docs) instead of having to to pull them up in separate tab in hexdocs. This output on the side seems like a really good idea though.

My 2c what I think may be useful. A panel in the dev tools style that always at the bottom:

I was reverse engineering a camera that has a soap interface and can send callbacks-it would be useful to log the callbacks
using telemetry events in livebook and see the output in realtime
any other async task output


Remove or fine tune FirebaseAnalytics warning from Firebase.h

Firebase.h should stop generate a warning about a missing FirebaseAnalytics.h. Or perhaps only keep it for pods removing the hard dependency on Analytics in Firebase 6.

Fixed internally in cl/242490144 as part of the upcoming Firebase 6.0.0 release.
There will no longer be a general warning, but instead specific warnings about incomplete features for Dynamic Links, In App Messaging, Messaging, Performance, and Remote Config.


Add files for bower_components

Adding files 'basket.full.min.js' and 'basket.min.js' to bower (removed from ignored files)

├── basket.full.map
├── basket.full.min.js.map
├── basket.js
├── basket.min.js.map
└── basket.min.map

The above is the current output when bower installing today. We ship the sourcemaps for minified builds, but aren't actually shipping the minified builds themselves. Merging. Thanks!


Resharding

@sougou @enisoc @michael-berlin
Removing a lot of obsolete stuff about old go client in there. Feels good.

LGTM


[Bug][BlueprintMakePlan] Cannot add more than 28 scopes to an azure devops connectioni

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
We have several hundred repositories in each 'project' area in our azure devops server. I was attempting ot create a project in devlake that mapps to those high level areas and link all the repos within to the connector.
However, the underlying api for PATCH the blueprint fails when there are more than 28 scopes defined as it fails with a
{"success":false,"message":"error patching the blueprint -dw (400)\nWraps: (2)\nWraps: (3) fork/exec ./run.sh: argument list too long\nWraps: (4) fork/exec ./run.sh\nWraps: (5) argument list too long\nError types: (1) *hintdetail.withDetail (2) *hintdetail.withDetail (3) *hintdetail.withDetail (4) *fs.PathError (5) syscall.Errno","causes":["fork/exec ./run.sh: argument list too long"],"data":null}
Possibly there are other fundamental reasons that I should not want to link that many scopes to a project? or possibly this is just an artefact of the azuredevops plugin being in python and not go?
What do you expect to happen
I would expect to be able to easily link as many repos as I want to any given project/blueprint.
How to reproduce
setup an azure devops connection to a system with over 30 repos. link them all to config scopes then create a project and try to link them all to the connection.
After about 28 are selected you start to receive errors on submit of the patch.
Anything else
this occurs every time. It's also worth mentioning that the UI element for selecting repos does not behave well with >hundred repos in teh system. It's obviously wired up to some underlying paginator, when you scroll towards the bottom is loads more but resets your position to the top so it's not obvious what's happend. at some point you hit a limit which I think is hard coded because it doesn't seem to successfully load any more beyond a certain point even thought there are many more to load.
the search function does not work for azure devops repos - again I think this is possibly because the python plugin does not implement that? I can raise a separate bug for that if it helps but I could work around all the UI issues if the underlying API accepted a json doc with the full list.
I'm also looking at fixing this locally, if i figure out a fix i'd be happy to submit a patch but possibly someone that already knows the code base would be able to fix it much eaiser.
Version
master
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Just to add some context to this now that I think I understand the code structure a bit better. the azure devops plugin is a remote plugin in python and as such we go via a bridge cmd to invoke a shell script with the parameters of any given plugin command which the python code is using hte Fire framework to automagically map onto it's methods. Sadly because this is all going via essentially linux command line args it's subject to the limits of those arg lengths and the payload for updating a pipeline with more than ~28 scopes is pretty massive.
I suspect there are two options (assuming this is even a direction it's sensible to head)

add a method for appending additional scopes rather than re-writing the whole list and break up the remote commands to keep them under a size limit.
write the command payload to a temporary json file and re-read that into the python program rather than relying on the commandline args.

Personally I would like to see the existing implementation be replaced with a proper RPC framework that supports streaming (e.g. grpc). The existing solution is something we put together for an initial release but it's not a mainstream solution, so extending it with additional features is going to create more maintenance headaches and tech debts.

I have just noticed that there is an open PR for a fully go implementation of the azure devops plugin - presumably this would ulti mately be the best route since it would be consistent with all the other plugins and would remove this whole situation of passing arguments via process execs. Perhaps it would be best to look at what else is needed to merge that PR?

Hi @wouldd , yes some contributors want to re-implement AD with Golang but it's on hold now.

I've opened #7204 to experiment with grpc support for Python and see where it goes. If done right it should fix this problem too.
As for search functionality missing, that is intentional. There's no API that azure gives us a way of globally searching for repos (AFAIK).

Close this issue since this PR has been merged. Feel free to reopen it if it still exists.


Karpenter is recreating the same type of node over a period of time and deleting it in parallel

Description
Observed Behavior:
Karpenter is recreating the same type of node over a period of time and deleting it in parallel when replicas are increased.
Expected Behavior:
Karpenter should not consolidate often when replicas are increased and new nodes are created , deleted over a period of time marking the pods to be shifted to new nodes.
Reproduction Steps (Please include YAML):

Create multiple nodepools with same weights and each for an AZ.
Create a deployment with 1 replica without any nodeselectors.
Increase the replica count to 10
Karpenter will create multiple nodeclaims and the pods will be re-shuffled over period of time.

Versions:

Karpenter Version: 1.0.5
Kubernetes Version (kubectl version): v1.31

Attached logs :
karpenter-dec07.log
Questions :

What could be the reason for a node repeatedly entering a recreating loop, even though there hasn’t been any scale-up or scale-down activity in the cluster? Specific Time: 16:15PM - 16:45PM , issue can be found in the attached logs.
What is the purpose of including deleting pods in the “found provisionable pod” category, especially those currently on a terminating node?

https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/controllers/provisioning/provisioner.go#L326

We were able to reproduce the issue, and it’s not a bug in Karpenter itself but rather an inefficiency of Karpenter’s scheduling with respect to the Kube-scheduler. Kube-scheduler have full control of pod placement, which causes conflicts with the Karpenter's consolidation calculation during scheduling.
Test Setup:
Deployments Configuration:

deploy1: 2 CPU
deploy2: 3 CPU
deploy3: 4 CPU
deploy4: 12 CPU
DaemonSet: 1.2 CPU per node

Node Pool Configuration:

Created a separate node pool for testing using specific labels and taints.
Instance Type: c5.4xlarge (16 CPU, 32 Gi memory)

Scale the Deployment:

Scale the deployments and ensure to schedule the pods in below mentioned nodes with the help of kubectl cordon/uncordon commands.

  | node 1 |   | node 2 |   | node 3 |
-- | -- | -- | -- | -- | -- | --
resource | pod count | cpu requested | pod count | cpu requested | pod count | cpu requested
deploy1 - 2 cpu | 0 | 0 | 1 | 2 | 0 | 0
deploy2 - 3 cpu | 0 | 0 | 2 | 6 | 0 | 0
deploy3 - 4 cpu | 0 | 0 | 0 | 0 | 2 | 8
deploy4 - 12 cpu | 1 | 12 | 0 | 0 | 0 | 0
daemonset | - | 1.2 | - | 1.2 | - | 1.2
total |   | 13.2 |   | 9.2 |   | 9.2
free |   | 2.8 |   | 6.8 |   | 6.8
Setup Complete:

Once pods are placed on the nodes, uncordon all nodes and ensure consolidation is enabled for the node pool.

What will happen next ?

Karpenter will now perform consolidation for node2, aiming to move the deploy1 pod (1 pod) to node1 and the deploy2 pods (2 pods) to node3, allowing the node to be evicted

Expected Scheduling by Karpenter:

  | node 1 |   | node 2 |   | node3 |
-- | -- | -- | -- | -- | -- | --
resource | pod count | cpu requested | pod count | cpu requested | pod count | cpu requested
deploy1 - 2 cpu | 1 | 2 | 0 | 0 | 0 | 0
deploy2 - 3 cpu | 0 | 0 | 0 | 0 | 2 | 6
deploy3 - 4 cpu | 0 | 0 | 0 | 0 | 2 | 8
deploy4 - 12 cpu | 1 | 12 | 0 | 0 | 0 | 0
daemonset | - | 1.2 | - | 1.2 | - | 1.2
total |   | 15.2 |   | 1.2 |   | 15.2
free |   | 0.8 |   | 14.8 |   | 0.8
Actual Scheduling by Kube-Scheduler

  | node 1 |   | node 2 |   | node 3 |
-- | -- | -- | -- | -- | -- | --
resource | pod count | cpu requested | pod count | cpu requested | pod count | cpu requested
deploy1 - 2 cpu | 0 | 0 | 0 | 0 | 1 | 2
deploy2 - 3 cpu | 0 | 0 | 1 | 3 | 1 | 3
deploy3 - 4 cpu | 0 | 0 | 0 | 0 | 2 | 8
deploy4 - 12 cpu | 1 | 12 | 0 | 0 | 0 | 0
daemonset | - | 1.2 | - | 1.2 | - | 1.2
total |   | 13.2 |   | 4.2 |   | 14.2
free |   | 2.8 |   | 11.8 |   | 1.8
Observed Issue:

One of the deploy2 pods enters the Pending state, which triggers Karpenter to provision a new node.
This behavior repeats in a loop, continuously recreating nodes.

Root Cause:

Karpenter performs calculations during consolidation to schedule pods on appropriate nodes. However, kube-scheduler disregards these calculations and places pods randomly.
This discrepancy leads to inefficient pod placement, causing some pods to remain pending and triggering unnecessary node provisioning.

Attached the deployment, pdb and nodepool manifests below.
manifest.zip

Increasing the consolidateAfter time helps reduce the node churn cycle, but it won’t resolve the actual issue. We believe that configuring the node scoring policy as MostAllocated in the Kube Scheduler could help in this scenario. However, EKS currently does not support customizing the Kube Scheduler configuration. https://github.com/aws/containers-roadmap/issues/1468.


investigate inflexible terraform provider for MAAS

In an effort to ship a baremetal provider for kraken quickly, investigate what is required to build a hardcoded version of a terraform provider for MAAS. This provider would expose zero knobs and would have poor documentation but would work with a specific process against a known state of MAAS that would be well documented.
Originally by @coffeepac

https://github.com/negronjl/terraform-provider-maas
https://github.com/RobWC/terraform-provider-maas/tree/merge
c/o @maratoid


[HUDI-1660] Excluding compaction and clustering instants from inflight rollback

What is the purpose of the pull request
This PR fixes a bug to ensure that pending compaction & clustering operations are always excluded when performing inflight rollbacks
Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

LGTM. Maybe create a ticket for adding unit test so this wont be missed (if you havent already created one)


Unstringify "insert custom globals" example.

Half of the example was displayed as a string.

Not a problem anymore, but thanks!


Add AHMC composable interface to README

There is a nice description of the composable interface in the StanCon submission. We should make it available somewhere, e.g. the README file.
http://xuk.ai/assets/StanCon-AHMC.pdf

Sure. I will do an update soon. Maybe add some highlights in the README.md as well. Like GPU-support?

Would be cool to to have an GPU example.

One more TODO for this

Would be great if someone could document these various options btw. - Will

Reminder for myself: do remeber to reuse this example: https://github.com/TuringLang/AdvancedHMC.jl/pull/90

StanCon-AHMC.pdf
Just to save the poster in the AHMC repo.

One more TODO for this

Would be great if someone could document these various options btw. - Will

Reuse the table in our draft.


Declare: Fix a potential crash

Introduced in https://github.com/Zarel/Pokemon-Showdown/commit/9d5b0968518713c5e3bf82ed814458a62fe1b4e3

Apparently target is now an empty string by default; I was under the assumption that it was undefined by default.


raffle staging test correction

"recentWinner" was misspelled at line 31.
And, it is "getLastTimeStamp" at line 20 & 34. There is no function in raffle called "getLatestTimeStamp".

There were some spelling issues in raffle stating test. I fixed them.

Thank you!


Refactor ReactCrop to be used as a HOC (Higher Order Component)

ReactCrop was split into two parts, the HOC itself is now in "withCrop.js", while the default rendering component is in ReactCrop.  This should not be a breaking change, because the default export is going to be the ReactCrop component already wrapped in the HOC.
This HOC now allows developers more fine tuned control of the rendering process, so that it can be mixed with perhaps other HOC components that work with the same image/canvas.
The work is also here: https://stackblitz.com/edit/img-hoc-poc

After discussion with Dom, closing to resolve issue around event handler and will add some basic unit testing, once those things are added I'll send another PR.


[FEATURE] Support Chinese caption video

I tried to summarize a youtube video with Chinese (traditional) subtitles and it tells me the following message：
❌ Caption language currently not supported.

{'zh-TW': <Caption lang="Chinese (Taiwan)" code="zh-TW">}

Describe the solution you'd like
Would like to request a feature to support this kind of video.

Hello, could you please share the YouTube link as a reference? Thank you.

Hi,
This is the video link I tried to summarize: https://www.youtube.com/watch?v=7VdhEE194fc
Thanks!


Please move ROADMAP.md to EOSIO/Documentation

In order to make translation easier using https://crowdin.com/project/eos-docs please move ROADMAP.md to EOSIO/Documentation repository.

@bytemaster You made roadmap; is there any reason to keep it in this repo?

Seems OK to move.

I have no write access to Documentation repo. Unable to move.

Oh, it's already done. Closing issue.


Add Python script for message sending via textbelt

@kaushl1998 Thank you for the contribution. Please star our repository


some cleanings and bigger time variance allowance

We still have some uncleanness in the code:

testing contracts are not in the testing files
Getter contract is needed
some more documentation is needed

Codecov Report

Merging #191 into contracts/DX-2.0-No-Frontend will decrease coverage by 94.59%.
The diff coverage is 0%.

@@                      Coverage Diff                       @@
##           contracts/DX-2.0-No-Frontend   #191      +/-   ##
==============================================================
- Coverage                           100%   5.4%   -94.6%
==============================================================
  Files                                 6      7       +1
  Lines                               472    481       +9
  Branches                             82     82
==============================================================
- Hits                                472     26     -446
- Misses                                0    455     +455

Impacted Files
Coverage Δ

contracts/ForTestingOnly/InternalTests.sol
0% <0%> (ø)

contracts/InternalTests.sol
0% <0%> (-100%)
:arrow_down:

contracts/DutchExchange.sol
2.45% <0%> (-97.55%)
:arrow_down:

contracts/Oracle/PriceOracleInterface.sol
15.78% <0%> (-84.22%)
:arrow_down:

contracts/Tokens/TokenTUL.sol
20% <0%> (-80%)
:arrow_down:

Continue to review full report at Codecov.

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

replaced by PR from codeAudit


Spout2 compatibility to be able to record with an alpha channel

Having the ability to record with transparency could open a lot of doors in artistic creations. For instance:

record a gameplay and select an environment afterward
some funky effects for streamers
easly blend 2 or more gameplays for collabs
help in creation of video thumbnails

This script seems to allow that just by enabling it on a camera in the unity editor https://github.com/keijiro/KlakSpout https://www.youtube.com/watch?v=iIwcqgAPVWI
Maybe it would be possible to have 1 spout2 sender per camera to allow either to blend the differents layers and external effects on obs or record all of them and chose how we want to blend them while editing the video.

System requirements

Unity 2020.3 or later

Already kinda ruled out by that - Beat saber uses 2019.4

Here's a fork that makes it work with 2019.4 https://github.com/fuqunaga/KlakSpout. I see some references to DX10 in the code but it's not explicitely said that it supports it.
Here's another one that introduce support to 2019.2 and explicitely DX9 (which may be compatible with DX10 if DX10 has retro-compatibility (would be sad if it were compatible with DX9 and DX11 but not DX10 :') )) https://github.com/mightypanda/KlakSpout