Add additional clean function for prometheus metric names

Issue description
With hostnames having dash in name and fabio using prometheus metrics, I'm running into the issue like:
2022/08/24 21:21:47 [INFO] Registering metrics provider "prometheus"
panic: descriptor Desc{fqName: "vol-client-1_fabio_route", help: "", constLabels: {}, variableLabels: [service host path target]} is invalid: "vol-client-1_fabio_route" is not a valid metric name

goroutine 1 [running]:
github.com/prometheus/client_golang/prometheus.(*Registry).MustRegister(0xc00

It is indeed invalid metric name as there is - in metric name which is not allowed.
With this PR there is another function added alongside clean called clean_prom and used in prometheus provider.
Other option would be changing clean function directly but that can break the existing environment with the upgrade.
Therefore, adding additional function is safer.
If this approach is fine - I'll update documentation as well, but first want to get feedback if I'm missing something or this approach is too simple to solve the issue

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

So overall I like the idea, but one thing that might be an improvement would be to handle the case where a hostname starts with a numeric character, as was encountered here:
https://github.com/fabiolb/fabio/issues/878

The way I handled it for my issue is by fixing this prefix with templating.
I'm using Fabio with Nomad and Consul, so for the Fabio config I just added
      template {
        data = <<EOF
[[- $hostname := env "HOSTNAME" ]]
...
metrics.target=prometheus
metrics.prefix = [[ $hostname | replaceAll "-" "_" ]]_{{ `{{clean .Exec}}` }}
EOF
        change_mode = "restart"
        destination = "local/fabio.cfg"
        left_delimiter = "[["
        right_delimiter = "]]"
      }

@nathanejohnson so you say we should leave it as it is and allow users to handle this issue by explicitly adjusting metrics.prefix?

that is certainly an option.  Regardless, since this has come up twice now, the docs could be clearer that metrics.prefix is still in play with prometheus, and maybe make mention of how picky prometheus is.  I will take that as as to-do for myself.  But I do like your clean method as well.

@nathanejohnson I somehow forgot about this. So do you think this still makes sense or just docs update enough?


Apparent shortcoming in current design of Schedule fragment

Actual Behaviour
Currently the Schedule Fragment has dates as tab titles just like in 'Google I/O 2016' app.
However, since we are aiming at generating a generalised event app, if a particular event is longer than just 3 days, let's say, 15 days long, then the app layout will become very untidy.
Expected Behaviour

We could use an overflow menu button that will contain all the dates of the event as a drop-down menu. Choosing a particular date from the menu will lead to the schedule for that particular date.

Alternatively, We could include a drop-down calendar and the schedule of the date selected on that calendar will show up on the screen.

Screenshots of the issue

Would you like to work on the issue?
Yes.

@mariobehling @mananwason @the-dagger Is this intended?

Last I checked, the TabBar is scrollable. Even if we have a 15-day long event we can scroll the tabs.
@mahikaw What do you think?

@free4murad sure we could, but I was wondering how clustered it will look in that case.
It's just a suggestion. I will be willing to work only if this is intended.  :)

The tab won't look clustered as only 3-4 tabs will be visible and rest will be accessed via scrolling.
Nevertheless, it better to try to see what will happen in that case

We can have a scrollable tablayout, so it won't be an issue.
@mahikaw If you want, change the following attribute to scrollable and send a PR to fix this up.
https://github.com/fossasia/open-event-android/blob/development/android/app/src/main/res/layout/fragment_schedule.xml#L21

@mahikaw ideally you should wait for the PR to be merged before closing the issue.
Please don't close it beforehand.

I'm sorry. I will take care in the future. 👍


stable/promethus-operator

Describe the bug
Installing prometheus-operator helm chart errors out during installation part, even when including the CRDs as outlined on their repo.
Version of Helm and Kubernetes: helm version version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"dirty", GoVersion:"go1.14.3"}
kubectl version  Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.4", GitCommit:"8d8aa39598534325ad77120c120a22b3a990b5ea", GitTreeState:"clean", BuildDate:"2020-03-12T21:03:42Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:07:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
Which chart:
stable prometheus-operator
What happened:
Error: failed pre-install: timed out waiting for the condition
What you expected to happen:
Install correctly
How to reproduce it (as minimally and precisely as possible):
helm install  prom-operator stable/prometheus-operator --set prometheusOperator.createCustomResource=false --namespace monitoring
Anything else we need to know:

have you checked the monitoring namespace exists? (must be created first with helm 3)
ive just used the chart on my k3s cluster with no issues

🚧 This chart is now deprecated.
Further development has moved to prometheus-community/helm-charts. The chart has been renamed kube-prometheus-stack to more clearly reflect that it installs the kube-prometheus project stack, within which Prometheus Operator is only one component.
If applicable, please re-open this issue there. Thanks!


withAsyncContext race condition

Version
3.1.3
Reproduction link
sfc.vuejs.org
Steps to reproduce
Note the rendered text.
What is expected?
It should say 'first - first / second - second'.
What is actually happening?
It says 'first - second / second - second'. The 'second' has jumped to the first component.
getCurrentInstance is returning the second component in both cases.

As withAsyncContext is new in 3.1.3 it isn't necessarily clear whether what I'm doing is allowed. However...
This failure is quite subtle. In 3.1.2 it would have failed obviously and explosively, whereas in 3.1.3 it appears to work and mysteriously yields incorrect values in certain cases.
I haven't stepped through in the debugger but from looking at the code I believe the problem is that the compiled code using withAsyncContext is assuming that the microtask queue is only dealing with a single component at once. My example creates two promises that resolve at the same time, so their microtasks get weaved together in the queue and the currentInstance gets set twice before the setup code resumes.

My fault.
The design I proposed for  withAsyncContext is flawed.
The problem is that withAsyncContext itself returns a promise. It is awaited. Continuation code doesn't run synchronously after it.
What happens in this bug report is:

Comp 1 runs before
Comp 1 saves its context and awaits 7
Comp 2 runs before
Comp 2 saves its context and awaits 7
<then>
Comp 1 restores its state
Comp 1 awaits withAsyncContext itself
<then>
Comp 2 restores its state
Comp 2 awaits withAsyncContext itself
<then>
Comp 1 runs after, it has the second, incorrect, context
<then>
Comp 2 runs after, it has the second context, by chance!
<then>
Vue setup for component 1 completed, it removes context
<then>
Vue setup for component 2 completed, it removes context

As can be seen, the problem is deeper than just withAsyncContext, it also touches on how Vue removes the component after setup completes.
Fundamentally, we would like to run code synchronously, i.e. immediately, when some promises settle.
This is possible on other platforms (e.g. .net) but AFAIK impossible in JS.
I suppose the only solution is to insert those synchronous calls manually in the right places.
For generated code such as script setup, that's no biggie.
But usability of classical script or even async composable functions will suffer a lot.
The high-level concept is that we want this:
const awaitable = ...;
const ctx = saveCtx(); // happens right before await
const result = await awaitable;
ctx.restore(); // must not happen in a Promise, must be right here in sync code
...
clearCtx(); // must not happen in a continuation of this promise, must be right here in sync code

(I'm gonna continue with a revised API proposal)

I'm sharing one failed idea, just in case it inspires someone:
I thought I could subclass Promise into a VuePromise, or just create a VueThenable.
(Subclassing Promise is super-tricky, but doable)
My idea was to set/remove context in .then() just so that it happens synchronously with the continuation itself.
That would have worked wonders, the api could work as-is in 3.1.3.
And it does work in .then()-style code.
But sadly, aync/await is doing crazy shenanigans, you'll never guess the exact sequence in which everything happen.
Long story short, the resolve callback that is passed to .then() is not synchronously executing user code; it enqueues a micro-task.
So attempting to set/remove context around this callback is not working.
Given this, it seems there has to be some calls in user code to set/remove context at boundary points.
Trying to think what the nicest API to do so could be, but nothing really satisfying comes to mind.

While working on the new proposal I noticed another bug.
If you use the current withAsyncContext in an asynchronous composable function, e.g.:
async function useRemoteSum() {
  const data = await withAsyncContext(fetch("/data"));
  return computed(() => data.reduce((a, b) => a + b, 0));
}

Then the caller of this function (e.g. setup()) will have already lost context when its own withAsyncContext is called.

Here's a new API proposal.
Async code is really tricky, I hope I thought of everything, even if I didn't spell it out fully -- and that's already a very long post. 🤞
I am not a huge fan but I don't have a better idea right now, I tried to balance ease of use and correctness as much as possible...
Far future
Basically what we want is an AsyncLocal from the Async Context proposal (not even stage 1).
If this lands, none of this would be required and everything can be hidden inside Vue.
Until then we need a workaround. Quote from that proposal:

While monkey-patching is quite straightforward solution to track async tasks, there is no way to patch JavaScript features like async/await. Also, monkey-patching only works if all third-party libraries with custom scheduling call a corresponding task awareness registration like AsyncResource.runInAsyncScope. Furthermore, for those custom scheduling third-party libraries, we need to get library owners to think in terms of async context propagation.

General idea
ctx = new AsyncContext() captures the current async context.
This must happen before nested async functions are called, as they will clear the current context at their await point.
ctx.async(awaitable) unsets context.
It returns an object with a result getter, which will be responsible for restoring context.
The key insight here is that result is read inside the user code.
Doing it this way rather than adding a ctx.restore() call means: one less call; and less likely to be forgotten as you can't use the returned value without it.
At the end of an async component setup, users must explicitely call ctx.end(), which unsets the context.
We can't leave this responsability to Vue itself, because other micro-tasks can run between the setup completion and the Vue continuation.
For convenience in functions that return an expression (see useAsync example below), it can passthrough a parameter ctx.end(42) == 42.
Explicit Resource Management is a stage 2 proposal that could make this better. If it lands, ctx.end() would not be necessary anymore if you declare it with using const ctx = new AsyncContext() instead.
About effectScope()
effectScope() is not finalized so things will have to be adjusted to take it into account if an effectScope can be asynchronous.
Basically, the effectScope callback should follow the same rules as setup function.
API
class AsyncContext {
  #ctx = getCurrentInstance();

  async<T>(awaitable: T | PromiseLike<T>) {
    setCurrentInstance(null);
    return Promise.resolve(awaitable).then(
      value => ({ get result() { setCurrentInstance(this.#ctx); return value; } }),
      error => ({ get result() { setCurrentInstance(this.#ctx); throw error; } })
    );
  }

  end<T>(result?: T) {
    setCurrentInstance(null);
    return result;
  }

  // If one day Explicit Resource Management lands, we could add the following:
  [Symbol.dispose]() { this.end() }
}

Example usage
This is what is required in hand-written code.
The nice thing about script setup is that all of this can be automatic.
async setup() {
  const ctx = new AsyncContext();
  // ... do stuff
  const { result: data } = await ctx.async(fetch("/data"));
  // ... do more stuff with data
  ctx.end();
}

// Async composable function

// 1. If no Vue function is called after await, then nothing special needs to be done.
//    This is a tricky situation, though.
//    You must be sure that neither your code, nor any transitive function you call, needs Vue context.
useAsync() {
  // Vue API before async call is ok.
  const result = computed(() => 42);
  // No need for context preservation if context isn't used after the async call
  await delay(10);
  return result;
}

// 2. If Vue context is required after await, AsyncContext must be used.
useAsync() {
  const ctx = new AsyncContext();
  const a = computed(() => 42);
  const { result: _ } = await ctx.async(delay(10));
  // Do more Vue stuff
  const b = computed(() => a + 1);
  return ctx.end(b);
}

Pitfalls and safeguards

Any async code that uses context-aware Vue functions needs to create an AsyncContext.
setup and effectScope could use a flag to check if an AsyncContext has been created when a Promise is returned, and warn in dev. This isn't perfect and induces:
(a) False negative for nested async function calls, we can only check if at least one AsyncContext was created. Docs and linters can help here.
(b) False positive for the case where an async setup doesn't require context after its first await. That's technically ok but it might be good to force context usage to be on the safe side anyway.

ctx.end() must be called.
Assuming 1st created context during setup or effectScope is captured, we could check when the promise settles if end() was called and warn in dev if it wasn't.
Impossible to check in composable async functions, but docs and linter could help.
setup and effectScope should still remove the current context when the they first return, and when the promise settles, for extra safety or the case where an async function doesn't need to preserve its context.

ctx.async() must be called at async points. This can be validated in the same way as 4 below.

ctx.async().result must be read.
This is a natural thing to do, except for void functions where you could do this: await ctx.async(delay(10)).
We could check for that in dev by having the next ctx.async or ctx.end call check if there's a context set.
If the context is null then something is amiss.

This all assumes async setup don't crash in normal operation.
Otherwise the next ctx.async() or ctx.end() won't be called and the context will not be cleared. This can lead to subtle errors as there's a small window where micro-tasks will see a set context, until Vue clears it because the promise has settled.
A function that can crash in normal operations should use a try..finally to ensure ctx.end() is called.

Thanks for the research into this @jods4 - I think it's ok for the API to be a bit unwieldy as long as it is easy to automatically generate.
It isn't that much a burden for userland composition functions to ensure proper placement of await - in fact I'd say it's good to discourage await in composition functions in general as it makes it too easy to create serial awaits that makes the suspense tree render appear slower.

@yyx990803 03e2684 is not a complete, proper fix.
I noticed:

You can't restore context in case of failure inside a .catch().
That's like restoring context in case of succes inside .then().
The continuation of .catch() runs in a micro-task so anything could run inbetween.
Restoring the context has to happen sync inside the user code.

I don't see a call to clear the context at the end of setup.
You can't rely on Vue runtime to do so, because anything can run inbetween the end of setup and the runtime continuation.

Capturing the context right before the expression that is awaited can lead to code patterns that mysteriously won't work, such as:

let promise = fetchData();
let data = await promise; // context is already lost here

That's why I chose captured the state once at the beginning of code.
More thoughts on advanced patterns
I realized that for code patterns that manipulate promises without using await (could be as simple as a .then()), transformations can't be fully automated and something needs to be added to script setup to support them fully.
(Of course, await should be encouraged to keep code simple and correct.)
Here's some code that tries to fetch three things in parallel:
const promises = [fetch(1), fetch(2), fetch(3)]
const [data1, data2, data3] = await promises;

Using the API I proposed, it's possible to write the following code manually:
// at beginning of method
const ctx = new VueContext();

const promises = [
  ctx.async(fetch(1), /*stayInContext:*/ true),
  ctx.async(fetch(2), true),
  ctx.async(fetch(3), true),
];
const { result: [data1, data2, data3] } = await ctx.async(promises);

// at the end of method
ctx.end();

But that can't be a fully automated transformation, because of the fetch calls without immediate await.
This kind of advanced async methods would need an API to help the code transformation.
Maybe the compiler should allow and recognize const ctx = new VueContext() in an async setup method and re-use it instead of injecting its own -> this allows advanced cases where users introduce more calls.
The example above would become, in script setup style:
// Not required in basic case, but is picked up by compiler
const ctx = new VueContext();

// Additional, manual calls
const promises = [
  ctx.async(fetch(1), /*stayInContext:*/ true),
  ctx.async(fetch(2), true),
  ctx.async(fetch(3), true),
];

// await is handled by compiler itself
const [data1, data2, data3] = await promises;

// end of setup is handled by compiler

Thanks for the research into this @jods4 - I think it's ok for the API to be a bit unwieldy as long as it is easy to automatically generate.
It isn't that much a burden for userland composition functions to ensure proper placement of await - in fact I'd say it's good to discourage await in composition functions in general as it makes it too easy to create serial awaits that makes the suspense tree render appear slower.

@yyx990803
While I agree that chain blocking should be discouraged, it's easy to shoot yourself in the foot if you have a watch call placed after an await call as it would (rightfully) not warn you being outside of an active instance. Having withAsyncContext being easy to use as an escape plan could be practical in some cases.
The new "fixed" version (https://github.com/vuejs/vue-next/commit/03e26845e2c220b1350a35179acf3435e2711282) makes it almost impossible to use for handwritten code.
Just my two cents after being relieved for this new feature of 3.1.3 :-)


multi-platform image unpacking layer is partial

multi-platform images is not totally unpacked into snapshotter
_output/nerdctl build --platform linux/amd64,linux/arm64 -t buildtest  examples/

root@713d2c6d62f1:/home/nerdctl# _output/nerdctl images
REPOSITORY    TAG       IMAGE ID        CREATED               PLATFORM       SIZE
buildtest     latest    b4dc1770f8fb    About a minute ago    linux/amd64    5.9 MiB
buildtest     latest    b4dc1770f8fb    About a minute ago    linux/arm64    0.0 B

then looking into snapshotter
root@713d2c6d62f1:/home/nerdctl# /home/containerd/containerd/bin/ctr snapshot ls
KEY                                                                     PARENT KIND
sha256:8d3ac3489996423f53d6087c81180006263b79f206d3fdec9e66f0e27ceb8759        Committed

We only have the amd64  layer
but when making some hacks
_output/nerdctl build --platform linux/amd64,linux/arm64 -t buildtest  examples/

_output/nerdctl build --platform linux/arm64,linux/amd64 -t buildtest  examples/

looking at snapshotter
root@713d2c6d62f1:/home/nerdctl# /home/containerd/containerd/bin/ctr snapshot ls
KEY                                                                     PARENT KIND
sha256:07d3c46c9599a88fa81c385391300ab877b98ef71b18cce942455025657edeb5        Committed
sha256:8d3ac3489996423f53d6087c81180006263b79f206d3fdec9e66f0e27ceb8759        Committed

We have both layers amd64 and amr64
@AkihiroSuda
is this the expected behavior  ?
Is it confusing to choose which platform that should be unpacked.

is this the expected behavior ?

Yes
https://github.com/containerd/nerdctl/blob/251ddcef7bac29f53241ed36d38038ed852089bb/pkg/imgutil/pull/pull.go#L85-L93


Wind effect shouldn't use mass

It appears that in sv_propeffects.lua, the wind's force is multiplied by the object's mass. I don't think this is a good idea, as it means that large and heavy objects that should logically be more resistant are pushed by wind just as much as small, light objects that should logically fly off the ground in high winds. Makes the wind effect less interesting and realistic when every unfrozen prop is just gliding in the same direction at the same exact speed.
Considering GetSurfaceArea() is already taken into account, there's no reason to be using GetMass().

https://github.com/Nak2/StormFox/blob/master/lua/stormfox/functions/sv_propeffects.lua#L123 ?


Install-DbaFirstResponderKit - Included TLS protocol override

Type of Change

[X] Bug fix (non-breaking change, fixes #)
[ ] New feature (non-breaking change, adds functionality)
[ ] Breaking change (effects multiple commands or functionality)
[ ] Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
[ ] Adding code coverage to existing functionality
[ ] Pester test is included
[ ] Nunit test is included
[ ] Documentation
[ ] Build system

Changes
Temporarily overrides the default TLS protocol settings to be able to access github.

Didn't we find a cleaner workaround changing the download uri for another function?

ah no, was this one already and the shortcircuit introduced was switching from github.com to codeload.github.com . at this point we may also revert the Uri


Generate winmd bindings in GitHub actions

Depends on #81
Fixes #79
After (re?)discovering @riverar's https://github.com/riverar/washington-rs sample I was both intrigued and inspired to see how easy it would be to generate a .winmd file for DirectX headers, fixing #79.  At the same time I prefer to automate this in GitHub actions for easy and direct access to metadata after changes, which ended up super trivial to implement.
At the same time I primarily use Linux where WinmdGenerator doesn't really work (starting with lots of capitalization discrepancies around sdk/sdk.{props,targets}), having direct access to an automated Windows CI is valuable.
Note that these bindings are generated from IDL (which Microsoft.Windows.WinmdGenerator converts to *.h first) instead of the *.h files checked in to the repo, as that only got me constants but not interfaces.
Bugs to fix

d3d12.cpp fails to generate because of missing DXGI_FORMAT type, unless I add the DXGI compiled headers to TraverseFiles: but this causes the type to also appear under that namespace;

I could <Exclude> the type, but then:
Somehow the various partitions should be able to cross-reference each-other; but none of the official GeneratorSdk samples seem to cover this.

D3D12_BARRIER_SYNC_SPLIT / D3D12_BARRIER_ACCESS_NO_ACCESS use 0x80000000 which result in an odd cast: D3D12_BARRIER_SYNC_SPLIT = unchecked((int)(0x80000000)), that's rejected by the C# compiler: error CS0031: Constant value '-2147483648' cannot be converted to a 'uint'.

Things to discuss

Should we check in .winmd to the repo, similar to how Direct3D Build Agent currently updates the repo, or only leave this file available as artifact in GitHub actions, or something else entirely?
Where to host the Rust code, once the bugs above are solved and my in-progress generator (based on @riverar's washington-rs) gets cleaned up?  Looks like @kennykerr already preempted this and squatted the crate name I wished to use for it yesterday: https://crates.io/crates/windows-directx;

I'll submit my (in-progress) bindings wherever you want it!

@riverar and I started looking into this. It's early days but we are exploring how we might split DirectX from the windows crate in a complimentary way. The challenge with crates.io is that there's no namespace support at present, hence the crate name reservation. We also have a ton of bugs to work through on the win32 metadata side to support layered API sets like DirectX, WDK, etc. We'll share more once we've made some progress, but it may take some time.

Thanks for looking at this! My gut is to keep the .winmd files just as GitHub actions artifacts. Once you get those bugs taken care of, seems like this could be merged ahead of having the Rust side addressed, right?

@jenatali sounds good, thanks! Yes I hope that having some form of .winmd available will help @kennykerr out fixing up the Rust side, unless he already got this far with @riverar :sweat_smile:.
Regardless, we should probably set up a list of things to fix on the windows-metadata Rust generation side, versus the WinmdGenerator side, and see if/how/when/who can address them.

Does this correctly generate winmd entries for functions such as D3D12SerializeRootSignature?
I see it in the generated .cs file:
    public static unsafe partial class Apis
    {
        [DllImport("", CallingConvention = CallingConvention.StdCall, ExactSpelling = true)]
        [return: NativeTypeName("HRESULT")]
        public static extern int D3D12SerializeRootSignature([NativeTypeName("const D3D12_ROOT_SIGNATURE_DESC *")] [CppAttributeList("Name=SAL_name; p1=\"_In_\"; p2=\"\"; p3=\"2\"^Name=SAL_begin^Name=SAL_pre^Name=SAL_notref^Name=SAL_null; p1=__no^Name=SAL_pre^Name=SAL_valid^Name=SAL_pre^Name=SAL_notref^Name=SAL_deref^Name=SAL_notref^Name=SAL_access; p1=0x1^Name=SAL_end")] D3D12_ROOT_SIGNATURE_DESC* pRootSignature, [CppAttributeList("Name=SAL_name; p1=\"_In_\"; p2=\"\"; p3=\"2\"^Name=SAL_begin^Name=SAL_pre^Name=SAL_notref^Name=SAL_null; p1=__no^Name=SAL_pre^Name=SAL_valid^Name=SAL_pre^Name=SAL_notref^Name=SAL_deref^Name=SAL_notref^Name=SAL_access; p1=0x1^Name=SAL_end")] D3D_ROOT_SIGNATURE_VERSION Version, [CppAttributeList("Name=SAL_name; p1=\"_Out_\"; p2=\"\"; p3=\"2\"^Name=SAL_begin^Name=SAL_pre^Name=SAL_notref^Name=SAL_null; p1=__no^Name=SAL_pre^Name=SAL_notref^Name=SAL_writableTo; p1=elementCount(1)^Name=SAL_post^Name=SAL_valid^Name=SAL_end")] ID3DBlob** ppBlob, [CppAttributeList("Name=SAL_begin^Name=SAL_name; p1=\"_Outptr_opt_result_maybenull_\"; p2=\"\"; p3=\"2\"^Name=SAL_begin^Name=SAL_pre^Name=SAL_notref^Name=SAL_null; p1=__maybe^Name=SAL_pre^Name=SAL_notref^Name=SAL_writableTo; p1=elementCount(1)^Name=SAL_post^Name=SAL_valid^Name=SAL_post^Name=SAL_notref^Name=SAL_deref^Name=SAL_notref^Name=SAL_null; p1=__maybe^Name=SAL_post^Name=SAL_notref^Name=SAL_deref^Name=SAL_readableTo; p1=elementCount(1)^Name=SAL_end^Name=SAL_end^Name=SAL_context; p1=SAL_failed^Name=SAL_begin^Name=SAL_post^Name=SAL_begin^Name=SAL_name; p1=\"_Outptr_opt_result_maybenull_\"; p2=\"\"; p3=\"2\"^Name=SAL_begin^Name=SAL_pre^Name=SAL_notref^Name=SAL_null; p1=__maybe^Name=SAL_pre^Name=SAL_notref^Name=SAL_writableTo; p1=elementCount(1)^Name=SAL_post^Name=SAL_valid^Name=SAL_post^Name=SAL_notref^Name=SAL_deref^Name=SAL_notref^Name=SAL_null; p1=__maybe^Name=SAL_post^Name=SAL_notref^Name=SAL_deref^Name=SAL_readableTo; p1=elementCount(1)^Name=SAL_end^Name=SAL_end^Name=SAL_end")] ID3DBlob** ppErrorBlob);

However, when I look at the winmd in ilspy I don't see these functions in the Apis class.

1 red flag I see there is the DllImport attribute is empty. That can prevent the API from being added to the metadata.

Looks like it'll need an options.rsp with --with-libpath entries for all the flat-C entry points.

https://github.com/microsoft/win32metadata/commit/987f01d0ec195f7d0cc4e476125184b3b12d9d78 is an example of a recent bug I fixed with a missing DllImport. We use libmappings.rsp in the SDK metadata.

@damyanp it looks like that function is missing from winmd: https://github.com/MarijnS95/DirectX-Headers/actions/runs/3574278277

I've successfully generated and published an initial Rust crate on top of this PR: https://github.com/MarijnS95/DirectX-Headers/compare/winmd...main
A couple noteworthy items and issues to resolve:
Namespace change to Microsoft.DirectX
@riverar suggested to solve all the import problems by defining the metadata outside of Windows.Win32., under a separate Microsoft. namespace to get rid of super:: imports.
Inter-partition (namespace) references
None of the partitions provided here currently reference each other. Even if we could fix that Dxgi definitions in the windows-rs crate would still be referencing windows-rs Dxgi.Common members, making for an inconsistent/inconvenient API when inevitably mixing the two crates (because this header library doesn't describe Dxgi functionality like adapter enumeration).
:tada: there were at least 3 more issues here, but writing them down resulted in some seriously efficient rubber duck 🦆 debugging :)

Namespace change to Microsoft.DirectX

Can I suggest using Microsoft.Direct3D.* to bring it in line with the naming convention used for the nuget packages that go with these headers?

Hmm, there's some moving parts here that I'm having trouble keeping track of.  This PR seems to generate metadata in the Windows.Graphics.* namespaces, but I think now that maybe the namespace change referred to above is just for the rust bindings generated from this? Or is the namespace change not yet in this PR?
Brainstorming a bit - maybe we should aim to have the metadata generated for interfaces defined in these headers to have exactly the same metadata as the interfaces defined in the Platform SDK / Win32Metadata project?
So, for example, d3d12.h defines the ID3D12Device interface.  This should have exactly the same name regardless of whether or not it came from the Platform SDK or from the DirectX-Headers repo.  The metadata should also at least describe the same ABI, but generally should be identical.
I think that the mental model for using the headers in this repo is that they just replace the corresponding headers in the platform SDK.  It'd be great if we could figure out how to make win32metadata support this.
(I've tried to add this to the discussion at https://github.com/microsoft/win32metadata/issues/998#issuecomment-1400738261).

The headers here are just newer versions of the headers in the SDK right? Eventually they make their way into the OS SDK?
Are these a 100% replacement of the APIs currently in the OS SDK? Should we be working toward removing the equivalent APIs from the base OS metadata package and just declaring a dependency on your package?

Should we be working toward removing the equivalent APIs from the base OS metadata package and just declaring a dependency on your package?

I'd rather these headers just make their way back into the Win32 metadata project where it can continue to canonically represent the latest shape of the Windows API.

Yes, most of these headers are just newer versions of the ones in the SDK, and yes the updates here will eventually make their way into the Windows SDK. There are a few helper headers with C++ inline code that probably don't belong metadata-projected anyway.
That said, the time scale for when that happens is very long, compared to what customers are able to achieve using these headers combined with the "Agility SDK" (i.e. D3D12 redist). Allowing customers using other languages to leverage that increased agility seems valuable to me.

Allowing customers using other languages to leverage that increased agility seems valuable to me.

Indeed, the simplest and fastest way to achieve that goal is to have the headers fed directly into the Win32 metadata project and the various language bindings can be updated immediately with no additional publishing requirements.

One challenge with this is that the Agility SDK has the concept of "preview" releases.  For example, we have a preview of "enchanced barriers", and the APIs are in flux enough that we wouldn't want to just merge them into the mainline of win32metadata.  It'd be great if we could find a way to enable non-C++ users to take part in these previews.
Maybe the answer is to have fork on win32metadata that's ingested the preview APIs?  This wouldn't scale really beyond one component shipping previews like this, but maybe it doesn't have to.

I think metadata can accommodate that multiple ways, such as writing those definitions into a Preview namespace or attributing them with a [Preview] attribute.

I think attributes can get us some of the way to supporting some subset of identified scenarios, but won't get us to the same level of flexibility C++ developers have today with picking up new Agility SDKs.
I realize that this has started to stray a bit off the topic of generating winmd's to go with the headers in this repo.  This repo also doesn't concern itself with preview versions of the Agility SDK.
My summary of where the discussion seems to be heading is that the conclusion is that we shouldn't be generating winmd files from this repo, and the right thing to do is to figure out the best way to get the headers in the win32metadata in sync with this repo?

Added https://github.com/microsoft/win32metadata/issues/1437.

Hmm, there's some moving parts here that I'm having trouble keeping track of. This PR seems to generate metadata in the Windows.Graphics.* namespaces, but I think now that maybe the namespace change referred to above is just for the rust bindings generated from this? Or is the namespace change not yet in this PR?

I've not propagated the namespace changes back to this PR yet (resulting in a CI failure because the manual .cs file does use it...), but did squat the crate name to reserve it for this purpose... if it wasn't for all the followup comments.

That said, the time scale for when that happens is very long, compared to what customers are able to achieve using these headers combined with the "Agility SDK" (i.e. D3D12 redist). Allowing customers using other languages to leverage that increased agility seems valuable to me.

Exactly, we really need immediate access to these Agility SDK headers from Rust. Having a minimal .winmd and generated Rust crate for that (as shown/linked/discussed above!) achieves that for us, at the detriment of overlap with the Windows. namespaces.

I think metadata can accommodate that multiple ways, such as writing those definitions into a Preview namespace or attributing them with a [Preview] attribute.

But does that allow external contributors to do a same-day ingest of DirectX-Headers into win32metadata and regenerate a local windows-rs with it? While you folks worry about a [Preview] annotation to permit breaking changes, I'm worried about keeping the Agility in "Agility SDK for Rust" :). I'm fine dropping this PR (@jenatali don't forget about #81!) as long as there's an easy, documented way for Agility SDK users to do this.

Closing as the published Nuget "Agility SDK" package from this repository is now proactively pulled into https://github.com/microsoft/win32metadata since https://github.com/microsoft/win32metadata/pull/1445, rather than having to generate a separate .winmd and consuming that downstream (in i.e. a custom Rust crate; the Agility SDK is now directly available in windows-rs :tada:).
That said https://github.com/microsoft/DirectX-Headers/releases/tag/v1.610.0 just released an hour ago, curious to see how quickly it gets picked up (if there are any API changes/additions at all...).


Add openmim in requirements/runtime

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.
Motivation
Related to #141
Modification
Please briefly describe what modification is made in this PR.
Checklist

Pre-commit or other linting tools are used to fix the potential lint issues.
The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
If the modification has potential influence on downstream projects, this PR should be tested with downstream projects, like MMDet or MMCls.
The documentation has been modified accordingly, like docstring or example tutorials.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@b7385cb). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #145   +/-   ##
=======================================
  Coverage        ?   62.59%
=======================================
  Files           ?       63
  Lines           ?     2016
  Branches        ?      314
=======================================
  Hits            ?     1262
  Misses          ?      650
  Partials        ?      104

Flag
Coverage Δ

unittests
62.59% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[BUG] 'ERR_STREAM_WRITE_AFTER_END' in wrangler-dist when using a DELETE method in Router

Is there an existing issue for this?

[X] I have searched the existing issues

What version of workers-rs are you using?
0.0.9
Describe the bug
When calling a DELETE method defined in a router, wrangler dev crashes with the error:
C:\Users\fluxe\AppData\Local\npm-cache\_npx\32026684e21afda6\node_modules\wrangler\wrangler-dist\cli.js:12110
            throw ex;
            ^

Error [ERR_STREAM_WRITE_AFTER_END]: write after end
    at new NodeError (node:internal/errors:387:5)
    at _write (node:internal/streams/writable:322:11)
    at Writable.write (node:internal/streams/writable:337:10)
    at IncomingMessage.ondata (node:internal/streams/readable:766:22)
    at IncomingMessage.emit (node:events:513:28)
    at Readable.read (node:internal/streams/readable:539:10)
    at flow (node:internal/streams/readable:1023:34)
    at resume_ (node:internal/streams/readable:1004:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
Emitted 'error' event on ClientHttp2Stream instance at:
    at ClientHttp2Stream.onerror (node:internal/streams/readable:785:14)
    at ClientHttp2Stream.emit (node:events:513:28)
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  code: 'ERR_STREAM_WRITE_AFTER_END'
}

I've confirmed this error occurs in workers-rs versions 0.0.9 and 0.0.10 on Windows 11, with Node.js version 16.x and 18.x. I've also occasionally seen that, instead of crashing, a 400 Bad Request is returned, but a restart will often fix this. This issue occurs with both regular and async delete routes.
Steps To Reproduce

Create a project using npm init cloudflare <name> worker-rust
Add any delete or async delete method to the router in lib.rs, such as:

router.delete("/test", |_, _| { Response::ok("Test") }

Run wrangler dev and call the method using any REST client.
wrangler dev crashes with error instead of returning the expected response.

It's possible this is a bug in wrangler rather than workers-rs but I haven't tested the JS equivalent.

I've confirmed that the issue occurs even when a DELETE route is not defined (i.e. a request to a non-existent DELETE route). It's very likely that this may be an issue with wrangler rather than workers-rs.

Ah, looks to be related to this issue here: https://github.com/cloudflare/wrangler2/issues/1388
I'll close this issue as it's unrelated to workers-rs.


cannot import name 'nms_impl' from 'clrnet.ops'

Traceback (most recent call last):
File "/content/CLRNet/main.py", line 9, in
from clrnet.utils.config import Config
File "/content/CLRNet/clrnet/init.py", line 1, in
from .ops import *
File "/content/CLRNet/clrnet/ops/init.py", line 1, in
from . nms import nms
File "/content/CLRNet/clrnet/ops/nms.py", line 29, in
from . import nms_impl
ImportError: cannot import name 'nms_impl' from 'clrnet.ops' (/content/CLRNet/clrnet/ops/init.py)

删除build，再次运行setup.py


.off(): create a function to detach events

This is an issue for newcomers and people who want to learn how to contribute to an open source project for the first time. Read more about this type of issues in Up For Grabs

Create a function opposite to on() capable of detaching a events from the matched elements. To do, please check you might not need jquery and follow these steps:

Clone the repository
Create the corresponding folder in src/plugins
Execute grunt watch in the terminal. Make sure you have phantomjs installed first.
Create the three files, off.js, documentation.md and test.js
In off.js add the code needed to execute it
Then (or before if you are into TDD) add the needed tests in test.js. After adding them all, open tests.html in your browser, which should show a passing/failing for your tests. Or check the terminal, since grunt should run tests now too.
Add the documentation.md needed to use it
Send a Pull Request and I'll provide feedback on the code

Note: Check out .on() code to create .off()
I'll be happy to review any code you submit or add tips :smile:

Will give this a go in a bit

Awesome, thank you

Hey I added a small register for the events as _e in the nodes. This is not to require the second callback in the .off(), as jquery does. It's awesome that you added all the tests, since I could verify that it didn't break anything when changed it :smile:


Cannot send keycodes like  or

Using zsh, I'm trying to create mp_attach alias, that will launch zsh in proc and send provided command
Example of usage:
"mp_attach uvicorn main:app"
It need to be launched in zsh as I have set up automatic launching of venv
zsh -c doesn't do the trick
When it comes to space and semicolon, it throws an error: Error: Wrong key code: "Space" and Error: Wrong key code: "Semicolon" respectively
Usual < > and <:> causes similar error as well
Code:
function mp_attach() {
  command="$@"
  parts=(${(s[])command})
  mprocs --ctl "{c: add-proc, cmd: zsh" --server localhost:4050
  for char in $parts; do
    echo $char
    if [[ $char == ' ' ]]; then
      mprocs --ctl "{c: send-key, key: <Space>}" --server localhost:4050
    elif [[ $char == ':' ]]; then

      mprocs --ctl "{c: send-key, key: <Semicolon>}" --server localhost:4050
    else
      mprocs --ctl "{c: send-key, key: <$char>}" --server localhost:4050
    fi
  done
  mprocs --ctl "{c: send-key, key: <Enter>}" --server localhost:4050

}

Result:

And in mprocs:

For 'add-proc' I launch zsh and the rest of commands are ignored

Thank you for a very detailed explanation. Unfortunately, currently it's impossible to send these keys. I just added most basic keys and never describes the rest of the keys.
I will add more keys in the next version, or feel free to send a PR.


chore: add ability to strip prerelease information from the version

Add a flag to strip the prerelease information from the determined version before bumping. e.g.
Before:
1.0.0-something -> 1.0.0
After (with the flag set)
1.0.0-something -> 1.0.1
This behaviour will make prerelease act more like build metadata with the advantage that build metadata cannot be added to a docker image version, but prerelease can.

nice, thanks for the PR.
because this only applies to the semantic strategy, what do you think about passing this flag along with the strategy directly? such as:
jx-release-version -next-version=semantic:strip-prerelease

(or semantic:without-prerelease)
similar to what we're already doing with other strategies such as
jx-release-version -previous-version=from-file:pom.xml

to avoid having too many root flags which only applies to a specific use-case

How would multiple values work in this case? e.g.
-next-version=from-file:pom.xml,strip-prerelease - would that be valid?

well, for this use-case, if you read the next version from a file and want to strip the prerelease, you can do it with the output format, something like -next-version=from-file:pom.xml -output-format={{.Major}}.{{.Minor}}.{{.Patch}}
but yes we can support multiple values in the strategy args here https://github.com/jenkins-x-plugins/jx-release-version/blob/master/main.go#L125-L134 or pass the whole arg to the strategy and let it re-parse it as it wants.
so basically I think:

if we only need this for the semantic strategy, maybe using a strategy arg is a good option
if we want to be able to support it for any strategy, maybe we can introduce some kind of processor between previous-version and next-version?

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: vbehar
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [vbehar]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Ah cool, I've pushed a PR that should support this.  I realised my previous comment was wrong so I removed it (apologies - i didn't realise you were replying to it!)


Slider to choose figure height/width in "curstomize additional other features of the plot" is hardly adjustable to a certain value

Upon clicking on the slider, you can use your keyboard's arrow keys to move the slider in a stepwise manner. Let me know if this already solving the issue or whether we should switch to a different widget!

Ah, didn't know this trick, that's fine then!


make the virtual mobile sprig great

It's on its way. Still some issues but well open up more specific ones later.


Add note to README about lacking module-info support for Eclipse

Added it to CONTRIBUTING.md instead


Google Pay

Shopware: 5.7.7
Adyen-Plugin: 3.7.0
We trying to succesful implement Google Pay in our shop. For Google Pay it is necessary to register our website in Google Pay business console. But what is the correct url to enter there?
Our domain or the domain of adyen?
If we enter our url, no payment is possible, google error is "You have not registered to use this API".
But if you look at the call chain, it could be another url:

Hi Andy,
Please check and follow the docs of google pay on this topic: https://developers.google.com/pay/api/web/guides/test-and-deploy/request-prod-access.
The correct url that you need to configure is the domain and or subdomains name of your webshop.
In the Adyen plugin you only have to configure the Google Merchant ID.
I hope this information helps you to further investigate the issue.

Hi Andy,
Please check and follow the docs of google pay on this topic: https://developers.google.com/pay/api/web/guides/test-and-deploy/request-prod-access.
The correct url that you need to configure is the domain and or subdomains name of your webshop.
In the Adyen plugin you only have to configure the Google Merchant ID.
I hope this information helps you to further investigate the issue.

Thanks for your reply. I think we have it so configured in google pay:

But in checkout we are getting this notice:

Problem is solved. In Adyen Customer Area "API Clientside Encryption Payments role" was missing and Google Pay was added twice in our account. Support solved the problem.
Perhaps interesting:
https://docs.adyen.com/payment-methods/google-pay/web-component#test-and-go-live


possible to create stacks that break stack command

While experimenting with stack variables I managed to inject something that breaks everything:
➜  stacks DEBUG=true dontena stack ls

D, [2016-12-02T12:45:48.420606 #31737] DEBUG -- CONFIG: Loading configuration from /Users/mpa/.kontena_client.json
D, [2016-12-02T12:45:48.423373 #31737] DEBUG -- CONFIG: Configuration loaded with 29 servers.
D, [2016-12-02T12:45:48.423418 #31737] DEBUG -- CONFIG: Current master: devmaster
D, [2016-12-02T12:45:48.423473 #31737] DEBUG -- CONFIG: Current grid: dev
Running #<Kontena::MainCommand:0x007fd3da289460> -- callback matcher = 'nil'
Running #<Kontena::Cli::StackCommand:0x007fd3da219b60> -- callback matcher = 'nil'
Running #<Kontena::Cli::Stacks::ListCommand:0x007fd3d99f0380> -- callback matcher = 'stacks list'
/Users/mpa/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/uri/rfc3986_parser.rb:20:in `split': undefined method `ascii_only?' for nil:NilClass (NoMethodError)
	from /Users/mpa/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/uri/rfc3986_parser.rb:73:in `parse'
	from /Users/mpa/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/uri/common.rb:227:in `parse'
	from /Users/mpa/dev/kontena/cli/lib/kontena/client.rb:46:in `initialize'
	from /Users/mpa/dev/kontena/cli/lib/kontena/command.rb:153:in `new'
	from /Users/mpa/dev/kontena/cli/lib/kontena/command.rb:153:in `rescue in verify_current_master_token'
	from /Users/mpa/dev/kontena/cli/lib/kontena/command.rb:149:in `verify_current_master_token'
	from /Users/mpa/dev/kontena/cli/lib/kontena/command.rb:181:in `run'
	from /Users/mpa/.rvm/gems/ruby-2.3.1/gems/clamp-1.1.1/lib/clamp/subcommand/execution.rb:11:in `execute'
	from /Users/mpa/dev/kontena/cli/lib/kontena/command.rb:187:in `run'
	from /Users/mpa/.rvm/gems/ruby-2.3.1/gems/clamp-1.1.1/lib/clamp/subcommand/execution.rb:11:in `execute'
	from /Users/mpa/dev/kontena/cli/lib/kontena/command.rb:187:in `run'
	from /Users/mpa/.rvm/gems/ruby-2.3.1/gems/clamp-1.1.1/lib/clamp/command.rb:132:in `run'
	from /usr/local/bin/dontena:16:in `<main>'

Any idea what was that "something"?

It's actually a bug elsewhere, not stacks.
(Your token has expired)

???

^- this token?

Yes.
Before command execution, the CLI checked if you have a working token, and noticed that indeed you do, but it has expired.
It tried to refresh it, but there was a bug that made it use the whole current_master object as the URL for refresh request, instead of using just the actual URL field of the current_master.


bridge between teslamate and Scan my Tesla

Maybe it's possible to merge datas from scan my tesla's csv in Teslamate
https://sites.google.com/view/scanmytesla/menus?authuser=0
Manually or automatically, it should be possible as log can be uploaded to Gdrive:
https://sites.google.com/view/scanmytesla/reccommended-software?authuser=0
Thanks for the great work

I'm not using the Scan my Tesla, so I can't (and don't want to) support/maintain an integration. I am open to suggestions though. If anybody wants to work on that we'll find a way to integrate it into teslamate.

Perhaps a collaboration with Teslalogger to use their scanmytesla implemetation?

What would be the benefit? Is there a feature Scan my Tesla has that TeslaMate doesn't?

It takes all of the obd port data via the app and uploads it so you can overlay all of that data on the API sourced data. I can show you on my set up sometime if you would like.

Interesting stuff, although given it's collected via bluetooth and not streamed over the Internet, it seems more like a parallel set of data you would log to csv and import later. Personally I'd be importing it into a separate DB and then setting up grafana to overlay the data over TeslaMate.

Is there a way to extend the TeslaMate grafana image? I am willing to create an app (docker container as well) which imports CSV files from Scan My Tesla to a new database. But I am not sure how to add these data to the existing grafana image 🤔 @adriankumpf can you help me in this point?

Is there a way to extend the TeslaMate grafana image? I am willing to create an app (docker container as well) which imports CSV files from Scan My Tesla to a new database. But I am not sure how to add these data to the existing grafana image.

That's really the basis of how Docker works, you later images on top of each other. It's as simple as creating your own Dockerfile, using the TeslaMate image as the base image and then adding your own customisations on top.

Yes but all the Dashboards are based on one json file. To add additional Data to the Dashboards I would have to edit existing files.

@adriankumpf do you think you'd start using it if you'd have app+adapter+OBD dongle or you're just not interested in diving that deep into technical stats of the car/don't like the hassle of phone requirement?

As I used SMT a few weeks now, I won't make that integration to TeslaMate. My plan was to let a phone permanently log to a file and upload that file to my server at home but the SMT app is way to buggy. Very often it can't establish a Bluetooth connection, so no data is logged. As I am only interested in things that run in background and I do not take care of it after initial set up, I won't do that integration.

Fair point, if it's truly like you describe I'd avoid that as well. My concern is if it is possible that the issues you are encountering are in fact due to OBD adapter you are using? Do you mind mentioning what device is that?

It's an ELM 327 adapter but I am pretty sure, that the app is the issue. Reason: Every time this issue occurs, disabling and reenabling Bluetooth does not help, flight mode does not help, unplug and plugin obd adapter does not help, only killing the app helps. After killing the app Bluetooth is connected within a few seconds, every single time so far.

It's an ELM 327 adapter but I am pretty sure, that the app is the issue. Reason: Every time this issue occurs, disabling and reenabling Bluetooth does not help, flight mode does not help, unplug and plugin obd adapter does not help, only killing the app helps. After killing the app Bluetooth is connected within a few seconds, every single time so far.

I would not blame SMT still. There are countless users who use it without any of such issues. Try it with another phone or a proper OBD adapter (obdlink for example).
I would very much be interested in an integration with scan my tesla with TeslaMate. It would give us a lot more data for statistics (battery temperature for example).


WIP: 041-clk-hrow-pips: Don't add tags for fake features.

When fuzzer 041-clk-hrow-pips is enabled is occasionally fails on db-check, e.g.

hecking kintex7 database
============================
Checking individual .db...
segbits_*.db: 23 okay
mask_*.db: 21 okay
Checking aggregate dir...
ERROR: 2 collisions
  00000c81_048_25: had INT_R_X25Y124.INT_R.CLK1.SR1END1, got CLK_HROW_TOP_R_X67Y130.CLK_HROW_TOP_R.CLK_HROW_CK_INT_0_1_ACTIVE
  00000c81_051_24: had INT_R_X25Y125.INT_R.CLK0.ER1END1, got CLK_HROW_TOP_R_X67Y130.CLK_HROW_TOP_R.CLK_HROW_CK_INT_1_0_ACTIVE

Checking aggregate dir...
ERROR: 1 collisions
  00020c81_048_25: had CLK_HROW_TOP_R_X67Y182.CLK_HROW_TOP_R.CLK_HROW_CK_INT_0_1_ACTIVE, got INT_R_X25Y174.INT_R.CLK1.ER1END1

CLK_HROW_TOP_R.CLK_HROW_CK_INT_1_0_ACTIVE which is causing the problem is most probably not real. This PR aims at fixing the instability on that front.

List of problems after a specific run:
Artix7:
041-clk-hrow-pips - timeout
056-pip-rem failing with ValueError: INT.FAN_ALT5.BYP_BOUNCE1: inconsistent bit index^ - bit calculated by 050-pip-seed
Kintex7:
053-pip-ctrlin - timeout
Zynq7:
041-clk-hrow-pips - timeout

CI is red, because the solution didn't work.
I am still looking into it and will re-request review once I am done.

@litghost I re-requested a review from you. but mostly for the todo list balancing part.
This PR transformed into a DNM branch with all remaining stabilization PRs merged (FAN_ALT.BYP_BOUNCE fix #868 and failing test case packing #856).
Once I can prove that the mechanism works for stabilizing 041 I could create a separate PR for the mechanism and then this PR would only make use of it, i.e. define the extra MAKETODO_FLAGS.

Issues for fails in Artix and Zynq have been created: #874 and #875.
The fixes are being tested on the DNM PR: #848

@tmichalak What is the status of this pull request?

@mithro: waiting for green CI

@mithro @litghost CI is green, so is the CI for the experimental stabilization PR #848.
I am not sure if we want to force the CI to rerun for a couple of times before we actually merge it.
However, reenabling 041 is quite important from the harness point of view.
Note, that this PR relies on the todo balancing (#869) which is also green BTW.

@mithro sure thing, let's wait then.


Can't compile on alpine

Hey,
We have started making a docker version of the code and got the following:
===> Compiling keccakf1600
make: Entering directory '/app/deps/keccakf1600/c_src'
 C      decaf-utils.c
In file included from /app/deps/keccakf1600/c_src/decaf-common.h:42,
                 from /app/deps/keccakf1600/c_src/decaf-utils.c:38:
/usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/include/stdint.h:9:26: error: no include path in which to search for stdint.h
    9 | # include_next <stdint.h>
      |                          ^
In file included from /app/deps/keccakf1600/c_src/decaf-utils.c:38:
/app/deps/keccakf1600/c_src/decaf-common.h:43:10: fatal error: sys/types.h: No such file or directory
   43 | #include <sys/types.h>
      |          ^~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:146: /app/deps/keccakf1600/c_src/decaf-utils.o] Error 1
make: Leaving directory '/app/deps/keccakf1600/c_src'
===> Hook for compile failed!```

The pesky keccakf1600 again eh ? I'll take a look at this, it probably needs an extra apk package

Sorry it was missing deps... Fixed by adding RUN apk add --update make gcc libc-dev


Fix mistral client when using recent node version

"fetch" variable needs to be declared before being assigned, otherwise you get a "Uncaught ReferenceError" error

This actually also fixes #44 by preventing the overwriting the global fetch. Can this be merged and published soon? It is breaking other libraries that rely on the built in fetch implementation. 🙏

Yes please, it breaks all other fetch-based libraries


Inherit from RestrictChildrenAttribute doesn't work.

Hi,
I have a sub class inherit from RestrictChildrenAttribute.  This class works correctly on ASP.NET Core 1.0/1.1.  But it does not on core 2.0.

@hughzzq can you provide more details about what doesn't work? Can you share the structure or code of your tag helpers so that we can investigate?

@Eilon here's a very simple sample.  The expecte behavior of MyRestrictChildrenAttribute is if I type '<' inside a  tag, intelligence will should only show 'testemail-child'.  But it shows all tag.
[MyRestrictChildrenAttribute("testemail-child")]
//[RestrictChildrenAttribute("testemail-child")] //this works correctly.
[HtmlTargetElement("testemail")]
public class EmailTaghelper : TagHelper
{
}

[HtmlTargetElement("testemail-child")]
public class EmailChildTagHelper : TagHelper
{
}

[AttributeUsage(AttributeTargets.Class, Inherited = false, AllowMultiple = false)]
public class MyRestrictChildrenAttribute : RestrictChildrenAttribute
{
    #region Ctors
    public MyRestrictChildrenAttribute(string tagName, params string[] tagNames)
        : base(tagName, tagNames)
    {
    }

    #endregion Ctors

}

@NTaylorMullen can you take a look? Is this expected?

Interesting. In the old world we used to utilize TypeInfo.GetCustomAttribute<RestrictChildren>(inherit: false) which turns out does return sub-classed variants of the attributes. In 2.0.0 world we take a Roslyn approach to analyzing TagHelpers which does not take into account an attributes inheritance structure.
Honestly it's not a scenario we've put time into thinking about (hence why we don't have tests) but nevertheless it's something we should handle since we did before.

We should have sealed these attributes. We can't enable scenarios where you metaprogram tag helpers by subclassing attributes, because we can't run user code during tag helper discovery.

Here is the issue to track the work to seal the attribute class: https://github.com/aspnet/Razor/issues/1884


winafl-cmin: Add --crash-dir and --hang-dir

Add two new command-line arguments --crash-dir and --hang-dir
--crash-dir allows specifying a directory in which all crashes encountered should be stored in
--hang-dir allows specifying a directory in which all hangs encountered should be stored in

Rationale:
In winafl-cmin, the only options are either "keep non-crashing inputs" (the default) or "only keep crashing inputs". However, if you're working through a large corpus of unknown files, wouldn't it make sense to also have an option to copy the hangs and crashes to a separate directory, since if you're already processing all the sample inputs, you should able to examine the crashes and hangs without needing to re-run or parse the details from the log file?


replace \n with new line in private key in service account

Sometimes the private key that include a new line inside of it was taking the new line and converting the new line to \n which was causing private key error
This way it will always replace the \n with a new line

I haven't encountered such a file yet, but it, of course, doesn't mean that it couldn't happen :)
Could you provide me with an example of such a file/value that would cause this problem? I tried re-creating the issue but wasn't able to so far.

I haven't encountered such a file yet, but it, of course, doesn't mean that it couldn't happen :)
Could you provide me with an example of such a file/value that would cause this problem? I tried re-creating the issue but wasn't able to so far.

This only happened after i injected the credentials using the array credentials method

The thing is: since I can't reproduce the issue (and I tried), an additional test would convince me that it actually exists. If I blindly accept this change and something else breaks, everybody else would be all over me :).
What is the specific error you're getting? Is it an exception or another error? Is it happening while instantiating a ServiceAccount instance or later when making a request to the Firebase APIs?

I was able to reproduce the issue. It's definitely an edge case, but after much consideration, the change should™ not have negative side effects if the service account credentials are otherwise correctly used.
Thanks for the contribution!


Understanding Turbine/ Hystrix stream metrics

Hi,
I am working with our monitoring team in understanding the metrics output from the Turbine/ Hystrix stream. It will help them setup dashboards & they want to understand which bits they want to pic in their monitoring dashboards. They are using Kibana for configuring their dashboard.
I am struggling to find any documentation online which explains each element in the metrics. There is documentation for Hystrix configuration but nothing explaining the metrics which is output in JSON format when you request the stream.
{
	"data": {
		"rollingCountFallbackSuccess": 0,
		"rollingCountFallbackFailure": 0,
		"propertyValue_circuitBreakerRequestVolumeThreshold": 40,
		"propertyValue_circuitBreakerForceOpen": false,
		"propertyValue_metricsRollingStatisticalWindowInMilliseconds": 20000,
		"latencyTotal_mean": 215,
		"rollingMaxConcurrentExecutionCount": 0,
		"type": "HystrixCommand",
		"rollingCountResponsesFromCache": 0,
		"rollingCountBadRequests": 0,
		"rollingCountTimeout": 0,
		"propertyValue_executionIsolationStrategy": "SEMAPHORE",
		"rollingCountFailure": 0,
		"rollingCountExceptionsThrown": 0,
		"rollingCountFallbackMissing": 0,
		"threadPool": "RibbonCommand",
		"latencyExecute_mean": 215,
		"isCircuitBreakerOpen": false,
		"errorCount": 0,
		"rollingCountSemaphoreRejected": 0,
		"group": "RibbonCommand",
		"latencyTotal": {
			"0": 203,
			"25": 203,
			"50": 203,
			"75": 227,
			"90": 227,
			"95": 227,
			"99": 227,
			"100": 227,
			"99.5": 227
		},
		"requestCount": 0,
		"rollingCountCollapsedRequests": 0,
		"rollingCountShortCircuited": 0,
		"propertyValue_circuitBreakerSleepWindowInMilliseconds": 10000,
		"latencyExecute": {
			"0": 203,
			"25": 203,
			"50": 203,
			"75": 227,
			"90": 227,
			"95": 227,
			"99": 227,
			"100": 227,
			"99.5": 227
		},
		"rollingCountEmit": 0,
		"currentConcurrentExecutionCount": 0,
		"propertyValue_executionIsolationSemaphoreMaxConcurrentRequests": 200,
		"errorPercentage": 0,
		"rollingCountThreadPoolRejected": 0,
		"propertyValue_circuitBreakerEnabled": true,
		"propertyValue_executionIsolationThreadInterruptOnTimeout": true,
		"propertyValue_requestCacheEnabled": true,
		"rollingCountFallbackRejection": 0,
		"propertyValue_requestLogEnabled": true,
		"rollingCountFallbackEmit": 0,
		"rollingCountSuccess": 0,
		"propertyValue_fallbackIsolationSemaphoreMaxConcurrentRequests": 20,
		"propertyValue_circuitBreakerErrorThresholdPercentage": 100,
		"propertyValue_circuitBreakerForceClosed": false,
		"name": "discovery-client",
		"reportingHosts": 2,
		"propertyValue_executionIsolationThreadPoolKeyOverride": "null",
		"propertyValue_executionIsolationThreadTimeoutInMilliseconds": 120000,
		"propertyValue_executionTimeoutInMilliseconds": 120000
	}
}

It will be great, even if I get any link to the documentation explaining above or any direction so that I can understand this better.
Thanks in advance.

Closing this due to inactivity. Please re-open if there's more to discuss.


Make polygons with an image material render as translucent

This came up on the forum.
Here's a PNG with a transparent background:

If you add this as a material to a polygon, you get a black background:

Code:
var viewer = new Cesium.Viewer('cesiumContainer');

viewer.entities.add({
    polygon : {
        hierarchy : Cesium.Cartesian3.fromDegreesArray([-93.42146226782502, 40.966453300249995, -93.41909064452037, 40.966453300249995, -93.41909064452037, 40.96882492355465, -93.42146226782502, 40.96882492355465]),
        material : "../images/Cesium_Logo_overlay.png",
        height: 100
    }
});

viewer.zoomTo(viewer.entities);

But if you comment out the height so it's clamped, it works fine:

This inconsistency is because the ground primitives batch will override the translucency property of a material:
https://github.com/AnalyticalGraphicsInc/cesium/blob/dceac54c0e96bcbd3f07e9632746c5e0e05a1025/Source/DataSources/StaticGroundGeometryPerMaterialBatch.js#L123-L126
Whereas the regular primitive batch will not:
https://github.com/AnalyticalGraphicsInc/cesium/blob/dceac54c0e96bcbd3f07e9632746c5e0e05a1025/Source/DataSources/StaticGeometryPerMaterialBatch.js#L131-L134
This PR updates the regular primitive batch to behave the same as the ground primitive one. In retrospect, I'm not sure if this is the right solution. The real problem is that the material declares it is not translucent, because the color's alpha channel is 1:
https://github.com/AnalyticalGraphicsInc/cesium/blob/dceac54c0e96bcbd3f07e9632746c5e0e05a1025/Source/Scene/Material.js#L1102-L1119
But I think for an image material, the behavior should be translucent by default, since you would expect an image with transparency to render as transparent. If we make the change in Material.js then the batches won't need to override this.

Thanks for the pull request @OmarShehata!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

The main issue here is the inconsistency between groundprimitive/primitive, but there's more going on. material in your example is an instance of ImageMaterialProperty, which has a transparent property.  So in master you can do:
var viewer = new Cesium.Viewer('cesiumContainer');

viewer.entities.add({
    polygon : {
        hierarchy : Cesium.Cartesian3.fromDegreesArray([-93.42146226782502, 40.966453300249995, -93.41909064452037, 40.966453300249995, -93.41909064452037, 40.96882492355465, -93.42146226782502, 40.96882492355465]),
        material : new Cesium.ImageMaterialProperty({
            image:"../images/Cesium_Logo_overlay.png",
            transparent: true
        }),
        height: 100
    }
});

viewer.zoomTo(viewer.entities)

and get the behavior you want.
Cesium historically defaulted to transparent false because transparent true causes issues if the image is no transparent.  We definitely need to look into the big picture more before we do anything.

Thanks for the context. I think it's OK to have the user supply the transparent: true parameter, and the only thing we need to fix here is the inconsistency. That code was originally written by @likangning93 but here's where the Dan says that the "render states are overridden for ground primitives":
https://github.com/AnalyticalGraphicsInc/cesium/pull/6393#discussion_r185289487
I just tried this to confirm. It's not actually possible to make a GroundPrimitive NOT translucent. So I think there need not be any code fix here, other than to document the translucent and closed options have no effect when the polygon is clamped?

Thanks again for your contribution @OmarShehata!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @OmarShehata!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @OmarShehata!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@mramato @OmarShehata what's the status of this PR?

We can probably just close this PR. Sounds like there may be a non-documented limitations in GroundPrimitive that perhaps @OmarShehata can open an issue for if he agrees.


Issue #3212: Remove duplicate string table implementation

Issue #3212: Remove duplicate string table implementation
Move Surelog/SymbolTable to UHDM as SymbolFactory to replace its own implementation. Also, pulled in SymbolId implementation.
Updated code generation scripts to use SymbolId instead of SymbolFactory::ID.
IMPORTANT NOTE:
One important difference between UHDM's and Surelog's use of SymbolTable is that UHDM resolves an invalid SymbolId to an empty string but Surelog's expects the BAD_SYMBOL. So, the API in the implementation can't be the same. UHDM has its own set of APIs and Surelog it's own.

I am not sure about the benefits of unifying these at this time.


Not Exporting Data on file

I tried exporting the data into a file with my code, but the file only has the default texts (no data)
MyCode:
mysqldump({       connection: {         host: process.env.DB_IP,         user: process.env.DB_USER,         password: process.env.DB_PASS,         database: "gamezone_3tar",       },       dumpToFile: './botData/3TarDB.sql',   });

I can confirm that the data is missing from my dump. Only the schemas are exported.
This is my API call:
mysqldump({
    connection: {
      host,
      user,
      database,
      password,
    },
    dumpToFile: filePath,
  });

MySQL 5.7
node 10.15

I resolved my problem by awaiting the call to mysqldump.
I deleted data directly after the dump and as I did not await the promise returned by mysqldump the deletion finished before the dump, leading to data missing from it.
From the first examples under "Usage" I could not infer that the method was in fact asynchronous rather than synchronous. That threw me off.

can u send me the code?

I just wrote await mysqldump in place of mysqldump. The rest is the same.

with dumpToFile option?

Yes, I use the dumpToFile option.


feat(discovery): add ability to hide classes from discovery

This pull request adds the ability to hide classes from all discovery implementations by adding a HideFromDiscovery attribute (edit: updated to DoNotDiscover).
Happy to change the attribute name to anything else:

SkipDiscovery
IgnoreFromDiscovery
WithoutDiscovery
\Tempest\Core\Discovery\Ignore
\Tempest\Core\Discovery\Skip

Closes #338
Related to #509

Nice, yeah the name, here are my preferences:

#[NoDiscovery]
#[SkipDiscovery]
#[DoNotDiscover]

I think I like #[DoNotDiscover] the most, but I don't have a super strong opinion on it

I like it! I updated the pull request.

Nice!

@brendt does it make sense to have this configurable too?

@aidan-casey configurable how?

@brendt by adding to a config file. Otherwise, the developer has no real way to not discover vendor files unless the package maintainer opts to not have them discovered.

Aaah gotcha. Yeah… that might make sense indeed 🤔


Missing features list

This will be a list of missing features (index of sounds-like issue):
Missing modules:

Feature:
Issue
PR

KoTH
#265
-

Renewables
#434
-

Custom projectiles
#550
-

Predicted kills
#598
-

FFA
#682
-

CTF
#684
#890

Double jump
#745
-

World border module
-
#754

Falling blocks
#862
-

Respawn Title
-
#892

Long distance render tnt
-
#934

To-add features:

Feature:
Issue
PR

Refilling chests (Wools)
#431
-

Dispenser explosions
#737
-

/rank info
#778
-

Localized death messages
#833
#844

Static and half-space regions
#888
-

When will this be deployed?

@chleongithub this is just a list to keep track of what's missing

Dispenser explosions, #973


login alias check

Small change to check that Alias is set on the AWS account name

Seems Tests are failing, not sure why as the PR shouldnt be changing the results. Investigating


When starting a node with mainnet genesis, the log comes out and then nothing happens, what could be the reason?

log example
2023-05-03T12:40:56.507397Z  INFO sui_node::admin: starting admin server filter=info address=<IP_ADDRESS>:1337
config example
`db-path: "/opt/sui/db"
network-address: "/dns/localhost/tcp/8080/http"
metrics-address: "<IP_ADDRESS>:9184"
this address is also used for web socket connections
json-rpc-address: "<IP_ADDRESS>:9000"
enable-event-processing: true
genesis:
Update this to the location of where the genesis file is stored
genesis-file-location: "/opt/sui/conf/genesis.blob"
authority-store-pruning-config:
num-latest-epoch-dbs-to-retain: 3
epoch-db-pruning-period-secs: 3600
num-epochs-to-retain: 1
max-checkpoints-in-batch: 10
max-transactions-in-batch: 1000
use-range-deletion: true
pruning-run-delay-seconds: 60`

me too, nothing happens

me too, the logs having been 2 hours like this
2023-05-04T04:17:43.693857Z  INFO sui_node: Sui Node version: 1.0.0-ae1212baf
2023-05-04T04:17:43.694875Z  INFO sui_node: Supported protocol versions: Some(SupportedProtocolVersions { min: ProtocolVersion(1), max: ProtocolVersion(9) })
2023-05-04T04:17:43.695625Z  INFO sui_node: Started Prometheus HTTP endpoint at <IP_ADDRESS>:9184
2023-05-04T04:17:43.702406Z  INFO sui_node: Initializing sui-node listening on /dns/localhost/tcp/8080/http node=k#acceb3b9fefbe401a0fc3d540e2875dd5792cbf4139360c29a5039df9f5c921ab1f38d0ae19a39f11cefa9247feb7bc2116b3b9f8b13f0de0da4209778bbd980fced13be4e94103a47b77047496846c92e5a371e254a07b586377c87ec7ebcb6
2023-05-04T04:17:44.540869Z  INFO sui_core::authority::authority_per_epoch_store: in_memory_checkpoint_roots = true
2023-05-04T04:17:44.880602Z  INFO sui_node: P2p network started on <IP_ADDRESS>:8080
2023-05-04T04:17:44.881992Z  INFO sui_network::discovery: Discovery started
2023-05-04T04:17:44.882020Z  INFO sui_core::authority: current protocol version is now ProtocolVersion(4)
2023-05-04T04:17:44.882025Z  INFO sui_core::authority: supported versions are: SupportedProtocolVersions { min: ProtocolVersion(1), max: ProtocolVersion(9) }
2023-05-04T04:17:44.882029Z  INFO connection-manager{peer=4216afdf}: anemo::network::connection_manager: ConnectionManager started
2023-05-04T04:17:44.882209Z  INFO sui_network::state_sync: State-Synchronizer started
2023-05-04T04:17:44.924358Z  INFO sui_core::execution_driver: Starting pending certificates execution process.
2023-05-04T04:17:45.155944Z  INFO sui_json_rpc: acl=Const("*")
2023-05-04T04:17:45.159537Z  INFO sui_node: SuiNode started!
2023-05-04T04:17:45.159599Z  INFO narwhal_network::connectivity: Spawning future narwhal/network/src/connectivity.rs:ConnectionMonitor
2023-05-04T04:17:45.159712Z  INFO sui_node::admin: starting admin server filter=info address=<IP_ADDRESS>:1337
2023-05-04T04:17:45.161113Z  INFO schedule_checkpoint{seq=0 epoch=0}: sui_core::checkpoints::checkpoint_executor: Checkpoint preparation for execution took 568.552��s
2023-05-04T04:17:45.168985Z  INFO sui_core::checkpoints::checkpoint_executor: Checkpoint execution took 7.877459ms seq=0
2023-05-04T04:17:45.169018Z  INFO sui_core::checkpoints::checkpoint_executor: Finished syncing and executing checkpoint 0
2023-05-04T04:46:58.634815Z  INFO connection{remote_addr=<IP_ADDRESS>:34426 conn_id=0}: jsonrpsee_server::server: Accepting new connection 1/4294967295
2023-05-04T04:47:00.998004Z  INFO connection{remote_addr=<IP_ADDRESS>:34432 conn_id=1}: jsonrpsee_server::server: Accepting new connection 1/4294967295
2023-05-04T04:47:02.436056Z  INFO connection{remote_addr=<IP_ADDRESS>:34444 conn_id=2}: jsonrpsee_server::server: Accepting new connection 1/4294967295
2023-05-04T04:47:03.211354Z  INFO connection{remote_addr=<IP_ADDRESS>:34448 conn_id=3}: jsonrpsee_server::server: Accepting new connection 1/4294967295
2023-05-04T04:47:03.978803Z  INFO connection{remote_addr=<IP_ADDRESS>:34456 conn_id=4}: jsonrpsee_server::server: Accepting new connection 1/4294967295
2023-05-04T04:47:04.777203Z  INFO connection{remote_addr=<IP_ADDRESS>:36878 conn_id=5}: jsonrpsee_server::server: Accepting new connection 1/4294967295
2023-05-04T05:39:39.936355Z  INFO connection{remote_addr=<IP_ADDRESS>:46440 conn_id=6}: jsonrpsee_server::server: Accepting new connection 1/4294967295
2023-05-04T05:39:39.936490Z  INFO connection{remote_addr=<IP_ADDRESS>:46440 conn_id=6}:get_latest_checkpoint_sequence_number: sui_json_rpc::read_api: success
2023-05-04T05:39:42.244120Z  INFO connection{remote_addr=<IP_ADDRESS>:46442 conn_id=7}: jsonrpsee_server::server: Accepting new connection 1/4294967295
2023-05-04T05:39:43.110819Z  INFO connection{remote_addr=<IP_ADDRESS>:46452 conn_id=8}: jsonrpsee_server::server: Accepting new connection 1/4294967295
2023-05-04T05:39:57.544099Z  INFO connection{remote_addr=<IP_ADDRESS>:58750 conn_id=9}: jsonrpsee_server::server: Accepting new connection 1/4294967295
2023-05-04T05:44:06.081682Z  INFO connection{remote_addr=<IP_ADDRESS>:54602 conn_id=10}: jsonrpsee_server::server: Accepting new connection 1/4294967295

me too

i think problem will be  happen when  configuration file does not configure P2P-config，like this

The following addition made the sync work. However, the sync does not progress beyond epoch 23.
p2p-config:
seed-peers:
- address: /dns/icn-00.mainnet.sui.io/udp/8084
peer-id: 303f1f35afc9a6f82f8d21724f44e1245f4d8eca0806713a07c525dadda95a66
- address: /dns/icn-01.mainnet.sui.io/udp/8084
peer-id: cb7ce193cf7a41e9cc2f99e65dd1487b6314a57c74be42cc8c9225b203301812
- address: /dns/mel-00.mainnet.sui.io/udp/8084
peer-id: d32b55bdf1737ec415df8c88b3bf91e194b59ee3127e3f38ea46fd88ba2e7849
- address: /dns/mel-01.mainnet.sui.io/udp/8084
peer-id: bbf3be337fc16614a1953da83db729abfdc40596e197f36fe408574f7c9b780e
- address: /dns/ewr-00.mainnet.sui.io/udp/8084
peer-id: c7bf6cb93ca8fdda655c47ebb85ace28e6931464564332bf63e27e90199c50ee
- address: /dns/ewr-01.mainnet.sui.io/udp/8084
peer-id: 3227f8a05f0faa1a197c075d31135a366a1c6f3d4872cb8af66c14dea3e0eb66
- address: /dns/sjc-00.mainnet.sui.io/udp/8084
peer-id: 6f0b25087cd6b2fd2e4329bcf308ac95a37c49277dd7286b72470c124809db5b
- address: /dns/sjc-01.mainnet.sui.io/udp/8084
peer-id: af1d5d8468b3612ac2b6ff3ca91e99a71390dbe5b83dea9f6ae2da708d689227
- address: /dns/lhr-00.mainnet.sui.io/udp/8084
peer-id: c619a5e0f8f36eac45118c1f8bda28f0f508e2839042781f1d4a9818043f732c
- address: /dns/lhr-01.mainnet.sui.io/udp/8084
peer-id: 53dcedf250f73b1ec83250614498947db00d17c0181020fcdb7b6db12afbc175

https://github.com/testnet-pride/Node-manuals/blob/main/Testnets/Sui/mainnet.md

@timurgum thanks for flagging this. I expect that this has been fixed since the launch, so I will close it. If you still encounter problems with this, please file a new issue.


Crash when starting the game on Android 12+

Godot version
3.5 Stable
System information
Android 12+
Issue description
The error occurs when running the game on Android 12 and above.
Players who have reported this cannot conduct full-fledged tests using ADB, that's why I'm attaching reports from Google Play.
I think this is a problem that can be solved. I will try to do it myself by modifying Gradle settings, and if I succeed, I will write a solution here.
The error is related to this:
android.app.PendingIntent.checkFlags
Unfortunately, I don't have a device running version 12 of Android, so I'm also asking for help in testing this problem.
Full Stack
Exception java.lang.IllegalArgumentException:
  at android.app.PendingIntent.checkFlags (PendingIntent.java:378)
  at android.app.PendingIntent.getBroadcastAsUser (PendingIntent.java:648)
  at android.app.PendingIntent.getBroadcast (PendingIntent.java:635)
  at androidx.work.impl.utils.ForceStopRunnable.getPendingIntent (ForceStopRunnable.java:174)
  at androidx.work.impl.utils.ForceStopRunnable.isForceStopped (ForceStopRunnable.java:108)
  at androidx.work.impl.utils.ForceStopRunnable.run (ForceStopRunnable.java:86)
  at androidx.work.impl.utils.SerialExecutor$Task.run (SerialExecutor.java:75)
  at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1167)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)
  at java.lang.Thread.run (Thread.java:920)

Steps to reproduce
Run any game built in Godot 3.5 on Android 12.
There is a theory that this will also be relevant for lower versions of Godot.
Minimal reproduction project
No response

@SkanerSoft Unfortunately the information provided is not enough to allow us to reproduce and identify the issue.

Run any game built in Godot 3.5 on Android 12.

Can you provide a test project that consistently crashes when built on Godot 3.5 on Android 12, but doesn't when using prior versions of Godot?

I don't have an Android 12 phone, so I'm not sure I can build exactly the minimal project. Someone else who has such a device is needed to make sure that the problem is really happening.

@SkanerSoft You may be able to use the Android emulator on a PC to test your project on Android 12: https://developer.android.com/studio/run/emulator

In general, I was able to test the problem. I can't say exactly why it appeared, but I was able to solve it by adding the following line to the Gradle settings:
implementation 'androidx.work:work-runtime-ktx:2.7.1'
After that, the project on Android 12 began to run without problems.
The device on which the tests were carried out is Realme 9Pro 5G.
As for the minimum project, this is literally any project.

@SkanerSoft I tested two sample projects using the Godot 3.5 stable build and stable build templates on a device running Android 13, and I was not able to reproduce the issue you're describing.
So it's likely the issue originates with your project configuration.
If you can share the project that's crashing, or provide a repro project, we can investigate further, otherwise there's not much we can do.

implementation 'androidx.work:work-runtime-ktx:2.7.1'

For reference, the stock Godot Android template doesn't make use of this library, so this may originate from one of the plugin your project is using.

I'll close the issue for now as not-reproducible. Feel free to re-open if you're able to provide a repro project.


Can't create new Schema

When I try to create a new schema I get an alert with the message: "Selected Case Number is 1". The new schema does not seem to be registered after this happens.
The generated curl command works well though.

I am still getting this error when using the most recent version uploaded to docker, which is supposed to contain this bugfix. I am having to run the generated curl manually because it still shows up an alertbox with Selected Case Number is 1 and ends up doing nothing

Hi @request-eduardo,
It seems that it was merged to master but not in release. So this will be available to v0.7.1 later today when the release is completed.
It's deployed here: https://schema-registry-ui.landoop.com

Thanks a lot, I appreciate the effort
Enviado con Mailtrack
<EMAIL_ADDRESS>2016-10-12 10:25 GMT-03:00 Christina Daskalaki<EMAIL_ADDRESS>
Hi @request-eduardo https://github.com/request-eduardo,
It seems that it was merged to master but not in release. So this will be
available to v0.7.1 later today when the release is completed.
It's deployed here: https://schema-registry-ui.landoop.com
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Landoop/schema-registry-ui/issues/14#issuecomment-253212476,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVXQMd3zOI95Abx9Gye9obDr4XfgL9MUks5qzN_cgaJpZM4Jvp-5
.

Hi @chdask
I suppose you had trouble again building v0.7.1 for docker... The bug is still there
Guess I'll stay checking


Reworded the contributing section of the README

Closes #244

Current coverage is 23.40%

Merging #245 into master will increase coverage by +0.02% as of f21a5e9

@@            master   #245   diff @@
=====================================
  Files          164    164
  Stmts         4545   4547     +2
  Branches       738    738
  Methods          0      0
=====================================
+ Hit           1063   1064     +1
+ Partial         94     93     -1
- Missed        3388   3390     +2

Review entire Coverage Diff as of f21a5e9

Powered by Codecov. Updated on successful CI builds.

@rultor merge

@rultor merge

@mafagafogigante OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@mafagafogigante Done! FYI, the full log is here (took me 4min)


Add x correlation id to header and logging

Coverage increased (+0.8%) to 84.795% when pulling c612d7f34bd15ff3795ea71e42aedb31526f755a on Add-X-Correlation-Id into d38280f157ed78471fdcc4015e156e036fbbfdcd on master.

Coverage increased (+0.7%) to 86.104% when pulling 32e4be1aa0ed4025863737da0edb6b2e9eb7d664 on Add-X-Correlation-Id into 630bade306c239e9497c62c41c33127bca15eb9d on master.

Coverage increased (+0.7%) to 86.104% when pulling db3d096cae696471115a6b3c37edcac070d70387 on Add-X-Correlation-Id into 630bade306c239e9497c62c41c33127bca15eb9d on master.

Coverage increased (+0.8%) to 86.216% when pulling 75347b2e3015ee81d40e9549fecf160adab3c43e on Add-X-Correlation-Id into 630bade306c239e9497c62c41c33127bca15eb9d on master.

Coverage increased (+0.8%) to 86.216% when pulling 8ad1bf4c0f3401e14ae208bf1887843646b245fc on Add-X-Correlation-Id into 630bade306c239e9497c62c41c33127bca15eb9d on master.


Make gem_installer generate a valid Gemfile

Description
When multiple cookbooks in the run list require the same gem from the gem_installer, and these gem declarations include keyword arguments (e.g. to install the gem from a git repository), the gem_installer will generate an invalid Gemfile.
This should fix this by handling keyword arguments separately and merging them together when necessary. This may still result in unwanted behaviour, if the cookbooks specify different arguments that do not play well together, but at least we will have a valid Gemfile in all cases.
Issues Resolved
None?
Check List

[X] New functionality includes tests
[X] All tests pass
[ ] RELEASE_NOTES.md, has been updated if required (not required for bugfixes, required for API changes)
[X] All commits have been signed-off for the Developer Certificate of Origin. See https://github.com/chef/chef/blob/master/CONTRIBUTING.md#developer-certification-of-origin-dco

I would rather we just leave it as invalid and surface the bundler error to the user. It's just like you've requested an invalid cookbook dependency, should be a fatal error not a warning.

Unfortunately, it would be totally valid that two cookbooks want to install the same gem with the same options (e.g. install from the same git repo), but currently it would produce an invalid Gemfile in that case.

We should check that the values are "compatible" then, i.e. make sure it's still an error if two cookbooks do actually request differing versions of the same gem and whatnot.

I changed the request to fail directly whenever we would have directly conflicting requirements. Further checking if values are "compatible" might be quite complicated and is probably better done by Bundler.

if you have two really identical gem declarations i think you should just drop the duplicate statement.  i think that would address the use case of what happens when two cookbook both want the same gem pulled from the same git source.
the problem that i see is github and git can still get merged and produce nonsense, and there may be other ways that merging flags produces dangerously successful nonsense, where bundler doesn't fail but it doesn't produce results that anyone would ever want.
i think i'd prefer to just de-dup based on strictly the options hashes being equivalent and raise otherwise.

And for internal use if you're installing gems across multiple cookbooks then all your gem statements should be synchronized.  If you have 50 identical gem statements across 50 cookbooks then you should really consolidate those into one cookbook that expresses that gem dependency (or one cookbook that manages all your gem dependencies) and make all the other depend on that.
For community cookbooks, those should generally not use any arguments and just install the gem, or set a version.  To keep those in synch, while allowing pulling from a git tag (that also meets the requirements) we could merge only the version requirements.
So you could build a coherent Gemfile out of:
gem "foo"
gem "foo", "~> 1.1"
gem "foo", "> 1.0"
gem "foo", git: "https://github.com/foo/foo", tag: "bugfix1"

merging that into:
gem "foo", "~> 1.1",  "> 1.0", git: "https://github.com/foo/foo", tag: "bugfix1"

any non-version-constraint options should strictly conflict though even before we fire it off to bundler.

yeah this is better but not perfect, i'm cool with merging, still think eventually it should get fixed better.

Let's hold off merging this until we get the 14.1 hotfix out the door


Stats: Invalid countries count.

https://github.com/threefoldtech/tfgrid-sdk-ts/blob/4e11b0eea16c2f9e31c3ed0b1dd84ea14bb70ef4/packages/new_stats/src/utils/stats.ts#L10
we should'n add the value, we should get the  countries from the length of the nodesDistribution at mergeAllStatsData
 res.countries = Object.keys(res.nodesDistribution).length;

Verified,
Devnet, stats site.
From devnet we get Belgium and Canada.

And from testnet we get Belgium, France, Netherlands, and United States.

And both are being counted as 5 correctly (not 6 because Belgium is duplicated).


add directives plugin

merging this into a new 2.0 branch since there is technically a breaking change in the types.  I have a few more breaking changes that are landing soon, so going to batch them all together.


Simple substitution variable not working in document footer.

Hi,
I noticed that the substitution variables do not show or take effect in the footer of the generated pen report. Example. Placing ΩtextΩ in the footer will have no effect.

Hey Rick! The substitution variables only replace in main document component (i.e. word/document.xml). Footer, Headers, and Comments are all stored in different xml files inside of the zip (e.g. footer.xml).
Currently there is no way to set a substitution variable in the footer. I will change this to a feature request.

Sounds good thanks!

We have decided not to implement this. Thank you for the submission.


Add Gemm operator for autograd and onnx

ready to be merged to dev branch

pls resolve the conflicts and clean the commits.


[Snyk] Security upgrade se.idsec.signservice.commons:signservice-commons from 2.0.0 to 2.1.1

Snyk has created this PR to fix 6 vulnerabilities in the maven dependencies of this project.
Snyk changed the following file(s):

pom.xml

Vulnerabilities that will be fixed with an upgrade:

Issue
Score
Upgrade

Infinite loop SNYK-JAVA-ORGBOUNCYCASTLE-6612984
  600
se.idsec.signservice.commons:signservice-commons:  2.0.0 -> 2.1.1  No Path Found Proof of Concept

Allocation of Resources Without Limits or Throttling SNYK-JAVA-COMNIMBUSDS-6247633
  525
se.idsec.signservice.commons:signservice-commons:  2.0.0 -> 2.1.1  No Path Found No Known Exploit

Observable Discrepancy SNYK-JAVA-ORGBOUNCYCASTLE-6613076
  520
se.idsec.signservice.commons:signservice-commons:  2.0.0 -> 2.1.1  No Path Found Proof of Concept

Allocation of Resources Without Limits or Throttling SNYK-JAVA-ORGBOUNCYCASTLE-6613079
  415
se.idsec.signservice.commons:signservice-commons:  2.0.0 -> 2.1.1  No Path Found No Known Exploit

Improper Handling of Case Sensitivity SNYK-JAVA-ORGSPRINGFRAMEWORK-8230364
  265
se.idsec.signservice.commons:signservice-commons:  2.0.0 -> 2.1.1  No Path Found No Known Exploit

Improper Handling of Case Sensitivity SNYK-JAVA-ORGSPRINGFRAMEWORK-8230365
  265
se.idsec.signservice.commons:signservice-commons:  2.0.0 -> 2.1.1  No Path Found No Known Exploit

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Allocation of Resources Without Limits or Throttling

Fixed in https://github.com/swedenconnect/signservice/pull/183


Concurrency issues when creating secret in e2e tests

Right now the e2e tests sometimes fail due to kubectl trying to create the secret when its already there
e.G. https://circleci.com/gh/kubermatic/machine-controller/2877?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
We should probably just not use a secret in the e2e tests and instead just put the required credentials into the machine spec.

https://github.com/kubermatic/machine-controller/pull/175


Add/Update shaders to v9.238

Closes #1068
Closes #1074
Closes #1075
Closes #1077
Closes #1078
Closes #1079
Closes #1080
Closes #1081
Closes #1082
Closes #1083
Closes #1084
Closes #1085
Closes #1086
Closes #1087
Closes #1088
Closes #1089
Closes #1090
Closes #1091
Closes #1092
Closes #1093
Closes #1094
Closes #1095
Closes #1096
Closes #1097
Closes #1098
Closes #1099
Closes #1100
Closes #1101
Closes #1102
Closes #1103
Closes #1104
Closes #1105

Ooof, that’s a massive one :D

Most of the shaders are just 3 lines code though.


Yup application validation

Video breakdown: https://www.loom.com/share/a1e37211ae054de2b997559b896086b2
Description
Removes the application validation from inside of the cacheSignUpData middleware, and introduces validation for the mentee and mentor applications using yup. This cleans up our middleware as well as introduces a better validation solution.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[x] Refactor (non-breaking change which changes existing code)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have removed unnecessary comments/console logs from my code
[ ] I have made corresponding changes to the documentation if necessary (optional)
[x] My changes generate no new warnings
[x] I have checked my code and corrected any misspellings
[x] No duplicate code left within changed files
[x] Size of pull request kept to a minimum
[x] Pull request description clearly describes changes made & motivations for said changes

I like the way the middleware is set up. Good job.


Maintainer GET projects

Expected Behavior
Use JWT to check for the maintainer projects
Current Behavior
Not Implemented till now

Resolved