No such interface 'org.freedesktop.Secret.Collection' on object at path /org/freedesktop/secrets/collection/login

The example from the readme file  throws an error on   keyring.Set(service, user, password)``:
No such interface 'org.freedesktop.Secret.Collection' on object at path /org/freedesktop/secrets/collection/login
Any idea why is that? If I run it with sudo the program just get stuck
package main

import (
    "log"

    "github.com/zalando/go-keyring"
)

func main() {
    service := "my-app"
    user := "anon"
    password := "secret"

    // set password
    err := keyring.Set(service, user, password)
    if err != nil {
        log.Fatal(err)
    }

    // get password
    secret, err := keyring.Get(service, user)
    if err != nil {
        log.Fatal(err)
    }

    log.Println(secret)
}

uname -a
Linux ubuntu 4.8.0-36-generic #36~16.04.1-Ubuntu SMP Sun Feb 5 09:39:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

@winteraz do you have gnome-keyring installed?

Same here. Amazon Linux 2 (AWS Linux Workspace), gnome-keyring is installed.

Same here, ubuntu 18.04 and gnome-keyring is installed.

Does it help to create it maually as described here? https://github.com/zalando/go-keyring#linux

Take a look at: https://github.com/zalando/go-keyring/issues/45 where I've managed to get it running on docker with Ubuntu 18.04.


Deprecate or remove ScopeManager.active()

ScopeManager.active is documented as a feature used to get the current span. Perhaps it is a relic from the previous design. It tempts people to call close on it eventhough ScopeManager is pretty clear that scopes should be managed directly.
I would remove this api, possibly for ScopeManager.activeSpan if that's the intended use case to serve. Otherwise, please clarify the documentation that calls to close are undefined.
If folks are doing things like subclassing, you can deprecate the api, and they can still offer "advanced" things as they exist today as their subtype would still be able to offer that functionality regardless of it it exists on a supertype.
https://github.com/openzipkin-contrib/brave-opentracing/pull/74#issuecomment-380382654

Hey @adriancole thanks for the feedback.
I think that's a very valid point, and the important question here is whether there is a pattern that requires the Scope to be available around (or a pattern that cannot keep the Scope around it close it itself).
Will think some though on it and try to cook some examples (both a) the need for the current design, if any, and b) the problem of exposing it in ScopeManager)
@yurishkuro @pavolloffay @tylerbenson  may have some thoughts on it too ;)

I need ScopeManager.active in C# to access the current Scope in scenarios where the library/framework I'd like to instrument only has OnStart/OnStop hooks without any chance to store the scope somewhere.
E.g. .NET has its own OpenTracing "span"-like construct called Activity and I'm translating them to "real" spans with this code: https://github.com/opentracing-contrib/csharp-netcore/blob/master/src/OpenTracing.Contrib.NetCore/Internal/GenericEventProcessor.cs#L43-L67
If I only had access to Tracer.activeSpan I could not close the scope.

I'm probably missing something, but I don't understand the problem with that method... Why wouldn't you want a way to get the current scope from the ScopeManager?  How would you get it otherwise except from where it was originally created?  In fact, we use it in a fair bit of our instrumentation.
When writing instrumentation, it is often useful to know if there is a current active span.  We also have additional logic on our scope that wouldn't be as nice to have on the span.  I suggest leaving it as is.

I understand @adriancole concern's: Scopes were designed to be explicitly passed around...
The current API is useful when there are no "attributes" where the Scope could be stored.
brave-opentracing  does noop on tracer.active().close() which means some instrumentations do not work properly with brave. I would like to understand why it's noop, is there something specific?
I have submitted fix for it https://github.com/openzipkin-contrib/brave-opentracing/pull/83 (if there is an agreement to fix it)

After discussing with Adrian in a side channel, I am ok with his proposal to have the return type change.
I still think there should be a way to tell if there is an active trace currently happening, so if that is a method that returns the span or the span context and that result being null means no trace, then I guess that will work.

My problem with the ScopeManager.active() active API is that it implies that the same instance is returned as when the Scope has been created and that the finishSpanOnClose flag is remembered.
This makes it impossible to integrate it into the internal "scope manager" of a tracer, which is agnostic of OpenTracing. The only way to make this work in a bridge is to have a separate scope manager for the bridge. But then you can't get the active span when the span was created using the internal API and not the bridge.
In it's current form it's impossible to write a correctly working bridge for tracer.active().close(). So for the Elastic APM OT bridge, this is a noop.
So my suggestion would be to remove the finishSpanOnClose flag or to deprecate ScopeManager.active in favor of ScopeManager.activeSpan.

folks @pavolloffay seems reluctant to fix the instrumentation he made and wants to force brave to implement this dodgy api instead. Can we please get this removed?

@codingfabian @raphw are either of you in love with this api that requires implementations to track and try to return scope instances? If you are can you please comment why? If not can you please help get this removed to de-burden implementations?
It is worth mentioning that thinking about this problem from a library pov is important. Agents can fix all sorts of misbehavior, but libaries cannot. So, for example, I'm aware that folks using agents might "shrug off" less than ideal apis as they can wrangle them in mysterious ways. Think about this problem in a way where you can't just fix it via bytecode. I think you'll agree we are better off without it.

folks @pavolloffay seems reluctant to fix the instrumentation he made and wants to force brave to implement this dodgy api instead. Can we please get this removed?

I am not sure where in the world you found that I am reluctant to fix this issue in instrumentations https://github.com/opentracing-contrib/java-jaxrs/pull/88. What is sure that you are reluctant to fix this in brave https://github.com/openzipkin-contrib/brave-opentracing/pull/83#issuecomment-394284185

@pavolloffay your comment was that existing instrumentation are broken. you wrote the instrumentation leading to that issue. fixing the version <1 instrumentation or fixing the <1 api both sort the problem in ways more sustainable than cementing in the malpractice that exists in the tracer. stop pushing design problems on other repos

Well there is this spec proposal to give access to span id for example, so implementations need to provide a way to access the instance anyway.
We currently have no problem with this API.

Hey everybody,
So, trying to move on with this topic, after reading the entire thread again, these are my impressions:

Having a Scope instance around can definitely be helpful, for operations other than the usual deactivation/finish of the contained Span (as Tyler had mentioned initially, DataDog's Scope implementation has extra members/operations). Another example is the initial Akka instrumentation, where the Scope also has extra members for keeping track of fire-and-forget operations count (https://github.com/opentracing-contrib/scala-concurrent/blob/master/src/main/scala/io/opentracing/contrib/concurrent/TracedAutoFinishExecutionContext.scala)

Having ScopeManager.active() around can be very helpful when instrumenting libraries that have no context or similar to store the Scope (as @cwe1ss pointed out already). The alternative for those cases is to keep a thread-safe, weak map to store the resulting Scopes (ironically, leading to the very case Adrian mentioned for Brave ;) ).

As Adrian pointed out, having ScopeManager.active().close() easily reachable can be dangerous, as users may indeed end up closing Scope instances they don't own. However, I think this could be handled by improving the documentation and making clear the consequences of bad usage here.

So, the main issue I really see here, is the case of writing bridges to other tracing systems, and make it work just fine with their internal logic (as both @felixbarny and @adriancole pointed out), as keeping the Scope object around on their side can be problematic. I wonder if there is a way to somehow fine a proper, correct, not so complicated way to face this.

I'd say the last point is the important one, which needs to be addressed first, in order to in go in either direction - keep ScopeManager.active() around or drop it.
cc @yurishkuro @tedsuo

Hey everybody,
We would like to have a Cross-Language group call on July 13th (next week) and discuss this item as part of it. Please let me know if you guys can make it, specially @adriancole @felixbarny @cwe1ss

What was the outcome of your call?
ps on your point about "Having ScopeManager.active() around can be very helpful when instrumenting libraries that have no context or similar to store the Scope" The main concern is creating an api less likely to lead to problems. The call-sites which have no other means to pass a scope are the "infected" call sites, and take the risk without exposing it (risky stuff) by default to all call sites and consumers. In other words, yes call sites like these using thread locals or a utility like brave has, have a chance of leaking. Just the surface area is much smaller and you can easily tell where that problematic code is, because it isn't.. well everywhere.

The more I think about this, the more I tend to agree with Adrian.
Scope is basically a container for span() that can be close()-ed.
Access to the current scope (over the current span) is therefore only useful if you want to close() it or have some implementation specific extension attached to it.
In my humble opinion:

The close from anywhere is problematic. I should be controlled by the one activating the scope.
Implementation specific is something we should avoid as much as possible in an API
Perhaps scope extension should have been applied to Span instead of scope?
If still going implementation specific; why not have an implementation specific way to obtain the active scope as well?

What would absolutely break if active scope was replaced by active span and couldn't be solved otherwise?
Background: I made an adapter between my 'general purpose' context propagation mechanism and the OpenTracing ScopeManager and it was non-trivial when to close and not close the scope.

@adriancole no real conclusions. I addressed the problems with ScopeManager.active() again and also proposed to remove the finishSpanOnClose flag. I've just created an issue about that here: https://github.com/opentracing/opentracing-java/issues/291.

Are there any use cases which require to get the Scope from the ScopeManager as opposed to the active Span? If so, could we collect some code samples for that?

@felixbarny I think the case @cwe1ss pointed out some time ago still stands:

I need ScopeManager.active in C# to access the current Scope in scenarios where the library/framework I'd like to instrument only has OnStart/OnStop hooks without any chance to store the scope somewhere.
...
If I only had access to Tracer.activeSpan I could not close the scope.

https://github.com/opentracing-contrib/csharp-netcore/blob/master/src/OpenTracing.Contrib.NetCore/Internal/GenericEventProcessor.cs#L43-L67

Hey @sjoerdtalsma

The close from anywhere is problematic. It should be controlled by the one activating the scope.

I think this could be easily 'enforced' by indeed not exposing Scope but Span in ScopeManager.

Perhaps the extension should have been applied to Span instead of scope?

So this is something that could be tried with some experimental API. We could need to think how to handle the separation between activation and lifetime in Span - maybe completely separated methods for finishing and deactivating ... In that regard, the opentracing-testbed section could be used to try out such new API.

@carlosalberto

The close from anywhere is problematic. It should be controlled by the one activating the scope.

I think this could be easily 'enforced' by indeed not exposing Scope but Span in ScopeManager.

@adriancole Sounds like the point of your request? Remove active Scope in favour of an active Span ?

I'm not sure why there is a concept of removing active scope in favor of span.. why this is somehow experimental. This was in use in brave and also census for quite a long time. Retrieving the scope is the thing that causes issues. As mentioned in the initial description ScopeManager.activeSpan or similar is fine by me.
I don't know why there is cause to stall something like this with a testbed notion, but as it is already stalled for a while if you feel you need to test the idea of only returning active span, be my guest!

Hey @adriancole

I'm not sure why there is a concept of removing active scope in favor of span.. why this is somehow experimental. This was in use in brave and also census for quite a long time. Retrieving the scope is the thing that causes issues

So, if I understood correctly, you would like ScopeManager.active() to go in favor of ScopeManager.activeSpan() and keep the notion of Scope (through startActive()) otherwise? That sounds fine (by me, at least ;) )
So the testbed notion is precisely for testing how API changes could impact different use cases. The change for active() -> activeSpan() is not that complex, so it wouldn't require as many iterations in that regard (and I can do a PR myself for that); but if we decide to try to change the Scope notion, well, that would require more effort on that front, for good or bad ;)
Nevertheless, I can definitely help with that as needed.

@carlosalberto so this is still an issue.. I can see you last explained yourself are you waiting for me or someone to say go?
I just recently had to do a lot of work to avoid holding up classloaders due to scenarios such as this issue. If you are planning to address this, can you go ahead and proceed? Thanks.

Hey @adriancole
Sorry, had been busy doing other work ;) So the plan is to work tomorrow on updating the PR for #291 and have something ready for testing soon.

so far my experience with opentracing in Java has been somewhat less than stellar particularly around this api and in particular the decision to track scopes with threadlocals.
Due to heavy use of executor pools and async things I've found out of the box scope management causes many mem leaks in my case. So in some cases where I know I'm in the same thread but just want to hand over context without polluting my code, I've been trialing creating an activeSpan and then immediately closing in the callee but leaving the  span open - using the threadlocal in managed short bursts. this however requires great care and is still likely to come unstuck, but at least the option exists. without scopeManager().active() I couldnt do that.

the decision to track scopes with threadlocals

Do you have a suggestion for a better alternative?

@yurishkuro I'm not sure tbh, and certainly don't have any good answer. I've tracked my own tracing contexts in a singleton trie model, using keys that make sense available in my application to find the active span or parent in any given circumstance.  I think I might try to instrument the returned futures from the various executors and services and attempt to track the start and end of each future to maintain the tracing.  carrying the context across method calls etc if there is nothing useful to hook is very problematic though and so far the only options I can think of are all very invasive.

Not sure I follow. A central cache (your trie) is of no help unless you explicitly propagate those IDs. The point of threadlocals is that you don't pass anything between functions yet preserve the context. Take spring boot - by adding a few jars to the classpath you can get your application traced with zero code changes. I'm not aware of any technique that can do that without threadlocals or relying on some bespoke, already explicitly propagated IDs.

I'm using spring boot, but adding a few jars to my context does not get my application traced. it gets it broken with metaspace memory leaks, and closing spans too soon. the issue is that there are executors starting services and the implementations of tracingexecutorservices assume that when the Runnable/Callable ends is when the tracing ends which just isnt always the case. the executing task might hand off to other threads several times, and invoke many other async tasks before it should terminate a span.  They need to track the returned Future (if submit is called) and be very careful about the likely reuse of the same thread in a different context.
so yes - I have to manage the propagation myself except in some cases where I am sure its safe and I momentarily use the threadlocal  - mostly just so I don't have to create new implementations of all the existing things that look for a threadlocal context.

As far as I can tell, the recent discussion is different than the "let's remove scope tracking from scope manager".
Basically, @jeacott1 discusses the usual concerns about tracking futures or async work, that some work spans multiple runnables etc. This is important to understand, and why for example in zipkin we started an advanced instrumentation wiki. OTOH, it seems to me if anything an argument to remove the scope tracking requirement as it still doesn't serve the use case discussed!
IOTW, can we please proceed in removing scope tracking as it has known problems, complicates scope manager and introduces error cases such as stacking and/or what happens when it is redundantly executed etc.

fwiw anything that leans on the fork-join pool will be broken by any method that's trying to use threadlocals, and more and more I find myself using Quasar or Kotlin coroutines neither of which work out of the box (or at all) with stock threadlocals.
an external store for me was a viable solution because I was already propagating a context object and it was fairly painless to use existing id's as span reference, from where I could reliably hop threads and manage the closing of same in callbacks.
I ended up with something like this - invasive, not pretty, but functional.
Jaeger worked fine with this, but the Datadog Agent still leaked even with this. - they have different approaches to managing things which I guess highlights the fragility of the notion.
//start a span.
String spanKey = eContext.getId(); //could be anything that makes sense.
Span span = tracingSpanManager.createSpan("spanName", Tags.SPAN_KIND_CLIENT, spanKey);
...
in a callback
Futures.addCallback(futureResponse, new FutureCallback<String>() {
				@Override
				public void onFailure(Throwable e) {
              Span activeSpan = tracingSpanManager.get(eContext.getId());
              Scope scope = tracingSpanManager.getTracer().scopeManager().activate(activeSpan, false);
              scope.close();
...

///create a child span
	String childId = tracingSpanManager.putChild(eContext.getId(), "seq", Tags.SPAN_KIND_CLIENT);
			Callable<Data> callable = new Callable<Data>(){

				@Override
				public Data call() throws Exception {
					final Span activeSpan = tracingSpanManager.get(childId);
					Scope scope = tracingSpanManager.getTracer().scopeManager().activate(activeSpan, false);
...
}
...
	Futures.addCallback(callableFuture, new FutureCallback<Data>() {

				@Override
				public void onSuccess(Data data) {
                                       //finish the span.
					tracingSpanManager.finish(childId);
                                   }
...

}

I am convinced by the arguments that scopeManager.active() should go away (starting with deprecating it), especially @sjoerdtalsma https://github.com/opentracing/opentracing-java/issues/267#issuecomment-406778165 that nails it imo. Would be interesting to see if anything at all in the testbed would break if we removed it - most code should just work by switching to scopeManager.activeSpan().
I am not sure about @cwe1ss 's https://github.com/opentracing/opentracing-java/issues/267#issuecomment-382126090, as I am not that familiar with C#. The code example he provided certainly looks like an unintended API usage: creating a scope and throwing it away, then relying on active() to retrieve it. The Activity looks very much like a Span, with its own unique IDs, so it feels odd that spans are created in parallel with that. In any case, we don't need to block a decision about Java API based on the needs of C# API.
Also agree with @adriancole that @jeacott1 's issue is unrelated to this ticket - if you propagate context manually/explicitly, you have no need for "active span". Creating a scope via activate() and immediately closing it is effectively no-op (+ gc noise), unless you're using some funky scope manager impl.
I +1-ed the initial description.

@yurishkuro "Creating a scope via activate() and immediately closing it is effectively no-op" - agreed, except that in the current setup if you dont do that you arent closing the right thing. close only closes the right thing if its also active - somewhere in the docs it says that and it tripped me up initially.

Hey all,

Would be interesting to see if anything at all in the testbed would break if we removed it

I think we forgot to add a test case to showcase Christian's case (comment). But the rest of the testbed section will run just fine after removing active(), I think.
Given the feedback, I'm wondering how often the aforementioned case shows up in real life (this case has been, historically, the reason to keep active() around). But if there's enough agreement, even with this specific (C#) scenario, we could definitely consider removing it.
Opinion on this @opentracing/opentracing-java-maintainers @CodingFabian @tylerbenson ?

I am ok deprecating->removing ScopeManager.active().  It significantly increases the risk of messing up the scope stack by allowing scopes to be closed where it shouldn't. In cases where the scope needs to be accessible between two different method calls (OnStart/OnStop), it might be best to use a separate thread local for storing the scope.


Create ref-01-top-level-api.ko-KR.md

Based on 4f50071de0ac1dd6ce6aeda4f3dd9549fb9e36ba
한번 봐주세요. :)

:+1:


Tricky multiselect that isn't

In the modal to add a second layer, if you click one layer, you can't change your mind without deselecting it. it behaves like a multiselect but it isn't

cc/ @saleiva

Duplicate of #3845


Update docker ecosystem on servers to fit ansible modules requirements

https://stackoverflow.com/questions/51283708/python-pip-package-requestsdependencywarning-when-installing-elastic-search-cura
sudo pip install --upgrade cryptography
sudo python -m easy_install --upgrade pyOpenSSL

https://github.com/docker/compose/issues/1567
pip install --upgrade docker-py

for docker_stack module

apt install python3-pip
pip3 install --upgrade pip
pip3 install jsondiff

for module docker_network

pip install --upgrade docker-py
pip2 uninstall docker
pip3 uninstall docker
pip install --ignore-installed docker-py
pip2 install --ignore-installed docker-py

pip3 install pyyaml

https://plexguide.com/threads/cannot-have-both-the-docker-py-and-docker-python-modules-installed.1498/

This issues do not occur on Debian 10. Seems fixed glad to #16


Add '×' conversion to 'x'

Since this repo does not seem to be accepting pull requests, I've forked it, added this and some other pull requests and published another node module with the updates; https://github.com/larvit/larvitslugify
I've added you to contributors because you contributed. :)


Zulip - Integration - Slack_Incoming - Error JSON Format

The integration for slack_incoming webhook is in json format. When I added the wazuh integration I saw that the field ts returns that it is not integer field:
Example:
    if "ts" in attachment and attachment["ts"]:
        time = attachment["ts"].tame(check_int)
        pieces.append(f"<time:{time}>")

Error:
2023-03-07 18:19:39.782 ERR  [zulip.zerver.webhooks] ["payload['attachments'][0]['ts'] is not an integer"]

TS example:
"ts": "1678162765.24731327"

I guess that the value above is not working by checking to be an integer, as soon I switch to check_string it works perfectly fine
and additionally the time format is also shown correctly in the channel.
Correct:
    if "ts" in attachment and attachment["ts"]:
        time = attachment["ts"].tame(check_string)
        pieces.append(f"<time:{time}>")

Result:

I just want to discuss this before preparing a pull request.

@alya is there a documentation why you check against int and not string?

This is not a question for me; someone else will take a look.

@alya  is there is any help needed in it?

@zulipbot claim

@talheim-it I think you should open up an discussion in CZO. You can expect a faster response time there.

@PIG208 is the bug here that we should be using check_float instead?

Looks like the attachment feature is getting deprecated, thus the instability of the API. ts is still documented as an integer, so that is confusing. For now, check_float suffices, but we should add support to layout blocks as well.


Error! tunneling socket could not be established

Hi,
I have set the linux proxy and also the npm proxy and both are working.
When I run the pkg . it can fetch the target but than fails due to socket not established.
pkg .

<EMAIL_ADDRESS>Targets not specified. Assuming:
node6-linux-x64, node6-macos-x64, node6-win-x64
Fetching base Node.js binaries to: ~/.pkg-cache
fetched-v6.10.3-linux-x64    [====================] 100%
Error! tunneling socket could not be established, cause=connect EINVAL <IP_ADDRESS>:80 - Local (<IP_ADDRESS>:0)
Asset 'v2.3/uploaded-v2.3-node-v6.10.3-linux-x64' not found by direct link
Error! tunneling socket could not be established, cause=connect EINVAL <IP_ADDRESS>:80 - Local (<IP_ADDRESS>:0)

Can you help me?
Thanks in advance.

Seems just your network problem. Please check if github is available.

Hi,
Thanks for the reply but I can download stuff from GitHUB.
Is a specific port or protocol besides http/s?
Thanks in advance

Does it work?
curl -L https://github.com/zeit/pkg-fetch/releases/download/v2.3/uploaded-v2.3-node-v6.10.3-linux-x64 -o dummy

Hi,
Sorry for the delay.
The curl worked. If not this what could it be?
Regards
On Fri, Jun 23, 2017 at 5:58 PM, Igor Klopov<EMAIL_ADDRESS>wrote:

Closed #130 https://github.com/zeit/pkg/issues/130.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/zeit/pkg/issues/130#event-1136804020, or mute the
thread
https://github.com/notifications/unsubscribe-auth/Ab7SC1GxoEMJRKfoa0ogc9zVMGRSqO8Oks5sG-60gaJpZM4N1M78
.


[DNM][WIP] Sandbox Build to play around with USI....

Do not merge.
Using this to hack on USI.
Making use of the tools/infra to get published snapshots...

hmm, looks like forked repos don't work ;(


Mass is not conserved for reflecting boundary conditions - Sod tube problem

Hello! We are currently doing some tests with Parthenon in another code in development and thought to test AthenaPK as well if the problem occurs there. It seems that both mass and energy is not conserved for a Sod tube problem with periodic boundary conditions along x2 and x3, and reflecting along the x1 direction. We also encounter this problem for an RT test we wrote for a private code we have where we set reflecting boundary conditions along the x1 direction as well.
We compile the code using these commands
cmake -DKokkos_ENABLE_OPENMP=off -DKokkos_ARCH_BDW=on ..
and
make -j
and run the Sod tube problem with the parameter file attached. Is there a fix for this problem or is it an unresolved issue for Parthenon? I run with commit 540deb9 in the main branch.
Parameter file used
sod.txt
Run with ix1_bc and ox1_bc set to periodic
parthenon_periodic.txt
Run with ix1_bc and ox1_bc set to reflecting
parthenon_reflecting.txt
Any insight about this would be really helpful!

There is a partial fix in this work-in-progress PR: https://github.com/parthenon-hpc-lab/athenapk/pull/58


Package.json script fix and port availability fixes

Description
Changed out get-port for portfinder

Original package had issues already and didn't seem like they were being acknowledged
The issue I found originally was that get-port did not recognize the port the react client was listening on
Moved writing proxy value to index.js (makes more sense because that is where the server port is defined)

React client listening port fixed so that incase the default port was in use, the client could start on a port not in use

Finds available port and then appends PORT=<port value> to scripts.start in package.json
Removed case for EADDRINUSE error since a port will always be found

Types of changes

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

Checklist:

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

@DrGirlfriend

The issue I found originally was that get-port did not recognize the port the react client was listening on

Are you saying that get-port determined 3000 as the port for the backend, thus causing issues trying to point the backend and frontend on the same port?
This is probably because we start up 2 processes concurrently so they both try for port 3000 at the same time. To fix this, we can just ensure that get-port only returns from a certain range: getPort.makeRange(9000, 9999)

@jdelbick The backend had it's own port assigned and was not identical to the client port, but a previously started client was still listening on port 3000 (CTRL + C wasn't shutting it down, just exiting out to the terminal command prompt) and that's how I got into that scenario.

please fix the merge conflicts

btw, fixing the merge conflicts will bring up a question, how to best make the index.js runnable?
we have two options:

make-runnable npm package like what is currently in master
replace every node index start with `'require("./index.js").start()'

I'd go for the path-of-least-dependencies: replace every node index start with 'require("./index.js").start()'`.

@tmathern merge fixes look good.

@jdelbick Can this be done in a subsequent PR? Or is it breaking devtool?
If it is not breaking, I would like to do this in another PR, so the port fixes get in.

@tmathern it is not breaking, we just changed the logic to make the index.js code runnable:
instead of using a library make-runnable, we use this: https://github.com/adobe/asset-compute-devtool/blob/6ca252418f6a4bb6f00d197b2d8d4b47bf2c8576/server/package.json#L19
so we can safely remove the make-runnable dependency
but double check manually before merging


[Biomes o' plenty] Inverted fog on Wasteland

The wasteland biome from BoP has very thick fog. This seems to conflict with Dynamic Surroundings.
Removing dsurroundings removes this problem. Biome fog, elevation haze or desert fog true/false and values don't have any effect on this. It seems to be similar to inverted fog where the fog is near the player but not far from the player.
Without DS: https://gyazo.com/4d9ac1ab58241250841dd2a8872b1adc
With DS: https://gyazo.com/0807b4d0bcd491a5f5d1f0fd38427663
https://github.com/Glitchfiend/BiomesOPlenty/issues/949
Edit: Upon further testing. Any of the following combination seems to work:

Dynamic surroundings + BoP
BoP + optifine
But BoP + optifine + dsurroundings, all three together do not work. And optifine's fog settings or any setting doesn't do anything to remedy this.

Mod Version:
1.11.2-<IP_ADDRESS>
Forge Version:
forge-1.11.2-<IP_ADDRESS>7-universal

I posted a comment on the issue in the BoP tracker related to fog event handling.  For DS I will see about adding an option to disable fog handling all together so at least you can take DS out the equation.

Changed logic so that if desert fog and biome fog are both turned off all fog processing from Dynamic Surroundings is disabled.  Will be in the next BETA.

Pushed v<IP_ADDRESS> BETA version that can disable all fog processing from Dynamic Surroundings.


Fix svd function return dtype

This PR,

[x] Fixes the return dtype of svd in the draft version of the spec
[x] Fixes the return dtype of svd in the 2022.12 version of the spec

@steff456 This fix also needs to be backported to the 2021 revision.


sprintfix: 进程启动优化 (closed #1369)

Codecov Report

Merging #1469 (a8fcf8c) into v2.3.1-dev (854bbe2) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@              Coverage Diff               @@
##           v2.3.1-dev    #1469      +/-   ##
==============================================
+ Coverage       73.80%   73.83%   +0.02%
==============================================
  Files             369      369
  Lines           25136    25102      -34
==============================================
- Hits            18552    18534      -18
+ Misses           6584     6568      -16

Impacted Files
Coverage Δ

apps/node_man/apps.py
92.30% <100.00%> (+28.97%)
:arrow_up:

apps/backend/subscription/steps/plugin.py
54.45% <0.00%> (-0.63%)
:arrow_down:

...nents/collections/agent_new/choose_access_point.py
94.90% <0.00%> (-0.47%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


RFP - nanazip

Checklist

[x] The package I am requesting does not already exist on https://chocolatey.org/packages;
[x] There is no open issue for this package;
[x] The issue title starts with 'RFP - ';
[x] The download URL is public and not locked behind a paywall / login;

Package Details
Software project URL : https://github.com/M2Team/NanaZip
Direct download URL for the software / installer : https://github.com/M2Team/NanaZip/releases/download/1.0-Preview3/NanaZipPackage_<IP_ADDRESS>_x86_x64_arm64.msixbundle
Software summary / short description:  The 7-Zip derivative intended for the modern Windows experience.

It's maintained: https://community.chocolatey.org/packages/nanazip


Cannot find module "theme" in V1

Failed to compile since theme seems to be missing in the styles folder.
Steps to reproduce
Install latest version of  Material-ui v.1 and try to compile
Versions

Material-UI: 1.0.0-beta.7
React: 15.6.1
Browser: chrome  60.0.3112.90 and Firefox 55.0.2

It was renamed to createMuiTheme.

I'm about to cut another release. Also, it's most likely a duplicate


[Bug] pcd_seg_demo assert error

Prerequisite

[X] I have searched Issues and Discussions but cannot get the expected help.
[X] I have read the FAQ documentation but cannot get the expected help.
[X] The bug has not been fixed in the latest version (dev-1.x) or latest version (dev-1.0).

Task
I'm using the official example scripts/configs for the officially supported tasks/models/datasets.
Branch
main branch https://github.com/open-mmlab/mmdetection3d
Environment
(mmdet3d) lk@sun:~/mmdetection3d$ python mmdet3d/utils/collect_env.py
sys.platform: linux
Python: 3.8.17 | packaged by conda-forge | (default, Jun 16 2023, 07:06:00) [GCC 11.4.0]
CUDA available: True
numpy_random_seed:<PHONE_NUMBER>
GPU 0,1: NVIDIA GeForce RTX 3060
CUDA_HOME: /usr/local/cuda-11.3
NVCC: Cuda compilation tools, release 11.3, V11.3.58
GCC: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
PyTorch: 1.9.0+cu111
PyTorch compiling details: PyTorch built with:

GCC 7.3
C++ Version: 201402
Intel(R) Math Kernel Library Version 2020.0.0 Product Build 20191122 for Intel(R) 64 architecture applications
Intel(R) MKL-DNN v2.1.2 (Git Hash 98be7e8afa711dc9b66c8ff3504129cb82013cdb)
OpenMP 201511 (a.k.a. OpenMP 4.5)
NNPACK is enabled
CPU capability usage: AVX2
CUDA Runtime 11.1
NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_80,code=sm_80;-gencode;arch=compute_86,code=sm_86
CuDNN 8.0.5
Magma 2.5.2
Build settings: BLAS_INFO=mkl, BUILD_TYPE=Release, CUDA_VERSION=11.1, CUDNN_VERSION=8.0.5, CXX_COMPILER=/opt/rh/devtoolset-7/root/usr/bin/c++, CXX_FLAGS= -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_KINETO -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter -Wno-unused-variable -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow, LAPACK_INFO=mkl, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, TORCH_VERSION=1.9.0, USE_CUDA=ON, USE_CUDNN=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=ON, USE_NNPACK=ON, USE_OPENMP=ON,

TorchVision: 0.10.0+cu111
OpenCV: 4.8.0
MMEngine: 0.8.0
MMDetection: 3.0.0
MMDetection3D: 1.1.1+d27e65a
spconv2.0: True
Reproduces the problem - code sample
def transform(self, results: dict) -> dict:
"""Call function to map original semantic class to valid category ids.
    Args:
        results (dict): Result dict containing point semantic masks.

    Returns:
        dict: The result dict containing the mapped category ids.
        Updated key and value are described below.

            - pts_semantic_mask (np.ndarray): Mapped semantic masks.
    """
    assert 'pts_semantic_mask' in results
    pts_semantic_mask = results['pts_semantic_mask']

    assert 'seg_label_mapping' in results
    label_mapping = results['seg_label_mapping']
    converted_pts_sem_mask = label_mapping[pts_semantic_mask]

    results['pts_semantic_mask'] = converted_pts_sem_mask

Reproduces the problem - command or script
Loads checkpoint by local backend from path: checkpoints/cylinder3d_8xb2-laser-polar-semantickitti.pth
07/04 11:49:06 - mmengine - WARNING - Visualizer backend is not initialized because save_dir is None.
Traceback (most recent call last):
File "demo/pcd_seg_demo.py", line 55, in
main(args)
File "demo/pcd_seg_demo.py", line 38, in main
result, data = inference_segmentor(model, args.pcd)
File "/home/lk/mmdetection3d/mmdet3d/apis/inference.py", line 403, in inference_segmentor
data_ = test_pipeline(data_)
File "/home/lk/anaconda3/envs/mmdet3d/lib/python3.8/site-packages/mmengine/dataset/base_dataset.py", line 58, in call
data = t(data)
File "/home/lk/anaconda3/envs/mmdet3d/lib/python3.8/site-packages/mmcv/transforms/base.py", line 12, in call
return self.transform(results)
File "/home/lk/mmdetection3d/mmdet3d/datasets/transforms/loading.py", line 489, in transform
assert 'pts_semantic_mask' in results
AssertionError
Reproduces the problem - error message
python demo/pcd_seg_demo.py demo/data/000004.bin configs/cylinder3d/cylinder3d_8xb2-laser-polar-mix-3x_semantickitti.py checkpoints/cylinder3d_8xb2-laser-polar-semantickitti.pth
Additional information
用的semantickitti一张点云  通过pcd_seg_demo.py测试

我也遇到了相同的问题，请问你找到解决方案了么？
I have encountered the same problem as you. Have found the an useful solution now?

我也遇到了相同的问题，请问你找到解决方案了么？ I have encountered the same problem as you. Have found the an useful solution now?

没有捏 但是去训练点云语义分割模型是没问题的 包括测试可视化。 Not solved but there is no problem to train the point cloud semantic segmentation model including test visualization

我也遇到了相同的问题，请问你找到解决方案了么？ I have encountered the same problem as you. Have found the an useful solution now?

没有捏 但是去训练点云语义分割模型是没问题的 包括测试可视化。 Not solved but there is no problem to train the point cloud semantic segmentation model including test visualization

我刚刚试了一下test是OK的，你知道有什么其他办法可以拿到点云分割结果的标签么？
I tried the test.py in point segmentation task, which worked. Do you know any other method to get the result of point segmentation?

We not provide the semantic label for kitti 000004.bin. We will consider add a demo for semanticKITTI in next version. Thank you for reminding this problem.

我也遇到了相同的问题，请问你找到解决方案了么？ I have encountered the same problem as you. Have found the an useful solution now?

没有捏 但是去训练点云语义分割模型是没问题的 包括测试可视化。 Not solved but there is no problem to train the point cloud semantic segmentation model including test visualization

你好 我想问一下你的训练和测试可视化是怎么做的啊，我这里一直测试失败，没法可视化带有3D检测框的点云

我也遇到了相同的问题，请问你找到解决方案了么？ I have encountered the same problem as you. Have found the an useful solution now?

没有捏 但是去训练点云语义分割模型是没问题的 包括测试可视化。 Not solved but there is no problem to train the point cloud semantic segmentation model including test visualization

我刚刚试了一下test是OK的，你知道有什么其他办法可以拿到点云分割结果的标签么？ I tried the test.py in point segmentation task, which worked. Do you know any other method to get the result of point segmentation?
how do you save prediction files?


fix(deps): update gomod

This PR contains the following updates:

Package
Type
Update
Change

github.com/IBM/cloud-databases-go-sdk
require
minor
v0.6.0 -> v0.7.0

github.com/IBM/platform-services-go-sdk
require
patch
v0.62.10 -> v0.62.11

Release Notes

IBM/cloud-databases-go-sdk (github.com/IBM/cloud-databases-go-sdk)
v0.7.0
Compare Source
Features

Cloud Databases: Add new error toolchain (#24) (bc1793d)

IBM/platform-services-go-sdk (github.com/IBM/platform-services-go-sdk)
v0.62.11
Compare Source
Bug Fixes

Catalog Management: support change notices and plan id in offering instance create (#325) (66e14c5)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

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


Update to Monogame 3.8

Hello,
i would really like to use this with Monogame 3.8 and .net core...
Could you push an update to NuGet?

Sure, will have a look this weekend hopefully.

This has been done.

This has been done.


Recommended Way to Load Auth Controllers and Views for Testing Only?

I'm running into a bit of a quandary, and I fear I'm going about things the wrong way, as it seems to be an up-hill battle with every step.
How do you recommend loading all the auth stuff commonly associated with make:auth for testing packages that require the use of auth middleware or authenticated users? (This involves testing that the endpoints are secured and redirect to the login page.)
I'm currently trying to shoehorn this into the CreatesApplication file, but it doesn't look like I'm going about this the right way:
<?php namespace GeneaLabs\LaravelGovernor\Tests;

use GeneaLabs\LaravelGovernor\Providers\Service as LaravelGovernorService;
use GeneaLabs\LaravelGovernor\Tests\App\User;
use Orchestra\Database\ConsoleServiceProvider;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Route;

trait CreatesApplication
{
    public function setUp()
    {
        parent::setUp();

        $this->withFactories(__DIR__ . '/database/factories');
        $this->loadMigrationsFrom(__DIR__ . '/database/migrations');
        $this->loadMigrationsFrom(__DIR__ . '../database/migrations');
        // $this->loadViewsFrom(__DIR__ . '/resources/views');

// dd(config('views.paths'));
        config(['genealabs-laravel-governor.auth-model' => User::class]);
        config(['session.expire_on_close' => true]);
        // dd(app('router')->getRoutes());
    }

    /**
     * @SuppressWarnings(PHPMD.UnusedFormalParameter)
     */
    protected function getPackageProviders($app)
    {
        config(['views.paths' => [__DIR__ . '/resources/views']]);
        Route::get('login', ["as" => "login", "uses" => "\GeneaLabs\LaravelGovernor\Tests\App\Http\Controllers\Auth\LoginController@showLoginForm"]);
        Route::post('login', ["as" => "login", "uses" => "\GeneaLabs\LaravelGovernor\Tests\App\Http\Controllers\Auth\LoginController@login"]);
        Route::post('logout', ["as" => "logout", "uses" => "\GeneaLabs\LaravelGovernor\Tests\App\Http\Controllers\Auth\LoginController@logout"]);
        Route::get('register', ["as" => "register", "uses" => "\GeneaLabs\LaravelGovernor\Tests\App\Http\Controllers\Auth\RegisterController@showRegistrationForm"]);
        Route::post('register', ["as" => "register", "uses" => "\GeneaLabs\LaravelGovernor\Tests\App\Http\Controllers\Auth\RegisterController@register"]);
        Route::get('password/reset', ["as" => "password.request", "uses" => "\GeneaLabs\LaravelGovernor\Tests\App\Http\Controllers\Auth\ForgotPasswordController@showLinkRequestForm"]);
        Route::post('password/email', ["as" => "password.email", "uses" => "\GeneaLabs\LaravelGovernor\Tests\App\Http\Controllers\Auth\ForgotPasswordController@sendResetLinkEmail"]);
        Route::get('password/reset/{token}', ["as" => "password.reset", "uses" => "\GeneaLabs\LaravelGovernor\Tests\App\Http\Controllers\Auth\ResetPasswordController@showResetForm"]);
        Route::post('password/reset', ["as" => "password.reset", "uses" => "\GeneaLabs\LaravelGovernor\Tests\App\Http\Controllers\Auth\ResetPasswordController@reset"]);
        // Auth::routes();
        return [
            LaravelGovernorService::class,
            ConsoleServiceProvider::class,
        ];
    }
}

Thanks for your input. :)

Hi Mike,
I've not looked too much at using the scaffolded views and routes, and have used loginAs() etc.
I tend to use  getEnvironmentSetUp in the test case to set config values and such.
I'd be tempted to also pull the route stuff out into a 'tests/routes/web.php' file or similar and then include it.
Happy to chat through when you have a bit of time.

Closing - but happy to review with you Mike if still needed.


Cannot read property 'transformFile'

Hi,
I getting the error code below.
Body:{'type':'InternalError','error':[],'message':'Metro bundler has encountered an error: cann't read property 'transformFile' of undefined'}

below is package.json:
"name": "test",
"version": "0.0.1",
"private": true,
"scripts": {
"android": "react-native run-android",
"ios": "react-native run-ios",
"start": "react-native start",
"test": "jest",
"lint": "eslint ."
},
"dependencies": {
"@react-native-community/masked-view": "^0.1.7",
"@react-navigation/native": "^5.0.8",
"@react-navigation/stack": "^5.1.1",
"react": "16.9.0",
"react-native": "0.61.5",
"react-native-gesture-handler": "^1.6.0",
"react-native-reanimated": "^1.7.0",
"react-native-safe-area-context": "^0.7.3",
"react-native-screens": "^2.2.0",
"react-redux": "^7.2.0",
"redux": "^4.0.5"
},
"devDependencies": {
"@babel/core": "7.7.5",
"@babel/runtime": "7.7.6",
"@react-native-community/eslint-config": "0.0.5",
"babel-jest": "24.9.0",
"eslint": "6.7.2",
"jest": "24.9.0",
"metro-react-native-babel-preset": "0.56.3",
"react-test-renderer": "16.9.0"
},
"jest": {
"preset": "react-native"
}

Hi,
How did you resolve this ?
Thanks

Hi,
How did you resolve this ?
Thanks

yes

Hi,
How did you resolve this ?
Thanks

yes

Can you explain how did you do please ?
Thanks

Can you explain how did you do please ?
Thanks!
@mazenwrq


Update regex string for token extraction

It seems like the later versions of Bluecat API can include extra characters in the returned token, specifically "/" and "+" from my experience.
This caused issues where the token was never extracted and all queries would then fail as token would be None.

Awesome, thank you for catching this issue and contributing. I appreciate it.


isocreator: Add version 1.0

closes #5364
ISO Creator is a simple app that creates ISO images from a given folder or volume.
NOTES:

The app is built in 32-bit.
Version number is not shown in the repo, but can be found in the application.
persist is not needed because the app does not store any config by files or regsitry (tested on a VM)
autoupdate is not needed because last update was in 2009.

License is not SPDX

Unrelated, but:

app does not store any config by registry (tested on a VM)

How does one check this?


XIVY-10351 Add responsible select to base

I know the data access is getting really ugly. I just want to have the full functionality first


ticket channel is broken

What's your nodejs Version.

Show the output of: node -v latest version 16

What's the version you downloaded the bot?

From the releases e.g.: 10.2.0 latest

Desktop (please complete the following information):

OS: [e.g. iOS] windows
Version [e.g. 22]

Describe the bug

When u try to choose a category to put the open tickets in it keeps saying invalid ID while the closed tickets category works fine.

To Reproduce

Steps to reproduce the behavior e.g:
try to make a open ticket category.

Write me un discord Jordan.#1659

its easy, every function
.addField()
change it to
`
.addField({
name: "name of the embed field",
value: "could be text or a value like a number"
})


Fixes for TF 0.11

All tests succeed with these small changes.

Removed the batch_ prefix from all except matmul
Tensor class has moved to tf.

Ran 195 tests in 187.652s
OK

Thanks @icouckuy !


Use the Direct Approach in Streaming-Kafka integration.

Spark 1.3 introduced a new direct approach for integrating Kafka and Spark Streaming (without receivers). It has several advantages, as explained here:
https://spark.apache.org/docs/1.3.1/streaming-kafka-integration.html

Take High Availability features into account, we will need to store Kafka status in Zookeeper.


squid:S106 - Standard outputs should not be used directly to log anyt…

This pull request is focused on resolving occurrences of Sonar rule squid:S106 - Standard outputs should not be used directly to log anything
You can find more information about the issue here: https://dev.eclipse.org/sonar/coding_rules#q=squid:S106
Please let me know if you have any questions.
M-Ezzat

Please do not spam our projects anymore and contribute meaningfull stuff like integration of this stuff in the pom.xml. See https://github.com/graphhopper/graphhopper/pull/629 for the whole discussion.


Soundfile thought microphone

Hello Community,
there's a method to stream sound from a file (for example 'mp3') throught microphone ?
Like... you have a Voice-Client like Skype, Discord, Teamspeak (or something like this) and you execute pizzicato and the Partner hears this Sound ?
Thank you very much and best regards.

Checked and dont worked with the default Sound API... :(


fix x-domain

Fixing the x-scale domain makes the visualization more stable during interaction. I also used the format option to round the displayed x values, rather than rounding the thresholds themselves to ensure uniformly-spaced thresholds in log space.

Thank you so much @mbostock! I wasn't sure how to do this 🙏 indeed it is much better for user experience :)


wrong coloring of variables of name number/boolean/string

VSCode Version: Version 1.3.0-insider (1.3.0-insider)
OS Version: 6bc81df453ab2156d2630fbb89ad7d0c80620420

The highlighting is a bit off for JavaScript/Typescript

Another one that I often see

This issue was moved to Microsoft/TypeScript-TmLanguage#186


WFLY-14971 Singleton deployment tests still failing intermittently

https://issues.redhat.com/browse/WFLY-14971

Adding hold label until verified via sufficient CI runs.

So far, so good.  I will focus rerunning on Linux SM - JDK 8 jobs, as these test seem to fail most often with that configuration.

@rhusar Please review.

This looks good now.  No singleton deployment test failures seen.


Want To add more Web Development Projects

@ghostmkg

Want To add more Web Development Projects
Please assign this issue under Hacktoberfest or Hacktoberfest2024

https://youtu.be/-KpH4fXBO3s?si=1xpDfQ8z6puIHAbP
Watch this video how to contribute.


Improve the description of splits and fees

These clarifications are based on the discussion https://github.com/Podcastindex-org/podcast-namespace/issues/434#issuecomment-1435657259
It is clarified that the meaning of split differs depending on whether fee is false or true.
Three examples are provided:

No fee recipients, splits add up to 100. Additionally, it is demonstrated how to batch payments.
No fee recipients, splits don't add up to 100.
Both fee and non-fee recipients are present.

The new version includes some LaTeX for mathematical expressions (e.g., $\dfrac{50}{50 + 40 + 10}$). GitHub (web version) can successfully render these, but https://podcastindex.org/namespace/1.0 may need to be updated with MathJax or KaTeX. If that's a problem, I can remove LaTeX.

Here's my understanding of the payment calculation. Hopefully I have it right:
Recipients are divided into fee recipients (fee=true) and share recipients (fee=false):

Fee recipients are paid first using split as their direct percentage of the total payment.
Share recipients are paid next using split as their share of the remaining payment (after fee recipients are paid).

All share recipient split values are summed together.
Each share recipient receives a percentage of the remaining payment obtained through dividing their split by the sum of all share recipient splits.

Here's my understanding of the payment calculation. Hopefully I have it right:
Recipients are divided into fee recipients (fee=true) and share recipients (fee=false):

Fee recipients are paid first using split as their direct percentage of the total payment.

Share recipients are paid next using split as their share of the remaining payment (after fee recipients are paid).

All share recipient split values are summed together.
Each share recipient receives a percentage of the remaining payment obtained through dividing their split by the sum of all share recipient splits.

That's exactly right!

My interpretation was that the split value coming with fee=true means a share calculated out of the total splits sum, just like for other non-fee items. But I guess that's wrong and everyone interprets it as a % value.

I find it a bit confusing that the split attribute value uses different units depending on the fee attribute value. But that's not a big deal, we just need a bit better spec description and some examples to make it clear to everyone.

Thanks! Quite clear overall I'd say. Just a minor comment.

Thank you! Merged!

I find it a bit confusing that the split attribute value uses different units depending on the fee attribute value. But that's not a big deal, we just need a bit better spec description and some examples to make it clear to everyone.

@joksas I also find this very confusing.
Having the split attribute behave differently based on the fee attribute adds complexity to an already complex setup - trying to work this out in your head is basically impossible and in my opinion will lead to a massive amount of support queries.
What is the problem we are trying to solve here?
I read through the discussion in https://github.com/Podcastindex-org/podcast-namespace/issues/434#issuecomment-1435657259 and it seems that @keunes outlined the splits logic like this:
Boost = 300 sats

App takes fee of 1% (= 3 sats)

Whatever is left (300-3=297), is split according to the value block:

Host split is 3 (= 75% of total splits) --> 0,75*297 = 222,75 (rounded down to 222 sats)
Co-host split is 1 (= 25% of total splits) --> 0,25*297 = 74,25 (rounded down to 74 sats)

However this is not how Fountain works - we take our fee on top of the boost - so our logic would look like:
Boost = 300 sats
Fountain Fee 1% = 3 sats
Cost to User = 303 sats

Original boost amount split according to the value block:

Host split is 3 (= 75% of total splits) --> 0,75*300 = 225
Co-host split is 1 (= 25% of total splits) --> 0,25*297 = 75

(we would also round down in the case of decimals)

I would strongly suggest that we think carefully around adding this layer of complexity to the spec and I'm still not sure why this change is necessary?
Surely the simplest way to reason with splits is that you 'split' the payment based on the ratio of the values? Simple to understand and no complex 'if this then that' logic.
Based on all of the above - if we are going to change the language in the spec I would suggest we remove any mention of treating fee splits differently.

The reason we formulated the split mechanics as it is today is the interaction between fees and value time split.
Say I use some service to host my show, or have additional functionality like op3  and want to send a 10% split (fee) their way. Then I insert some songs as value time split into my show. While these songs play, my own split is reduced in favor of the split for the owner of the remote item. This works as intended. But if we don't treat fees as special and don't calculate them before all other splits, the op3 split is reduced too. For a show consisting mainly of remote items, that would mean the value sent to services is reduced a lot. I'm not sure this is a side effect the producer expects when using both fees splits for services and remote items for content. Keep in mind that some services can have in their license a fixed percentage split they ask to be sent their way in exchange for the service.
My personal idea as a producer is that the percentage I want to send to some service via a fee split stays the same if I use remote items or not. But we can discuss on this if you have different ideas or find a way to obtain the same result in a easier and more intuitive way.

@francosolerio aah ok thanks for the detailed explanation that makes sense as a rational for doing this - however I still think the complexity it introduces is not worth it.
Fountain for example takes a fee split for the podcasters we onboard - and I personally would rather have our fee reduced during value time splits than over-complicate the spec and confuse everyone.

Either way - we agree the use case is this:
"As a producer I want the percentage I send to some service via a fee split to stay the same if I use remote items or not."
My questions to everyone would be:

is this use case worth supporting given the additional complexity?
which services that take a fee are calling for this?

@MerryOscar I agree the split shouldn't be a percentage, but should have the percentage derived from the split total.
However, what we need a consensus on is how to calculate the split total, because some may add all splits including fee=true and others may use just the fee=false splits. I'm in favor of simply adding all of the splits including 'fee=true' to come up with the total split, but that's not a hill I'm willing to die on.
My reason for adding all of the splits is it prevents this scenario.  Imagine the 'fee=false' are a: 50 and b: 50. So, the split total so far is 100. Now, imagine someone puts in their podcast a 'fee=true' and the split is 200. How is that handled for a 1000 sat boost? By adding all of the splits, including fee=true, this becomes less problematic.
A hill I am willing to die on is I won't ever add fees to the boost. When I boost 1000 sats, I expect 1000 sats to be taken out of my wallet, and would be bothered if I saw 1200 sats removed because the podcaster had a bunch of services adding up to 20%. That 20% should come out of the podcasters pocket not mine. And in the case above, where fees add up to 200%, the podcaster would end up sending 3000 sats even though they only intended to send 1000 sats.
The only caveat to that would be if the app decides to take a cut. I could see an argument for adding the app's cut to the top of the boost, almost like a tax, since the podcaster didn't decide which app the listener would use, and one app could decide to take a 20% cut if they wanted to. In that case, the app shouldn't get 20% of what was intended for the podcaster, because the podcaster didn't have a say in that. However, with the splits, the podcaster has complete control of the split amounts, and should be responsible for paying them out of the listeners initial boost amount.

@francosolerio I also agree that the fee should be the complete percentage as intended by the remoteItem, so if they intended for a service to get 1%, then that service should get 1%. However, the fee being a split instead of a percentage isn't an issue. Since I have to fetch the remoteItem and get it's valueBlock anyway, I just run it through my splitToPercent function to determine what the percent I send to the service would be. I actually want the fee to be a split instead of percentage, because with it being an int there's no way to enter fractional percentages for a service.
One issue I've run into using remoteItem is how to handle when the podcast value block and the remoteItem valueBlock have the same service in their splits as a fee. For example, they may both have OP3 with a 1% and 3% split effectively. So, should OP3 get 4%? I've had cases were a fee ends up combining to be 10%. What I've been doing is taking the larger of the percentages and using that instead of adding them all together.

A hill I am willing to die on is I won't ever add fees to the boost.

@thebells1111 just to be clear - we only add our fountain app fee on top of the boost - not any of the fees in the value block:
example boost for 100 sats:
value block:
- main podcaster split - 95%
- podcaster op3 service split (fee=true)  - 4%
- podcast index split (fee=true) - 1%

fountain app fee - 1%

user sends the following:
- 95 sats to the podcaster split
- 4 sats to op3 service fee
- 1 sat to podcast index

- 1 sat for fountain app fee added on top

podcaster service fees come out of the podcasters share
app fees get paid by the listener on top of the boost value so that the podcaster still gets the full amount

One issue I've run into using remoteItem is how to handle when the podcast value block and the remoteItem valueBlock have the same service in their splits as a fee. For example, they may both have OP3 with a 1% and 3% split effectively. So, should OP3 get 4%? I've had cases were a fee ends up combining to be 10%. What I've been doing is taking the larger of the percentages and using that instead of adding them all together.

this is another great example of the complexity of the if this then that logic being proposed here - the edge cases will pile up and it will be impossible to reason what's going on without a calculator or spreadsheet.
we should just add up all the splits and calculate the percentages - simple

we should just add up all the splits and calculate the percentages - simple

I'm not necessarily opposed to this, even for fees. My only concern is fees are typically used by podcasters to ensure a TLV record is sent to a service that provides them valuable stats, and I don't want to see a fee percentage knocked so low that the TLV record isn't being sent and the podcaster loses out on those stats they want.

If podcasters want to maintain a certain split at 1% - why can't hosting companies just build this into their splits editing ui instead of pushing this it onto the spec so everyone else has to run complex calculations that inevitably will produce different results in different apps, and require listeners to get out a calculator or spreadsheet to validate?

I think I agree with basically removing the concept of a "fee" split.  In the early days of working out the spec, much of this was envisioning how things would work in the future because there was literally only one client that supported the value tag (Sphinx) and they needed a fee.  Then we decided to do the PI API "fee", and it made sense to have that attribute.
But, now that we are using the splits as a way to activate third party features, the biggest issue is we can't ever do a sub-1% split, which could become a big problem at much higher totals.  If we just remove the "fee" attribute altogether then people can more easily sub-divide what they are wanting to send where.  You can still do a 1%.  But, you can also do a .5% or something else.
Will discuss in the board meeting.

@daveajones @MerryOscar I would like to hear from Cameron from IPFSPodcasting, @johnspurlock from OP3 and others who provide services relative to P2.0, as removing the fee calculation protection from VTS reduction might create unfavorable conditions for the developement of such services.

I like the idea of removing the fee concept - a split is a split.  If folks want to to use services and want these services to exist in the future, they should give them a proper split (participate in both large and small txns) and not try to come up with ways to give them as little as possible.  That's not a proper partnership.

I think standardizing on one calculation rather than this split percentage/share calculation makes it easier to understand and implement for everyone.
It may still be useful to have the 'fee' flag in there purely as a flag to denote fees vs non-fees. Some apps show them differently and it's nice to see how much of my sats are going to the podcasters vs the services/infrastructure.

I'm actually okay with removing fees as well. My only concern (and this isn't about fees), is if a podcaster has a service at a 1% split, and the remotePercentage is set to 90% with that podcast as a remoteItem, it will lower that service to .9%. That means there's a higher threshold before a TLV record is sent to that service. Maybe it's not a problem worth worrying about and I'm overthinking it, but I'd like some way for the podcasters to be able to say "Hey, this service getting a TLV record is really important to me, because I need the data".

Another thing we'll have to keep in mind is how to grandfather old valueblocks that were made with fee. I suspect one of the easiest ways is to just ignore the fee, and count that recipient as normal split.

@thebells1111 If I host my show on IPFS podcasting and decide to send 1% of my income to them (they might actually make it mandatory by license), if 90% of my content is songs with VTS 90% split, the app is actually sending ~0.1%, one tenth of what I what I expected to send. Should the producer calculate and adjust the IPFS split at the end of each show, calculating the effect of each remote item to compensate it and get back to the 1% required?
This will make things easier for apps developers (hey, that's me!), but much more obscure and unpredictable for show producers.

This should probably be in a dedicated discussion thread rather than @joksas 's excellent PR.

TLDR; (My $0.02) Keep fee=true, but don't change a share to a percentage based on "fee-true".
I've always thought the word "percentage" was a typo in the original docs. That all the split numbers were a "share". This says ...this split should be calculated as a fee, meaning its percentage (as calculated from the shares) should be taken off the top... IMO, that means even the fee is converted to a percentage based on the share value. A podcaster could then define 0.5% by making the shares add up to 200 (and setting fee=true split="1").
With remote items, fee=true was meant to pay those first before sending (90%) to the remote item. Sending 90% to the remote item comes from all the non-fee channel/item level splits. This way, a 1% split to a fee=true (op3/sf/ipfs) wouldn't be reduced 90% (to 0.1%).
If there were a fee=true recipient at the channel level, and nothing for that recipient at the item level, they would still get their fee, and be excluded from the remote item split. OTOH, if they were fee=true at the channel level, but also specified at the item level without fee=true, it's an override without a fee (so they lose 90% to the remote item with all the other non-fee entries).
Item level splits override channel level splits. So you don't add them together. Instead use the item level value. This allows the podcaster to override the default (channel) split for a specific item/episode. Explained in the last paragraph here.

As a developer I'm ok with getting rid of the "fee" concept, that would indeed simplify the calculations.
On the other hand, we can go in another direction and replace splits with percentages completely. The only responsibility for podcaster would be to ensure that the total is 100%. In a way that may look more "traditional" for producers and other non-technical people.

I would strongly advise against moving to percentages and making it mandatory to ensure the total is 100. It would make errors unmanageable by the apps and lead to a bad user experience.
What should an app do if the splits don't add up to 100?

Don't send boosts and streams: the user will think the app is bugged and complain with the developer (maybe with a bad review on an app store)
Display a panel signaling the error to the user: the user has no way to correct this and would be annoyed, as it is an error he cannot correct

Mistakes happen, podcasters are human, and all this is new. Podcast hosting provider might provide methods to enforce correctness of the total split == 10, but many podcasters code their feed by hand.
Considering the split values as shares makes the system much more resistent to all this.
In the spec we can suggest to choose shares that add up to 100 to make all the reasoning more intuitive, and the hosting providers can do the same, without making it mandatory.

Having a simple requirement for percentages to add up to 100 in a way makes human mistakes obvious. Easy to detect. When similar mistakes happen with splits there's no way to detect that. Btw, for splits it would be possible to introduce a (redundant) "splitSum" attribute to make similar check possible.
There are basically two ways to handle an incorrect percentage configuration in the app: 1) show an error message and prevent any payments for such broken configs or 2) try do "fix" the percentages doing a similar to splits calculation (and probably displaying a warning to the user). If 1) is too annoying for users, then 2) should work.
Anyway, I'm absolutely ok with splits. The only thing I would like to avoid is mixing both splits and percentages. This makes the calculations messy and, as we can see now, easy to misinterpret.

Shares and percentages are functionally equivalent if all shares total to 100, which makes 1 share equal to 1%. People who want to use percentages can enter them in as shares so long as all of their shares total to 100.
Shares have the added benefit of applying to the total amount rather than to a total of 100%. There's never a case where a portion of the total amount is undefined.
For instance, how would you express a 1/3 split between three people?

Percentage model: 33%/33%/33% = 99% leaving 1% undefined.
Share model: 1:1:1 = 1/3 + 1/3+ 1/3 = 3/3 = 100%

OK, had a few weeks of me time to emotionally recover from this thread, and I'm ready to rejoin.

Met with @MerryOscar this week, and I now believe that the following approach will cover all use cases, while being sufficiently simple:
All splits act like shares. They don't have to add up to 100.
Calculations on the player side
For recipients with splits $x_1, x_2, \ldots, x_n$, the sat amount will be distributed in the ratio $x_1 : x_2 : \ldots : x_n$.
For example, if recipients A, B, and C, have splits $5$, $4$, and $1$, respectively, then the payment should be divided in the ratio $5:4:1$:

A will receive $\dfrac{5}{5 + 4 + 1} = 0.5 = 50\%$ of the payment
B will receive $\dfrac{4}{5 + 4 + 1} = 0.4 = 40\%$ of the payment
C will receive $\dfrac{1}{5 + 4 + 1} = 0.1 = 10\%$ of the payment

Player fees
Players are responsible for forwarding listeners payments. Thus players can decide themselves what fraction (or flat amount) they charge and how—this behavior doesn't have to be described in the spec, because players will not be recipients in the feed.
Example 1
Recipients A, B, and C in the feed have splits $5$, $4$, and $1$.
App P charges 1% of the payment as a fee.
Listener sends $1000$ sats.

P charges 1%, i.e., $10$ sats.
P uses the spec to distribute the remaining $990$ sats in the ratio $5:4:1$:

A receives $50\%$ of $990$ sats, i.e., $495$ sats
B receives $40\%$ of $990$ sats, i.e., $396$ sats
C receives $10\%$ of $990$ sats, i.e., $99$ sats

Example 2
Recipients A, B, and C in the feed have splits $5$, $4$, and $1$.
App Q charges 1% of the payment on top.
Listener wants to send a $1000$-sat boost. The app charges $10$ sats on top, i.e., the listener pays $1010$ sats.

Q gets $10$ sats.
Q uses the spec to distribute $1000$ sats in the ratio $5:4:1$:

A receives $50\%$ of $1000$ sats, i.e., $500$ sats
B receives $40\%$ of $1000$ sats, i.e., $400$ sats
C receives $10\%$ of $1000$ sats, i.e., $100$ sats

Other uses of fees
If all the recipients live in a feed, the current concept of fees (i.e., take $x\%$ off the top) can be simulated using simple (share-based) splits.
The only legit use case I can think of right now is the Podcast Index, which too may simulate this behavior using simple splits.
Podcast Index use case
When players fetch value recipients via the Podcast Index, the Index currently inserts itself as a 1% fee recipient.
If the players start ignoring the concept of fees, the Index would receive too much or too little of the payment. For example, if the recipients were A and B with splits $1$ and $1$ (i.e., intending to split the payment $50:50$), and the Index was inserted as a recipient with a split of $1$, the payments would be distributed in the ratio $1:1:1$:

A would receive $\dfrac{1}{1 + 1 + 1} \approx 33.3\%$ of the payment
B would receive $\dfrac{1}{1 + 1 + 1} \approx 33.3\%$ of the payment
The Index would receive $\dfrac{1}{1 + 1 + 1} \approx 33.3\%$ of the payment

Because this is a very niche use case, I'm proposing that if the Index wants to insert itself for 1%, it can do so by transforming the splits so that it is indeed paid 1%, while the ratios in the original splits are preserved.
In this specific case, the Index would transform the splits to $99$, $99$, and $2$, and the payment would be distributed in the ratio $99:99:2$:

A would receive $\dfrac{99}{99 + 99 + 2} = 49.5\%$ of the payment
B would receive $\dfrac{99}{99 + 99 + 2} = 49.5\%$ of the payment
The Index would receive $\dfrac{2}{99 + 99 + 2} = 1\%$ of the payment

This ensures that the Index gets 1% of the payment, while A and B still split the remaining amount $50:50$.
Importantly, this transformation would only have to be done by the Index. The complexity is hidden from the players. They just use the usual share-based calculation. The philosophy is that if someone wants a more complex use case, they handle the complexity themselves. For Podcast Index specifically, I'd be happy to help @daveajones to implement this transformation.
The only disadvantage to this is that if the players expose the splits to the listeners (which I don't think they should do, they should use the percentage abstraction), the creator might be surprised to see different splits than what they set in the feed, even if the end result achieved is the same.
Why not require to add up to 100?

With the current spec, where splits are integers, this would prevent non-integer-percent recipients. We may allow floating-point splits, but that's usually avoided in financial calculations due to precision issues.
It's a UI nightmare:

If splits don't add to 100, players may block the payment
If splits don't add to 100, players may normalize the splits, which is exactly what the current spec does, so why require things to add to 100?
On the hosting side, if a user unchecks a box which says "give 5% to service X", we have to require the user to readjust the splits for every episode which has custom splits.

Some services need at least 1 sat to work?
Some services provide things like analytics by receiving a fraction of each payment. Should there be a way to signal to the players that they should receive at least something?
For simplicity, I think we should avoid it at this stage, and leave it to the players to decide how to do the rounding. Some players already ensure that each recipient gets at least 1 sat, which I personally believe is very reasonable.

Great job @joksas! This feels clear and straightforward.

No mention of Value Time Split. @joksas do you think that fees to services should be diminished during VTS segments?

No mention of Value Time Split. @joksas do you think that fees to services should be diminished during VTS segments?

I very much agree with @Cameron-IPFSPodcasting's use case, but I honestly think that for now, we should prioritize the simplicity of implementation for the players. At the moment, it's chaos and I would rather have something simple than something with more fatures but inconsistent across the ecosystem. That would mean that yes, for now, I don't think we should have the concept of fees.
In the future, when the ecosystem is more mature, and we see more services and use cases, I can see the spec being adjusted for more advanced use cases.
Currently, to ensure that services like OP3 receive at least one sat (for listen-time stats), I think we can encourage (but not require) players to send each recipient at least 1 sat (even if the exact amount is less than 1). Fountain already does that.
For services that may have minimum required percentages, for now the creators might simply need to give them a larger split to ensure that they get the required percentage even when the VTS is on.


fix: import openChannel casing in type defn

Incorrect casing causing builds to fail on unix machines which is case sensitive for imports
External Contributions
This project is not yet set up to accept pull requests from external contributors.
If you have a pull request that you believe should be accepted, please contact
the Developer Relations team<EMAIL_ADDRESS>with details
and we'll evaluate if we can setup a CLA to allow for the contribution.
For Internal Contributors
<TICKET_ID>
Description Of Changes
Add a brief description of the changes that you have involved in this PR
Types Of Changes
What types of changes does your code introduce to this project?
Put an x in the boxes that apply_

[x] Bugfix
[ ] New feature
[ ] Documentation (correction or otherwise)
[ ] Cosmetics (whitespace, appearance (ex) Prettier)
[ ] Build configuration
[ ] Improvement (refactor code)

Thanks @Ruan20795 appreciate this


Propose to install each Platform level in Windows installer.

It was reported to me (by Pierre Rousselin) that since the Coq Platform Windows installer offers the option to unselect any unnecessary package, it can be considered annoying by the users that want a lightweight installation to unselect a lot of things. Instead, the suggestion was to propose various levels + a custom one, and it seems to me that the natural thing to do is to reuse the existing levels of the Platform, i.e.:

base
IDE
full
extended
+ custom which then would allow the user to (un)select packages manually

This reminds me of a recent similar suggestion in #278.

Triage note: this would indeed be nice to have, but it is a lot of work since the selection process in NSIS essentially has to be coded in some abstract assembly language. Set to low prio.


adding css lib build task

Hi!
Having a css build task for 'lib' (webpack, browserify, etc) components would be good to distribute the components' styles on npm. This PR follows the same style you did for the 'dist' counterpart :)

ping :)


Could not clone Unreal Engine

Hi,
I have already connect my GitHub account to my Epic accout, but I still cannot clone Unreal Engine for CARLA.
Any help?

Please give more information. What command are you executing and what was the error that occurred?

issue closed. It's because that I didn't verify on Github.


On-demand List allocation in Values<> type

Previously we would allocate (up to) 4 lists in the IEnumerable<object> constructor on Values<>. This is fine when we have all types supported by Values<> present in the JSON we are reading but is overkill when we have less than that.
This change is effectively just-in-time list construction where we only instantiate that type when we actually have an item of that type.
According to my benchmarks, there is a 1.5% decrease in allocations - likely as a best case. As a worst case (a Values4 has all 4 types present in JSON), the allocations should be the same.

There is an interesting quirk with this change - it now shows the problem I mentioned in #116 more obviously. With that in mind, this now depends on #116 - once that is merged, then I can rebase this on that and we can try again!

Happy to take this. Just got some failing tests.

I've rebased this on top of master now that the refactoring of OneOrMany is now merged - now the tests are passing.


⚠ Fortnite has degraded performance

In 9b6f09f, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1604 ms

Resolved: Fortnite performance has improved in 717f0d4.


v3.x no  release tag

The centos7 3.10 kernel environment cannot compile yara 4.x and can only use yara 3.11, but go-yara only has v1.x v4.x tag and no v3.x

Please use the 1.x version which is compatible with YARA 3. I had originally intended to provide tagged 3.x releases with changed API, but I never got around to it.


Undocumented exceptions thrown by System.Windows.Media.ColorConverter.ConvertFromString()

https://docs.microsoft.com/en-gb/dotnet/api/system.windows.media.colorconverter.convertfromstring?view=netframework-4.7.1#System_Windows_Media_ColorConverter_ConvertFromString_System_String_
The ConvertFromString(String) method isn't documented as throwing any exceptions, but at least throws a FormatException for invalid input. I haven't done a PR, as I don't know what exceptions are thrown by any overloads etc.

Thanks @ChrisMaddock. You can see the source for that at https://referencesource.microsoft.com/#System/compmod/system/componentmodel/TypeConverter.cs. We're adding this to our backlog but feel free to jump in.

it throws NotSupportedException when the input string is null or if there are any unsupported values in the string according to the line below https://referencesource.microsoft.com/#System/compmod/system/componentmodel/TypeConverter.cs,256 , the other overloads also seems to throw the same exception. But it isn't mentioned in the docs . Should I create a PR for this?

If you'd like to create the PR, @Niladri24dutta, we'll be delighted to review it.

@rpetrusha ok I will create a PR for this, is there any existing format to show the exception for any method in the docs ? Should I follow any reference?

Yes, there is an existing format, @Niladri24dutta. It uses XML. The following is an example that illustrates the <exception> element, as well as the two elements  (<paramref /> and <see langword />) most commonly embedded in text:
<exception cref="T:System.ArgumentNullException">
          <paramref name="array" /> is <see langword="null" />.</exception>

There is an <exception> element for each exception, and the set of <exception> elements follows the <remarks> element.
The documentation is in the dotnet/dotnet-api-docs repo in the xml folder.
Let me know if you have any questions.


Update Caleb's name

https://calebhearth.com/why-hearth

Thanks, Chad
On September 18, 2021, GitHub @.***> wrote:

Merged #319 https://github.com/thoughtbot/griddler/pull/319 into
master.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/thoughtbot/griddler/pull/319#event-5323265787, or
unsubscribe <https://github.com/notifications/unsubscribe-
auth/AAFNYJP57KEGB6QBIOM6W3LUCSZKZANCNFSM5EAXATMA>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-
email&mt=8&pt=524675> or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-
email%26utm_medium%3Demail%26utm_source%3Dgithub>.


init client

ci: mv codecov.yml
feature: init client
ci: add codecov and testing

Codecov Report

Merging #6 (38f3a0f) into main (0ba623f) will increase coverage by 1.41%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main       #6      +/-   ##
==========================================
+ Coverage   82.45%   83.87%   +1.41%
==========================================
  Files          14       16       +2
  Lines          57       62       +5
==========================================
+ Hits           47       52       +5
  Misses         10       10

Flag
Coverage Δ

client
100.00% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

client/lib/ledgex_client.dart
100.00% <100.00%> (ø)

client/test/ledgex_client_test.dart
100.00% <100.00%> (ø)


HOSTEDCP-967: Drop conversion webhook and v1alpha1 code

What this PR does / why we need it:
Drop conversion webhook and v1alpha1 code.
continuing the work of Alberto in #2267
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #HOSTEDCP-967
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/retest-required

closing in favour of https://github.com/openshift/hypershift/pull/2596


Bug 2136425: Windows 11 is detected as Windows 10

Signed-off-by: Aviv Turgeman<EMAIL_ADDRESS>📝 Description

windows VMs have double labeling for the os name for the guest agent
inconsistent os naming in vm overview, vm details and vmi details

🎥 Demo
Before
VMI details

VM details

VM overview

After
VMI details

VM details

VM overview

/retest

/bugzilla refresh

last iteration focuses on the wrong details received by getting the wrong vmi from useK8sWatchResource
Before
https://user-images.githubusercontent.com/67270715/203768447-3901657d-6e32-471b-b886-da45fd24689a.mp4
After
https://user-images.githubusercontent.com/67270715/203768470-b417b60f-23ab-4a8a-8a0c-3d9abe1d716f.mp4

/cherry-pick release-4.12


Snapshot fix

Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

There's an actual bug with the run / export button due to the changes we made on the pipeline editor - the validation is looking for a field that has been re-arranged in the node definitions here: https://github.com/elyra-ai/pipeline-editor/blob/54b5a1e0c41d540b001b9145c328bae1186c1ed8/packages/pipeline-services/src/validation/index.ts#L62


DEPTH_TEXTURE broken on mobile GLES 3

Godot version
3.5 beta 5
System information
Android 12, Adreno 640
Issue description
When I exported a project using GLES 3, proximity fade materials vanished. I converted the spatial material to a shader material and set it to display the DEPTH_TEXTURE and it's is pure black. Depth texture seems correct on GLES 2, but it's precision is too low to be usable in large meshes.
On PC it look like this:

On mobile it look like this

PC with GLES 2:

Mobile with GLES 2:

Steps to reproduce

Add any mesh to a scene.
Add a spatial material with proximity fade to the mesh.
Export to mobile using GLES 3 renderer.

Minimal reproduction project
ProximityFadeIssue.zip

Depth texture seems correct on GLES 2, but it's precision is too low to be usable in large meshes.

You can force high precision in the Project Settings (Enable High Float.Android).


Plunker not working

This issue tracker is for Bug Reports and Feature Requests only.
Please, direct requests for help to StackOverflow.  See http://bit.ly/UIR-SOF for details.
This is a:

[ ] Bug Report
[ ] Feature Request
[x] General Query

My version of UI-Router is: (version)
latest

[ ] I have already asked my question on StackOverflow and nobody could answer the question

[ ] I have already reviewed the sample application for examples of common approaches

[x] I believe my question can only be answered by the UI-Router maintainers

Hi,
I am trying to use https://ui-router.github.io/ng1/tutorial/helloworld for a tutorial. But somehow, the plunkers in the live demo are not working. Attaching the screenshot for the same.

Fixed


IMPRO-1446: removing extrapolate from optical flow

Removed extrapolate from optical flow

only calls optical-flow
stops the saving of the extrapolated files
remove tests
removed argparser args

Saved the 2 files as a cubelist rather than 2 cubes

process returns cubelist
saves that cubelist
update tests
make argparser take n output argument for the output filepath.

Testing:

[x] Ran tests and they passed OK

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 1

Complexity decreasing per file
==============================
+ lib/improver/cli/nowcast_optical_flow.py  -2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 1

Complexity decreasing per file
==============================
+ lib/improver/cli/nowcast_optical_flow.py  -2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 1

Complexity decreasing per file
==============================
+ lib/improver/cli/nowcast_optical_flow.py  -2

See the complete overview on Codacy


Print all local variables

It would be nice to be able to print all local variables so inspection could be easier.

This should be easily achievable with op(locals()), and lack of meaning to implement.


Improvements to _.isEqual comparisons for typed arrays and DataView

Fixes #2875 by taking the .byteOffset into account when comparing two typed arrays.
Factors out the internal toDataView function as the single source of truth on how to correctly cast (or shallow copy) buffer-like objects to DataView.
Adds an optimization to avoid byte-wise comparisons between DataViews that have identical buffer, offset and length.

@carpben @mafiosso @sktguha @yashshah1 I would welcome a review by one of you.
(@jashkenas you are of course also welcome to review. I'm however addressing other reviewers because I know your time is scarce and because the change doesn't seem dramatic enough to require your attention.)

Coverage increased (+0.008%) to 96.288% when pulling 00d64f42cb2d4745211a657629a4406bd827f6ca on jgonggrijp:fix-2875 into 7ee13c8a470e1a1c6bd6d5f3fee29e92d40b6c17 on jashkenas:master.

Thanks for the mention @jgonggrijp 😊😊. Will check in the morning

@jgonggrijp two comments

I could be wrong, but it seems Buffer exposes a .equals method
so the issue given in #2875 could simply be fixed by using the .equals method given by default.
i.e
const a = [Buffer.from([1, 2, 3]), Buffer.from([1, 2, 3])];
const b = [Buffer.from([4, 5, 6]), Buffer.from([4, 5, 7])];
const c = [Buffer.from([1, 2, 3]), Buffer.from([1, 2, 3])];

const isEqual = (a,b) => {
if(a.length !== b.length) return false;
return a.every((aElem,i)=> aElem.equals(b[i]));
}
console.log(isEqual(a,b)); //return false -> Correct
console.log(isEqual(a,c)); //returns true -> Correct
//of course this assumes both arrays have only Buffer, but you get the idea
//This approach also fixes your regression test that you have added in this PR, https://github.com/jashkenas/underscore/pull/2876/commits/20a39e75c755d3d17142f7bea0b931edec0816d4
var shared = new Uint8Array([1, 2, 3, 4]);
var view1 = new Uint8Array(shared.buffer, 0, 2);
var view2 = new Uint8Array(shared.buffer, 2, 2);
console.log('reg test', Buffer.from(view1).equals(Buffer.from(view2))) // returns false, which is the correct result acc to your test

Also I found an interesting comment on stackoverflow regd performance of such tests
"You can also further optimise the test by comparing an aligned prefix (e.g., given 131 bytes, comparing the first 131 bytes as longer words then comparing the final three bytes one-byte at a time)."
Here is the link:  https://stackoverflow.com/questions/21553528/how-to-test-for-equality-in-arraybuffer-dataview-and-typedarray#comments-52181275:~:text=You can also further optimise the,three bytes one-byte at a time).

So if it requires any code changes, please let me know . As it would be Really Cool 😎😎😎 for me to push code to underscore itself.

Thanks for the very interesting feedback @sktguha!
You are more than welcome to contribute code. If you agree that my code could be faster, but is still correct, I suggest that we merge this first and that you then submit another PR with optimizations. Would that order work for you?

Sure Julian, that does sound good
But I am wondering is that if we have the .equals readymade method available, do we really need to convert to ArrayView as it is being done currently
One case where we might still need the conversion is that the .equals method is not supported but the ArrayView support is there. Not sure if that will ever be the case as I think it's a recent feature and it's nodejs , not browser environment, so there kind of things maybe are not present.
Also regards the performance comparison between . equals method and conversion to ArrayView , let me make a jsperf. But not sure if jsperf and other tools support nodejs. Otherwise let me test on local machine.

@jgonggrijp But ok if its an important fix we can go ahead and merge. ya later I can make another PR for optimisation.
looks good to me otherwise (LGTM)

Performance testing is definitely a good idea.
I'll merge this now so you can use the master branch as your base.

so can we discuss about future improvements here or I should create a new issue for the discussion ?

Here is fine, or you can already create a draft PR for your submission.

sure. let me think of the things to do in the new PR ,and come back


(Vaal) Righteous Fire gem quality does not change DPS

Changing gem quality on either Vaal Righteous Fire or Righteous Fire gems does not increase Righteous Fires DPS Despite quality adding +1% Increased Spell Damage per quality.
Vaal Righteous Fire does change DPS correctly for itself.

In fact, this is a bigger issue than first thought. It seems additions to spell damage as a whole are not being reflected in either Vaal or normal Righteous Fires DPS calculations.
https://pastebin.com/VYUyNKfK
Selecting the passive node "Light of Divinity" for instance, only increased Righteous Fire (and Vaal RF) DPS by 0.2% due to the life change.