CosmosClient can't connect to Cosmos DB Emulator created through aspire

Is there an existing issue for this?

[x] I have searched the existing issues

Describe the bug
If you create a cosmos emulator instance with aspire, and then try to connect to it from another application CosmosClient, attempting to do anything will hang nearly indefinitely.  (I've waited 5+ mins - maybe it fails eventually, but I didn't have patience to find out).
When looking at the debug logs, an initial connection is successfully made to https://localhost:59029, however the CosmosClient very shortly decides to use https://<IP_ADDRESS>:8081/ instead - the IP is the raw IP address of the container, and the port is the container port, not the DCP proxy port.
DocDBTrace Information: 0 : DocumentClient with id 1 initialized at endpoint: https://localhost:59029/ with ConnectionMode: Gateway, connection
...
DocDBTrace Information: 0 : Current WriteEndpoints = (https://<IP_ADDRESS>:8081/) ReadEndpoints = (https://<IP_ADDRESS>:8081/)

On the aspire side, you can work around this by setting AZURE_COSMOS_EMULATOR_IP_ADDRESS_OVERRIDE and also exposing the 8081 directly on port 8081 (although I suspect this will break containers trying to talk to cosmos).
.RunAsEmulator(container =>
{
    var endpoint = container.GetEndpoint("emulator");

    container
        .WithEnvironment("AZURE_COSMOS_EMULATOR_IP_ADDRESS_OVERRIDE", "<IP_ADDRESS>")
        .WithHttpsEndpoint(port: endpoint.TargetPort, targetPort: endpoint.TargetPort, isProxied: false);
        // May be able to do something with `AZURE_COSMOS_EMULATOR_ARGS="/port 12345"` if you can update the targetport to match the dynamically allocated dcp port
    ;
});

Alternatively on the caller side, you can work around this by setting LimitToEndpoint to true - this has been done for the cosmosdb health checks - https://github.com/dotnet/aspire/blob/7d66c53f697d35d4a01963bc824c29d63931d9f8/src/Aspire.Hosting.Azure.CosmosDB/AzureCosmosDBExtensions.cs#L170 .
Expected Behavior
I'd expect CosmosClient to be able to connect to the emulator without having to set LimitToEndpoint.  If LimitToEndpoint is needed, then I'd expect to see this requirement documented at https://learn.microsoft.com/en-us/dotnet/aspire/database/azure-cosmos-db-integration?tabs=dotnet-cli .
I'd also like to see the cosmos client provide some kind of error, within 5 minutes to let you troubleshoot the problem, but that's an issue with the Azure SDK, not aspire.
Steps To Reproduce
Aspire:
var cosmos = builder.AddAzureCosmosDB("cosmosDb")
    .RunAsEmulator(container =>
    {
        container
            .WithLifetime(ContainerLifetime.Persistent)
            .WithDataVolume()
            ;
    });

Console App
var client = new CosmosClientBuilder("AccountEndpoint=https://localhost:32787/;AccountKey=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==")
         .WithHttpClientFactory(() => new HttpClient(new HttpClientHandler()
         {
             ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
         }))
         .WithConnectionModeGateway()
    .Build();

var db = await client.CreateDatabaseAsync("foo123"); // This will hang indefinitely

Exceptions (if any)
Debug output
DocDBTrace Information: 0 : DocumentClient with id 1 initialized at endpoint: https://localhost:59029/ with ConnectionMode: Gateway, connection Protocol: Https, and consistency level: null
DocDBTrace Information: 0 : Azure Environment metadata information not available. A socket operation was attempted to an unreachable network. (<IP_ADDRESS>:80)
DocDBTrace Information: 0 : SystemUsageMonitor started
DocDBTrace Information: 0 : Current WriteEndpoints = (https://<IP_ADDRESS>:8081/) ReadEndpoints = (https://<IP_ADDRESS>:8081/)
DocDBTrace Information: 0 : GlobalEndpointManager: StartLocationBackgroundRefreshWithTimer() refreshing locations
DocDBTrace Warning: 0 : ClientRetryPolicy: Gateway HttpRequestException Endpoint not reachable. Failed Location: https://<IP_ADDRESS>:8081/; ResourceAddress:
DocDBTrace Information: 0 : GlobalEndpointManager: Marking endpoint https://<IP_ADDRESS>:8081/ unavailable for read
DocDBTrace Information: 0 : Current WriteEndpoints = (https://<IP_ADDRESS>:8081/) ReadEndpoints = (https://<IP_ADDRESS>:8081/)
DocDBTrace Information: 0 : Endpoint https://<IP_ADDRESS>:8081/ unavailable for Read added/updated to unavailableEndpoints with timestamp 10/16/2024 23:51:35
DocDBTrace Information: 0 : GlobalEndpointManager: Marking endpoint https://<IP_ADDRESS>:8081/ unavailable for Write
DocDBTrace Information: 0 : Current WriteEndpoints = (https://<IP_ADDRESS>:8081/) ReadEndpoints = (https://<IP_ADDRESS>:8081/)

.NET Version info
	<PackageReference Include="Aspire.Hosting.AppHost" Version="9.0.0-rc.1.24511.1" />
	<PackageReference Include="Aspire.Hosting.Azure.CosmosDb" Version="9.0.0-rc.1.24511.1" />

.NET SDK:
 Version:           8.0.403
 Commit:            c64aa40a71
 Workload version:  8.0.400-manifests.47119bbc
 MSBuild version:   17.11.9+a69bbaaf5

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\8.0.403\

.NET workloads installed:
Configured to use loose manifests when installing new manifests.
 [aspire]
   Installation Source: SDK 8.0.400, VS 17.11.35222.181
   Manifest Version:    8.2.1/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.1\WorkloadManifest.json
   Install Type:        FileBased

Host:
  Version:      8.0.10
  Architecture: x64
  Commit:       81cabf2857

.NET SDKs installed:
  6.0.427 [C:\Program Files\dotnet\sdk]
  8.0.400 [C:\Program Files\dotnet\sdk]
  8.0.403 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.35 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.35 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.35 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Anything else?
Using LimitToEndpoint is the easier solution here, however I'm trying to wire cosmosdb up to azure functions, and I don't see a way to set LimitToEndpoint in Azure functions.

Looks like a dupe of https://github.com/dotnet/aspire/issues/6349

You linked the issue to itself. did you mean #5364?

Ah yes

Closing as duplicate of #5364


Select().from().count() always return 1

Hi:
I went to count all instance in db,but this statement always return 1

new Select().from(Baby.class).count();
Is any Idea?

Yes it's not well documented but you need to do:
new Select().count().from(Baby.class).count(). I will make this more clear in 3.0

@agrosner
Thank you!


system-filepath is apparently now deprecated

The package page for system-filepath says

Deprecated in favor of filepath
Please see: https://plus.google.com/+MichaelSnoyman/posts/Ft5hnPqpgEx

I'm aware of the deprecation status, but the library is still functional.
The main reason I'm still on the system-filepath library is that all the alternatives (except for path) are just type synonyms for either String or ByteString, and I prefer the FilePath type to be a separate type.

Maybe dirstream package can have a cabal file flag that switches underlying filepath library? This way either having a separate type for FilePath or not depending on a deprecated package will be possible, depending on the user's needs.

Perhaps Haskell's new support for Backpack could solve this issue?

Yes, Backpack might help to resolve the issue. However, I believe there's simple solution. Recently I noticed that path's type for paths is not a type synonym any more - https://hackage.haskell.org/package/path-0.6.1/docs/Path.html#t:Path. Perhaps it would be a good candidate now?

The main issue with the Path type is the absence of an IsString instance, so you can't use string literals for paths


CreateTransactionResponse struct never includes contract_address in response

CreateTransactionResponse Missing Contract Address in Response
The CreateTransactionResponse struct seems to have a field for contract_address:
#[derive(Clone, Serialize, Debug)]
#[serde(rename_all = "PascalCase")]
pub struct CreateTransactionResponse {
    #[serde(skip_serializing_if = "Option::is_none")]
    pub contract_address: Option<Address>,
    pub info: String,
    #[serde(rename = "TranID")]
    pub tran_id: B256,
}

However, in the function create_transaction:
fn create_transaction(
    params: Params,
    node: &Arc<Mutex<Node>>,
) -> Result<CreateTransactionResponse> {
    let response = CreateTransactionResponse {
        contract_address: None,
        info: "Txn processed".to_string(),
        tran_id: transaction_hash.0.into(),
    };
    Ok(response)
}

The response never contains a contract_address, as it's always set to None.
Is this intentional by design, or is it an oversight? I'm aware of the GetContractAddressFromTransactionID API, but this struct suggests the contract address should be included in the response.
Relevant Code:

Struct definition
Implementation

Linked issue: https://github.com/Zilliqa/gozilliqa-sdk/issues/122

Thank you, @PurrProof, for reporting this. We’ve resolved the issue on both the SDK and ZQ2 sides.

Thank you.
I've found another related issue here:
{
    "id": 0,
    "jsonrpc": "2.0",
    "result": {
        "ContractAddress": "0x7ACb6a641Ad9b3BB9dC947aa019d9B44b4aD572c",
        "Info": "Txn processed",
        "TranID": "0x42d0ddae6ce111353638c12ae2359c84d19e9e59cca751cf5d6d74e0e6bd18d5"
    }
}

There should not be those 0x in the RPC response.
They are not compatible with go-zilliqa sdk (at least):
TxID: 0x0367a73945cbf76f98a1968fd7d15109008a3a74b03b88f165b8f6f7b2bfe7d3
track 0x0367a73945cbf76f98a1968fd7d15109008a3a74b03b88f165b8f6f7b2bfe7d3
Track error: -20:Txn Hash not Present

It happens because gozilliqa-sdk makes such requests:
{
    "id": 0,
    "jsonrpc": "2.0",
    "method": "GetTransaction",
    "params": [
        "0x42d0ddae6ce111353638c12ae2359c84d19e9e59cca751cf5d6d74e0e6bd18d5"
    ]
}

and receives responses:
{
    "error": {
        "code": -20,
        "message": "Txn Hash not Present"
    },
    "id": 0,
    "jsonrpc": "2.0"
}

Moreover, in all examples of the CreateTransaction there are no 0x in response:
zq1
zq2


Issue with misc.ip_loadbalancer

DEBUG:core:Running on CPython (3.8.10/Sep 28 2021 16:10:42)
DEBUG:core:Platform is Linux-5.11.0-40-generic-x86_64-with-glibc2.29
WARNING:version:Support for Python 3 is experimental.
INFO:core:POX 0.7.0 (gar) is up.
This is my command
./pox.py --verbose forwarding.l3_learning --fakeways=<IP_ADDRESS>,<IP_ADDRESS> log.level --DEBUG --openflow=DEBUG  misc.ip_loadbalancer --ip=<IP_ADDRESS> --servers=<IP_ADDRESS>,<IP_ADDRESS>.
L3 forwarding works fine, but as soon as I try a tcp connection (http) from <IP_ADDRESS>  to <IP_ADDRESS> it crashes with:
ERROR:openflow.of_01:Exception reading connection [00-00-00-00-00-01 4]
Traceback (most recent call last):
File "/home/javier/pox/pox/openflow/of_01.py", line 940, in read
h(self, msg)
File "/home/javier/pox/pox/openflow/of_01.py", line 206, in handle_ERROR
msg.show(str(con) + " Error: ").strip())
File "/home/javier/pox/pox/openflow/libopenflow_01.py", line 4043, in show
outstr += prefix + hexdump(self.data).replace("\n", "\n" + prefix)
File "/home/javier/pox/pox/lib/util.py", line 485, in hexdump
data = [ord(c) for c in data]
File "/home/javier/pox/pox/lib/util.py", line 485, in
data = [ord(c) for c in data]
TypeError: ord() expected string of length 1, but int found

This was fixed earlier this year in my repo, but the change hasn't been merged into noxrepo/pox yet.
For the short term, pull from the gar branch of https://github.com/MurphyMc/pox instead.

(Reopening until this actually gets merged.)

Awesome. Thanks a million. We'll try with the code from your repo.

Fix should be in halosaur.


remove block update

old logic for handling updates to blocks, no longer needed now that votes are a separate table. this should have been part of #379 and makes sure #221 still works correctly

[Current coverage][cc-pull] is 89.87%

Merging [#440][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master       #440   diff @@
==========================================
  Files            18         18
  Lines          1274       1274
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           1145       1145
  Misses          129        129
  Partials          0          0

[][cc-pull]

Powered by Codecov. Last updated by [fe136be...5e35cbb][cc-compare]
[cc-base-branch]: https://codecov.io/gh/bigchaindb/bigchaindb/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/bigchaindb/bigchaindb/compare/fe136bea9c6e1e3b2952d7e3e59a0e3963e2dd15...5e35cbb74bb4f8ccfc667ef4cae91da666971d3e?src=pr
[cc-pull]: https://codecov.io/gh/bigchaindb/bigchaindb/pull/440?src=pr

:+1:

@r-marques actually this was a little more involved than I thought. Thanks @vrde for catching this.

good catch

Closing since we moved to pipelines.


[PSRule] Integrate PSRule pre-flight checks with ADO module validation workflows

This is the ADO version of issue #2426.
This is a separate issue wrt the GH one for the following reason:
As noticed during PoC (ref #2026) the PSRule ADO extension prerequisite may be a blocker to adopting the analyzer in ADO pipelines, since the current extension is not released with a Microsoft verified publisher.
A workaround to be discussed for CARML is to replace the action with custom script using PSRule module and cmdlets, getting rid of the extension prerequisite, but likely requiring more effort.
Alternatively, since a new ADO extension is planned to be released with a Microsoft verified publisher, we may want to block this issue until then. This is tracked by https://github.com/microsoft/PSRule-pipelines/issues/513,
A first implementation of this issue for, e.g., the KV module, is hosted by branch hack/topic6. The branch leverages the currently published extension.

Suggestion: apply the needsfurtherdiscussion label.
Discuss if blocking the issue until https://github.com/microsoft/PSRule-pipelines/issues/513 completion

Should be discussed after the other PSRule issues are implemented


removed uuid rpm dependency

Coverage remained the same at 51.094% when pulling eed2fe0b8b1f2b2741136e1c4c05cf492140ccae on compae:bug/remove-uuid into 562deef99b5826dc03f7504dea7bc9f964df92db on Stratio:master.


macos editor bugs

unreleased macOS editor has these bugs:

- i
	-

will cause editor to crash
also this:
+ #

Unexpectedly valid:

test


Come out with a new release and drop <3.3

I think we should have 1.3 release be the last release to support <3.3. We can come out with a new release and stop worrying about <3.3. Just dropping it from pypi.
the new release will just have less python classifiers so when someone pip installs, it will resolve the dependencies accordingly.
A pip install with Python 2.7 will install <=1.3 but a pip install on 3.4 will install >=1.4

This is a pretty simple library with no external dependencies, and maintaining backwards compatibility is easy. I wouldn't want to drop compatibility without an extremely compelling reason.

I've come around on this and am in agreement with you now. The next release should drop support for <3.3.


Support Lotus

Hi,
This pull requests makes bootstrap-sass compatible with the Lotus framework.
https://github.com/lotus/assets

Thanks! You might also want to add this to https://github.com/twbs/bootstrap-rubygem

@glebm Sure, will do :) What's the difference between that project and this one?

@Nerian This one is for Bootstrap 2 and 3, the other one is for the upcoming Bootstrap 4 currently in alpha.

I see :)
Pull request done: https://github.com/twbs/bootstrap-rubygem/pull/17


Add Karma

Ehh, does jasmine support good async testing like mocha's done passed into the callback? Because we're probably gonna need it.

Sure, it does, but it is always better to use spies and mocked time instead.
  it("should support async execution of test preparation and expectations", function(done) {
    value++;
    expect(value).toBeGreaterThan(0);
    done();
  });

Cool, that's jasmine 2.0 right. It's been a while but I recall jasmine being on < 2.0 for quite a while.
Will mocked time work correctly with the new animation loop? Say, I want fine-grained simulation for when the next raf is. And I assume this works in phantom?

Mocking works pretty well. Phantom, yes. I would not submit a PR that does
not work lol :)

:+1:


Add migration db scripts for postgresql

Purpose
Add migration db scripts for postgresql and Upgrade carbon-apimgt version

The following JIRA has been created to address the doc impact.
[1] https://wso2.org/jira/browse/DOCUMENTATION-8117


Use double quotes in npm scripts

This should make it compatible with windows in addition to bash, zsh, etc. E.g. instead of:
"git-commit": "git add -A . && git commit -a -m 'gh-pages update'"

Write
"git-commit": "git add -A . && git commit -a -m \"gh-pages update\""

(also the -a is not necessary)

FTR that didn't work so I opted to remove quotes altogether: 7beb81d2f9b461245443748f2205559ee5c8bc33.


Fix the error License for 1.3 release

Coverage increased (+0.02%) to 56.247% when pulling d3866d4dff22f5114a756138e50602414ccae7c6 on reasonerjt:release-1.3.0 into de8f9f05f8d982c9a8fb4397ed78247e2f3fc253 on vmware:release-1.3.0.


Bruno/document local testing

Facilitate constraints and templates troubleshooting by documenting and tooling how to run local test without deploying to Forseti. Benefits:

Speedup troubleshooting
Reduced complexity by segregating rego code issues from Forseti issues

@morgante do we have docs somewhere for local config-validator testing (without Forseti) ?

@ocervell I'm not quite sure I follow though, because constraint template testing should have no need to look at ancestry info. In fact, constraint template authors should never be inspecting the ancestry_path field at all.
I'd like to understand what part of make test isn't working today for template authorship/debugging.
As for debugging a customer's actual environment, that is best done via go/cft-scorecard.
I do agree the conversion from .dump to .json is potentially useful. Instead of making a whole new script/testing approach, I'd instead suggest we significantly trim down this script to make it a utility for populating test fixtures within the existing testing system/managing that. I don't think we should have two different testing approaches in 1 repo.

@ocervell Got it, I think scorecard should be able to provide that flow.


basic float formatting

[ ] autocomplete

I'm unsure how to proceed here. This seems sensible in principle, but the question is whether we want a more general formatting mechanism.

Like with #1834, I'm not yet sure how we should design number (and possibly) other formatting, but I think it should be a more general mechanism that this. I'm going to close this for now, we can still reopen if the design ends up close to this.


Starborn Ship - Contraband - Item's Stay After FI

On the Starborn Ship you get from NG+, contraband sticks around after paying any fines related to having the items on the ship. Have used multiple kinds of contraband and all have the issue on the ship.

Details
N/A
Game Version
1.10.0
New Game
No
Reproduction Steps
NG+. Starborn Ship. Contraband.

Unable to replicate


Readme

Create Readme to cover several areas

Intro
Getting Started
Individual Hooks documentation
Local development setup
Contributing

I feel the readme is sufficient. Closing issue


issue #9

Method __invoke has 28 lines of code (exceeds 25 allowed). Consider refactoring.

Hi @thanhnt-2075 . We really appreciate your contribution. Unfortunately somebody else made a similar change before you and her change was merged. Don't get discouraged about this, there are many more small changes to be made. Thanks!


Add test suite for Blockly compiler

We current don't test the Blockly -> TS compiler, so we should add something similar to the decompiler test suite. This involves getting Blockly to run in our CLI

Won't fix for now.


More Num methods

Here thery are some additions I had stashed some time ago. Guess now it's time for them to be commited.

I added lots of comments, but thank you for doing these!

Got a lot of homework to do. Better roll up my sleeves and do them. :+1:

:D

Still missing the sign change to adehere with signbit. Will throw a pull request to change this. :+1:

Sounds good. I'd say we should just use signbit(), but I think it's C99-only so I'm hesitant to depend on that. :confused:

Yep, in fact signbit is C99/C++11 only.
Perhaps we could find our way by mean of a union/cast/masking? Sounds too hacky?

Yeah, I'm happy with the solution you already did. :)

All rights, let's keep this then! =D


keep code base clean

Coverage remained the same at 53.843% when pulling cdc52e415831025fda20b80f56f8e5eb697a498d on yuye/file-change into 9417ec3f7dab149b5d7d762c55fd4e000b452af7 on master.


navigation2: 0.3.3-1 in 'eloquent/distribution.yaml' [bloom]

Increasing version of package(s) in repository navigation2 to 0.3.3-1:

upstream repository: https://github.com/ros-planning/navigation2.git
release repository: https://github.com/SteveMacenski/navigation2-release.git
distro file: eloquent/distribution.yaml
bloom version: 0.9.0
previous version for package: 0.3.2-1

I'm attempting to fix the debian generation for nav2_system_tests (http://build.ros2.org/job/Ebin_uB64__nav2_system_tests__ubuntu_bionic_amd64__binary/)  with the issues described here (https://github.com/ros-planning/navigation2/issues/1506).

Awwww yeah, that's what I like to see, all green :dollar:

Wow, great work!


Support Django 4.2

Djoser currently supports Django 4.1: could it also officially support Django 4.2? It might be that it already does and we could just extend CI to test against it.
This replaces #740.

Added.


Add a PDFViewerApplication helper method to center the position after wheel/pinch-zooming

This avoids having to repeat the same code twice, now that we support both wheel- and pinch-zooming.

/botio-linux preview


Value gets out of sync with html view

When you press enter, the value does not match what is seen in the browser (value may not have the line feed where it is in the browser).  Found this workaround to keep them in sync.
  updateValue: Ember.on('keyUp', function(event) {
    this.handleKeyUp(event);
    var v=this.stringInterpolator(this.$().text());
    this.set('value', v);
    this.$().html(v);
  }),

Was this a problem with 0.2.4? I introduced a bug there that sounds similar to this. Can you check if 0.3.0 fixed this?

have not tested it with new updates... will test it and report back

tested the latest build and not an issue.  Awesome job!


Some questions regarding the Akinci Boundary Handling Method

Hello ! ,
From the tutorial https://animation.rwth-aachen.de/media/papers/64/2019-EG-SPH_Tutorial.pdf
If i'm not wrong, the Akinci Boundary Handling method is described in section :
5.1 / One layer of non-uniform boundary samples .
equation (95) is presenting the pressure force computation , where a correcting coefficient is used,
"gamma 2" : equation (96)   ( i think that there is a missing minus sign in equation (96) )
Under the present WCSPH implementation :
1-  i can't find where this coefficient is used for the pressure computation using the Akinci boundary handling method , is that formulation of the pressure force not used ? if yes, is there a reason why not ?
2- If i got it right , in the present implementation of this boundary handling method the pressure is not precisely mirrored since:
ai -=mj*( pi / (densityidensityi) + pj/(density0density0) )* gradW   (TimeStepWCSPH.cpp , line 186) i'd like to know :
why not use  2pi/(densityidensityi) instead of pi / (densityidensityi) + pj/(density0density0) ?
Thank you kindly for your clarifications
Best regards

If i'm not wrong, the Akinci Boundary Handling method is described in section :
5.1 / One layer of non-uniform boundary samples .
equation (95) is presenting the pressure force computation , where a correcting coefficient is used,
"gamma 2" : equation (96) ( i think that there is a missing minus sign in equation (96) )

I see no reason why this term should be negative. Can you explain why you think the equation is wrong?

Under the present WCSPH implementation :
1- i can't find where this coefficient is used for the pressure computation using the Akinci boundary handling method , is that formulation of the pressure force not used ? if yes, is there a reason why not ?

SPlisHSPlasH implements the original paper of Akinci et al. "Versatile Rigid-Fluid Coupling for Incompressible SPH" where no gamma1 or gamma2 is used. The group of Universtiy Freiburg introduced these parameters in their pressure boundaries extension. This extension is not implemented since we developed volume maps, an implicit boundary representation, which allows for more accurate results.

2- If i got it right , in the present implementation of this boundary handling method the pressure is not precisely mirrored since:
ai -=mj*( pi / (densityidensityi) + pj/(density0density0) )* gradW (TimeStepWCSPH.cpp , line 186) i'd like to know :
why not use 2pi/(densityidensityi) instead of pi / (densityidensityi) + pj/(density0density0) ?

This is a small improvement in our code. By deriving the equations in a constraint form, we can find a factor where pressure mirroring is not required anymore. Instead of getting a local approximation at the boundary, we now get a locally exact result. However, it is hard to decribe the whole formulas here.

Hi M bender , thank you for your responses ,

I see no reason why this term should be negative. Can you explain why you think the equation is
wrong?

from the comment right after equation (96) , the same factor "gamma2"  was also derived in section 5.1 / One layer of uniform boundary samples . which means that since the (96) was previously derived in equation (92) using (91) , if you derive "gamma 2" using equation (91) , isn't (96)  negative ? if that's the case then both (92) and (96) are missing a minus sign .

SPlisHSPlasH implements the original paper of Akinci et al. "Versatile Rigid-Fluid Coupling for
Incompressible SPH" where no gamma1 or gamma2 is used. The group of Universtiy Freiburg
introduced these parameters in their pressure boundaries extension. This extension is not implemented since we developed volume maps, an implicit boundary representation, which allows for more accurate results.

i see that "delta" from the original paper of Akinci et al  is computed in the present code, thank you for clarifying that
i also read the volume maps original paper , it's a really great boundary handling method .
the formulation from the tutorial for both the uniform and non-uniform boundary handling should work fine right ? is there an original paper describing that formulation ? or an open source code testing it ? if yes , i'd appreciate more documentation .

This is a small improvement in our code. By deriving the equations in a constraint form, we can find a factor where pressure mirroring is not required anymore. Instead of getting a local approximation at the boundary, we now get a locally exact result. However, it is hard to decribe the whole formulas here.

i think i kind of understand what you mean , is there a paper or some documentation that will clarify the point you are making ?
Best Regards


backend-test: Reach 100% coverage for zerver/lib/create_user.py.

This PR adds tests for zerver/lib/create_user.py to get coverage of this module to 100%.
Related Issue: #7089
GIFs or Screenshots: N/A.

@shikharvaish28 thanks for working on this!  I think if you rebase, you'll see that we actually ended up deleting that option instead in the last few days?
We've been coordinating work on #7089 in
https://paper.dropbox.com/doc/3HjAzwNDXqAno1R9Zzjs9 over the last few days at the PyCon sprints.

Yep, just mark the file or case you want to do in that Paper doc :)


Test 12

Stack from ghstack (oldest at bottom):

-> #17
#16
#15

Signed-off-by: Andrea Frittoli<EMAIL_ADDRESS>

/land


[MAJOR] Add a new role system

Description
A new role system was added in #16. However, all this system did was restrict permissions to certain roles and add a new role for moderators. This is insufficent for big sites, some sites may prefer custom roles.
Changes

Add a new SQL table for roles
Move premium to the roles table
Move verification to the roles table (maybe)
Multiple roles for users (json)

Halted for now


feat(source): add more types for avro

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?

add timestamp-micros and duration support for avro

Checklist
~- [] I have written necessary rustdoc comments~

[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation
Types of user-facing changes
Please keep the types that apply to your changes, and remove those that do not apply.

Connector (sources & sinks)

Release note
user can use timestamp-micros and duration type in avro schema:
{
  "name": "anniversary",
  "type": "long",
  "logicalType": "timestamp-micros",
  "default": null
},
{
  "name": "passed",
  "type": {
    "name": "interval",
    "type": "fixed",
    "size": 12
  },
  "logicalType": "duration"
}

Refer to a related PR or issue link (optional)
None

@neverchanje please take a look at the syntax for the new types

@waruto210 @tabVersion @neverchanje Quick question: Should we document the Avro schema that is supported in RW? Thanks.


aync set callback with non-ZOK status contains bad data

If you get ZBADVERSION or something like that then you still get the node status results but they are complete strange and probably pointing to uninitialized memory.  An example appears below.  Probably should not enumerate the status array if the result isn't ZOK.
zk ::zk status ZBADVERSION czxid<PHONE_NUMBER>726548340 mzxid<PHONE_NUMBER>028592221 ctime<PHONE_NUMBER>724242800 mtime<PHONE_NUMBER>885020773 version 673195558 cversion 538976266 aversion<PHONE_NUMBER> ephemeralOwner<PHONE_NUMBER>248086629 dataLength<PHONE_NUMBER> numChildren<PHONE_NUMBER> pzxid<PHONE_NUMBER>679066144

Merged PR#8


Can const retryIntervalSeconds = 10; be customized?

Hi there!  I'm finding that I'm quickly running out of Github tokens using this action.  Is it possible to customize the retryIntervalSeconds in the yaml script?  Here's the instances where I'd like to customize it:
https://github.com/NextChapterSoftware/ec2-action-builder/blob/main/src/github/github.ts#L95
https://github.com/NextChapterSoftware/ec2-action-builder/blob/main/src/github/github.ts#L132

Hmm, this basically makes 6 API requests/second and since it's an authenticated request it shouldn't cause an issue.
I can make it configurable through the action settings. Would that work ?

Hi there!  Yes, if you could make it configurable, that would be amazing.  Thanks you!

https://github.com/NextChapterSoftware/ec2-action-builder/pull/33
Release 1.8 is out with this change

We're no longer hitting github token limits.  Thank you for this!


The "next in" timestamp for polling is rendered incorrectly as "a day ago"

When logged into brid.gy, the timestamp shown for the next time my webmentions will be polled shows up confusingly as "a day ago". Hovering over it will of course show the real timestamp, which appears correctly to be 30 minutes after whenever the previous poll was, but I'm not sure why it ends up rendering as "a day ago" instead of, in this case, something like "next in 22 minutes":

Odd! Thanks for the report. No clue what's going on here, I'll look.

Added some tracing, looks like a timezone issue here in logs.maybe_link, whee.
DEBUG:root:when 2022-05-08 14:36:41.858503 None
DEBUG:root:when 2 2022-05-08 14:36:41.858503+00:00 UTC
DEBUG:root:now 2022-05-08 21:35:11.888161+00:00 UTC
DEBUG:root:naturaldelta 6:58:30.029658


Add support for tenant MarkNewFilesSensitiveByDefault

Type

[ ] Bug Fix
[X] New Feature
[ ] Sample

Related Issues?
None
What is in this Pull Request ?
Added support for tenant setting MarkNewFilesSensitiveByDefault

Thanks @jensotto !


MAINT: adding gitignore file

This PR is supposed to resolve Issue #49.
This is just adds the default gitignore from the topobank-dev-stack

I would like to open the same PR in the topobank-publication repo, but i don't have the permissions yet.


Better examples

People who are checking out libcompose for the first time might not immediately see its full value. Having a few good examples can go long way with showing some of its potential uses.
On a related note, it might be worth mentioning in the README where libcompose is currently being used (especially since I'm seeing it being used in a few new projects :smile: )

I definitely agree. I've added a "documentation" overall in my TODOs, including godoc and inline example and more standard documentation on how to use and integration with libcompose and such ! :+1:


AL2023 builds fail due to missing ecs-init packages

Summary

Amazon Linux 2023 images fail to build due to missing ecs-init packages.
Description

There are no amzn2023 versions of the ecs-init package in S3.
Supporting Log Snippets

==> amazon-ebs.al2023: Provisioning with shell script: scripts/install-ecs-init.sh
==> amazon-ebs.al2023: + '[' -n '' ']'
==> amazon-ebs.al2023: + '[' -n '' ']'
==> amazon-ebs.al2023: ++ mktemp -d
==> amazon-ebs.al2023: + WORK_DIR=/tmp/tmp.BdnRqUECYj
==> amazon-ebs.al2023: + trap 'rm -rf /tmp/tmp.BdnRqUECYj' EXIT
==> amazon-ebs.al2023: + cat
==> amazon-ebs.al2023: + '[' -z '' ']'
==> amazon-ebs.al2023: ++ uname -m
==> amazon-ebs.al2023: + ARCH=x86_64
==> amazon-ebs.al2023: + host_suffix=
==> amazon-ebs.al2023: + grep -q '^cn-'
==> amazon-ebs.al2023: + ECS_INIT_URL=https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/ecs-init-1.70.0-1.amzn2023.x86_64.rpm
==> amazon-ebs.al2023: + curl -fLSs -o /tmp/tmp.BdnRqUECYj/ecs-init.rpm https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/ecs-init-1.70.0-1.amzn2023.x86_64.rpm
==> amazon-ebs.al2023: curl: (22) The requested URL returned error: 403
==> amazon-ebs.al2023: + rm -rf /tmp/tmp.BdnRqUECYj

Hello @lkinley-rythmos ,
ECS Optimized AL2023 AMIs were shipped starting from ECS init v1.70.1-1 - https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-ami-versions.html. Version 1.70.0-1 is not available for AL2023. Please try with the v1.70.1-1.
curl -fLSs -o ./ecs-init.rpm https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/ecs-init-1.70.1-1.amzn2023.x86_64.rpm

Feel free to re-open this issue if this doesn't help.


Added Dell Update version 4.1.0.

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Have you tested your manifest locally with winget install -m ?

Microsoft Reviewers: Open in CodeFlow

All of the URLs are valid, I believe this is another case of the URL verification failing if there is a query string in the URL. If you cut off everything after the question mark the page 404s, but if you leave the query string on you get a page, so I think that's what's causing the hiccup.
-----------------------------------------------------
Manifest: manifests\Dell\DellUpdate\4.1.0.yaml
-----------------------------------------------------
URI: https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=ckwj2, Validation result: Failed, Http status code: NotFound
URI: https://www.dell.com/learn/us/en/uscorp1/legal_terms-conditions_dellgrmwebpage/art-software-license-agreements, Validation result: Passed
URI: https://dl.dell.com/FOLDER06986434M/1/Dell-Update-Application-for-Windows-10_7CKK6_WIN_4.1.0_A00.EXE, Validation result: Passed

****************************************************************************************
Manifest Content Validation
****************************************************************************************
Status: Completed
##[error] Result: Failed

See #7920 for another instance of this bug.

/AzurePipelines run
running again.  If it fails assign to ashwini.

/azp run

No, @msftbot, wait! This is part of a bug!

Darn, the bug still exists :(.

/azp run

/azp run

gee this @msftbot guy is pretty slow on the uptake.

gee this @msftbot guy is pretty slow on the uptake.

They are hard to train sometimes 🤣


Add support for non-interleaved audio

Hi Tuukka! Sorry to disappear on you, a lot of things have been demanding my attention (as I guess has also been the case with you). Hope all is well :)
I found this message in PulseAudioConvertPortaudioFormatToPulseAudio:
    case paNonInterleaved:
        PA_DEBUG(("PulseAudio %s: THIS IS NOT SUPPORTED BY PULSEAUDIO!\n",

Which is fine, but actually it doesn't matter if pulse audio supports non-interleaved audio because port audio's buffer processor can adapt it for us (so the user deals with non-interleaved samples but pulse audio sees interleaved samples).
There doesn't seem to be a patest case that uses non-interleaved samples so I modified patest_sine_formats - if curious you can find the modified version on my patest-sine-non-interleaved branch.
I also uncovered some problems with the error handling in OpenStream - at first my modified test failed like so:
Assertion 'm' failed at pulsecore/mutex-posix.c:88, function pa_mutex_lock(). Aborting.

Which was OpenStream freeing the entire host api representation on failure causing Terminate to hit this assertion. The first commit fixes this along with several other error handling problems. After that the test fails like so:
An error occured while using the portaudio stream
Error number: -9999
Error message: Unanticipated host error

Which is expected since it's only in the second commit that non-interleaved audio support is added. The patch works because PaUtil_SelectClosestAvailableFormat discards the paNonInterleaved flag - ie. hostOutputSampleFormat will never be non-interleaved.

Nice to have you back. I have also been just using this  and not doing anything else.. I'll take a look at them and comment.

Very clean and welcome changes. One thing mainly it just me thing is can you add {} to one-line ifs after that this is mergable. It think I'll start to push this to main Portaudio because I haven't run in issues for a while.

Ok I've added the {}s. Coding style might become an issue when pushing to main portaudio -- you've used if (...), while (...) etc etc, whereas the portaudio convention uses spaces inside the paren like if( ... ), while( ... ). See https://www.assembla.com/spaces/portaudio/wiki/ImplementationStyleGuidelines

@sqweek thanks to pointing that out. Just a habit of mine but have to convert it to portaudio one.


Prevent users from modifying the special _replication fields

Overview
The _replication_* fields are reserved for couchdb internal usage (indicated by the underscore prefix). Nonetheless the replicator docs are still editable by local admins. In order not to mislead them into thinking that editing these fields has any intentional effect, this PR prevents them from saving an update that changes any of these fields.
Testing recommendations
Try to change these fields as an admin (one without the reserved _replicator role) and confirm it fails.
Related Issues or Pull Requests
N/A
Checklist

[x] Code is written and works correctly
[ ] Changes are covered by tests
[ ] Any new configurable parameters are documented in rel/overlay/etc/default.ini
[ ] A PR for documentation changes has been made in https://github.com/apache/couchdb-documentation

This is a nice usability improvement. One interesting corner case to consider is when users replicate the _replicator database. Then, the updates would seem as if they are coming from the user and not the replicator and the new VDU update would reject those documents. Perhaps that is a cleaner way to handle it, anyway. But it would be an incompatibility.
If validate_doc_update has a replicated_changes | new_edits option passed in, we could allow an "replicated externally" exception for compatibility. After a cursory look I couldn't see if we pass that flag into the VDU callback.

I'm tempted to expand to any property beginning with _replication in case we invent new ones. And should this be inside the if (!newDoc._deleted) section?

A prefix check could make sense. We should probably synchronize it with https://github.com/apache/couchdb/blob/3.x/src/couch/src/couch_doc.erl#L346-L373 and have a prefix check there too?
Putting it under if (!newDoc._deleted) would work.
But, overall, still not sure if this would break replication of the _replicator dbs.  Yeah it is a bit odd to replicate the _replicator db, but it might still be something users do. Those updates would look like user _bulk_doc  updates with new_edits:false flag, and won't have the _replicator role. I don't think we've explicitly considered what should happen in that case across all the combination matrix of old -> new state updates.

we have a general prohibition at https://github.com/apache/couchdb/blob/3.x/src/couch/src/couch_doc.erl#L377 for unknown special fields. I'm not sure it's wise to expand the couch_doc clauses to allow all _replication_-prefixed fields but others can comment if they feel strongly.
replications of _replicator db should be unaffected as the first clause allows any write by a user with the _replicator role.
The PR is trying to prevent users from being misled if they attempt to influence the replicator in undocumented ways.

The _replicator role isn't applied to replicated _bulk_docs writes to the replication endpoints. In that case, the write is indistinguishable from any other user _bulk_docs replicated POST request.
In other words, if user has backed up their replication job on $backup_sever/_replicator/repjob then they replicate $backup_server/_replicator -> $server/_replicator. The _replicator role is not applied when the repjob document is written. It is only applied when the replication app running on $server has started running that job, and wants to do a state update from "triggered" to "failed", for example.
So, this would be one difference in behavior that I am not 100% sure about. Previously users were able to replicate replicator docs in any state, but after this change those documents could be skipped over.
I made a script to demonstrate it https://gist.github.com/nickva/6ad4f7a284fe410d54da5affeb0e43de

It seems to me like there's a potential for a slippery slope into doing full JSON schema checking. I.e. in some context a confused admin may think replacing a property that is a string with an array or other type is meant to have an effect or that this secures against tampering with auditable history. This leads me to wonder if warnings in the fauxton's editor could be extended for more document-type specific checks and admins who edit directly should continue to do so at their own risk?

The _replicator database should not have been user-accessible from the start. We should have put it behind an api endpoint with defined semantics. Too late to change it now, hence the approach in this PR. As for additional testing in fauxton, I'm skeptical. The best place to block unwanted writes is the VDU, which is enforced however the request is made.
If we think there's a risk that this change breaks existing legitimate uses (as @nickva is saying), it might be best not to merge this change.

@lostnet yeah, it might be nice, in general, to have a schema we can export or publish from an endpoint so then Fauxton could use it to validate input.
Specifically for the replicator's VDU, an improvement could be to port the BDU (the Erlang VDU) approach from main. There we have a single module which both validates and parses the replication job.  That reduce duplication, so we don't validate it twice, and, as a bonus, it avoids having to auto-inject the VDU design doc.
https://github.com/apache/couchdb/blob/main/src/couch_replicator/src/couch_replicator_parse.erl
@rnewson One way we could allow replicated changes and disallow interactive edits is by using _revisions field as a heuristic. VDU functions don't get the replicated_changes | interactive_edit flag passed in, but in most cases, we could detect the  replicated changes by the presence of a _revisions = {"start":N, "ids: [Rev1, Rev2, ...]} field. A bit too hackish perhaps?

@lostnet There's no mechanism to send an "advisory" though, otherwise I'd agree. I also don't know what percentage of users edit documents through Fauxton but anything we do here would need to work for those that don't.
The underscore-prefixed fields are reserved for system use (lots of examples of this and is documented). There's enforcement against misuse for most of them because they stem from the erlang code itself. It's been tricky to extend that protection inside documents.
I am not a huge fan of my proposed change, and the motivating case is a user that got caught out by this. It is the first time in my experience of couchdb (circa 11 years) where someone has thought they could edit the _replication_state field to achieve an effect (cancellation, in this case).
@nickva A bit too cute, imo.
We've had a good discussion but perhaps it is best to do nothing.


Gradle dependencies command handling

Just for early feedback to know if thats the right direction. Next step would be to add a direct dependency. For the dependency management equivalent I am thinking of using the version catalogs feature, but thats second or third step.
udpates #1862

Yes, xml manipulation should not be needed. Still thinking of a nice way to do it. The more I tempting using rewrite looks.

Yes, xml manipulation should not be needed. Still thinking of a nice way to do it. The more I tempting using rewrite looks.

So you should extract an interface instead of an abstract class

Ah! 🤦 No I got it, because of the match inside the super class. Yes thats totally nonsense.

@atomfrede : I'm closing this draft since a few PR for gradle support have already been merged, and https://github.com/jhipster/jhipster-lite/issues/1862 has been fixed


Update CMakePresets.json

set 	"CMAKE_SYSTEM_PROCESSOR": "x64" to prevent setup problems with WindowsToolchain

Is this still relevant after #20

I still have this issue with the latest (v0.35.1)

Is this still relevant after #20?

I am not sure, I will check


Create Test Cases for Inventory Automation

Create test cases and get it reviewed

Create test cases and get it reviewed


Update quill-jdbc, quill-jdbc-zio to 3.15.0

Updates

io.getquill:quill-jdbc
io.getquill:quill-jdbc-zio

from 3.10.0 to 3.15.0.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.getquill" } ]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #268.


[SMALLFIX] Improve error propagation in FileOutStream

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Tachyon-Pull-Request-Builder/7638/
Test PASSed.

LGTM


Add file sources

Adding:

json source
yaml source
toml source
compatibility with default pydantic sources (env, secrets)
general code improvements

Codecov Report

Merging #12 (94b767d) into main (a9f0d5d) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              main       #12    +/-   ##
==========================================
  Coverage   100.00%   100.00%
==========================================
  Files            8        15     +7
  Lines          312       462   +150
==========================================
+ Hits           312       462   +150

Impacted Files
Coverage Δ

argdantic/convert.py
100.00% <100.00%> (ø)

argdantic/core.py
100.00% <100.00%> (ø)

argdantic/parsing/__init__.py
100.00% <100.00%> (ø)

argdantic/parsing/actions.py
100.00% <100.00%> (ø)

argdantic/parsing/arguments.py
100.00% <100.00%> (ø)

argdantic/sources/__init__.py
100.00% <100.00%> (ø)

argdantic/sources/base.py
100.00% <100.00%> (ø)

argdantic/sources/json.py
100.00% <100.00%> (ø)

argdantic/sources/toml.py
100.00% <100.00%> (ø)

argdantic/sources/yaml.py
100.00% <100.00%> (ø)

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


removed extra has_static_member_data_modulus_bits

more context:
https://github.com/NilFoundation/crypto3-algebra/pull/73#issuecomment-1046152032


Simplify slurm system

Summary
Remove fetching for allocated nodes when looking for available nodes as it is useless.
Test Plan
Tested with a scenario with 2 consecutive tests such as :
name = "llama_2"
[Tests]
[Tests.1]
name = "llama"
nodes = ["cluster_name-[042,045,047-049,051,059-060]"]
[Tests.2]
name = "llama"
nodes = ["cluster_name-[042,045,047-049,051,059-060]"]
[Tests.2.dependencies]
start_post_comp = { name = "Tests.1", time = 0 }
$ python ./cloudaix.py --mode run --system-config ... --test-templates-dir conf/v0.6/general/test_template --tests-dir conf/v0.6/general/test --test-scenario conf/v0.6/general/test_scenario/gpt/gpt_175B.toml
...
Section Name: Tests.1
Test Name: gpt_175B
Description: gpt
No dependencies
[INFO] Initializing Runner
[INFO] Creating SlurmRunner
[INFO] Starting test scenario execution.
[INFO] Starting test: Tests.1
[INFO] Running test: Tests.1

Hi guys, can you please review this PR ? @TaekyungHeo @amaslenn @srinivas212

@jeffnvidia pl rebase and fix any conflicts.

@jeffnvidia pl rebase and fix any conflicts.

This is done


[Bug] internal audience on property not respected inside external audience endpoint

Describe the bug
I want to have an external audience for an endpoint, but on the endpoint request one of the fields should be internal. When I then generate the docs for the external audience, that field still gets included in the OpenAPI spec when i dont want it to.
To reproduce
Steps to reproduce the behavior:

Create a Fern def that looks something like the following, with an external endpoint containing an internal property:

service:
  auth: true
  base-path: /transact
  endpoints:
    sendTransaction:
      audiences:
        - internal-docs
        - external
        - external-docs
      docs: Send transaction to blockchain
      method: POST
      path: /sendTransaction
      request: SendTransactionRequest
...

types:
  ErrorBody:
    properties:
      message: string

  SendTransactionRequest:
    properties:
      requestId:
        docs: (Optional) ID of the request. Needs to be a valid UUID. If provided, it will be saved and returned as the transactionId of the response. If not provided, we will generate one for you and return it as the transactionId.
        type: optional<uuid>
      projectId:
        docs: ID of the project you want this request to be sent from
        type: uuid
      contractAddress:
        docs: The contract address to send request to
        type: string
      chainId:
        docs: The chain ID for the network (e.g. 1 for Ethereum Mainnet, 137 for Polygon Mainnet, 80001 for Polygon Mumbai). For a complete list of chain IDs, see [ChainList](https://chainlist.org/?search=&testnets=true).
        type: long
      functionSignature:
        docs: The human readable signature to call on the contract
        type: string
      args:
        docs: (Optional) The function arguments for the transaction if any. The keys are the argument names or index from the provided function signature and the values are the argument values.
        type: optional<map<string, unknown>>
      organizationId:
        type: string
        audiences:
          - internal-docs

Run the command fern register
Run the command fern generate --group external-docs
The fields marked internal-docs are still included in the produced OpenAPI spec.
NOTE: might need to have 2 services. See comment below

If relevant, provide a minimal API definition (OpenAPI or Fern Definition) or Docs configuration (docs.yml) that can be used to reproduce the error.
Expected behavior
The internal-docs fields organizationId are not included in the produced openapi.yml file.
Screenshots
If applicable, add screenshots to help explain your problem.
Version
Fern Version: 0.14.3
Additional context
Add any other context about the problem here.

Investigated a little bit with a colleague and there might be some non-determinism at play.

Scenario # 1 - 1 external endpoint, 1 internal property
He had the following:

service:
  auth: true
  base-path: /transact
  endpoints:
    sendTransaction:
      audiences:
        - internal-docs
        - external
        - external-docs
      docs: Send transaction to blockchain
      method: POST
      path: /sendTransaction
      request: SendTransactionRequest
...

types:
  ErrorBody:
    properties:
      message: string

  SendTransactionRequest:
    properties:
      requestId:
        docs: (Optional) ID of the request. Needs to be a valid UUID. If provided, it will be saved and returned as the transactionId of the response. If not provided, we will generate one for you and return it as the transactionId.
        type: optional<uuid>
      projectId:
        docs: ID of the project you want this request to be sent from
        type: uuid
      contractAddress:
        docs: The contract address to send request to
        type: string
      chainId:
        docs: The chain ID for the network (e.g. 1 for Ethereum Mainnet, 137 for Polygon Mainnet, 80001 for Polygon Mumbai). For a complete list of chain IDs, see [ChainList](https://chainlist.org/?search=&testnets=true).
        type: long
      functionSignature:
        docs: The human readable signature to call on the contract
        type: string
      args:
        docs: (Optional) The function arguments for the transaction if any. The keys are the argument names or index from the provided function signature and the values are the argument values.
        type: optional<map<string, unknown>>
      isInternalOnly:
        type: boolean
        audiences:
          - internal-docs

And it worked initially for him. OrganizationId was not in the external OpenAPI def, only the internal one.
However, turns out what we really have is

Scenario # 2 (simplified) - 1 external endpoint, 1 internal endpoint, 1 internal property on each that shares the same name

service:
  auth: true
  base-path: /transact
  endpoints:
    sendTransaction1:
      audiences:
        - internal-docs
        - external
        - external-docs
    sendTransaction2:
      audiences:
        - internal
...

types:
  ErrorBody:
    properties:
      message: string

  SendTransactionRequest1:
    properties:
      otherParam: string
      organizationId:
        type: string
        audiences:
          - internal-docs

  SendTransactionRequest2:
    properties:
      otherParam: string
      organizationId:
        type: string
        audiences:
          - internal-docs

and in this scenario it didn't work, and the internal property organizationId was included in the external docs.
What was really weird is that he then reverted his Fern def back to Scenario 1 exactly, and it now did not work! So maybe something is up with the shared property name organizationId between the external and internal endpoint?

@daniilrrr I am just merging https://github.com/fern-api/fern/pull/2526; I think this should start to address your issues? The only thing worth calling out is that you will need to mark both external and internal properties for filtering to work
  # Only organizationId is included when you filter to `internal-docs` audience
  SendTransactionRequest2:
    properties:
      otherParam: string
      organizationId:
        type: string
        audiences:
          - internal-docs

Fixed in https://github.com/fern-api/fern/pull/2526. If anyone runs into this issue, feel free to reply and re-engage!


Conflicts in resolving dependencies

Running "flutter packages get" in TestProject...
Because every version of just_jwt depends on pointycastle ^0.10.0 and pointycastle >=0.10.0+2 <1.0.0-rc1 depends on reflectable ^1.0.1, every version of just_jwt requires reflectable ^1.0.1 or pointycastle >=0.10.0 <=0.10.0+1.
And because pointycastle <=0.10.0+1 depends on reflectable ^0.5.1, every version of just_jwt requires reflectable ^0.5.1 or ^1.0.1.
Because reflectable >=0.5.3 <1.0.1 depends on analyzer ^0.27.2 and reflectable >=0.5.1 <0.5.3 depends on analyzer 0.27.1, reflectable >=0.5.1 <1.0.1 requires analyzer 0.27.1 or ^0.27.2.
Thus, every version of just_jwt requires analyzer 0.27.1 or ^0.27.2 or reflectable ^1.0.1.
Because reflectable >=1.0.1 <1.0.4 depends on analyzer >=0.27.2 <0.30.0 and reflectable >=1.0.4 <=2.0.0-dev.1.0 depends on path >=1.2.0 <1.5.0, reflectable >=1.0.1 <=2.0.0-dev.1.0 requires analyzer >=0.27.2 <0.30.0 or path >=1.2.0 <1.5.0.
Thus, every version of just_jwt requires analyzer 0.27.1 or >=0.27.2 <0.30.0 or path >=1.2.0 <1.5.0.
And because every version of flutter_test from sdk depends on both analyzer 0.31.2-alpha.2 and path 1.5.1, flutter_test from sdk is incompatible with just_jwt.
So, because TestProject depends on both just_jwt ^1.3.1 and flutter_test any from sdk, version solving failed.

pub get failed (1)

@techyrajeev Feel free to do a PR. I didn't use Dart for a while.


feat: add get_opt and take_opt to row

It's useful to have a non-panicking way to get column values from a row. Nullable columns seem to fail with the traditional .{get|take} methods.

Hi! Sorry for late response. I'm on vacation at the moment.
I don't like it because with this approach there is no way to distinguish between conversion error and value absence. Also from_value_opt gives a way to recover original value in case of error but take_opt does not.
BTW there exists impl<T: FromValue> FromValue for Option<T> specifically for nullable columns. All other conversion errors is for cases when type is wrong and does not match column type (i.e. programmer's error) or column type is unknown and one wants to probe it (which is possible but quite unusual).

I don't like it because with this approach there is no way to distinguish between conversion error and value absence.

Yeah in hindsight blindly converting to an option with .ok wasn't the best idea.

BTW there exists impl<T: FromValue> FromValue for Option<T> specifically for nullable columns.

Ah good to know!
There are a few edge cases where I would like to define a default value for a struct field that implements FromRow. In these cases the default value for the application does not match the general case for all of the other applications that use the database so setting a default value for the column is out of the question. Ideally I would be able to intercept Option<T> where T: FromValue so I could call .unwrap_or on Option<T>.
Is there a way to implement that behavior with the current API?

Hi again! My vacation is finally over.

There are a few edge cases where I would like to define a default value for a struct field that implements FromRow. In these cases the default value for the application does not match the general case for all of the other applications that use the database so setting a default value for the column is out of the question. Ideally I would be able to intercept Option where T: FromValue so I could call .unwrap_or on Option.

I'm not sure that i understand you correctly. Could you please give a simple illustration if this question is still relevant?

Hey, I hope you had a nice vacation! I included a simple example below. It's a bit of an edge case but I imagine there are many more uses for such logic. Let me know if you need more context.
// Imagine we have a `posts` table has 2 body columns, one of which is a remnant of
// an old system. Ideally there would be away to fallback to other columns or default
// values that may not be expressed in the database schema.
post.body = row.take_opt("body")
               .or_else(|| row.take_opt("legacy_body_column"))
               .unwrap_or_default();

For this case and if column order is known i'd use FromRow followed by or_else.
let (body, legacy_body) = from_row::<(Option<String>, Option<String>)>(row);
post.body = body.or(legacy_body).unwrap_or_default();

For other cases your approach should work:
post.body = row.take::<Option<String>, _>("body")
               .or_else(|| row.take::<Option<String>, _>("legacy_body"))
               .unwrap_or_default();

I think you're right. (get|take)_opt may be useful symmetric addition to get and take.
Could you please alter return type of both to Option<Result<T, Value>>? Obviously None if value was taken, Err with original value if conversion error occurred and Ok on success.

Ok! I'll update the PR as soon as I have moment. :)

Thanks!
But there is one more thing: documentation still states that None will be returned in both convertion error and taken column cases.

No problem! I updated the docs. Let me know if you would like any additional changes.

Published as v11.3.0. Sorry for delay.

No worries! Thank you! :)


Replicates

We probably need a paragraph about replicates, whether they are combined, analysed/classified independently, how are they normalised, ...

This has now been added


Fixed: Ground truth tracks are displayed not only on GT frames in review mode

Motivation and context

How has this been tested?

Checklist

[x] I submit my changes into the develop branch
[x] I have created a changelog fragment
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (see GitHub docs)
[ ] I have increased versions of npm packages if it is necessary
(cvat-canvas,
cvat-core,
cvat-data and
cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.

Summary by CodeRabbit

New Features

Ground truth tracks are now visible during review mode, enhancing the review process.

Bug Fixes

Fixed the display of ground truth tracks to ensure consistency across different contexts.

Chores

Minor formatting adjustments and comments added for clarity, without impacting functionality.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 74.21%. Comparing base (ea5955a) to head (7088587).

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #8531   +/-   ##
========================================
  Coverage    74.20%   74.21%
========================================
  Files          400      400
  Lines        43207    43207
  Branches      3905     3905
========================================
+ Hits         32063    32066    +3
+ Misses       11144    11141    -3

Components
Coverage Δ

cvat-ui
78.61% <ø> (+0.01%)
:arrow_up:

cvat-server
70.47% <ø> (ø)


GH1816: Sign net46 nuget content

fixes #1816

@devlead your changed have bern merged! Thank you for your contribution!


Add condition to gate deployment on GitHub 'pull_request' event types…

Changes
Add condition to gate deployment on GitHub pull_request event type
Update yaml formatting to be consistent
Update interpolation since ${} is deprecated with Tekton 0.7
Additional Info
The Tekton Dashboard webhooks will now pass an event-headers param into PipelineRuns once https://github.com/tektoncd/experimental/pull/264 is merged to make this deployment condition possible.
The names of Tekton Condition maintains the ContainerId prefix, which is not a valid Kubernetes name, but should be replace as specified by https://github.com/kabanero-io/kabanero-operator/pull/161

We cannot deliver this PR until we have updated the project dependencies in Kabanero -- it is a breaking change that is dependent on Tekton 0.7.0.

@stephenkinder Is this one still blocked? Can this PR be merged now?


Cargo workspaces support

Currently, if cargo-rpm launched from within the workspace root the following error is printed:
error: no [package] section in Cargo.toml!

As I may guess, the workspaces are not supported and for now it's just possible to iterate over necessary crates manually and for each execute cargo rpm build. Would be nice, if it supported from cargo-rpm itself. List of possible subtasks:

new command cargo rpm list that lists projects that has a (valid) .rpm sub-folder at that workspace;
executing cargo rpm init at workspace root inits .rpm for each crate in that workspace, optionally with specified crate list;
executing cargo rpm build at workspace root builds each crate in a workspace (optionally) skipping ones without .rpm sub-folder;
flag -p/--package for selecting a package to work with (i.e. cargo rpm -p mypackage build works the same as changing directory to mypackage package and then launching cargo rpm build).

This sounds like a good plan

cargo-rpm is unmaintained: #96


BUG: check array bounds in csr_todense

Fixes #9253.

this is a demo patch showing how bounds checking could be implemented for scipy routines.  if there are no issues with this approach, i'd be happy to do the same for other routines.  wdyt?

question: this doesn't seem to break BC because csr_todense is imported from a _ module, right?
idea: use some build system magic to never expose _csr_todense and other _* variants to users. instead:
_sparsetools would expose safe wrappers right away.  might be messy since _sparsetools is more about CPP compilation right now, so i just defined a wrapper on the python side to avoid touching that
note: cannot do .size checking on the CPP side (in the routine body) because ndarrays are converted to
regular C arrays by then
note: must do bounds checking in the routine body because there are many cases where indptr (and other attrs) could be modified after an object is already created.  and it's even less practical to try catching all cases like that than the approach presented here

will do some benchmarking later and post results here
cc @rgommers @mattip

there’s also this comment which describes other approaches i’ve tried to mitigate issues like that (tl;dr: i think it’s better to address it in each particular case—in the routine body as shown in this pr): https://github.com/scipy/scipy/pull/14373#issuecomment-1131483590

one potential problem that i see with this patch, that i forgot to mention, is that i use:
    'i':  integer scalar

for sizes.
i guess i should have used this one instead (similar to size_t, which is 64-bit on 64-bit systems):
    'l':  64-bit integer scalar

because if a very large array is allocated, this might lead to overflow issues in the counter.

This approach (or something like it) makes sense to me, so I'd like to see this PR progress if possible.
It's a bit awkward to have to pass the size of each array manually, but we can fix that with a type like std::span and some improvements to the sparsetools codegen. (Note: we can't actually use std::span for a while yet, but it's simple to implement our own version.)

As discussed IRL with @perimosocordiae, adapting C++ implementations for misformatted inputs for invalid inputs add complexity and it might be reasonable to expect that users provide valid inputs that implementations can use.
In this regard, an alternative correction would be to validate the constructor's inputs using the following checks:

indptr is sorted
indptr[0] >= 0
indptr[-1] == len(indices)
np.min(indices) >= 0 (unrelated to resolving #9253).

What do you think, @rgommers?

That sounds quite reasonable to me.

Actually, all those checks already are present in _cs_matrix.check_format:
https://github.com/scipy/scipy/blob/86da5cdd175b2dff2b2aaba31c07eb837a1b88b3/scipy/sparse/_compressed.py#L166-L193
Yet, only some of them are run when full_check=True is passed (which is never the case).
I guess full_check could be an instance attribute instead, allowing callers to perform all the checks when required.
What do you think?

Would adding a piece of documentation indicating that callers are responsible for providing correct inputs resolve and a non-regression test asserting that x.check_format(full_check=True) raises otherwise resolve https://github.com/scipy/scipy/issues/9253?

Sounds good to me.

I will try to address this issue when I get some time.


ModuleNotFoundError: No module named 'flightrl'

Thank you for interesting challenge.
I ran python.run_vision_ppo with the folloing command, but the command says there are no module named flightrl
_$ python3 -m python.run_vision_ppo --render 0 --train 1
Traceback (most recent call last):
File "/home/myworkspace/anaconda3/envs/agileflight/lib/python3.8/runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/home/hamyworkspaceu/anaconda3/envs/agileflight/lib/python3.8/runpy.py", line 87, in run_code
exec(code, run_globals)
File "/home/myworkspace/icra22_competition_ws/src/agile_flight/envtest/python/run_vision_ppo.py", line 14, in
from rpg_baselines.torch.common.ppo import PPO
File "/home/myworkspace/anaconda3/envs/agileflight/lib/python3.8/site-packages/rpg_baselines/torch/common/ppo.py", line 21, in
from flightrl.rpg_baselines.torch.common.on_policy_algorithm import
ModuleNotFoundError: No module named 'flightrl'
I did the following things.(cf. https://github.com/uzh-rpg/agile_flight/blob/main/envtest/python/README.md)

Run ./setup_py.bash with conda environment.
Checked to run well the $ python3 -m python.run_vision_demo --render 1

I have several bugs when run ./setup_py.bash , and I cured these by myself.
If these cause some problem, prease tell me
A. ModuleNotFoundError: No module named 'rpg_baselines.torch'
Based on this issue, I changed f
lightmare/flightpy/flightrl/setup.py from
packages=['rpg_baselines'],
to
packages=find_packages()
https://github.com/uzh-rpg/agile_flight/issues/5#issuecomment-1072016802

@HarukiKozukapenguin
I got the same error with you.
The reason is that the package of rpg_baselines is installed without the upper prefix of flightrl (Please see https://github.com/uzh-rpg/flightmare/blob/master/flightrl/setup.py).
However, https://github.com/uzh-rpg/flightmare/blob/092ff357139b2e98fc92bcdee50f38f85b55246d/flightpy/flightrl/rpg_baselines/torch/common/ppo.py#L21-L23 uses a prefix of flightrl.
A simple workaround is to change https://github.com/uzh-rpg/flightmare/blob/092ff357139b2e98fc92bcdee50f38f85b55246d/flightpy/flightrl/rpg_baselines/torch/common/ppo.py#L21-L23
as follows:
from rpg_baselines.torch.common.on_policy_algorithm import \
    OnPolicyAlgorithm
from rpg_baselines.torch.common.util import plot3d_traj, traj_rollout

and redo https://github.com/uzh-rpg/agile_flight/blob/main/setup_py.bash#L64-L66 in your conda enviroment.

@yun-long
What is the purpose to add flightrl in https://github.com/uzh-rpg/flightmare/blob/092ff357139b2e98fc92bcdee50f38f85b55246d/flightpy/flightrl/rpg_baselines/torch/common/ppo.py#L21-L23?
This breaks the consistence with your rule described in https://github.com/uzh-rpg/flightmare/blob/092ff357139b2e98fc92bcdee50f38f85b55246d/flightpy/flightrl/setup.py#L19

hi @tongtybj
thanks a lot for helping to address the issues.
You are right. there should be no flightrl in the ppo.py

@tongtybj
Thank you so much.
I fixed, and it works well.


Warning: new AudioContext() was not allowed to start

Full message:

audio.js:6 The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page. https://goo.gl/7K7WLu

This blocks recording/playing even after the microphone access permission is given.
Current workaround: Refresh and click anywhere before page loading ends 🤣

Thanks for your reporting @saschanaz! Threre are fixed commit 3ffd637.
It seems to scope problem, and I changed the scope to create AudioContext when click the start button.
Sorry to say that I don't have test code, but I didn't find same Warning after that commit in my devices.

Thanks, it now works on my machine 👍


docs: use action helper in more examples

Thanks for this. Re-running the build

Hmm, seems to be a problem that’s preventing build running. I’ll look into it.

👍


Fix vertex colored flat shading

Motivation and Context
Currently, it is impossible to view a mesh that is flat shaded because this case is being handled incorrectly. Flat shaded meshes show up completely black. This PR fixes that issue.
In addition, the property vertexColored is now removed from PhongMaterialData, as this is not technically a property of a material because it depends on the geometry of the mesh. It has now been changed to a flag for Drawable.
How Has This Been Tested
A flat shaded mesh was loaded into the viewer successfully. If more testing is necessary, please give suggestions.
Types of changes

[ ] Docs change / refactoring / dependency upgrade
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have completed my CLA (see CONTRIBUTING)
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Screenshot requested by @bigbike of a vertex colored mesh. Better before/after pictures will be uploaded later.

Interesting. This mesh is vertex colored mesh for the Replica dataset. We can display it before even without your change.
Can you try the "master" branch on this mesh? I suspect you can display it already.

Just tried it on the master branch, and it's all black:

Interesting. This mesh is vertex colored mesh for the Replica dataset. We can display it before even without your change.

Context on this test model: I provided it to Lawrence. It is a GLB that I created (not the Replica source PLY). I agree that we'd like to see another vertex-colored test model here.

You'll need to add the HasVertexColor flag here https://github.com/facebookresearch/habitat-sim/blob/8ec2ef573a8367670fc7c7ed678f0c8c8ff8ae49/src/esp/assets/ResourceManager.cpp#L1171

You'll need to add the HasVertexColor flag here
https://github.com/facebookresearch/habitat-sim/blob/8ec2ef573a8367670fc7c7ed678f0c8c8ff8ae49/src/esp/assets/ResourceManager.cpp#L1171

I pushed a change that does this, although I'm not sure if this is actually a good idea. It will apply to all instance meshes because currently, there's no way to determine whether it's actually supposed to be vertex colored or not (see the warning comment under the changed line). This is a bigger issue than this PR is trying to address.

Yep, not the job of this PR to address that issue, but currently we default to instance meshes have vertex coloring, so we shouldn't change that unintentionally.

Good job, @ldcWV !
I approved this PR but left a question for you to consider.
Also please wait the CI tests passes.

Pull from master to fix the Habitat-Lab issue.

Wait. Why I cannot see any comments from @eundersander ? I received a lot of comments in email notification. But cannot see any here?
To answer the "invisible" question:
Yes, that model is purple. I confirm it. Sorry I happened to give him a model that looks a bit strange.

Wait. Why I cannot see any comments from @eundersander ? I received a lot of comments in email notification. But cannot see any here?
To answer the "invisible" question:
Yes, that model is purple. I confirm it. Sorry I happened to give him a model that looks a bit strange.

He replied to an already resolved conversation. The thread is the second one in your approval comments.


[SPARK-39334][BUILD] Cleanup Class path contains multiple SLF4J bindings waring when run UTs

What changes were proposed in this pull request?
HADOOP-18088 Replace log4j 1.x with reload4j , this pr change to exclude slf4j-reload4j instead of slf4j-log4j12 for hadoop-minikdc to clean up waring message about Class path contains multiple SLF4J bindings.
Why are the changes needed?
Cleanup Class path contains multiple SLF4J bindings waring when run UTs.
Does this PR introduce any user-facing change?
No
How was this patch tested?

Pass GA
Manual test

run mvn clean test -pl core
Before
[INFO] Running test.org.apache.spark.Java8RDDAPISuite
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/Users/xxx/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.17.2/log4j-slf4j-impl-2.17.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/Users/xxx/.m2/repository/org/slf4j/slf4j-reload4j/1.7.36/slf4j-reload4j-1.7.36.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]

After
no above warings

cc @sunchao

Looks like a change introduced by hadoop 3.3.3
https://github.com/apache/hadoop/compare/rel/release-3.3.2...rel/release-3.3.3

cc @viirya

Could you update the following PR description according to the latest change, @LuciferYang ? We exclude both ones.

this pr change to exclude slf4j-reload4j instead of slf4j-log4j12

For the code change, +1, LGTM.

done

thanks all

LGTM too, thanks @LuciferYang !


No way to provide an alternative formatter for numbers

Expected Behavior

I would like to have some way to use any function to format numbers in tooltips or mini-tooltips. It would suffice to be able to set the valueFormatter property. I have not found a way to do this. Is it? Would you accept a pull request making this property available to the user of the library?
Current Behavior

No way to format numbers without using d3-format.
Possible Solution

Make valueFormatter accessible.
Screenshots (if appropriate):
Context

I am using this library in Angular app and I would like the Angular function (pipe) that I use to format every other number in the app to be used also in tooltips inside britecharts.

Hi @adrm, thanks for the issue!
I see, we didn't think on that use case. I guess it makes sense and we could add it to those components.
If you are so kind to create a PR for both Tooltip and Mini-tooltip, that would be awesome!

Perfect, I'm on it. I wanted to confirm with you that you are ok with this feature before implementing.


Windows Container support

Is your feature request related to a problem? Please describe.
I'm testing running Kubernetes with Windows nodes, so of course i need this tool, but there is no instruction of how to build and run this in a Windows container.
Describe the solution you'd like
A instruction of how to build this on a windows container and preferably a pre-build container on docker-hub
A instruction of how to deploy this on a mixed Linux/Windows Kubernetes cluster.
Describe alternatives you've considered
Building this myself, but then i need to understand how go things are build.
Additional context

It's a good point. I have no experience with Windows Containers, but I'd be happy to assist anyone who'd like to give it a shot.

@seeker89 I'm willing to pick this feature up (because I would like to use it, ofc), but I will warn you up front that making multiplat images for Windows is a bit ugly 🙂

That would be awesome!

I found some windows images on DockerHub (careful: random user), no github project linked: https://hub.docker.com/r/tylloyd/goldpinger

@jkroepke that's @tyler-lloyd who was investigating implementing this. those are very unofficial dev/test images but are probably functional

@jkroepke, @rbtr is right. very unofficial. here is the script I am working with right now. still figuring out how to contribute back to this project. currently running into issues with more recent verions of buildkit. https://github.com/tyler-lloyd/goldpinger/commit/521471175c1270c423a9c6b42be50ac06bee4c74

@tyler-lloyd please let me know if I can assists here. I need them soon and I would not like to copy and own docker images.
I hope @seeker89 and @skamboj are still open for the kind of feature.

Again, can I help here?

@jkroepke - taking a look at your PR! thanks for picking this up!

@tyler-lloyd I found the blog artical which mention the cross OS builds for Windows. But instead using the shell scripts, I modernize the concept by using buildx bake

I saw. The bake stuff is new to me so I'm interested to learn more about it. Do you have a test repository we can pull from that used your new ci tooling?

Sure:
https://github.com/cloudeteer/goldpinger/pkgs/container/goldpinger/143990577?tag=latest
ghcr.io/cloudeteer/goldpinger:latest

hmm @jkroepke @skamboj I noticed the most recent version doesn't have the v prefix on the docker images? (it's 3.9.0 not v3.9.0) https://hub.docker.com/layers/bloomberg/goldpinger/3.9.0/images/sha256-955e43662647e650ef2f918f099e40bab2e0ac4d67c0855ae55652e852c581f6?context=explore

Whoops. Omit the v prefix on docker tags is very common. It's also the default behavior on the metadata-action. Sorry for this. I do not looked deeper on existing version.
In case the v prefix should be ensured, replace
https://github.com/bloomberg/goldpinger/blob/0b96e45e05740a5da24354d05e5c46812b84c06d/.github/workflows/main.yml#L59
with
             type=semver,pattern={{raw}}

Should add the v again


feat: leverage pgbouncer's auth_dbname

Fixes #1383.
An initial draft implementation to discuss

/test limit=local


Unable to use (build/serve) Qwik app that uses Qwik lib

Qwik Version
0.0.34
Operating System (or Browser)
OSX
Node Version (if applicable)
16
Which component is affected?
Qwik Rollup / Vite plugin
Expected Behaviour
Create a trivial lib using the starter.
Create a trivial app using the starter.
npm i the lib to the app.
App should work both in dev and build + serve.
Actual Behaviour
npm run dev in the app works!
But... npm run build doesn't. I've seen various failure modes, the one in this repro is:
Identifier directly after number
file: /Users/kcordes/projects/Qwik/qwik-lib-repro/example-app/src/entry_Counter.js:2:10
1: export { KeQObwj8Uik } from "./keqobwj8uik.js";
2: export { 3L0LnWO3YPk } from "./3l0lnwo3ypk.js";
             ^
error during build:
Error: Identifier directly after number
    at error (/Users/kcordes/projects/Qwik/qwik-lib-repro/example-app/node_modules/rollup/dist/shared/rollup.js:198:30)
    at Module.error (/Users/kcordes/projects/Qwik/qwik-lib-repro/example-app/node_modules/rollup/dist/shared/rollup.js:12555:16)

Additional Information
Repro:
https://github.com/kylecordes/qwik-lib-repro

Related hint, but harder to reproduce: in a more complex scenario that also fails, I get an error message "Computing file stem for" with no filename listed. That error came from inside the Rust code, while the error in this repro seems to come from a file naming problem in the JavaScript output.

looking into it with highest priority, i think i know what is going on!

https://github.com/BuilderIO/qwik/pull/743

Fixed!

@manucorporat it appears the publish of this commit failed:
https://github.com/BuilderIO/qwik/actions/runs/2642623742
... I'll look for another way to update the repro and verify.

With link I was able to get past the above error, to a different one:
src/components/app/app.tsx:8:5 - error TS2307: Cannot find module<EMAIL_ADDRESS>or its corresponding type declarations.

... but I think might be an artifact of link, so I'll wait for a published qwik with the fix above, then retest and report any new error in a new issue.

That was an adventure. Upon running the right build target to locally recompile the Rust code where the fix occurred, and then linking the right dist directory…
I can confirm this issue is fixed.


Turns missing pr in workflow_run into warning.

Sometimes (quite often really) when PR gets approved, the PR
gets merged rather quickly, without waiting for result of this
action. Or a new PR gets pushed quickly. In those cases PR will
not be found. But this is usually not a problem then and rather
than failing, we should simply print a warning and exit.

@TobKed  -> I think there is a problem with running locally the pre-commit to package the JS. Not sure how you run it before but seems that my home dir lands in the generated code (/home/jarek/code/label-when-approved-action) and it messes up with the pre-commit run on CI.
How did you generate it before :)?

@potiuk I found installing node modules with npm ci (as it done in CI) solves the problem of differences between local and CI pre-commit.


Issue with creating azure external stage -- azure_sas_token is mangled when passed in as variable.

I have an 'always' script that is responsible for replacing an external stage with a new SAS token on each deployment.  The stage url and sas token are passed in as variables, and they get passed in correctly, but upon execution, the sas token seems to be getting double-encoded.
Below is my script:
use schema "PUBLIC";

-- will always run, updating SAS token for stage on each deploy.
create or replace stage foo_stage_extern
    url = '{{foo_stage_url}}'
    credentials=(azure_sas_token='{{foo_stage_sas}}')
    file_format = foo_csv;

The log when running shows the sas token was passed into schemachange correctly:
Using variables {
  'foo_stage_sas': '?sv=2020-02-10&ss=bf&srt=sco&sp=rwdlac&se=2031-11-13T15:50:49Z&st=2021-11-15T15:50:49Z&spr=https&sig=signature',
  'foo_stage_url': 'azure://storageaccountname.blob.core.usgovcloudapi.net/foo-staged-files'
}

But the actual executed sql appears to be encoding the variable (note the & in place of the & for the query string):
create or replace stage foo_stage_extern

    url = 'azure://storageaccountname.blob.core.usgovcloudapi.net/foo-staged-files'

    credentials=(azure_sas_token='?sv=2020-02-10&ss=bf&srt=sco&sp=rwdlac&se=2031-11-13T15:50:49Z&st=2021-11-15T15:50:49Z&spr=https&sig=signature')

    file_format = foo_csv

Looks like schemachange is using automatic html escaping with Jinja, which is not the default behavior of Jinja according to the docs.
If anyone else runs into this, see:  https://jinja.palletsprojects.com/en/3.0.x/templates/#working-with-automatic-escaping
I was able to fix this with:
use schema "PUBLIC";

-- will always run, updating SAS token for stage on each deploy.
create or replace stage foo_stage_extern
    url = '{{foo_stage_url|safe}}'
    credentials=(azure_sas_token='{{foo_stage_sas|safe}}')
    file_format = foo_csv;

Looks like this was bad behavior within v3.3.2
Also looks to be fixed in v3.3.3 according to #92
see: https://github.com/Snowflake-Labs/schemachange/issues/92#issuecomment-964522116
and: https://github.com/Snowflake-Labs/schemachange/issues/92#issuecomment-964563914

Yep, this has been fixed and published in v3.3.3.


fio-d: Implement servers as a list to loop through

Pushing fio to find system limits usually involves ramping up the parallelism of worker jobs. You can do this via threads per worker (which should also be implemented as a list; separate issue), but it is often valuable, particularly for a distributed storage SUT, to increase the total number of workers in order to get past any per-worker bottlenecks and properly saturate the storage system.
Implementing the servers key in the CR as a list would allow us to iterate through server counts as an outer loop to samples. This is a bit complicated with the current implementation of the fio-d role as we first run an ansible task to spin up the number of workers as fio server pods before executing the fio job task. So we would need to be able to spin up servers, run a job, increment the number of servers, and then run the subsequent job from the server list.
One option is to use the highest value from the servers list and spin up a number of server pods once equal to that maximum value, that way only the fio job task needs to be looped. The downside is that the server pods unused for the lower-value jobs will still be consuming resources in the k8s system and could potentially skew the results.
Another option may be to implement this loop at the playbook.yaml level, similar to the original proposed method for implementing the samples feature.

One option is to use the highest value from the servers list and spin up a number of server pods once equal to that maximum value, that way only the fio job task needs to be looped. The downside is that the server pods unused for the lower-value jobs will still be consuming resources in the k8s system and could potentially skew the results.

@bengland2 @jtaleric @dustinblack what do you think about the above mentioned methodology?

One option is to use the highest value from the servers list and spin up a number of server pods once equal to that maximum value, that way only the fio job task needs to be looped. The downside is that the server pods unused for the lower-value jobs will still be consuming resources in the k8s system and could potentially skew the results.

@bengland2 @jtaleric @dustinblack what do you think about the above mentioned methodology?

I'm generally comfortable with this, but have only a minor concern when it may mean that hundreds or thousands of server pods are pre-spun, waiting for workloads initiated from the clients. If we think of these as just idle processes and ports, it doesn't seem like a major concern. But we could possibly get into impacts at the k8s api level or the large number of pre-created PVs that could skew the results.

@dustinblack I don't see a problem in principle with starting up the servers, once.    fio servers don't generally consume significant resources unless a job is running.   But are we over-thinking it?   Let's just get it to run at all, then see whether this really helps elapsed time of the test.    In real world, you have to run fio jobs for long enough that the system reaches equilibrium and can't cache the dataset, so I doubt this is going to determine test's elapsed time.


Move to new V8 building system

https://github.com/v8/v8/wiki/Building with GN

See also https://github.com/cowboyd/libv8/issues/228

We are moving away from building V8 inside PyMiniRacer, thanks @Lothiraldan


DPP 0.22 Updates

Identity Public Key Purposes and Levels

Codecov Report

Merging #30 (6dab72f) into master (d28607d) will increase coverage by 0.92%.
The diff coverage is 59.77%.

@@             Coverage Diff              @@
##             master      #30      +/-   ##
============================================
+ Coverage     45.00%   45.92%   +0.92%
- Complexity      224      242      +18
============================================
  Files            82       84       +2
  Lines          1431     1511      +80
  Branches        233      243      +10
============================================
+ Hits            644      694      +50
- Misses          662      683      +21
- Partials        125      134       +9

Impacted Files
Coverage Δ

...org/dashj/platform/dpp/identity/IdentityFactory.kt
13.20% <0.00%> (-1.69%)
:arrow_down:

...on/errors/PublicKeySecurityLevelNotMetException.kt
0.00% <0.00%> (ø)

...ransition/errors/WrongPublicKeyPurposeException.kt
0.00% <0.00%> (ø)

...p/statetransition/StateTransitionIdentitySigned.kt
57.69% <27.27%> (-8.17%)
:arrow_down:

...g/dashj/platform/dpp/identity/IdentityPublicKey.kt
75.00% <80.32%> (+12.83%)
:arrow_up:

...dpp/identity/errors/EmptyPublicKeyDataException.kt
100.00% <0.00%> (+100.00%)
:arrow_up:

Continue to review full report at Codecov.

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


Prebuilt .whl and .conda of torchvision for aarch64 + cuda

🚀 The feature
torchvision provides prebuilt binaries for aarch64 + cuda on linux for pip and conda
Motivation, pitch
pytorch now provides aarch64 cuda prebuilt binaries in 2.4.0 (https://github.com/pytorch/pytorch/issues/134117) but currently torchvision doesn't provide corresponding prebuilt binaries. It makes very hard to adopt torch on aarch64 + cuda environment, which is often much cheaper in cloud providers.
Alternatives
Build torchvision from source, which is not ideal for users of this library since it requires lots of work.
Additional context
Some relevant discussion here: https://discuss.pytorch.org/t/cuda-pytorch-package-manager-on-gh200/208582

Did you solve this question?


Add AR file format support

Hi,
I had to write my own ar archive writer because the CL-land doesn't have one, afaik. Would you be interested in adding this feature in archive? The format is very similar to tar, so my guess would be that a lot of code could be reused.

Sure, wider format support is always appreciated!


Move the proxy to the last step of pipeline

This moves the proxy step to the last step of the pipeline, which should allow users to properly configure and use the proxy.
cc @mikeharder

@jonathandturner Can you point to any discussions around why the move is required for the proper configuration of proxy to work?

cc @bterlson

I logged #5020.

Did some digging with @jeremymeng, looks like this is because of the retry policies. The retry policies use clone() to duplicate the request object, and clone() forgets to copy over the proxySettings property. The right fix here is to fix up clone I think!

I agree with @bterlson that the fix should be in clone()

I submitted PR #5047

Closing now that #5047 is merged.


Blinkt! only supported on Linux

I'm working on a PR to add Blinkt! support to blinky, but it turns out the blinkt Gem has dependencies that are Linux-only (and very Linux-only, relying on kernel functionality not present in other OSs).
Assuming non-Linux OSs are important targets for blinky (e.g. mention of Windows in the docs), I wonder how to proceed here.
There's an open issue on bundler about supporting OS-specific groups, but no progress as of yet.
I guess I could always maintain a Blinkt!-specific fork, but that feels a bit hacky.
Thoughts?

I think we discussed this in person and it turned out Blinkt! was not a USB light, so it isn't really playing in the same sandpit as blinky anyway?


Random ShortURLs error

Plugin Random ShortURLs has an error on its code, after activate it not working properly.
After review plugin.php code the filter assignation seems to be wrong, it says:
yourls_add_filter( 'random_shorturl', 'ozh_random_shorturl' );
After replacing to:
yourls_add_filter( 'random_keyword', 'ozh_random_shorturl' );
Plugins works as expected.

Thanks for opening this issue, @garanda21!
You're right. Could you open a pull request with this change?
Thanks! 👍

Thanks @garanda21

Lol, I must have messed up a global find-and-replace long ago when first migrating that plugin to core. Thanks!

Glad to help!


Containers with underscore (_) in the name not appearing in ShellHub

Description
It seems that the hostname of the SSHID does not support the underscore (_) character.
Edition
Community
Version
master

@gustavosbarreto, what should the new rule for the name?
I think it is good opportunity to strengthen that validation.

Docker's pattern doesn't include a limitation to that property.
https://github.com/moby/moby/blob/master/daemon/names/names.go


Preparing Easymock for a future upgrade.

Easymock 4.0 changed EasyMock.createMock's signature in a backwards incompatible way from .createMock(Class<T> clazz) to .createMock(Class<> clazz).  This requires adding an explicit generics type to be set.
Easymock 4.0+ doesn't support Java 7, so we can't immediately upgrade.  This PR future proofs Easymock upgrades once we no longer have to support Java 7.

Looks like easymock 4.0 no longer supports Java 7

@chingor13, I reverted the pom.xml changes, but kept the generics changes in the code.  Can you PTAL?


Content-Type check doesn't account for optional "charset" parameter

The W3C Recommendation for SSE states that the Content-Type Heder field should be text/event-stream (which you're checking) but it also states that you may optionally include the charset parameter along with it.
So a full response-header looks like this: Content-Type: text/event-stream; charset=utf-8
The current implementation in EventSourceChannelHandler does not account for this, since it uses Matcher.matches(), which:

Attempts to match the entire region against the pattern.

While the regex itself should allow extra data at the end (or beginning), the matches()-function will always try to match the entire input against the specified regex, which fails if there is extra stuff in there.
Fixes
Option A) Change the regex to something more lenient: *:Content-Type: text/event-stream*.
Option B) Use the find()-method instead.

I'll go ahead and update this in my next commit. Thanks.

Applied fix in latest commit.