@ThreadContextConfig / @ManagedExecutorConfig are superfluous

Currently we have two different ways for a user to configure a ThreadContext or a ManagedExecutor:

in procedural code using a Builder, or
using a Config annotation that performs injection.

The annotation-based approach is ever so slightly less verbose, and the builder-based approach lets one specify attributes based on runtime conditions, but other than that there's not much difference AFAICT.
It's not necessary to have two ways to do this thing. Assuming that the extra flexibility of a Builder is actually truly useful, then I would get rid of the annotation. It is very easy in CDI to create a little producer method that builds something and binds it to the CDI application scope. It is not the CDI way to have injection annotations with lots of configuration attributes that then get copy/pasted all over the codebase.

The builders were originally added so that MicroProfile Concurrency could still be used in the absence of a CDI implementation (one of the original contributors asked for this).  For the most part, the capability of the builders does overlap the capability of the config annotations.  The builders add some additional versatility due to their programmatic nature and I think they make user errors more debuggable due to exception stacks pointing directly back to the line of application code where it was misconfigured.  On the other hand, the container-injected CDI instances do provide a more concise way of specifying configuration, and they also ended up allowing for a convenient way to let the user override individual instances via MP Config even if the application isn't written with MP Config awareness in mind.

injection annotations with lots of configuration attributes that then get copy/pasted all over the codebase.

The intent was to avoid this sort of thing, in that the spec also included a NamedInstance qualifier specifically to allow for a single injection point with a config annotation to act as an implicit producer, such that injection points elsewhere could inject that same instance by specifying only the NamedInstance qualifier with the same value.
My comments above are intended, as much as possible, to be an unbiased summary of the differences that I am aware of between the builders and the config annotations.
@manovotn who works on WELD and has been heavily involved in this spec has a lot of depth and expertise in this area and will be better able to comment on this issue and assess what action should be taken here.

Personally I agree with @gavinking here. I think the config annotations don't add much value beyond what the builders offer. Additionally, the config annotations add a lot of complexity to the spec because of instance sharing considerations.
If a user wants to inject things with CDI, a standard field-based producer is simple enough:
@Produces @ApplicationScoped
ManagedExecutor exec = ManagedExecutor.builder()
          .maxAsync(5)
          .propagated(...)
          .cleared(...)
          .build();

Since we've already spent a disproportionately large amount of time discussing the config annotations, I'm fine leaving things as they currently are in the spec as a compromise. However, personally I am still in favor of scrapping the config annotations entirely.

That's a tough question. I guess I'm neither for nor against them, except I assume we have use-cases for looking up commonly configured ThreadContext (or ManagedExecutor) objects, such as "all contexts propagated", "all contexts cleared", "all contexts propagated except transaction". We could argue that getting those injected with a name (or qualifier annotation) is easier than calling the builder, but really we could have static methods for those that would be simpler than either form of injection.
I would say we keep them because we spent a lot of time implementing them, and it's possible that users will prefer them over the builders, but those are pretty weak arguments (from a non-implementer perspective). Consistency with other MP specs could be a valid reason to keep them, if other MP specs have equivalent annotation/builder splits.

I think this complaint comes a bit late as, much like others above me said, we've already spent some considerable time designing that. It is true that you can instead use builders and producers.
However, this puts some extra weight on user to correctly define the producer - for instance using other then application scope can result in unexpected behaviour. The way we have it, you get everything out of the box, no handling the create/destroy, all beans for your IPs are automagically added, sharing included. You can still have your own producers if you wish to but the way I see it, when you write a CDI producer, you are trying to turn an object that wasn't meant to be a bean into one.
Like you said, there isn't a clear benefit you get from this approach as opposed to going pure builder model. It's more like giving users multiple options, you can use whichever approach you prefer. Having it though makes CDI a first class citizen.
Furthermore I would say that purely annotation-based approach is rather popular lately so having these annotations in place supports this model. I am not saying the model is better or clearer, I have just seen it used quite often, including some configuration on it.
So overall, unless having these annotations somehow blocks us, I don't really see any strong argument to remove them (albeit the arguments to keep them are equally weak).

@njr-11

the container-injected CDI instances do provide a more concise way of specifying configuration

Well, on the contrary, they are only just barely more concise and only when you get down to the level of counting tokens. They're no simpler in terms of writability/readability, and it's at least arguable that they add complexity by forcing the user to have to decide between two essentially equivalent constructs that do the same thing.

On the other hand, the container-injected CDI instances do provide a more concise way of specifying configuration

No. This is pretty much a misuse of CDI. The whole point of CDI is that you want to avoid doing configuration at injection points. You want to do it in one central place (a producer), and in that case it makes no difference whether it's a builder or an annotation.

The intent was to avoid this sort of thing, in that the spec also included a NamedInstance qualifier

Ugh. If you mean @Named, that's also a misuse of CDI. One shouldn't inject on the basis of stringly-typed identifiers. Those are only really for use within dynamically-typed UI definitions.

I would say we keep them because we spent a lot of time implementing them

I think this complaint comes a bit late as, much like others above me said, we've already spent some considerable time designing that.

Sorry, folks, but these are really bad arguments for making an API more complex. I've had to remove things I liked from a spec based on feedback in the weeks before release (yeah, the CDI spec, ironically), and I did it happily because it was the right thing to do and made the spec simpler and easier to learn.
Time you've spent designing/implementing something not very useful is a sunk cost and doesn't come into this decision.

It is true that you can instead use builders and producers. However, this puts some extra weight on user to correctly define the producer

But they should to use a producer whether they're using builders or annotations. So this argument seems to fail.

for instance using other then application scope can result in unexpected behaviour.

AFAICT, the "unexpected behavior" is non-harmful.

The way we have it, you get everything out of the box, no handling the create/destroy, all beans for your IPs are automagically added, sharing included.

Except that you don't. What you're doing is leading the user down the wrong path of re-defining in the configuration at the injection point, instead of having the configuration in one place.

You can still have your own producers if you wish to but the way I see it, when you write a CDI producer, you are trying to turn an object that wasn't meant to be a bean into one.

This statement makes no sense to me at all, and I wrote the CDI spec.

I don't really see any strong argument to remove them

It makes (a) the API surface smaller, and (b) the spec simpler. These are always strong arguments.

I didn't state a position on this in the previous posts, which were mostly focused on trying to ensure that the two approaches were fully understood, so that we can come to the right agreement for the right reasons.  I am willing to remove @ManagedExecutorConfig and @ThreadContextConfig from the spec if we have agreement from @manovotn and other contributors who had previously advocated for them.
There is one further area that still needs to be clarified, which is @NamedInstance, which is not the same as @Named

Ugh. If you mean @Named, that's also a misuse of CDI. One shouldn't inject on the basis of stringly-typed identifiers. Those are only really for use within dynamically-typed UI definitions.

As one of those who were previously advocating for application-defined producers vs the config annotations, the main obstacle we saw in that case was the learning curve for the basic user to create their own CDI qualifier(s) in order to differentiate the various managed executors that they produced.  I suggested it would be convenient to use the built-in @Named annotation for this, but was told that isn't proper usage and was directed that the right approach would be for us to define our own qualifier of the same form for this purpose, which we called @NamedInstance.  Based on the reasoning behind your arguments against @Named, I expect you would have the same concerns with @NamedInstance as well.  If so, do you have a better alternative here?

There is one further area that still needs to be clarified, which is @NamedInstance, which is not the same as @Named

Where is @NamedInstance defined?

Based on the reasoning behind your arguments against @Named, I expect you would have the same concerns with @NamedInstance as well. If so, do you have a better alternative here?

Well if it amounts to injecting an object on the basis of a string name, then it's isomorphic to @Named, and I don't see why you would not just use the built-in one.
But yeah, it's the wrong way to use CDI. String-based names are untypesafe and very fragile. The whole point of the system of injection in CDI is that you're supposed to use typesafe identifiers for things.

the main obstacle we saw in that case was the learning curve for the basic user to create their own CDI qualifier(s) in order to differentiate the various managed executors that they produced

Well in the simple and I imagine quite common case that they have exactly one ManagedExecutor, there's no need for a qualifier annotation. (It's implicitly the @Default ManagedExecutor.
Once things get more complex, and you need to add a second ManagedExecutor to your app (which I imagine is not a getting-started type usecase), then, yes, you would typically define a custom qualifier annotation for that. But this is something that's totally plain-vanilla CDI usage, and all users are expected to understand how to do that.
(Note: you do not need to change the injection points with for the @Default instance when you add a non-@Default instance! CDI was carefully designed to avoid that need.)

Ufff.
https://github.com/eclipse/microprofile-concurrency/blob/master/api/src/main/java/org/eclipse/microprofile/concurrent/NamedInstance.java
AFAICT, this is essentially a copy-paste job of:
https://docs.oracle.com/javaee/6/api/javax/inject/Named.html
Please remove it.

I don't really see any strong argument to remove them

It makes (a) the API surface smaller, and (b) the spec simpler. These are always strong arguments.

And, of course, (c) you're imposing a requirement that all future implementors of MP Concurrency also implement this annotation-based injection stuff.

I wasn't really advocating for this, it pretty much existed by the point I started taking part in the spec.
From there I figured that there was an intention to have this CDI-first approach and we were going over it, especially over how to share it and how to implement this. In order to "support CDI" in the spec it seemed reasonable to provide this kind of structure we have here.
So if we want to back out of that, we can, I am not blocking that.
Just note two things:

There is no feedback on usability as we ponder over this, so we cannot know what users really mean to use.
A conversation similar to this happened before and people seemed to be in favor of supporting CDI injection with configuration annotations so I was just kind of surprised at the change now that we have it TCK-covered and are nearing releasable state.

As a side note - the @NamedInstance is pretty much the same as @Named except that @Named is linked to bean names and the ability to resolve beans from just a string (in JSF for instance). We didn't want to mix the two but wanted to give user a way to name their executor that they are going to share from several points in the code while referring to them via the name they chose. That's just the background of how this came to be...

On the MP Concurrency call, we confirmed that all were in agreement with the approach of removing the config annotations and NamedInstance.  This will be replaced in the spec doc with an example of the best practice of using an ApplicationScoped producer that uses the builder.

Great! +1


Partly address #120 and include ISF in suggestion.json

pull out current calculated ISF from oref suggestion and make available via $state.isf
partially addresses issue from #120

So far, this is useless, but in the future it may come in handy.


[Feature request]: Improve rest exceptions or use a more functional pattern

General Info

[X] I installed the latest version of Supabase Kt
[X] I checked for similar feature requests

Feature request
Currently, there's primarily one exception type: RestException which is hard to catch because you don't know exactly whats causing the Rest Exception without parsing the raw error.
Now the library could either parse the exception and throw corresponding exceptions (1) or use a more functional pattern which forces developers to handle the result (maybe using arrow-kt ?) (2).
Independently of that, results of Postgrest Calls must be improved severely
Example for (1)
try {
   gotrue.getUser("id")
} catch(e: UnauthorizedException) {

}

Example 1 for (2)
val result = gotrue.getUser("id")
when(result) {
      is Result.Success -> //
      is Result.Unauthorized -> //
}

Example 2 for (2) using arrow-kt (which has the advantage of already being there, and could be implemented easily)
val result = gotrue.getUser("id")
when(result) {
  is Either.Left -> when (result.value) {
    is UnauthorizedException -> //
    is IllegalArgumentException ->//
    else -> "Unknown error"
  }
  is Either.Right -> println(result.id)
}

Usecase
Error Handling

Even though I'm a happy arrow user for years and I'm all for specifying sealed error domain wherever possible, I'm not sure if it's very ergonomic to add arrow as a dependency and make error handling harder to understand (although better). Until we (hopefully) get union types providing sealed error domain does not provide ready to use solution for the consumers. Consumers would have to map error domain of this lib to their error domain anyway. Maybe it'd be best just to provide clear sealed hierarchy extending <some>Exception and throw them. Wrapping library calls in Either/Effect/Result etc. is straightforward (and users are gonna be mapping errors to their own domain anyway). This'd keep the library unopinionated about error handling (and not scaring potential consumers with words like monad 😆 ), while retaining clear, easy to use, easy to understand error domain.

Yea also thought about that, it might be best to just stick to the standard try catch way. Thought about adding a new parseException method to the Main Plugins (as the error responses are always different), and reworking the way the plugins make rest calls, so the library could handle exceptions and authenticated routes automatically

Regarding the "more functional pattern". There are some very nice things coming in the future. With context receivers we can specify that the function can be called only in a scope that can handle the problem. For example my wrapper looks like this:
context (EffectScope<ApplicationError.IO.DatabaseError>)
suspend inline fun <reified RES : HasIdentity<*>> Postgrest.list(
    tableDescriptor: TableDescriptor<RES, *, *>,
    crossinline where: PostgrestFilterBuilder.() -> Unit = {},
): List<RES> =
    attempt {
        catching {
            get(tableDescriptor.tableName)
                .select(filter = where)
                .decodeAs<List<RES>>()
        }
    } mapLeft {
        Napier.d(throwable = it) { "" }
        ApplicationError.IO.DatabaseError(it.message.orEmpty())
    }

Unfortunately context receivers are still experimental and available only for JVM.


Create 0000-01-02-1203166966.md

layout: slide
title: "Welcome to our second slide!"
Your text
Use the left arrow to go back!

more commit


WinAppDriver Dont support Appium-Python-Client higher version than v2.2.0

Dear experts:
I encounter issues like below picture when use:

Appium-Python-Client 3.2.1
selenium 4.18.1
WinAppDriver 1.2.1

to do simple windows app automation like Caculator. But with Appium-Python-Client 2.2.0/selenium 3.141.0/WinAppDriver 1.2.1  works well. I found from Appium-Python-Client 2.3.0 it has big changes about options that need higher version of selenium, after upgrade selenium version, it always has errors like below picture, do you know how can I solve the problem? Thanks very much

According to this answer, higher versions of Appium uses Selenium 4, which uses the W3C protocol. However, WinAppDriver uses the JSON Wire Protocol. So they are incompatible. You can either use Selenium 3.14 or use the Appium Windows Driver. Note that the appium windows driver does not support actions other than touch or pen actions!


python311Packages.stanza: 1.7.0 -> 1.8.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python311Packages.stanza is: Official Stanford NLP Python Library for Many Human Languages
meta.homepage for python311Packages.stanza is: https://github.com/stanfordnlp/stanza/
meta.changelog for python311Packages.stanza is: https://github.com/stanfordnlp/stanza/releases/tag/v1.8.0
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.8.0 with grep in /nix/store/qjqc50591lwg4h9g86zbm9j3fr2yhrpj-python3.11-stanza-1.8.0
found 1.8.0 in filename of file in /nix/store/qjqc50591lwg4h9g86zbm9j3fr2yhrpj-python3.11-stanza-1.8.0

Rebuild report (if merged into master) (click to expand)

7 total rebuild path(s)

7 package rebuild(s)

First fifty rebuilds by attrpath
libretranslate
python311Packages.argos-translate-files
python311Packages.argostranslate
python311Packages.libretranslate
python311Packages.stanza
python311Packages.translatehtml
python312Packages.stanza

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/qjqc50591lwg4h9g86zbm9j3fr2yhrpj-python3.11-stanza-1.8.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python311Packages.stanza https://github.com/r-ryantm/nixpkgs/archive/c2cadb4e3f980c40f649c66716fdc11119766871.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/c2cadb4e3f980c40f649c66716fdc11119766871#python311Packages.stanza

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/qjqc50591lwg4h9g86zbm9j3fr2yhrpj-python3.11-stanza-1.8.0
ls -la /nix/store/qjqc50591lwg4h9g86zbm9j3fr2yhrpj-python3.11-stanza-1.8.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package marked as broken and skipped:

python312Packages.stanza

1 package failed to build:

libretranslate (python311Packages.libretranslate)

4 packages built:

python311Packages.argos-translate-files
python311Packages.argostranslate
python311Packages.stanza
python311Packages.translatehtml

Maintainer pings
cc @riotbib for testing.

Result of nixpkgs-review pr 291323 run on x86_64-linux 1

2 packages marked as broken and skipped:

python312Packages.stanza
python312Packages.stanza.dist

2 packages failed to build:

libretranslate (python311Packages.libretranslate)
libretranslate.dist (python311Packages.libretranslate.dist)

8 packages built:

python311Packages.argos-translate-files
python311Packages.argos-translate-files.dist
python311Packages.argostranslate
python311Packages.argostranslate.dist
python311Packages.stanza
python311Packages.stanza.dist
python311Packages.translatehtml
python311Packages.translatehtml.dist

Result of nixpkgs-review pr 291323 run on x86_64-linux 1

2 packages marked as broken and skipped:

python312Packages.stanza
python312Packages.stanza.dist

2 packages failed to build:

libretranslate (python311Packages.libretranslate)
libretranslate.dist (python311Packages.libretranslate.dist)

8 packages built:

python311Packages.argos-translate-files
python311Packages.argos-translate-files.dist
python311Packages.argostranslate
python311Packages.argostranslate.dist
python311Packages.stanza
python311Packages.stanza.dist
python311Packages.translatehtml
python311Packages.translatehtml.dist

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python311Packages.stanza is: Official Stanford NLP Python Library for Many Human Languages
meta.homepage for python311Packages.stanza is: https://github.com/stanfordnlp/stanza/
meta.changelog for python311Packages.stanza is: https://github.com/stanfordnlp/stanza/releases/tag/v1.8.1
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.8.1 with grep in /nix/store/50rran3kkriiihwj4g8jvxsc7hpzz1hc-python3.11-stanza-1.8.1
found 1.8.1 in filename of file in /nix/store/50rran3kkriiihwj4g8jvxsc7hpzz1hc-python3.11-stanza-1.8.1

Rebuild report (if merged into master) (click to expand)

7 total rebuild path(s)

7 package rebuild(s)

First fifty rebuilds by attrpath
libretranslate
python311Packages.argos-translate-files
python311Packages.argostranslate
python311Packages.libretranslate
python311Packages.stanza
python311Packages.translatehtml
python312Packages.stanza

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/50rran3kkriiihwj4g8jvxsc7hpzz1hc-python3.11-stanza-1.8.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python311Packages.stanza https://github.com/r-ryantm/nixpkgs/archive/bce333f4becd7ccf5193af9e783c6d59bb0492ad.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/bce333f4becd7ccf5193af9e783c6d59bb0492ad#python311Packages.stanza

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/50rran3kkriiihwj4g8jvxsc7hpzz1hc-python3.11-stanza-1.8.1
ls -la /nix/store/50rran3kkriiihwj4g8jvxsc7hpzz1hc-python3.11-stanza-1.8.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

2 packages marked as broken and skipped:

python312Packages.stanza
python312Packages.stanza.dist

2 packages failed to build:

libretranslate (python311Packages.libretranslate)
libretranslate.dist (python311Packages.libretranslate.dist)

8 packages built:

python311Packages.argos-translate-files
python311Packages.argos-translate-files.dist
python311Packages.argostranslate
python311Packages.argostranslate.dist
python311Packages.stanza
python311Packages.stanza.dist
python311Packages.translatehtml
python311Packages.translatehtml.dist

Maintainer pings
cc @riotbib for testing.


OCPBUGS-14824: Bump gcp-filestore-csi-driver-operator library-go

Bump library-go
The library-go fix openshift/library-go/pull/1541 merged we also need to bump the library-go dependency for csi drivers operators.
$ go get -u github.com/openshift/library-go
go: upgraded github.com/openshift/api v0.0.0-20230509100629-894b49f57a15 => v0.0.0-20230613151523-ba04973d3ed1
go: upgraded github.com/openshift/library-go v0.0.0-20230508110756-9b7abe2c9cbf => v0.0.0-20230626162119-954ade536d6d
go: upgraded github.com/spf13/cobra v1.6.0 => v1.6.1
$ go mod tidy && go mod vendor

/lgtm
/label docs-approved
/label px-approved

/lgtm
/label docs-approved
/label px-approved

/test operator-e2e

/test operator-e2e-extended

/approve


Indentation inside documentation/commentary

It’d be nice if vim-indent-guides could be configured to still hilight indentation after commentary markers, if there is no non-commentary-marker code between the beginning of the line and the commentary markers themselves.

So just to clarify, do you mean showing indent guides for code that's commented out?
For example, with Ruby:
  # if true
  #   if true
  #     # some stuff
  #   end
  # end

Not just code that's commented out, but otherwise, yes, that's what I mean. My specific use-case is that most of my in-code-documentation is in markdown, and now that I've come to depend on vim-indent-guides, it gets to be a pain to visualize the difference without it.
Here's an (old) example from my own code: http://git.io/Paws.c@1c02#L55-74


Sort by column headers such as Display Name

It does not appear you can sort by any of the header names such as Display Name to put everything within some sort of order as clients are added.
Using version v0.7

Hmm, never thought of that.
I think the WinForms control I'm using will support that, however, I'm porting over to WPF to fix resolution issues on high dpi displays (see issue #4 )
I'm pretty sure that will be possible in the WPF control too.. just gotta figure out how.


[Feature Request] Unified auth mechanism and/or authentication docs

Good Morning,
When implementing auth in our version of the Orchestrator, we had to put a custom authentication function in /esnetorch.identity, and then implement the follow elements to properly enable authentication:
/monkeypatch.py
...
from esnetorch.identity.controller import oidc_security

...
class EsnetWebsocketManager(orchestrator.websocket.WebSocketManager):
    async def authorize(self, websocket: WebSocket, token: str) -> Optional[Dict]:
        try:
            await oidc_security(request=websocket, token=token)
        except HTTPException as e:
            return {"error": vars(e)}
        return None

orchestrator.websocket.WebSocketManager = EsnetWebsocketManager

/main.py
import monkeypatch

/esnetorch/init.py
def load_esnet(app: OrchestratorCore) -> None:
...

    app.dependency_overrides[opa_security_default] = oidc_security
    app.dependency_overrides[oidc_user] = oidc_security

/esnetorch/api/api_v1/api.py
api_router = APIRouter()

api_router.include_router(esdb.router, prefix="/api", dependencies=[Depends(oidc_security)])

I get the sense that the last two entries are the 'normal' ways to wire up auth to a route, but it would be nice if there was documentation around a recommend auth mechanism or a unified way to implement this kind of thing.

@gstewart86 @acidjunk Perhaps we should dicuss this in the following meeting, however as far as I can see we are willing to provide feedback on any contribution that would make the current way of working with auth configurable. As long as the method results in a dependancy that can be injected at the endpoint level to do Authz we should be able to make it configurable/pluggable into the main OrchestratorCore class. I.E if we can override the opa_decision function at startup with a custom function. We are golden. Then each and every person can configure their own Authz.

Closing, stale


Add a License to Project

@thechee What type of license should I add to this project?

Added the LICENSE file.


Move 'Guide' section to Github

The Guide section of the website is super useful! But mostly for developers working on the front-end. For people trying to learn how to use BioJS components, it's probably not the best start.
I will prepare (or find some old) copy (i.e. content) for the Guide section that will be more helpful for people trying to understand what BioJS actually is :)
For now, let's move this documentation to Github, maybe in the README.md ?

[ ] Move info to the Github Readme
[ ] Point link to EDU pages


pull request for e2e test at 01/17/2017 20:15:09

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Deployment show command doesn't show observability settings.

Readiness Checklist

[x] I am running the latest version
[x] I checked the documentation and found no answer
[x] I checked to make sure that this issue has not already been filed
[x] I am reporting the issue to the correct repository (for multi-repository projects)

Expected Behavior
Running ecctl deployment show <id> should output everything in the settings block, not just traffic filter information.
Current Behavior
When running  ecctl --config ess deployment show <deployment-id> --verbose for a deployment that has traffic filter and observability settings you can see the following output:
ecctl --config ess deployment show f9c2c6a47f3f49dba60edc9a2b030de8 --verbose
Using config file: /Users/karen/.ecctl/ess.yaml
==================== Start of Request #0 ====================
GET /api/v1/deployments/f9c2c6a47f3f49dba60edc9a2b030de8?convert_legacy_plans=false&enrich_with_template=true&show_metadata=false&show_plan_defaults=false&show_plan_history=false&show_plan_logs=false&show_plans=false&show_security=false&show_settings=false&show_system_alerts=5 HTTP/1.1
<...>
"id" : "f9c2c6a47f3f49dba60edc9a2b030de8",
<...>
"settings" : {
    "ip_filtering_settings" : {
      "rulesets" : [
        "4e974d9476534d35b12fbdcfd0acee0a"
      ]
    },
    "traffic_filter_settings" : {
      "rulesets" : [
        "4e974d9476534d35b12fbdcfd0acee0a"
      ]
    },
    "observability" : {
      "logging" : {
        "destination" : {
          "deployment_id" : "cfd563de3b3d4883aa0f1b060174b81c",
          "ref_id" : "main-elasticsearch"
        }
      },
      "metrics" : {
        "destination" : {
          "deployment_id" : "cfd563de3b3d4883aa0f1b060174b81c",
          "ref_id" : "main-elasticsearch"
        }
      }
    }
  },
<...>
====================  End of Response #0  ====================
<...>
"id" : "f9c2c6a47f3f49dba60edc9a2b030de8",
<...>
"settings": {
    "ip_filtering_settings": {
      "rulesets": [
        "4e974d9476534d35b12fbdcfd0acee0a"
      ]
    },
    "traffic_filter_settings": {
      "rulesets": [
        "4e974d9476534d35b12fbdcfd0acee0a"
      ]
    }
  }

Steps to Reproduce

Create a deployment with both traffic filter and observability settings
run ecctl deployment show <deployment id> --verbose

Your Environment

Version used: v1.0.0

Note this affects deployment update request that includes deployment settings. E.g.
test-edit1.json
{
  "prune_orphans": false,
  "settings": {
    "observability": {
      "metrics": {
        "destination": {
          "deployment_id": "558bcdafbdbd421bb0f52a9a450eb881",
          "ref_id": "main-elasticsearch"
        }
      },
      "logging": {
        "destination": {
          "deployment_id": "558bcdafbdbd421bb0f52a9a450eb881",
          "ref_id": "main-elasticsearch"
        }
      }
    }
  }
}

ecctl --verbose deployment update $CLUSTER_ID -f test-edit1.json
Using config file: /Users/ed/.ecctl/config.json
==================== Start of Request #0 ====================
PUT /api/v1/deployments/22168e94cdb84d339d5f7801cbb8042e?hide_pruned_orphans=false&skip_snapshot=false&validate_only=false HTTP/1.1
Host: api.elastic-cloud.com
User-Agent: ecctl/v1.0.1
Content-Length: 24
Accept: application/json
Authorization: ApiKey Yk5DdG5YVUJITmdvY3V5bXFxTk46WjVfR3lDbjlRRkNiTlpGS2xxNWxDZw==
Content-Type: application/json
Accept-Encoding: gzip

{"prune_orphans":false}

The ecctl deployment update command takes a .json file and applies the plan, so this bug will only affect .json files generated with ecctl deployment show --generate-update-payload

Thanks for the direction and confirmation, @karencfv and @s-nel!  I'll close this out as a bug and issue summary.


Integration support for management tools (JIRA, Trello, etc.)

Hey guys, is there a plan to add integration support for management tools such as JIRA, Trello, etc.? We have a mapping between PR & commit with JIRA tickets and it'd be really cool to be able to set the release versions after generating the changelog on those management platforms.
The integration itself is very easy. Was just wondering if you have plan to incorporate them, through a plugin system perhaps?

No plans, sorry! We'd like to keep the package as minimal as possible.


Clean up default config behavior

Please note that while we are transitioning from travis-ci to AWS CodeBuld, some tests are run on each platform. Non-AWS contributors will temporarily be unable to see CodeBuild results. We apologize for the inconvenience.
Issue # (if available):
Description of changes:
Previously, creating a connection with tls1.3 enabled didn't
automatically configure a tls1.3-enabled config. This was annoying for testing.
We also don't need a separate default config for fips mode, because
fips mode is known at compile time and can't change.
We do need a separate default config for tls13, as at the moment
it's possible to switch to tls13 at runtime (and we do so in
multiple tests).
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

:exclamation: No coverage uploaded for pull request head (defaults@87cda35). Click here to learn what that means.
The diff coverage is n/a.

fips mode is known at compile time and can't change

is this true? fips mode may be a result of dynamically loading fips version of libcrypto at runtime

fips mode is known at compile time and can't change

is this true? fips mode may be a result of dynamically loading fips version of libcrypto at runtime

I double checked: code. We set the ABILITY to enable fips with an #if, but it could still be false. I'll put the fips one back, and add a test.

fips mode is known at compile time and can't change

is this true? fips mode may be a result of dynamically loading fips version of libcrypto at runtime

For the FIPS libcrypto 1.0.x API, entering FIPS mode is a runtime option that only succeeds if openssl is compiled with the FIPS module. So I think you're both right. In Openssl 3.0 it looks like it will be more of a runtime flag, but that's out of scope here.


Andarist/sta 560 hand tool

This PR introduces a "pan mode" that can be enabled by pressing a hand icon in our canvas controls toolbar. This allows one to pan around the canvas without having to press Space constantly which is an accessibility feature. It might be hard to both hold Space down and operate a mouse at the same time.
This is how it looks in the toolbar:

And this is how it looks pressed:

The core of the changes is just in the CanvasContainer file. I've refactored the machine there completely while also extracting "drag session tracker" to a separate machine that gets invoked by the parent. One thing worth noting is that I've used coordinated parallel regions pattern in the parent machine. While this is based on kinda an implicit relation between those regions (one raises an event and the second one transitions based on it) it has allowed me to keep the overall modeling of this pretty simple and reuse a panning region for both the classic panning with a space and for the pan/hand mode. I'm very curious to hear out what do you think about it.
For comparison, I put the before & after of the machine(s) here.
Before

After

Some minor implementation changes:

moved attaching pointer listeners to a machine - this allows us to neatly avoid checking if an event should be dispatched to a machine or not in the React event listeners. This requires passing ref to a machine but this seems to be mostly OK even if not something that we do anywhere else. I feel like we could leverage this pattern more, wdyt?
PAN gets sent to the canvasService from within an action - instead of being synchronized through effect
removed disabling/enabling of the text selection. I've tried hard (experimented with different interactions with that and without that) but I couldn't see what it has been fixing. It might be that it was needed at some stage but is no longer needed. I could also just be wrong and maybe I've missed what exactly it has been fixing. If you find anything broken because of that it will be very easy to bring it back again - I would appreciate you testing this out
ensured that only a single (and the same) pointer is handled throughout the panning session
added onpointercancel handling
ensured that the panning happens only with the left button the mouse

Bug fixes:

fixed an issue with buttons in the application not being "clickable" with Space (previously invokeDetectLock was calling ev.preventDefault() for buttons)

Fixes https://linear.app/statelyai/issue/STA-258/refactor-drag-machine-to-encapsulate-all-the-logic-scattered-through

Fixes https://linear.app/statelyai/issue/STA-258/refactor-drag-machine-to-encapsulate-all-the-logic-scattered-through

@mattpocock Does this comment get picked up by Linear or should it be in the PR description?

@Andarist Here is a loom showing the machine ID text is selected while dragging
https://www.loom.com/share/d005abf1556a40acbbf460d670395300

@Andarist Although pan mode and panning by Spacebar are 2 different features, they're still the same to the end-user and I think pan mode should be enabled while panning by Spacebar.

@mattpocock Does this comment get picked up by Linear or should it be in the PR description?

Unsure but once I've added it to the PR description - it clicked. It might be the poster issue though (I might be treated differently since I'm the author of the PR). Either way - I've linked this to that Linear issue.

@Andarist Although pan mode and panning by Spacebar are 2 different features, they're still the same to the end-user and I think pan mode should be enabled while panning by Spacebar.

Do you mean that the icon in the toolbar should look "pressed" when I pan with a Spacebar? It would be kinda confusing for me and I wouldn't think of this myself but I see that it works like that in Whimsical 🤔

Do you mean that the icon in the toolbar should look "pressed" when I pan with a Spacebar? It would be kinda confusing for me and I wouldn't think of this myself but I see that it works like that in Whimsical 🤔

Yes. To the end-user, they're both the same thing, Pan the canvas. So it makes sense to align the two.


Updates required in README.md

There are two small problems in the instructions that can be quickly addressed.

Step 1 instructions should include installation of @stripe/stripe-js
In the sample code in step 3, there's a comma at the end of the following code block that needs causes errors.

const pay = () => {
  // Get stripe element
  const cardElement = card.value.stripeElement

  // Access instance methods, e.g. createToken()
  elms.value.instance.createToken(cardElement).then((result: object) => {
    // Handle result.error or result.token
    console.log(result)
  })
},

Thank you for reporting the issue, fixed in v1.0.2


FIX: bugs of assign=True in load lora

When I load Flux trained lora through:
from diffusers import AutoPipelineForText2Image, FluxPipeline
from safetensors.torch import load_file

pipe = FluxPipeline.from_pretrained("black-forest-labs/FLUX.1-dev", torch_dtype=torch.bfloat16).to('cuda')
pipe.load_lora_weights("model_qk_text.safetensors")

It raised this problem:
    pipe.load_lora_weights("model_qk_text.safetensors")
  File "/output/diffusers/src/diffusers/loaders/lora_pipeline.py", line 1848, in load_lora_weights
    self.load_lora_into_transformer(
  File "/output/diffusers/src/diffusers/loaders/lora_pipeline.py", line 1951, in load_lora_into_transformer
    incompatible_keys = set_peft_model_state_dict(transformer, state_dict, adapter_name, **peft_kwargs)
  File "/usr/local/lib/python3.8/site-packages/peft/utils/save_and_load.py", line 458, in set_peft_model_state_dict
    load_result = model.load_state_dict(peft_model_state_dict, strict=False, assign=True)

After remove assign=True, it all works.

Thanks for reporting this error. We cannot change the argument just like that, as this will lead to failure in loading other models. Instead, let's try to debug why Flux fails in this case. As a first step, could you please check if loading while passing low_cpu_mem_usage=False to from_pretrained resolves your error?

low_cpu_mem_usage=False is work, even with assign=True, so what's your opinion on this problem? Should we add a special flag for peft Flux compatible?

Should we add a special flag for peft Flux compatible?

Before we do that, we need to first understand why this adapter causes the issue, while others work. Then we can think of the best solution. I'll take a look at it when I have a bit of time on my hands.

I have a bit of time to investigate the issue this week. Do you know of a publicly available LoRA Flux adapter that causes the issue you described (only safetensors)? That way, I can try to reproduce the error.


Adding a carriage return

so the text show up correctly.

Learn Build status updates of commit 56cb708:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/machine-learning/how-to-create-data-assets.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

Looks good; thanks, @wutaomsft


confused aa.length in lollipopPlot()

Describe the issue
Hi, when i use lollipopPlot()  plot FLT3 domain, it shows there are 996 aa, actually，there are 993 aa in FLT3(NM_004119). I download the "protein_domains.RDs", it shows 993 aa, too. Why does this phenomenon occur?

Session info
Run sessionInfo() and post the output below

Hi,
Sorry for the late response. I can't seem to reproduce your issue. On my system, your example shows 993 as the length. I believe, you are using an older version of the package. Could you please update it and try again?
I am closing the issue now, feel free to comment if you still see the same.

I updated the R package to the latest version, and now FLT3 is displaying correctly. Thank you.


Migrate API reference documentation to MkDocs

This PR migrates this project's docs engine to MkDocs from Sphinx. It uses the mkdocs-material theme and mkdocstrings to extract docstrings from source code. There are many knobs and levers to tune in mkdocs.yml and in putting together this PR I've explored most/all of them and am quite happy with the result.
The diff is larger than I'd like, mainly due to subtly different interpretation of docstrings:

We're still using the Sphinx docstring style, but markup is now in Markdown instead of reST
References are now formatted [`ClassName`][path.to.ClassName] instead of :class:`path.to.ClassName`
Instead of accepting attribute docstrings as #: comments in front of a docstring, mkdocstrings wants """string""" docstrings following the attribute definition
mkdocstrings doesn't support inheritance, which means there's a fair bit of boilerplate necessary to get legacy classification and detection definitions properly documented

The first of many PRs in this chain. Planning to follow up with PRs to customize styles, migrate docs.kolena.io content into this repo, set up automated publishing, and add metrics guides (among other things).
Fixes KOL-2457
Fixes KOL-2459

I'm happy with where this is for a first pass. Requesting review specifically from @ly-kolena, @munkyshi, and @y27choi — will probably be easiest to render locally with poetry run mkdocs serve -a localhost:8999 and explore in your browser.

Sorta miss some of the alphabetical sort from previous API layout

Glad that you flagged this. I decided to go with a "usage ordering" rather than alphabetical for kolena.workflow definitions under the assumption that it would be easier to browse. What do others think?

Non-blocking footnote, the TOC of legacy workflows is a bit more jarring in terms of habits.

Non-blocking footnote, the TOC of legacy workflows is a bit more jarring in terms of habits.

Ack — updated these to be [mostly] alphabetical in the latest commit.

Do we want to add the source code block for every page or only the ones that would benefit from having?
I noticed that we have it for TestCase but not for TestSample or GroundTruth.

Do we want to add the source code block for every page or only the ones that would benefit from having?

I'm going to disable this flag entirely. Source code is usually not relevant when viewing documentation, and the callouts are pretty distracting.

There are duplicate GroundTruth and Inference sections on kolena.detection page.  Should we remove the GroundTruth and Inference reference at the top?

Finished the review and left some comments.  Mainly compared the new docs with the old api docs and flagged the differences.


Install on a Docker image

Describe the bug
I'm not able to install this with pip on a Docker image.
To Reproduce
FROM ubuntu:18.04
[..]
RUN curl -fsSL https://deb.nodesource.com/setup_14.x | bash -
RUN apt-get install -y nodejs  #v12.22.7
RUN pip install robotframework-browser

This is the error i get:
ERROR: Could not find a version that satisfies the requirement robotframework-browser (from versions: none)
ERROR: No matching distribution found for robotframework-browser

Expected behavior
I'd expect to install.
Additional context
BTW: i can't find a way to install this even directly on my laptop which runs on Ubuntu. Getting the same problem.
I wonder is this caused by having installed a bad version of node or something?

Most likely pip in that image points to Python 2 and Browser library supports only Python 3.6+. I would assume that changing pip to  pip3 solves the problem. But I am going to close this issue, because this is not Browser library problem.
For future you will get faster and better support when reaching the Robot Framework community: https://robotframework.org/#community

Thanks for helping... using pip3 doesn't solve the issue though. Same exact problem.
As i can install without any problem all the other libraries i tried:
#Install the required libraries
RUN pip install --user robotframework
RUN pip install --user robotframework-sshlibrary
RUN pip install --user robotframework-seleniumlibrary
RUN pip install --user robotframework-requests
RUN pip install --user pyperclip
RUN pip install --user robotframework-xvfb
RUN pip install --user robotframework-csvlib
RUN pip install --user robotframework-browser

and browser is the only one i can't find a way to install... then i'd say the problem is indeed with this library?


Document the process of implementing feature classes and individual features

issues to cover:

inherit from base class
follow conventions for naming feature getters
adding tests
adding documentation

Might this be a good idea to add this as an extra heading in the sphinx documentation (e.g. a "developers" section)?

resolved by #216


Harvester shell integration - bump chron libraries

Summary
Contributes to https://github.com/rancher/dashboard/issues/12347

Occurred changes and/or fixed issues

Technical notes summary

Some new features in Harvester require newer chron lib versions.
Areas or cases that should be tested

Areas which could experience regressions

Chron field in CronJob page.

Screenshot/Video

Checklist

[x] The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
[x] The PR has a Milestone
[x] The PR template has been filled out
[x] The PR has been self reviewed
[x] The PR has a reviewer assigned
[x] The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
[x] The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

Can we also run yarn install for storybook as well? We typically have to do this to update the storybook lockfile when we modify dependencies in the root package.json.


🏗 [ADMIN] - ryanhiebert

DSF member

[X] I am a DSF member

Why do you want to join?
I like what you’re doing and want to help
Please tell us about your packaging experience?
tox-travis, django-safemigrate, aldjemy
Please tell us about your GitHub Actions experience?
I’ve used it quite a bit at several different companies, though I’m sure that this project poses unique challenges
How long do you expect to be involved with Django Commons?
No definite timeline at this point. If I got a job that didn’t deal with Django at all, that might be a time I’d want to step back.
Code of Conduct

[X] I agree to follow Django Commons's Code of Conduct

Thanks for your interest Ryan! Right now the roster is full, but the expectation is that we'll cycle people in and out of roles over time. I'll circle back with you when we get to that point.


added scrollable directive to the dashboard grid container

@MaddyDev , Could you please describe the issue you are trying to solve? and add screenshots for before and after?

Added this to address:
https://github.com/microsoft/azuredatastudio/issues/5988#issuecomment-503672054
I added the scroll, I am not able take the screenshots with scroll.

Fix for #5988


Features importance

Hey,
I ran the feature significant and compared the results to Sklearn output. not only the results are different, but also the results that I'm getting using this implementation doesn't make any sense(using the info that I have about my data).
for example a feature that is constant is one of the most significant features(it got the heights value).
maybe I don't know how to read the output properly?
("data:0.33" (1; #27), 235)
this means that feature number 27 got score of 235?
Tsachi

في الأحد، ٢٢ أغسطس، ٢٠٢١ ٣:١٠ م tsachiblauamat @.***>
كتب:

Hey,
I ran the feature significant and compared the results to Sklearn output.
not only the results are different, but also the results that I'm getting
using this implementation doesn't make any sense(using the info that I have
about my data).
for example a feature that is constant is one of the most significant
features(it got the heights value).
maybe I don't know how to read the output properly?
("data:0.33" (1; #27
https://github.com/tensorflow/decision-forests/issues/27), 235)
this means that feature number 27 got score of 235?
Tsachi
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/decision-forests/issues/56, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVDUTKK4XDHIG66H6DOVHPDT6DSK5ANCNFSM5CS4MNDQ
.
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&utm_campaign=notification-email
.

I'm sorry @SaultanBeagama, we need better documentation for these.
Can you display the output of model.summary() after training ? It will pretty-print the variable importances, it may become obvious ?

Hi tsachiblauamat,
Thanks for the ping.
The different variable importances (VIs) are described here. This documentation should propagate soon to the TF-DF documentation.
In your example ("data:0.33" (1; #27), 235), 235 is effectively the score of the VI. However, we need the VI name to make sense of it :).
Constant features are not used by the model. Therefore, the VI of such feature should be the "worst" possible one (the "worst" value depends on the semantic of the VI). Unless specified, the greater the score, the most important the feature. Currently, the one exception is the MEAN_MIN_DEPTH VI (see doc).
As Jan mentioned, printing the model.summary() would help understand the situation.
Cheers,
M.

I read in (your example)[https://www.tensorflow.org/decision_forests/tutorials/advanced_colab]
# Mean decrease in AUC of the class 1 vs the others.
inspector.variable_importances()["MEAN_DECREASE_IN_AUC_1_VS_OTHERS"]

with output:
[("bill_length_mm" (1; #1), 0.06972998903508787),
 ("flipper_length_mm" (1; #3), 0.008532072368420462),
 ("island" (4; #4), 0.004488760964911687),
 ("bill_depth_mm" (1; #0), 0.0032552083333338144),
 ("year" (1; #6), 0.0022101151315789824),
 ("sex" (4; #5), 0.0004625822368422572),
 ("body_mass_g" (1; #2), -5.1398026315596645e-05)]

I wonder that what do number in tuple mean?


swagger2dbricks and added documentations

[x] add documentations: readme, changelog, roadmap and examples
[x] schema code generation with swagger (current release) and avro (next release) to generate

[x] create table ddl
[x] pyspark loading struct type
[x] markup for confluence

from bricklayer.catalog.schema.swagger import SwaggerRecord
swagger = SwaggerRecord(swaggerString="""
openapi: 3.0.0
info:
  title: test
  description: A weather reading.
  version: 1.0.0
components:
  schemas:
    weather:
      description: >-
        A weather reading.
      x-data-asset-schema: test
      x-data-asset-table: weather
      x-data-asset-version: 1
      x-data-asset-partition-keys: [station]
      x-data-asset-unique-keys:
      - station
      - time
      x-data-asset-static-reference:
        s3-location: s3://data-asset/test.time/version=1/
      x-data-asset-source-urls:
      - https://github.com/intelematics/bricklayer/generate_weather.py
      x-data-asset-changelog:
      - version: 1
        description: >-
          Contains weather
      x-data-asset-dependencies: []
      x-data-asset-relationships: []
      properties:
        station:
          type: string
          description: >-
            Weather station
        time:
          type: date
          description: >-
            timestamp
          example: 123456789
        temp:
          type: integer
""")
for rendered_output in swagger.get_create_table_sql():
    print(rendered_output)

CREATE TABLE test.weather_version_1 (
  station STRING,
  time DATE,
  temp INT
)
USING DELTA
PARTITIONED BY (
  station
)
LOCATION '/mnt/data_asset/test.weather/version=1'
TBLPROPERTIES ('unique_keys' = '["station", "time"]')

Cool stuff, shall we still keep the html examples now that we have the examples in Readme.md?

I guess people can import the html to databricks workspace and use them


Discovery in subnet without zero at the end

I am currently trying to set up upsnap at work and having trouble to enable network discovery. We only have a fraction of an IP range, lets say <IP_ADDRESS>/26. If I try to enter it in upsnap it says Please match the requested format. Does it expect a zero at the end? I tried also <IP_ADDRESS>/24 and even then I don't get any output, but even if it would output something, I do not want to get results from other departments. nmap -sn <IP_ADDRESS>/26 gives me the desired range, while nmap -sn <IP_ADDRESS>/24 also works, but I also get devices that I do not care about.

It's currently matching the ip against a regex expression (done in html's "pattern" tag) which requires a 0 at the end and then passes the value to nmap.
When creating this, I tried to make sure people don't put in wrong values. But if its creating too much problems I'm also fine with removing the pattern.
As a quick workaround you can probably open up the browser dev tools on the input field and remove the pattern tag.

Thanks for the tip, by removing the pattern tag I was able to add our "exotic" subnet and I am able to scan the network nicely.
I don't mind removing the tag since it has to be done only once. Would be nice if it was mentioned in the readme, or the zero at the end could be omitted.
Btw, one more question: if a device gets a new IP from the DHCP, will it automatically update in the dashboard (using the MAC address entry), or do I need to manually change it?

Looking forward to that feature! :D
P.S. if I'm already making small requests, I would also add a small comment section for each device to the wish list. It could be used to manage who is currently owning/using it or what kind of device is it (server, workstation, personal machine, phone, etc.).

I've removed the regex checks in the frontend. You can now use whatever mac or ip you want.


Pad build numbers and prefix PRs

This will create stuff like:
MyLib.0.1.0-CI0000798.nupkg (from master)
MyLib.0.1.0-pr17-0000798.nupkg (from PRs)

Ah, good to know - so, do you want to port it to a build.proj are are we going to :shipit: ?
(I'll copy whatever you decide to merge into the converters project)
NB I know the great is the enemy of the good, but I've been suggesting to others to clone from one of these as a way to get a good template-project; if we don't polish this sort of stuff now, we'll have ripples of manual work to fix this when we get to this (I'm guessing someone wanting to build this on non-Windows will end up doing it... - except they'll probably port this to an even worse .sh monstrosity)

Merging this for now. I'll keep improving the build infrastructure in separate PRs.

What's the failure?
I have a build.proj already. See the on in XRay.

About pull request id - see the master commit log. Unfortunately the removal of your commit did not help as the build config cant cope with that (we also need to fix that - I'll leave it the way it was now)

or is our build numbering predicated on the commit index on a branch? (for early days of a project I tend to do force pushes to keep history neat rather than doing formal revert PRs and tiny fixup PRs)

link to error log on master https://jet-tfs.visualstudio.com/Jet/_build/results?buildId=70166&view=logs

Weird, I'll have a look shortly, but it seems to be a problem in the pipelines rather than the build script.
That's why removing this commit didn't solve it.

The problem was that Azure Pipelines was not expanded uninitialized variables.
I did a workaround in the Pipeline itself, so now it should work fine for both projects.

OK, I've elided it from master to save the distration of having to analyze - #12 will presumably reinstate when it merges (I'm doing some integration work now in #11 which I will merge as soon as)


Adjust PWM Update Timings Based on Intensity

Timing of updates to the PWM duty cycle is tricky. In part because of how the eye is sensitive to changes.
If the change is too big, then the eye catches it. One aspect is the delta brightness change. The other is the absolute brightness.
RPiLight accounts for the delta brightness, and will update more frequently if the ramp is faster/bigger between two points in time. This is what allows previews to be smooth, or to have a 30 second ramp that doesn't look terrible in the morning if that's what you want.
It doesn't account for the absolute brightness though. So if it decides it only needs to update every 8 seconds when first turning on, it will do that. But in the very low brightness range, you can see the steps happening much more easily, even though it only represents one-tenth of a percent brightness change.
So the algorithm for picking an interval should also account for how close to 0 brightness the channels currently are.
One idea is to use a logistic function to push the interval towards minimum when the brightness is very low, but to these very large multi-second pauses when the brightness is very high.

Moving this to 0.3. The priority on this is a bit lower than figuring out how brightness/intensity/gamma all work. This builds on top of whatever foundation that is.

Closing this out as the current behavior hasn’t been something I’ve been able to see in practice. The current algorithm seems to handle things well enough without the need for extra logic.


[MINOR] Callback message add partitionPath Field

Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contributing.html before opening a pull request.

What is the purpose of the pull request
Currently, we need to know which partitions hudi has successfully written.
Brief change log
org.apache.hudi.client.AbstractHoodieWriteClient
Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

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

The Travis is red, please check.

The Travis is red, please check.

The Travis is red, please check.

Thanks for the reply, I have been busy recently,
I will deal with it after this time is over

The Travis is red, please check.

Thanks for the reply, I have been busy recently,
I will deal with it after this time is over

if the scope increases to log any data as per config/props, can you create a jira and link it.

if the scope increases to log any data as per config/props, can you create a jira and link it.

if the scope increases to log any data as per config/props, can you create a jira and link it.

+1

if the scope increases to log any data as per config/props, can you create a jira and link it.

+1

@liujinhui1994 Let's fix the Travis firstly?

if the scope increases to log any data as per config/props, can you create a jira and link it.

ok

Codecov Report

Merging #2445 (a63e5e4) into master (e3d3677) will decrease coverage by 1.44%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master    #2445      +/-   ##
============================================
- Coverage     50.73%   49.28%   -1.45%
+ Complexity     3064     2838     -226
============================================
  Files           419      381      -38
  Lines         18797    17055    -1742
  Branches       1922     1730     -192
============================================
- Hits           9536     8405    -1131
+ Misses         8487     7986     -501
+ Partials        774      664     -110

Flag
Coverage Δ
Complexity Δ

hudicli
36.87% <ø> (-0.40%)
0.00 <ø> (ø)

hudiclient
100.00% <ø> (ø)
0.00 <ø> (ø)

hudicommon
51.39% <ø> (-0.62%)
0.00 <ø> (ø)

hudiflink
45.44% <ø> (+35.23%)
0.00 <ø> (ø)

hudihadoopmr
33.16% <ø> (+0.09%)
0.00 <ø> (ø)

hudisparkdatasource
?
?

hudisync
?
?

huditimelineservice
?
?

hudiutilities
69.51% <0.00%> (+0.03%)
0.00 <0.00> (ø)

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

Impacted Files
Coverage Δ
Complexity Δ

...callback/kafka/HoodieWriteCommitKafkaCallback.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

...java/org/apache/hudi/common/util/CleanerUtils.java
47.72% <0.00%> (-15.91%)
6.00% <0.00%> (ø%)

...a/org/apache/hudi/cli/commands/CommitsCommand.java
53.50% <0.00%> (-5.30%)
15.00% <0.00%> (ø%)

...i/common/model/OverwriteWithLatestAvroPayload.java
60.00% <0.00%> (-4.71%)
10.00% <0.00%> (ø%)

...common/table/log/HoodieMergedLogRecordScanner.java
87.50% <0.00%> (-4.31%)
10.00% <0.00%> (ø%)

...g/apache/hudi/hadoop/HoodieParquetInputFormat.java
36.26% <0.00%> (-4.15%)
11.00% <0.00%> (-1.00%)

.../apache/hudi/common/config/SerializableSchema.java
54.54% <0.00%> (-3.35%)
6.00% <0.00%> (ø%)

...che/hudi/common/table/log/HoodieLogFileReader.java
67.85% <0.00%> (-3.22%)
22.00% <0.00%> (-1.00%)

...e/hudi/metadata/FileSystemBackedTableMetadata.java
92.10% <0.00%> (-2.49%)
13.00% <0.00%> (ø%)

...c/main/java/org/apache/hudi/common/fs/FSUtils.java
49.77% <0.00%> (-2.12%)
61.00% <0.00%> (ø%)

... and 107 more

@yanghua: feel free to land this once your feedback is addressed

yeah, I missed to see the MINOR.
but I did check the code path to ensure we don't trigger any dag actions as this is List.
realizing that this is called before postWrite, within commitstats(). So, wanted to hear your opinion if we this is fine or should we disallow sending entire WriteStats to the callback.

I am not sure how widely the commit callbacks are used atm. This change does seem more generalized. But would be good to call this out as a backwards incompatible change?

In general, lets add API stability annotations ApiMaturityLevel to these classes?

@yanghua any other concern?

@yanghua any other concern?

No, also wait to address vc's concern.

Codecov Report

Merging #2445 (1068b7f) into master (e3d3677) will decrease coverage by 43.74%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master   #2445       +/-   ##
============================================
- Coverage     50.73%   6.98%   -43.75%
+ Complexity     3064      65     -2999
============================================
  Files           419      79      -340
  Lines         18797    3492    -15305
  Branches       1922     431     -1491
============================================
- Hits           9536     244     -9292
+ Misses         8487    3227     -5260
+ Partials        774      21      -753

Flag
Coverage Δ

hudicli
?

hudiclient
?

hudicommon
?

hudiflink
?

hudihadoopmr
?

hudisparkdatasource
?

hudisync
4.88% <ø> (-43.74%)
:arrow_down:

huditimelineservice
?

hudiutilities
8.04% <0.00%> (-61.44%)
:arrow_down:

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


Unable to download S-C-K from

Not really a bug but I am unable to download s-c-k from https://splunk.github.io/splunk-connect-for-kubernetes/
It has been giving me 404 not found at least since Wed, Nov 24, 2021
This URL is referenced in the README file documentation for s-c-k at
https://github.com/splunk/splunk-connect-for-kubernetes/blob/develop/README.md
What happened:
Unable to download from https://splunk.github.io/splunk-connect-for-kubernetes/
Keep seeing the following
404
File not found
The site configured at this address does not contain the requested file.
If this is your site, make sure that the filename case matches the URL.
For root URLs (like http://example.com/) you must provide an index.html file.
Read the full documentation for more information about using GitHub Pages.
What you expected to happen:
Expect to be able access the web location to download it.
How to reproduce it (as minimally and precisely as possible):
Paste - https://splunk.github.io/splunk-connect-for-kubernetes/ in any browser
Anything else we need to know?:
Is the link just broken or has it been moved and the documentation has not been updated?
Environment:
Nope

Hey @harmanbirdi, we are using docs directory to keep track of SCK releases.
You can use SCK chart by cloning the repo, download from release or download from https://github.com/splunk/splunk-connect-for-kubernetes/tree/develop/docs.

Closing the issue, feel free to reopen or create a new one if required


Avoid returning self from _get_base_font_or_default()

Fixes #72739
Opening the linked project in the editor (on Windows) immediately causes a stack overflow. With this fix, the project builds and runs without crashing.

Right, that also fixes a stack overflow when trying to edit the SystemFont resource.

Thanks!


Creating basic functionality to connect to Discord API, work in progress.

[x] Connect function.
[x] Identify.
[x] Interval to send heartbeat.
[ ] Handling all kind of events from Discord through OP Code.
[ ] Make the actual resume a function, so it can be used throughout the code.

Need to uninstall un pkg I installed by fault.

TODO:

[ ] Add new Application properties (discordjs/discord-api-types#239)

I think, we should change this Pull Request, and move it to other separate pull requests. This PR is getting just way too big and it already does what it needs to do. I will merge it soon.


0.4.6 conflict with OptiFabric

Attempting to run version v0.4.6 alongside OptiFabric 1.12.10 results in a mixin crash. Only tested on 1.18.1. Error no longer occurs when OptiFabric is removed, or when reverting to v0.4.5.
Fabric Loader 0.13.3
Mods:
- fabric-api-0.46.4+1.18
- freecam-0.4.6+1.18
- optifabric-1.12.10_1 (OptiFine_1.18.1_HD_U_H4_4)
log: https://paste.ee/p/6NLwn

Thanks for reporting. This has been fixed in 0.4.7.


Change projection of rasters overlaid on Mapnik

Hello,
I am new to GeoNotebook, I am at the stage where I try to understand how GeoNotebook works, or more precisely what each of the python libraries that are used in GeoNotebook do.
What I didn't understand is how I can change the projection of the rasters overplayed in Mapnik? What is the library that does this, is it Mapnik or Rasterio? For the vectors, is Shapely, if I am not mistaken.

At a low level, raster reprojection is handled by GDAL.  Rasterio has functions that wrap GDAL and make it more palatable to use.  To reproject a raster, you can either do it offline with a command-line tool like gdalwarp, or you can do it by generating a vrt file.  gdalwarp can help in generating a vrt file by specifying the output format as "VRT".
For vectors, shapely has a function called transform that can perform an arbitrary transforms on all coordinates.  See this stackoverflow answer for how it can be used with pyproj to reproject geometries.  GDAL can also reproject vector files using the commandline tool ogr2ogr.

Actually my question is, changing the projection will change the aspect of the raster too? I can only see the raster from a side, not actually a rectangle, more like a diamond shape. If the shape is preserved (no matter the projection), that it is actually how Mapnik displays images?

Mapnik (via GDAL) transparently reprojects the image while tiling if the projection is set correctly in the source image.  Is the image actually projected correctly when you see it?  I'm guessing the "diamond shape" is a result of reprojecting from a source image provided in a sinusoidal projection common among satellite imagery.

Probably it would have been better if I had said I am trying to reproject the images from the examples that come by default with GeoNotebook. But I had a closer look and I think the way images are displayed on Mapnik has nothing to do with the projection in this case, but more with the image itself, because the projection is 4326.

I see, you want to set the projection of the map on the client.  It's possible to get mapnik to output tiles in other projections, but there isn't any code in geonotebook to handle this.   In principle it could be done, but there are a lot of places in the code base that assume that the display projection is in web mercator.

Ah, I see. So it is necessarily a Mapnik issue, it is how GeoNotebook is set to display images. It would be nice to be able to change projection, at least for the most common ones. :)

@corinat what projection you are hoping to use inside GeoNotebook?

Hi @aashish24. I apologies for the late response. EPSG 4326 would be great.

What is your motivation for displaying the map in 4326?  In terms of visual distortion, it is worse than 3857 in every way.  If you are just looking to display gridded that is given on a regular lat/lon grid, mapnik can seemlessly reproject them while generating the tiles for display.  Many if not all of the examples that we have created use datasets given in 4326.
While displaying the map in an alternate projection is certainly something we can consider implementing, I want to make sure there isn't an easier option available for your use case.  Also note that if the map were displayed in an alternate projection, you would have to find (or create) a base layer tile server that supports it.  I don't know of any publicly accessible tile servers that provide 4326.

We have large stores of imagery that are served only in 4326.  I was working on a proof of concept/demonstration that would allow a user to search and display imagery from this source for which they could train and run ML models.  We have moved on to another phase, but I would still be interested in any plans to add support for 4326.


Techdebt: Add CodeCoverage

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@e13602f). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage        ?   36.31%
=======================================
  Files           ?        6
  Lines           ?      369
  Branches        ?        0
=======================================
  Hits            ?      134
  Misses          ?      235
  Partials        ?        0


Testing computed props

Hey,
Is there a good way to test computed properties? I have something like
// MyComponent.vue
<template>
  <div :class="computedClass">
  </div>
</div>

export default {
  props: {
    customClass: {
      type: String
    },
  },

  computed: {
    computedClass () { return this.props.customClass }
  }
}

Test
const wrapper = shallow(MyComponent, {
  propsData() { customClass: 'aaa' }
})

wrapper.vm.setProps({ customClass: 'bbb' })

const actual = wrapper.vm.$options.computed.computedClass()
expect(actual).toEqual('bbb')

In all cases, the prop is undefined. I can dig deeper if needed, I haven't looked at the source much yet. If I do {{ computedClass }} in the template it does indeed work fine.
Any good option to test computed methods? Or I can look to add something.
Thanks!

You check it as you would check any data property on the component
On Oct 15, 2017 4:56 PM, "Lachlan"<EMAIL_ADDRESS>wrote:

Hey,
Is there a good way to test computed properties? I have something like
// MyComponent.vue

export default {
  props: {
    customClass: {
      type: String
    },
  },
computed: {
computedClass () { return this.props.customClass }
}
}
Test
const wrapper = shallow(MyComponent, {
propsData() { customClass: 'aaa' }
})
wrapper.vm.setProps({ customClass: 'bbb' })
const actual = wrapper.vm.$options.computed.computedClass()expect(actual).toEqual('bbb')
In all cases, the prop is undefined. I can dig deeper if needed, I
haven't looked at the source much yet. If I do {{ computedClass }} in the
template it does indeed work fine.
Any good option to test computed methods? Or I can look to add something.
Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/vuejs/vue-test-utils/issues/103, or mute the thread
https://github.com/notifications/unsubscribe-auth/AACoukJ8RTYo0hRSK1fk1znggsUzAOjiks5ssg8mgaJpZM4P5wVK
.

So you do. Thanks.


Fixed: remove docstrings from click text messages #775

thanks for working on this @edeediong. Couple of comments:

the docstrings need to be removed from the messages, but not from the comments. We can leave them in the form of # comments
only the docstring of cli() functions get shown by click, so these are the only functions we need to modify

Oh I misunderstood your previous instructions. Reverting and making changes now.

Hello @edeediong! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file cli/popper/commands/cmd_ci.py:

Line 151:80: E501 line too long (95 > 79 characters)

In the file cli/popper/commands/cmd_dot.py:

Line 46:80: E501 line too long (95 > 79 characters)

In the file cli/popper/commands/cmd_info.py:

Line 21:5: E303 too many blank lines (2)
Line 24:80: E501 line too long (95 > 79 characters)

In the file cli/popper/commands/cmd_run.py:

Line 167:80: E501 line too long (95 > 79 characters)

In the file cli/popper/commands/cmd_scaffold.py:

Line 17:80: E501 line too long (95 > 79 characters)

In the file cli/popper/commands/cmd_search.py:

Line 31:80: E501 line too long (95 > 79 characters)

In the file cli/popper/commands/cmd_version.py:

Line 16:80: E501 line too long (95 > 79 characters)

thanks @edeediong !

Glad I could contribute!


HF1 - Be more lenient when evaluating peer ENR's

Description
We're currently doing a very strict check on peer EnrForkId's, which will reject peers whose next configured fork does not match out own.  In order to make the altair upgrade rollout smoother, we should probably accept any peer with a matching forkDigest.  It may also be worth suggesting the spec  states that nodes SHOULD be lenient to allow for smoother upgrades.

Looks like we're only validating that the forkDigest matches currently, which is what we want: https://github.com/ConsenSys/teku/blob/b12f64fa2b3c4be0de7c2814d5146f8d6b10c352/networking/p2p/src/main/java/tech/pegasys/teku/networking/p2p/discovery/DiscoveryNetwork.java#L191-L200


mounter(ticdc): fix decoding when upstream doesn't enable new collation

What problem does this PR solve?

Issue Number: close #11371
What is changed and how it works?
Explicitly call collate.SetNewCollationEnabledForTest(false) before run cdc.
Previously, this function was called in a tidb package. But it was removed as described in https://github.com/pingcap/tidb/pull/52191#issuecomment-2024836481.
If the upstream doesn't enable new collation, the primary key is not encoded in the value part when the table is a cluster index table. And we rely on the following line to decode the primary key. https://github.com/pingcap/tiflow/blob/2db092244d18c043f7f8ecc85a598680b33cc324/cdc/entry/mounter.go#L301
But this line only decode the primary key when the global variable newCollationEnabled in tidb package is false. (It means collate.SetNewCollationEnabledForTest(false) must be called.)
Check List
Tests

Integration test

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
Fix the issue that TiCDC cannot correctly decode primary key of table with cluster index when the upstream does not enable new collation.

/retest

/test verify


[BEAM-2939] Fix splittable DoFn lifecycle.

getInitialRestriction/splitAndSize should not be wrapped with startBundle/FinishBundle invocations.
Instead of copying the stateAccessor initialization (used for side inputs) I made it so that it was initialized only once and cleaned up the caches/references in the finalizeState call.
Tested within Google using runner_v2.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.


⚠ ClamAV has degraded performance

In 7ea9b53, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 76 ms

Resolved: ClamAV performance has improved in 5082dc7.


Update sbt-tpolecat to 0.1.21

Updates io.github.davidgregory084:sbt-tpolecat from 0.1.20 to 0.1.21.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.github.davidgregory084", artifactId = "sbt-tpolecat" } ]

labels: sbt-plugin-update, early-semver-minor, semver-spec-patch, commit-count:1

Please consider reviewing https://github.com/typelevel/keypool/pull/335 in lieu of this update. Thanks! :)

Superseded by #352.


Provide more context when starting PostgreSQL

Description
Advise the operator that they may be observing an unrecoverable problem if attempts to connect to the PostgreSQL database consistently fail. In this case, also display the relevant error message.
Checklist:

[x] I've made sure that tests are updated accordingly (especially if adding or updating a template option)
[x] I've updated the documentation or confirm that my change doesn't require any updates

Rationale
Currently, if a connection to the PostgreSQL database cannot be established, operators are instructed to wait indefinitely. They need to exercise their own judgement to determine that an unrecoverable error may have occurred, and they must then formulate their own plan to diagnose the problem. This change introduces a suggestion about the possibility of failure and some contextual information that will assist in debugging. It also causes the script to fail immediately for truly exceptional circumstances such as the absence of required modules.
I've arbitrarily chosen 30 seconds as the duration to wait before suggesting that something may not be working. Does that seem like an appropriate value to folks more familiar with this process?

👍
If there are no eyes on the logs generated by the connection process, this would be very helpful.

Great stuff! Thanks a lot!

My pleasure!


Added ProviderName to cluster

## Proposed changes
Modify the Cluster Resource and Added the Provider to the ReplicaSetConfiguration
Type of change:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as
expected)
[ ] This change requires a documentation update

Required Checklist:

[x] I have signed the MongoDB CLA
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have added any necessary documentation (if appropriate)
[x] I have run make fmt and formatted my code
[x] I have tested the CDK constructor in a CFN stack. See TESTING.md

Further comments

Hi @andreaangiolillo ! ive added the test that was missing, can you review again?


IP address missing from runner details

The RunnerDetails struct is missing a field for the IP address of the runner, which is provided as the ip_address key in the response from gitlab, as documented at https://docs.gitlab.com/ce/api/runners.html#get-runners-details

By all means feel free to open a PR to add the missing fields. Ordering of struct fields is (trying) to use the same order as is used in the docs.


Slash Commands

Please describe the changes this PR makes and why it should be merged, as well as any and all proof of successful tests:
Added interactionCreate event.
Added ./base/slashCommand.js structure.
Added ./commands/deploy.js command, bot owner only, deploys both guild, and global slash commands.
Added ./slash/ping.js an example slash command.
Modified ./index.js to load slash commands.
Modified ./events/guildCreate.js to deploy guild commands, and added documentation.
Modified ./events/guildDelete.js with documentation.
Semantic versioning classification:

[X] This PR changes the framework's interface (methods or parameters added)
[X] This PR includes breaking changes (methods removed or renamed, parameters moved or removed)
[ ] This PR only includes non-code changes, like changes to README, etc.

 Slash Commands


When using port to transfer a bridged ERC20, if the amount reaches 9 digits(UFix64 Integer part), the contract will throw an error.

Instructions
Problem
Successful TX: https://www.flowdiver.io/tx/5ef517c8cd715d1196a489c6d88b8aa0f0b589059635b5fdf5d39c4e786fd6a9
Failed TX: https://www.flowdiver.io/tx/0c36b6d852d93698897e1755ca5c49067b1df7e81cf146565e4ee61dd2e49b09
Steps to Reproduce
The only differency is amount
Acceptance Criteria
Not to panic
Context

Closing as the failed transaction failed in the COA call to the ERC20 contract and doesn't involve bridge functionality.


Automating the double/quadruple res line in encode.avs.

Just above line 135 this should cover the auto double res being done on every console system, and also for handhelds quad the size.
For the other more modern handhelds which is 3/DS double is used instead, and for future proofing PSP (480x272) as well if that day ever comes.
And as the warning, this isn't something I verified if it works on the encode.avs script as I actually don't use it, but this should work when implemented at the line I suggested.
handheld ? last.height > 270 ? PointResize(last.width*2,last.height*2) : \
PointResize(last.width*4,last.height*4) : \
last.height < 400 ? PointResize(last.width*2,last.height*2) : 0

The 400 is based on what fsvgm777 has suggested

@fsvgm777 do we want to have this kind of automation? I wanted to make the baseline script very basic, and then people could add things they need on top, locally, to avoid maintaining infinite checks and hacks.
Naturally it feels there just needs to be an override option in case something isn't covered by the automatic thing, or we just need to go through known resolutions of our consoles and check which factor will be needed for each, automating based on that?

I wouldn't be necessarily opposed to having it, but I'd like an option to have it done manually as well (like how it's done in the package) for the less usual cases. (i.e. cases where the width is smaller than height on handheld mode, e.g. several Flash games)

So something like this then if we're focusing strictly on Flash games?
And also enabling handheld to also prevent the aspect correction at the next part.
Hindsight I should've named it "prescaleFactor" instead, but that can be fixed in post whenever a decision is made.
override = 2
handheld = false

override > 1 ? Eval("""handheld = true \
PointResize(last.width*override,last.height*override)""") : \
handheld ? last.height > 270 ? PointResize(last.width*2,last.height*2) : \
PointResize(last.width*4,last.height*4) : \
last.height < 400 ? PointResize(last.width*2,last.height*2) : 0```

Do we want to upscale Wii?

Do we want to upscale Wii?

Wii/GCN resolution is at/above 480 which the point was to not double res anything above that resolution, same with PlayStation.
I'm just echoing what I recall in that conversation which was a "soft no" if I'm not mistaken.

Yeah, what Spikestuff said.

I mean Wii video in our encodes is 360p, even if the signal is meant to be 480p technically.

...Isn't Wii meant to be 540?

I think it's actually meant to be 480 (576 for regular PAL?) across the board. Dolphin's logic is a bit too whack for me.


Girlscript Summer of Code Introduction/Tracking

👋 Hi @VaibhavCodeClub,
I am Prince,web developer(Core Team) Girlscript Summer of Code. I'll be collaborating with you on preparing your repo for GSSoC'24 Program
Why are these changes required?
After Analysing last year's contributions and feedback it would be great for students to have a couple of standard readme files on the repo to understand what the project is all about and some issues detailing what they can contribute. This will help you to see increased engagement in your repository as well.
As mentioned students get a chance to learn step by step, how to build this project as well as invite mentors to collaborate and add features to this repo. I will generate issues, which will provide guidance on how to prepare your repo for Girlscript summer of code 2024 on 10th May.
This issue will serve as a tracking issue to track all issues related to GSSoC'24. I recommend creating a new branch for every issue and opening a pull request to track changes so we can effectively collaborate with each other and merge changes when you and I feel like those changes are ready to be merged on your primary branch.
If you have any questions or concerns, please feel free to leave a comment on this issue or any of the other issues that are generated.
I look forward to working with you :octocat:

[x] #6
[ ] #7
[ ] #8
[x] #9
[x] #10

Thank you for bringing up this issue. I've sent you an invitation to collaborate on this project. I'm looking forward to your valuable contribution.

Hello .I am intrested in contributing for this task .Please assign me this under GSSOC'24


Nullable command line arguments not fully supported

I think having a nullable option isn't fully supported.
I had to update the following function in TypeConverter.cs
private static Maybe<object> ChangeType(string value, Type conversionType, CultureInfo conversionCulture)
        {
            try
            {
                return Maybe.Just(
                    MatchBoolString(value)
                        ? ConvertBoolString(value)
                        : conversionType.IsEnum
                            ? Enum.Parse(conversionType, value)
                            : Convert.ChangeType(value, conversionType, conversionCulture));
                            : Convert.ChangeType(value, conversionType, conversionCulture));
            }
            catch (InvalidCastException)
            {
                return Maybe.Nothing<object>();
            }
            catch (FormatException)
            {
                return Maybe.Nothing<object>();
            }
            catch (OverflowException)
            {
                return Maybe.Nothing<object>();
            }
        }

with
private static Maybe<object> ChangeType(string value, Type conversionType, CultureInfo conversionCulture)
        {
            try
            {
                Func<object> SafeChangeType = () =>
                    {
                        var t = Nullable.GetUnderlyingType(conversionType) ?? conversionType;
                        return (value == null) ? null : Convert.ChangeType(value, t, conversionCulture);
                    };

                return Maybe.Just(
                    MatchBoolString(value)
                        ? ConvertBoolString(value)
                        : conversionType.IsEnum
                            ? Enum.Parse(conversionType, value)
                            : SafeChangeType());
            }
            catch (InvalidCastException)
            {
                return Maybe.Nothing<object>();
            }
            catch (FormatException)
            {
                return Maybe.Nothing<object>();
            }
            catch (OverflowException)
            {
                return Maybe.Nothing<object>();
            }
        }

HI @guyzeug,
thanks a lot for posting here. I'm happy you use this project and that your post is about the new 2.0 pre-rel so it can reach a more stable situation.
At the moment I'm working on another issue (68), but I'll examine your contribution as soon as possible.
My best regards,
Giacomo

Added a unit test that expose this bug:
		private class MyOptions
		{
			[Option('f', "foo")]
			public int? Foo { get; set; } // nullable
		}

		[Fact]
		public void Parse_nullable_int()
		{
			var parser = new Parser();
			var result = parser.ParseArguments<MyOptions>(new[] {"--foo", "5"});
			result.Value.Foo.ShouldBeEquivalentTo(5);
		}

However, the proposed fix breaks the following three tests:
CommandLine.Tests.Unit.Core.InstanceBuilderTests.Parse_enum_value_with_wrong_index_generates_BadFormatConversionError
CommandLine.Tests.Unit.Core.InstanceBuilderTests.Parse_enum_value_with_wrong_item_name_case_generates_BadFormatConversionError
CommandLine.Tests.Unit.Core.InstanceBuilderTests.Parse_enum_value_with_wrong_item_name_generates_BadFormatConversionError

I definitely think that nullable types should be supported. @guyzeug, do you want to have a go at coming up with a better fix? :)

@mizipzor, @guyzeug, this is the next thing I'll care about...

@mizipzor, @guyzeug, please check :+1:

Looks good to me, thanks ! :)

@guyzeug, as a side note, now if you use the library from F# you can take advantage of option<'a>.

That's great, thanks for letting me know :)

:+1:


hwid like a audio device fingerprint

maybe this great idea?

it is unique and interesting. users use portable audio device like bluetooth headset. it sounds good.


Try to get author from from in generate license

Author detection logic:

Config option --owner (#104)
Git tag

New logic:

Config option --owner (#104)
Read from dependencies file to get authors.
from python_discover import Root as PackageRoot; PackageRoot(self.config['project']).metainfo.authors.
Git tag

So this issue would require parsing the config file indicated in the build_from parser as --from, getting the author metadata from that and accordingly setting that as author name in license - is this right?

Yeah, right.
loader = CONVERTERS[self.config['from']['format']]
root = loader.load(...)
if root.authors:
...

Alright, thanks.


Chapter 2-Issue saving figures

Hi Aurelien, really enjoying your book a lot.
I have been running across this issue with my code. In the book, you have the following block of code:
housing.plot(kind="scatter", x="longitude", y="latitude", alpha=0.4,     s=housing["population"]/100, label="population", figsize=(10,7),     c="median_house_value", cmap=plt.get_cmap("jet"), colorbar=True,     sharex=False) plt.legend() save_fig("housing_prices_scatterplot")
whenever I type this in however, I get the following error message:
FileNotFoundError: [Errno 2] No such file or directory: '.\images\fundamentals\housing_prices_scatterplot.png'
I dont know where I could have messed up in my code because I cant seem to figure out how to create this directory.
Thank you for your help

Hi @sebassilverac ,
Thanks for your kind message!
The simplest solution is to comment out the save_fig() line: all it does is save the figure, so unless you need the image file, you can safely ignore this line.
However, if you really want this save_fig() command to work, you just need to have an .\images\fundamentals directory. It's part of the handson-ml project, so if you cloned this project, you just need to make sure that you start the Jupyter server from the handson-ml directory.
Alternatively, you can just create this directory by running the following code:
import os
os.makedirs(os.path.join("images", "fundamentals"))

After that, the save_fig() command should work fine.
Hope this helps!

Thank you for the quick response. Your suggestion worked perfectly.
Again, really enjoying this book. very thorough and very informative. I look forward to reading the rest.
Cheers


Streamline gardener-scheduler entrypoint and controllers

How to categorize this PR?

/area dev-productivity
/kind enhancement
What this PR does / why we need it:
This PR streamlines the main entrypoint of the gardener-scheduler and its controllers so that they are in line with all other components which have been refactored to native controller-runtime functionality.
Which issue(s) this PR fixes:
Part of #4251
Release note:

The `metrics` port of the `gardener-scheduler` is no longer hard-coded to `9090` but now uses the same value as the container target port (configurable via the component configuration).

/cc @ary1992

/assign

Failure due to VPN looks unrelated to the changes:
/test pull-gardener-e2e-kind

/lgtm

Rebased after conflicts, adding labels for merge.


Missing config in $PATH

When using npx / npm i -g or installing the library from npmjs, we got the issue of config module accessing NULL config file leading to an error.
This occurs due to config lib searching for the config file in current PWD path ( which is whatever path the shell is located at with global npmjs bin execution.
Fixes would be :

utilizing __filename/__dirname or relative path loading on runtime for global,
AND
programmatic library usage should offer option to provide peer channel public key as parameter for initReader startup method

❯ npx trac-tap-reader
Need to install the following packages:
<EMAIL_ADDRESS>Ok to proceed? (y) y
WARNING: No configurations found in configuration directory:/Users/eL1x00r/config
WARNING: To disable this warning set SUPPRESS_NO_CONFIG_WARNING in the environment.
  _____                  ____                 ____                _
 |_   _| __ __ _  ___   / ___|___  _ __ ___  |  _ \ ___  __ _  __| | ___ _ __
   | || '__/ _` |/ __| | |   / _ \| '__/ _ \ | |_) / _ \/ _` |/ _` |/ _ \ '__|
   | || | | (_| | (__  | |__| (_) | | |  __/ |  _ <  __/ (_| | (_| |  __/ |
   |_||_|  \__,_|\___|  \____\___/|_|  \___| |_| \_\___|\__,_|\__,_|\___|_|

Protocol: Ordinals/TAP
/Users/el1x00r/.npm/_npx/d0d1003349eb1dca/node_modules/config/lib/config.js:182
    throw new Error('Configuration property "' + property + '" is not defined');
          ^

new notice:
due to npx and npm i -g might not be running postinstall script for patching corestore bug,
we should avoid exposing a global package.json bin (!) from now.