Add a cylinder mesh to bevy_render

What problem does this solve or what need does it fill?
Cylinders are a fundamental shape and we should have a means of generating cylinder meshes in Bevy. Currently the closest option to this is a capsule shape.
What solution would you like?
The addition of a Cylinder shape and implementation of From<Cylinder> for Mesh.
What alternative(s) have you considered?

Modify the capsule so that the ends could have zero radius?
Import a GLTF

Additional context
PR #305 implemented this feature but was closed before merge. I would like to bring this PR back to life and get it merged, however, meshes, normals, UVs etc are not my area of expertise and I am having some problems with the UVs/normals I think (see below). Perhaps I can open a new PR for this? Some more commits will be necessary to get the rendering working.

Have you seen the geometric primitives RFC? :)
https://github.com/bevyengine/rfcs/pull/12
It's ready for community comment, so your input on this topic  would be valuable.

I attempted this, but I don't think it's possible to create a cylinder from a capsule. The radius controls both the radius of the capsule section and the radius of the spheres on the ends. Setting radius to 0 makes it invisible. Modifying latitudes and longitudes just changes the resolution. depth changes the distance between the spheres.
Also I experimented with RegularPolygon, and it could be used to create the caps, but not sure how to create the column connecting them.
I think a cylinder needs to be a separate shape.

Sounds good, I'd be happy to have this implemented as a seperate shape.

I'll take a look at #305 and see if I can revive it, but I'll probably have the same problems that @allsey87 had with UVs/normals. But I'll see how it goes.

I'd be happy to donate the cylinder code here: https://github.com/rparrett/typey_birb/blob/main/src/cylinder.rs

Yeah, feel free to PR that code if you want. Maybe add the author of #305 and me as co-authors if you want. IIRC, my code was very loosely based on that one (docs still seem pretty similar) but I abandoned most of it when the UVs weren't behaving and referenced... some textbook somewhere.


Meshex EntryFlags fix

Minor bugfix + version bump

Good catch. Thanks.

The new release is up if you need it.

that was fast, ill be using those releases for the next smush_blender_update ty


[WIP] Integrate with the Swift 4 Decodable Protocol

Just wanted to throw this out there early to get some thoughts from the maintainers of the project (or anyone else, for that matter!).
Basically, I'm not a fan of using the JSON enum for consuming the Twitter API. It's much better than having to cast from Any all over the place, but it's still pretty inelegant--especially compared to what you can get away with in weakly-typed languages like JavaScript.
So, in parallel with a personal project of mine, I've been writing a wrapper API for Swifter, built on top of the Swift 4 Decodable protocol (actually originally built in private on top of the JSON type, then switched to Decodable). I intend to continue working on it no matter what, but I'm willing to go the extra mile and add support for all possible interactions with the API if it's decided that that would be within scope for the project.
The main alternative I can think of to building this wrapper (other than doing nothing) is the following:

Provide generic methods for all API endpoints, which take generic success handlers, which take in arguments of type T where T: Decodable
Defer creation of wrapper types to the user

Lastly, as of right now, all timeline and tweet methods have been implemented, and both demo apps have been updated to use the wrapper instead of the JSON API. Please feel free to ask questions, and give any feedback you have time to.
Thanks!

Hi, thanks again for the contribution. I've actually been thinking about this since Codable was first announced in a Swift Evolution some months ago. From a framework standpoint, I do not think that Swift should provide any struct/class that wraps around the Twitter classes. All Swifter is, is a Twitter API framework that gets the data in a neat fashion; rather, all wrapper classes should be separate from the core project.
What I believe should be done is that we just have a flag (either static or while calling each function) that asks the user if they would like to get a Data struct or the JSON object that we already wrap for them. Plus, if at all necessary, we could always just add a data property on the JSON object to get the raw data (in which they can use Codable to create their own objects).

Thanks for your input, Andy. I can completely understand wanting to limit the project to what you described above. I have an idea of an interesting solution that may or may not work; I’ll report back here soon.

OK, so now I know for sure my idea can work. Here goes, let me know what you think:

Have JSON conform to Decodable (already done; jsonRequest now uses JSONDecoder to create the JSON objects that it passes to JSONSuccessHandlers)
Add one or more (in the case of progress handlers) generic types to each function that returns data through a closure
Add a parameter to those functions allowing users to specify the meta-type of the Decodable object they want in their success handler
The default value can be JSON.self, allowing for full (or close to full) source compatibility
Probably more stuff, I'm tired

I'm also a fan of Codable so much that I've completely removed the JSON enum in favor of the new Swift protocol in my other projects (I also wrote a post about it).
However, as @meteochu says, Swifter doesn't strive to provide structs/classes that wrap around the Twitter ones, this is something that should happen on your side of the project (outside the framework).
Making JSON conform to Decodable is a nice middleground though 😄

Thanks, Federico. Your post was one of the first I came across when I was looking into Codable, didn't realize it was you who wrote it until now, though! Great stuff.
And thanks for the correction. What I might end up doing is just having the Swifter class hold on to an instance of JSONDecoder and use that for all decoding.

The Swift compiler seems to dislike default values for metatype parameters, claims Default argument value of type 'JSON.Type' cannot be converted to type 'T.Type'.
For now, unless there's some other way to do this I haven't thought of, the meta-type parameters will have to be mandatory. If compatibility with old code is important enough, we can just add second versions of each of the public success-handler methods which call the generic versions with JSON.self. Annoying, yes, but not the end of the world. For now though, I'll just be focusing on the generic versions.

Good news! All endpoint methods now support the Decodable protocol, and any existing code that expects JSON objects should work completely unchanged. The demo apps, at the very least, work as expected.
One important note I should make is that all methods which extract data from JSON objects (such as the streaming API methods which decide which handler to call based on the format of the data) were scrapped in favour of using simple success handlers. The specialized JSON methods still extract this data and thus should continue to work as they did before. I originally attempted to recreate this behaviour for the Decodable API, but because Swift doesn't necessarily specialize generic types at compile time, it wouldn't be possible without changing the jsonRequest method to support one of multiple possible types for each handler, and that would get really messy.
Let me know your thoughts, guys.

Any comments or questions so far?

On first glance, it seems a bit messy; I'm hoping for a cleaner implementation than our current one because otherwise there's no point in using Decodable if it's messier. I'll look over it when I have time (can't guarantee when).

Do you mean it imposes messiness on the user’s code, or that the implementation itself is messy (or both)? In either case I can explain why I did what I did, but in general I had to bend over backwards in order to ensure any existing JSON code continues to work unchanged. Perhaps that’s not necessary though?

Both. We shouldn't use a new API just for the sake of using a new API; it needs to make the client's implementation easier, which in this case I'm doubting. Swifter is a framework, which means we need to ensure its flexibility for people using it. IMO using Decodable locks the client down and forces them to use the API even if their implementation doesn't use it, which means we'll be breaking a lot of projects by going with it. Furthermore, making JSON conform to Decodable like an hack and not what the API is supposed to be used for. It's meant for type-safety decoding of JSON of a known schema.
My current preferred solution is just to continue passing the JSON object like we are, and also provide a new rawData property to extract the rawData if they want to use Decodable on the client side, or a generic way of specifying if they want a JSON or Data object in the success handler, which shouldn't be too hard with generic conformance.

Ok, sorry for the long message but there’s a lot to respond to here.
“It doesn’t make the client’s implementation easier”: It’s true that when calling Swifter methods you have to specify a type for the decoder to decode to. But that would be true of any possible implementation of Decodable for this library. Either you add a meta-type parameter or you force the user to specify it in their closure. Technically non-negotiable. I would’ve opted for the latter, except for doing so would break existing non-Decodable code because then the compiler would get confused as to which overload to use. I actually like that option a lot better as we could get rid of the method duplication I added, but again, it would break code so I didn’t do it. I also think you’re overlooking the ergonomic benefit of having type-safe wrapper types to work with.
“Using Decodable locks the client down to using it”: I don’t understand what you mean. What could a user possibly want to do with the JSON data other than decode it in some way? And what projects would be broken by going in this direction? All changes to the public interface are additive.
“Making JSON conform to Decodable is a hack and is not what it’s meant for”: I say it’s a hack that works. It allows all code to continue working as-is, while also giving users who want to customize their experience to do so with custom wrapper types. It’s not extensively tested so maybe there’s a bug or two in my implementation; but ignoring that I don’t see any way that this approach would necessarily produce different results, be significantly less performant, or be more difficult to maintain. JSONDecoder uses the same JSONSerialization type as Swifter does under the hood, after all.
“Our current JSON implementation ensures that the type of the JSON object can always be checked...”: Can you elaborate on how my implementation changes this? Any valid JSON value should be placed into the same enum case as it was before. All I did was add an initializer that takes a decoder.
“My current preferred solution is...”: Both proposed solutions have the problem that they require the user to manually decode the data and catch any potential decoding errors in their success and progress handlers (rather than in the error handlers), which I think is undeniably more inconvenient than merely specifying the type on method call. More on that below, though.
“...provide a new rawData property...”: There’s no efficient way (that I can think of) to handle this in Swift. Either you make rawData a computed property and waste CPU cycles, or you wrap JSON in a struct with a rawData stored property and waste memory.
“...a generic way of specifying if they want a JSON or Data object...”: This has the same problem my solution has. You’d still be forced to specify a type, this time either JSON or Data, but also would still have to decode and handle errors in the data.

Our current implementation is type-safe too. You'll only ever get a value you want to fetch if the type is correct; it'll never hand you the wrong kind of value. Having rawData as a computed property isn't so bad either; it'll only ever get calculated once. Plus, from the completion handler, we can just attach the raw data (pre-JSON-prased) into the success handler: 0 wasted CPU cycles. Plus, leaving the client to decode the data themselves allows them the flexibility to handle how they want to catch the data.
My opinion is that Swifter is simply a framework for fetching Twitter data with convenience. We leave the flexibility and options of implementation to the user, we just need to get the data, and feed it to the user. That's all. They handle the rest. As to how we feed it to them, our current implementation is safe and convenient enough that there's no problems with type-safety, plus, it's extremely convenient to use.
Upon further inspection, what you're doing in JSON is the same as what we do before, except you're just using Decodable to do it. Sure, it's additive, but it's now adding duplicated functionality onto the existing framework, which is unnecessary.

It seems we'll have to agree to disagree, Andy. Thank you for sharing your thoughts

I sincerely apologize if I've wasted your time, but thank you again for your contributions and efforts.

No apology necessary! I would've done this work anyway. I'm just unwilling to compromise on the core of how I've implemented this. That's the great thing about open source software. :)

@zachrwolfe Is your fork still around? I would like the ability to decode JSON into my own model objects rather than use the provided JSON enum type. Seems like you solved this problem in the PR?

@lukestringer90 Unfortunately no, or at least not publicly. I tried to get the discussion going again in #204, but gave up after having trouble soliciting feedback from the maintainers of Swifter. I plan to open-source my fork eventually, but it's not ready at this time. If you'd like, you can email me at zachrwolfe at me dot com and I can share with you the version I'm working with?

@zachrwolfe Great. I'll drop you an email.


Some trading pairs in Binance are not recognized

Some trading pairs in Binance are not recognized, including ALT/USDT and STRK/USDT. I am sure there are more.
Actual Behavior
When I initialize my quantconnect algo to my Binance account, which holds ALTUSDT, it returns the following error:

When I explicitly add_crypto() inside the __initialize__() constructor, it returns:

Expected Behavior
I would expect these trading pairs are supported inside Quantconnect.
Potential Solution

short-term: Adding these two tickers to symbol-properties-database.csv
a better solution: is there a way to write a script to pull all trading pairs from Binance and import them in the csv, and then we run it once a day?

I am happy to investigate this if core dev team is okay with this suggestion and willing to support it.
Reproducing the Problem

Checklist

[x] I have completely filled out this template
[x] I have confirmed that this issue exists on the current master branch
[x] I have confirmed that this is not a duplicate issue by searching issues

[x] I have provided detailed steps to reproduce the issue

Yes, will close as duplicate of https://github.com/QuantConnect/Lean/issues/6469


handle BucketAlreadyOwnedByYou when storing xarray Dataset

When attempting to store an xarray Dataset in zarr format into my own
minio object-store I was getting the exception BucketAlreadyOwnedByYou
from botocore even though the makedirs called had exist_ok=True.
Looking at the s3fs source-code it appears this situation wasn't handled
before, but it is now.

Does this happen also on moto? It would be good to have a test, for existing bucket:

mkdir errors
makedirs(exist_ok=True) doesn't error
makedirs(exist_ok=False) errors

Fixes https://github.com/intake/filesystem_spec/issues/397 ?

Looking at the code, it seems straight-forward, putting this in.


Can't disconnect from DB while testing and using transactional plugin

Hello, I'm trying to integrate nestjs-cls into my project for transactions and faced issue with disconnecting from DB while testing repositories.
There code of tests:
describe(`POSITIVE: UserRepository`, () => {
    let repository: IUserRepository;
    let prismaService: PrismaService;

    beforeEach(async () => {
        const module: TestingModule = await Test.createTestingModule({
            imports: [
                PrismaModule.forRoot({
                    isGlobal: true,
                }),
                ClsModule.forRoot({
                    plugins: [
                        new ClsPluginTransactional({
                            imports: [
                                PrismaModule
                            ],
                            adapter: new TransactionalAdapterPrisma({
                                prismaInjectionToken: PrismaService,
                            }),
                        }),
                    ],
                    global: true,
                }),
            ],
            providers: [
                {
                    provide: IUserRepository,
                    useClass: UserRepository,
                },
                UserMapper,
            ],
        }).compile();

        repository = module.get<IUserRepository>(IUserRepository);
        prismaService = module.get<PrismaService>(PrismaService);
    });

    afterEach(async () => {
        await prismaService.$disconnect();
    });

    it(`Should be defined`, () => {
        expect(repository).toBeDefined();
    });

    it(`Should create user`, async () => {
        const user = UserEntity.create();
        const createdUser = await repository.create(user);

        expect(createdUser).toBeDefined();
        expect(createdUser.id).toBeDefined();
        expect(createdUser.createdAt).toEqual(user.createdAt);
        expect(createdUser.updatedAt).toEqual(user.updatedAt);

        await prismaService.user.delete({
            where: {
                id: createdUser.id
            }
        });
    });

   // More test cases
});

In repository I've provided both private prisma: PrismaService and private readonly txHost: TransactionHost<TransactionalAdapterPrisma> since I need transactions in few methods like creating, updating, but not for searching.
So after tests are done, I'm dropping test DB and there occurs that error Error dropping database: error: database "..." is being accessed by other users and I can't finish testing properly.

Hi, thanks for the report.
There should be nothing preventing the use of txHost along with the original PrismaService (although you can also use txHost.withoutTransaction if you need to run a piece of code outside of the current transaction).
The issue sounds more akin to forgetting an await somewhere.
Would you be able to provide a minimal reproduction of the issue that I can run on my side? The test that you shared doesn't really tell the whole story and I don't know why it shouldn't work.

Sure, need time for creating reproduction so I'll do it in next few days

Hello, there reproduction goes and in Readme I've provided details how to prepare for reproduction

Hi, thank you for the repository, I was able to reproduce it locally, and find the issue.
Investigation
Initially, I thought the issue was caused by the 3rd party library nestjs-prisma, because when I removed it and replaced with setting up Prisma directly according to the NestJS docs, the issue was gone.
Then, I reverted back and thought that maybe the PrismaService was being instantiated twice, so I put a simple console.log into the constructor of the nestjs-prisma library's PrismaService (by editing the compiled javasript file in node_modules) and sure enough, two logs appeared in the output.
The problem
That led me to finally notice the issue with your setup, where you actually register PrismaModule twice.
imports: [
    PrismaModule.forRoot({ // registration #1 - dynamic version
        isGlobal: true,
    }),
    ClsModule.forRoot({
        plugins: [
            new ClsPluginTransactional({
                imports: [
                    PrismaModule // registration #2 - static version
                ],
                adapter: new TransactionalAdapterPrisma({
                    prismaInjectionToken: PrismaService,
                }),
            }),
        ],
        global: true,
    }),
],

The problem is that the first dynamic registration creates a new PrismaModule instance, but so does the second static registration - and because those are two different instances of the module, each provides their own version of PrismaModule - but the static one is only available within the context of ClsPluginTransactional, so you never call $disconnect on it in your test suite.
Another issue you would have noticed is that if you provided some more configuration to the forRoot registration, it would have not been respected within the transactional plugin.
There's a simple fix to this on your side (actually multiple ones):
Potential Fix 1: Don't import PrismaModule in ClsPluginTransactional.
Since you already marked PrismaModule.forRoot as global, there's no need to additionally import it - the PrismaService is available globally
new ClsPluginTransactional({
-    imports: [
-        PrismaModule
-    ],
    adapter: new TransactionalAdapterPrisma({
        prismaInjectionToken: PrismaService,
    }),
}),

Potential Fix 2: Save the dynamic instance to a variable and reuse that
To refer to an instance of a dynamic module, one has to save it into a variable first. If you don't want to make the dynamic instance global, you can do this instead:
+ const prismaModuleInstance = PrismaModule.forRoot({ /* config */ });

const module: TestingModule = await Test.createTestingModule({
    imports: [
-       PrismaModule.forRoot({
-           isGlobal: true,
-       }),
+       prismaModuleInstance
        ClsModule.forRoot({
            plugins: [
                new ClsPluginTransactional({
                    imports: [
-                        PrismaModule
+                        prismaModuleInstance
                    ],
                    adapter: new TransactionalAdapterPrisma({
                        prismaInjectionToken: PrismaService,
                    }),
                }),
            ],
            global: true,
        }),
    ],
    providers: [
        {
            provide: IUserRepository,
            useClass: UserRepository,
        },
        UserMapper,
    ],
}).compile();

Potetial fix 3: Use a wrapper module
Dynamic modules that need to be configured and re-used can be wrapped in a static module and re-exported via Module re-exporting feature (bottom of the page)
+ @Module({
+     imports: [PrismaModule.forRoot({/* config */})],
+     exports: [PrismaModule] // module re-exporting
+ })
+ class ConifiguredPrismaModule {}

const module: TestingModule = await Test.createTestingModule({
    imports: [
-       PrismaModule.forRoot({
-           isGlobal: true,
-       }),
+       ConifiguredPrismaModule
        ClsModule.forRoot({
            plugins: [
                new ClsPluginTransactional({
                    imports: [
-                        PrismaModule
+                        ConifiguredPrismaModule
                    ],
                    adapter: new TransactionalAdapterPrisma({
                        prismaInjectionToken: PrismaService,
                    }),
                }),
            ],
            global: true,
        }),
    ],
    providers: [
        {
            provide: IUserRepository,
            useClass: UserRepository,
        },
        UserMapper,
    ],
}).compile();


create stretch cell

Close #392

I see that some conflicts appear in that branch,
Could I ask you to re-create branch with that exercise ?
Looks like it because you have created branch before I've merged pre-hook, so you have two ways to solve this issue:

Merge that branch with exercise branch
Re-create branch from exercise and copy your code there


[Pluggable Components] Race between daprd and components during startup

In what area(s)?

/area runtime

/area operator

/area placement

/area docs

/area test-and-release

What version of Dapr?

1.10.4
Edge

Expected Behavior
If a configured pluggable component has not yet created its configured socket file when daprd starts initializing components, daprd should wait a reasonable amount of time for the component to create the component (and update file permissions, as necessary).  If, after an unacceptable amount of time, the socket file has not been created, daprd should fail to initialize.
Actual Behavior
Very soon after startup, daprd looks for socket files in the configured location (e.g. /tmp/dapr-components-sockets). If none are found, daprd continues to initialize its components (and will, in fact, appear to succeed).  However, daprd will be unable to "find" the component upon actual invocation as it has not been able to associate the socket with the component.

NOTE: this issue is timing specific and therefore does not always occur; the same machine saw the issue occur repeatedly one day but not the next.

Steps to Reproduce the Problem
The dapr-ai-bindings sample has a branch that adds an arbitrary 2s delay during startup of the component, to force the issue. Instructions for deploying the sample to Kubernetes is here:
https://github.com/philliphoff/dapr-ai-bindings/tree/philliphoff-k8s-deployment#running-in-kubernetes
Logs
Note that the components are "loaded" despite no pluggable components services found.
time="2023-04-03T20:45:32.256056251Z" level=info msg="starting Dapr Runtime -- version 1.10.4 -- commit 42964736b1e99c9c03595c80c61fbe77912391c8" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.256080251Z" level=info msg="log level set to: debug" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.256139334Z" level=info msg="metrics server started on :9090/" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.metrics type=log ver=1.10.4
time="2023-04-03T20:45:32.256249043Z" level=info msg="Initializing the operator client (config: )" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.259085751Z" level=info msg="loading default configuration" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.362470084Z" level=debug msg="No resiliencies found." app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.362495126Z" level=debug msg="Found 0 resiliency configurations." app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.362503001Z" level=info msg="Resiliency configuration loaded." app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.362724293Z" level=info msg="kubernetes mode configured" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.362756084Z" level=info msg="app id: app" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.362767418Z" level=info msg="mTLS enabled. creating sidecar authenticator" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.362806584Z" level=info msg="trust anchors and cert chain extracted successfully" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime.security type=log ver=1.10.4
time="2023-04-03T20:45:32.362818126Z" level=info msg="authenticator created" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.364938168Z" level=info msg="Dapr trace sampler initialized: DaprTraceSampler(P=0.000100)" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.365063584Z" level=info msg="Initialized name resolution to kubernetes" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.365095834Z" level=debug msg="loading pluggable components under path /tmp/dapr-components-sockets" app_id=app instance=app-66db6dc746-xhvh8 scope=pluggable-components-grpc-connector type=log ver=1.10.4
time="2023-04-03T20:45:32.365163334Z" level=debug msg="found -1 pluggable component services" app_id=app instance=app-66db6dc746-xhvh8 scope=pluggable-components-grpc-connector type=log ver=1.10.4
time="2023-04-03T20:45:32.365218584Z" level=debug msg="loading component. name: kubernetes, type: secretstores.kubernetes/v1" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.365306459Z" level=info msg="loading components" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.365852918Z" level=info msg="component loaded. name: kubernetes, type: secretstores.kubernetes/v1" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.46741271Z" level=debug msg="found component. name: ai-engine, type: bindings.ai-engine/v1" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.46743671Z" level=debug msg="found component. name: ai-state, type: state.redis/v1" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.467442126Z" level=debug msg="found component. name: open-ai-gpt, type: bindings.open-ai/v1" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.467458876Z" level=debug msg="loading component. name: ai-engine, type: bindings.ai-engine/v1" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.467479043Z" level=info msg="component loaded. name: ai-engine, type: bindings.ai-engine/v1" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.467492585Z" level=debug msg="loading component. name: ai-state, type: state.redis/v1" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.47050721Z" level=info msg="component loaded. name: ai-state, type: state.redis/v1" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.470528085Z" level=debug msg="loading component. name: open-ai-gpt, type: bindings.open-ai/v1" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.470544376Z" level=info msg="component loaded. name: open-ai-gpt, type: bindings.open-ai/v1" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.470552293Z" level=info msg="waiting for all outstanding components to be processed" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4
time="2023-04-03T20:45:32.470556001Z" level=info msg="all outstanding components processed" app_id=app instance=app-66db6dc746-xhvh8 scope=dapr.runtime type=log ver=1.10.4

Release Note

RELEASE NOTE:

More notes:

It appears the reason for the lack of errors is specific to bindings; state store and pub-sub components that are not found do result in an error.   However, because a component can be an input or output binding, or both, there's a case where neither kind of binding being found that should result in an error, but doesn't.

Pluggable components (as located in the sockets folder) are added to the same registry as built-in components, which could lead to a name collisions as Dapr versions (e.g. a new built-in component is added that has the same name as the socket file name of an existing pluggable component). It might be a good idea to recommend pluggable component developers to use a namespace-like naming scheme.

Because component configuration does not explicitly indicate use a pluggable component (vs. built-in), it may be difficult for Dapr to know during initialization if/when it needs to wait for a socket file to exist.  Perhaps do not pre-register socket file based components but, instead, wait until initialization of a component.  If component is not registered (i.e. not a built-in component), assume it's a pluggable component.  In that case, poll for the existence of the socket file until some timeout period elapses.

/assign

@philliphoff There's a similar behaviour for pubsub. When we deploy the cluster, we deploy both components and apps at the same time. If sidecar happens to start before component is fully created, it just fails silently. Neither app or sidecar will be aware subscription failed so it's a permanent failure.


[Question] Where cai i found compatibility between angular-formio with angular ?

Are you referring to Angular versions that we support?  Currently the place to find that is in the package.json file where it shows the version that is supported. We are currently working toward coming out with an Angular 10 release which should be ready for testing within the next couple of weeks.

We're currently addressing a backlog of GitHub issues, and as part of this effort, some inactive issues may be marked as closed. This isn't a dismissal, but a step toward more efficient tracking.
If you feel the issue is still relevant, please re-open and we'll ensure it gets the attention it deserves. Your understanding is appreciated as we work to enhance our open-source responsiveness.


Moehrke 2020 cp integration for MHD and AppendixZ

Please review Steve

Lynn indicated that the proper edits were published


personal_menu: Fix clicking on Set status not working.

Use tabindex instead of href to set focus on a tag.
Ideally, we should use button for these elements but since we want to keep the pattern for these dropdowns same where some a elements do have a valid href.

Merged, thanks @amanagr! It looks like we have a few others uses of href="", say in web/templates/navbar.hbs -- worth investigating if those should be tweaked too.


Can you share the final loss?

Hi,
I am fine tuning the network. Can you share the final loss you trained with mobile0.25?
You may forgot the exact values, but can you give a rough value (like 3.xxx or 4.xxx) ?  I need a reference.
thanks.

sorry, just remember the general range,
loc: about 1.0 , Cla: about 0.X, Landm: about 2.0

@biubug6
that's good for me. thank you.

@biubug6
Did you train for 250 epochs?


New version: OpenWhisperSystems.Signal version 5.29.0

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

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

already updated the manifest

I think I fucked up by adding the second commit after I noticed my mistake but just before the wingetbot added the manifest error label


fix(v2): fixed props being passed to @svgr/webpack loader

Without comma option -prettier-svgo is parsed as 'prettier-svgo': false
Motivation
Fix problems that svgo introduces when inlining SVG pictures.
Have you read the Contributing Guidelines on pull requests?
yes
Test Plan
Pretty print options are consumed by @svgr directly in node_modules/ directory.

Thanks,
That looks fine to me, however was not really able to understand where does this syntax comes from.
Was wondering if you have a doc ref for this loader syntax anywhere?
Couldn't we make it more conventional and maintainable by migrating it to such syntax?

Let's merge for now but still interested for feedback @anru

Couldn't we make it more conventional and maintainable by migrating it to such syntax?

Definitely.
The only reason I didn't do it was because of the existing setting at the end of the line: "+ref![path]". Absolutely no idea what it is or how it should look like in a complete configuration object.
Regarding the official documentation of parsing loader's string options: I tried to find it on the official website of the webpack, but did not succeed.

Thanks 👍
I also have no idea what is this +ref![path] thing so we likely keep it until someone figure out 😅


feat: Implement the correct way of calling monitor classes depending on position strategy

makes sure monitor classes are called based on position strategyId so we can have multiple.

@ffahimi did you manage to test this? Can we merge it? Seems to be working fine for me.

Tested it with single and multiple tickers and it worked.


'Copy 1st' should be 'Copy Across'?

As an idea, maybe 'Copy 1st' should be 'Copy Across'?

Hilary, Mitch, what would you say?


Possible issue on RPOPLPUSH method inside transaction block

Hi,
First of all, thanks for the lib, you have done an excellent work.
I'm getting this error text WRONGTYPE Operation against a key holding the wrong kind of value when using RPOPLPUSH and the destination list is not created yet, inside a transaction.
Actually, I think that the error text is showed because if list doesn't exists, is creating as String, not as list
I send a StackOverflow link with an example.
http://stackoverflow.com/questions/32487602/redis-node-rpoplpush-method

Sorry!, i found the error, i was using redis-scheduler to make the list expires and catch the event. that converts list key to a string. Thanks for your great job doing this lib.


Extract color at any LinearGradient position [Feature question]

I am using gradient for giving visual representation to a current value on a scale, where green means that the value is inside acceptable limits and red means that the value is outside of those limits. The scale showing these limits is implemented with LinearGradient and Path, the value marker is implemented with Path and the value itself is implemented with RN Text.
The question is
given the current value, how to extract the color corresponding to it in the LinearGradient, so that I can use this color to fill the value marker and the value text?
Here is an example of how my screen looks now and how I want it to look like:

Here is my code:
<View>
  {/* Speed Sensor */}
  <Text style={[styles.sensorNameText]}>Speed</Text>
  {/* Current sensor value */}
  <Text style={[styles.sensorValueText, {color: "green"}]}>{this.state.speedValue}kmh</Text>

  <Svg height={this.state.widthViewLevel2} width={this.state.widthViewLevel2}>
    {/* Creating gradient color fill */}
    <Defs>
      <LinearGradient id="gradient2" x1="0%" y1="0%" x2="100%" y2="0%">
        <Stop offset="0" stopColor="red"/>
        <Stop offset="0.5" stopColor="green"/>
        <Stop offset="1" stopColor="red"/>
      </LinearGradient>
    </Defs>
    {/* Color scale */}
    <Path
      d={"M10 20 L " + (this.state.widthViewLevel2-10).toString() + " 20"}
      fill="none"
      stroke="url(#gradient2)"
      strokeWidth="15"
    />
    {/* Number Scale */}
    <TextSvg
      fill="black"
      fontSize="17"
      x="15"
      y="47"
      textAnchor="middle"
    >0</TextSvg>
    <TextSvg
      fill="black"
      fontSize="17"
      x="105"
      y="47"
      textAnchor="middle"
    >100</TextSvg>
    {/* Current sensor value marker */}
    <Path
      d={"M" + this.state.speedValue + " 8 L " + this.state.speedValue + " 32"}
      fill="none"
      stroke="black"
      strokeWidth="1.5"
    />
  </Svg>
</View>

Any idea how to do it?

Hi, can anyone help with this?
@msand, I've noticed you answered many questions of similar type. Could you suggest something in this case?

@alexsmartens Hey there, the colors are interpolated linearly, inside any part of the gradient it is normal arithmetic where you have an input parameter x giving an argument in [0, 1] with two constants a and b, and the result is (1-x)a + xb
But, the colors have several color components, so you'll probably want to use something from npm like:
const interpolate = require('color-interpolate');

let colormap = interpolate(['red', 'green', 'red']);
let redleft = colormap(0); // 'rgb(255, 0, 0)'
let inbetween = colormap(.25); // 'rgb(128, 128, 0)'
let green = colormap(.5); // 'rgb(0, 255, 0)'
let redright = colormap(1); // 'rgb(255, 0, 0)'

let colorAnywhereElse = normalizedDistanceAlongAxis => colormap(normalizedDistanceAlongAxis);

Then just calculate how far along your scale you are as a number and call that function. color-interpolate does clamping for you, i.e. ensuring you stay inside the scale instead of doing extrapolation. So, it does everything you need except the part which is specific for your app: deciding the scale and colors, and mapping touch events back to the scale.
So, no need to use the native layer for this, you have all the information you need to calculate this already and going over the bridge would just make things slower.

Thanks for your suggestions @msand! I solved the problem by computing RGB color values in my function


Improving Docs and description

Personally as a developer I find this part of the docs confusing. If someone is a semi-newbie it will be even cumbersome to read and understand what kind of info this part is trying to transfer.
I like to improve this in a pr
yarn
nano app.json /* here we go to edit project name and displayName */
react-native eject /* generate ios and android folders */
react-native link /* add app/assets/fonts and react-native-vector-icons  */
cd ios && pod install && cd ../ && yarn ios
yarn android /* android */

this is cool @art1373
let's do it \m/


Install knative-eventing instead knative-eventing-core

KubeArchive needs knative-eventing instead knative-eventing-core now that brokers are introduced
KubeArchive is using in-memory brokers by default which we think is enough. If you think Konflux need more performant brokers like Kafka those should be included.

/ok-to-test

/approve

/test appstudio-e2e-tests

/approve

/approve

/lgtm

The new manifest being brought are not passing kubelinter checks:
kustomize build components/knative-eventing/base/ | kube-linter lint -
KubeLinter v0.6.4-0-g4f0b1e01fd

<standard input>: (object: knative-eventing/imc-controller apps/v1, Kind=Deployment) container "controller" has cpu request 0 (check: unset-cpu-requirements, remediation: Set CPU requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/imc-controller apps/v1, Kind=Deployment) container "controller" has cpu limit 0 (check: unset-cpu-requirements, remediation: Set CPU requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/imc-controller apps/v1, Kind=Deployment) container "controller" has memory request 0 (check: unset-memory-requirements, remediation: Set memory requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/imc-controller apps/v1, Kind=Deployment) container "controller" has memory limit 0 (check: unset-memory-requirements, remediation: Set memory requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/imc-dispatcher apps/v1, Kind=Deployment) container "dispatcher" has cpu request 0 (check: unset-cpu-requirements, remediation: Set CPU requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/imc-dispatcher apps/v1, Kind=Deployment) container "dispatcher" has cpu limit 0 (check: unset-cpu-requirements, remediation: Set CPU requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/imc-dispatcher apps/v1, Kind=Deployment) container "dispatcher" has memory request 0 (check: unset-memory-requirements, remediation: Set memory requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/imc-dispatcher apps/v1, Kind=Deployment) container "dispatcher" has memory limit 0 (check: unset-memory-requirements, remediation: Set memory requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/mt-broker-controller apps/v1, Kind=Deployment) container "mt-broker-controller" has cpu limit 0 (check: unset-cpu-requirements, remediation: Set CPU requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/mt-broker-controller apps/v1, Kind=Deployment) container "mt-broker-controller" has memory limit 0 (check: unset-memory-requirements, remediation: Set memory requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/mt-broker-filter apps/v1, Kind=Deployment) container "filter" has cpu limit 0 (check: unset-cpu-requirements, remediation: Set CPU requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/mt-broker-filter apps/v1, Kind=Deployment) container "filter" has memory limit 0 (check: unset-memory-requirements, remediation: Set memory requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/mt-broker-ingress apps/v1, Kind=Deployment) container "ingress" has cpu limit 0 (check: unset-cpu-requirements, remediation: Set CPU requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)

<standard input>: (object: knative-eventing/mt-broker-ingress apps/v1, Kind=Deployment) container "ingress" has memory limit 0 (check: unset-memory-requirements, remediation: Set memory requests and limits for your container based on its requirements. Refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits for details.)


[BUG] Unexpected error "undeclared name"

The latest master version with the 13th Jan changes (https://github.com/GoASTScanner/gas/commit/cc52ef5b26b37bf253625795b7de6de4d2ef82bd) is unexpectedly reporting the following error on one of my projects:
[gas] 2017/01/14 11:03:59 Processing "/home/user/GO/src/project/src/authrequest.go"...
[gas] 2017/01/14 11:03:59 Failed to process: "/home/user/GO/src/project/src/authrequest.go"
[gas] 2017/01/14 11:03:59 Error during type checking: "/home/user/GO/src/project/src/authrequest.go:25:22: undeclared name: SamlAuthnRequest"
[gas] 2017/01/14 11:03:59 Halting execution.

All previous gas tool versions works fine without reporting any error.
The  "SamlAuthnRequest" is a defined type struct.

Thanks for reporting. It looks like the entire content of the package isn't being considered by the type checker. The simplest reproducer I can come up with is this:
// file1.go
package module

type Something struct {
	Foo string
	Bar string
}

// file2.go
package module

import "fmt"

func FooBar(foo, bar string) {
	something := &Something{Foo: foo, Bar: bar}
	fmt.Printf("%v\n", something)
}

./gas ~/samples/module/...
[gas] 2017/01/14 13:53:14 Processing "/Users/gm/samples/module/file1.go"...
[gas] 2017/01/14 13:53:14 Processing "/Users/gm/samples/module/file2.go"...
[gas] 2017/01/14 13:53:14 Failed to process: "/Users/gm/samples/module/file2.go"
[gas] 2017/01/14 13:53:14 Error during type checking: "/Users/gm/samples/module/file2.go:6:16: undeclared name: Something"
[gas] 2017/01/14 13:53:14 Halting execution.

I'll submit a temporary fix that removes this as a fatal error so the previous behaviour is restored but the way files are processed might need to be reworked to fix it properly.

Might need to use something like https://godoc.org/golang.org/x/tools/go/loader to address these types of errors.

I am working on a fix for this in the experimental branch


multiqueue: Discussion about non virtio interfaces, and validation

Lets use this issue please in order to discuss
If we want to convert Multi Queue to be best effort or keep it with the current validation.
Is your feature request related to a problem? Please describe:
Currently if Multi Queue is enabled, there must be at least one Virtio interface,
or no interfaces at all, else the validating webhook would block the creation
of either the VM or VMI.
There was a suggestion [1] to make Multi Queue Best Effort,
if possible allocate queues, if not don't, but don't fail the request.
The PR was closed because reviewers concluded we should warn
in case of an error, and it can't be best effort even that it has some corner cases.
The discussion was renewed when PR [2] was proposed.
PR [1] suggested the following change:
"enable Multi Queue when it makes sense"
Make the Multi Queue be a best effort.
In case Kubevirt can't honor it, simply don't, but don't reject the VM / VMI.
Reasons:

In case there is only one Cpu, the NIC gets a single queue, even that Multi Queue is enabled.
It will allow to use VM templates, and add any interface type upon needs,
without having to update the Multi Queue field.
Once we have hot unplug feature, it might make things more complicated,
unless the validating webhook is only for VM / VMI creation.
Note that even if it a mixed virtio + non virtio, where we hot unplug the virtio one,
won't be blocked, it means that at the end the machine will be with MQ enabled,
and only non virtio nics, which we block upon creation but not after hot plug.

Arguments against it:

About 1 above - A user asking for Multi Queue with one Cpu simply gets a single queue.
The guest OS user should explicitly request this, and it should
be deterministic, not silently ignored.

Please add any info that I might missed.
Lets discuss please what direction we want to take.
Additional context:
Previous discussions can be found on
[1] https://github.com/kubevirt/kubevirt/pull/4631
[2] https://github.com/kubevirt/kubevirt/pull/7432
@AlonaKaplan @EdDev @dankenigsberg @maiqueb @davidvossel @vladikr @rmohr
FYI as you were involved
Thanks

/cc @lyarwood
In general, we don't have best effort tunings in our VMI api. If some one asks for something, they either get it, or they get a validation error if the tuning can't be satisfied.
The new flavor api does conceptually allow for best effort tunings though. For example, with the flavor api we're considering the idea of preferred fields. So a flavor could have preferredDiskBus=virtio which would default the disks to use virtio on a vmi. I could see preferredMultiQueue being another option.

It will allow to use VM templates, and add any interface type upon needs,
without having to update the Multi Queue field.

If preferredMultiQueue is part of the flavor, then multiqueue doesn't have to be a part of the template at all. The flavor matched to the VMI will handle multiqueue.

/cc @lyarwood
In general, we don't have best effort tunings in our VMI api. If some one asks for something, they either get it, or they get a validation error if the tuning can't be satisfied.
The new flavor api does conceptually allow for best effort tunings though. For example, with the flavor api we're considering the idea of preferred fields. So a flavor could have preferredDiskBus=virtio which would default the disks to use virtio on a vmi. I could see preferredMultiQueue being another option.

It will allow to use VM templates, and add any interface type upon needs,
without having to update the Multi Queue field.

If preferredMultiQueue is part of the flavor, then multiqueue doesn't have to be a part of the template at all. The flavor matched to the VMI will handle multiqueue.

Apologies just catching up after PTO. Yeah the current series for flavors and preferences in https://github.com/kubevirt/kubevirt/pull/7578 introduces a preference of preferredNetworkInterfaceMultiQueue that is applied to the VMI submitted by the VM controller on start:
https://github.com/kubevirt/kubevirt/blob/a9c43b1cb6da664cecef2db5aba9863e8080c8b4/pkg/flavor/flavor.go#L311-L313
There's a chunky functional test in the series that needs to be broken up eventually but should give some context on how we envisage using flavors and preferences:
https://github.com/kubevirt/kubevirt/blob/8ab9f209dbca6a07b50f41bb393d8e2228a77ea6/tests/flavor_test.go#L178-L296

I think that deprecating networkInterfaceMultiqueue in favor of a flavor-level preferredNetworkInterfaceMultiQueue would make sense.
(I should dive deeper to understand how flavor-level defaults/preferences are going to be resolved with lower-level specific requests, but this is not the right place to discuss it)

In general, we don't have best effort tunings in our VMI api. If some one asks for something, they either get it, or they get a validation error if the tuning can't be satisfied.

I agree we do not have "best effort", however, we have something much worse (in API concepts): We have defaults.
Not only that, when the default was detected as not a fit for all cases, instead of going in the path of "specifics", we went and created a configurable defaults.
These layers of defaults and configurable defaults led us to the problem of maintenance we have today.
It is not only our maintenance issue, but also of clients that need to use our API.

We can't deprecate NetworkInterfaceMultiqueue directly as PreferredNetworkInterfaceMultiQueue would still need something to set in the DomainSpec. We could however encapsulate the graceful fallback logic within the PreferredNetworkInterfaceMultiQueue preference, avoiding a failure when we later validate the VirtualMachineInstance

I think the direction is not to deprecate the functionality, but the API that tries to describe a generic state instead of being specific (per interface). If we will have this parameter per interface, there will be no need to make complex decisions and the flavors can easily adjust and set these per the interface types.

Meaning the VM would have flavor with preferredNetworkInterfaceMultiQueue, and the VM controller would set on the VMI the multiqueue related tunings.
So, the flavor is using VMI tunings behind the scenes. We cant' get rid of tunings that the flavors use.

I think @dankenigsberg aimed to the deprecation of the global parameter in favor of one per-interface. Then the flavors will translate the needed (with its own logic) over to the logic-less API.
Will that make sense?

I think @dankenigsberg aimed to the deprecation of the global parameter in favor of one per-interface. Then the flavors will translate the needed (with its own logic) over to the logic-less API.
Will that make sense?

i don't know. It's unclear to me why someone would ever need to set this multiqueue option per interface
Maybe to take this back a bit. This discussion exists because of the technical limitations we have with what can be expressed using a VM templates. VM templates are static with variable substitution. Depending on the variables, it's possible portions of the VMI spec need to change for the spec to make sense.
The options i see are

change the multiqueue behavior on the VMI, which gets a little weird when people set multiqueue but don't actually get multiqueue
replace templates with flavors/preferences.

Is there a reason we can't plan to go with item 2?

i don't know. It's unclear to me why someone would ever need to set this multiqueue option per interface

Multiqueue does not for free. Each queue takes memory and we allocate a CPU to service it. It makes sense to enable multiqueue only on interfaces where this kind of service is needed. That is why Linux and libvirt allows to set the number of queues per NIC. KubeVirt opted not to do so, but rather hard code a policy on how many queues should each NIC be allocated, based on the total number of cpus and nics. But that's not the only possible policy.

This discussion exists because of the technical limitations we have with what can be expressed using a VM templates.

The discussion also stems from generic API design reasoning. The current API is not normalized and should be improved as it incurs redundant webhook validation, caused one bug and is likely to cause others once we allow NIC hot-plug.

change the multiqueue behavior on the VMI, which gets a little weird when people set multiqueue but don't actually get multiqueue

Note that this happens today, too. If I ask for multiqueue on a VM with one CPU, I'm getting a single queue. Our current API is already weird because on one hand it is very strict (you are not allowed to request multiqueue if you have no virtio) but on the other it quite lax (you may get a single queue). We have a semantics that is "best effort with a thorn".

replace templates with flavors/preferences.

Flavors gives us another location to clean up after imperfect API. For example, I assume that the flavor named "highperf" would have logic to enable multiqueue if the VM has virtio NIC, but disabled multiqueue if there is no NIC at all. In a way, it would be fighting against the lower-level KubeVirt API. I suggest to tidy up the lower level API, either by making it "best effort all the way" as in PR#4631 or by precise prescription as libvirt does.

Does this sound reasonable?

To me it does, I suppose some people would like to see how many queues were enabled on each NIC.

What about allowing to get this info, but not via the status.interfaces but via some virtctl API or so ?
I feel its better to keep  status.interfaces as light as possible ?

FWIW I agree with David here.

What about allowing to get this info, but not via the status.interfaces but via some virtctl API or so ? I feel that it is better to keep status.interfaces as light as possible ?
Another possible advantage of such, is that we don't need to keep this info anywhere, we just fetch XML upon request IIUC.

It's hardly overloading vmi.status.interfaces with additional data? Plumbing in a virtctl command that reaches all they way down into the domain XML of a guest seems far more heavyweight in comparison to me at least.

What about allowing to get this info, but not via the status.interfaces but via some virtctl API or so ?
I feel that it is better to keep status.interfaces as light as possible ?
Another possible advantage of such, is that we don't need to keep this info anywhere, we just fetch XML upon request IIUC.

the vmi status is the place used to aggregate info related to the vmi and publish it over a well defined api. I wouldn't be concerned about the status growing a new field, this happens pretty regularly as we need to present more detailed information.

PR created https://github.com/kubevirt/kubevirt/pull/8071


In Exercise 3.36 #include  is unnecessary

I just found out that this Compiler Directive was unnecessary.
About the compiler I used:
$ clang -v
Apple LLVM version 8.0.0 (clang-8<IP_ADDRESS>)
Target: x86_64-apple-darwin16.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Its compiler associated. I am closing the issue.


Powertrackreplay

At the end of a Twitter PowerTrack Replay, Gnip sends a "replay completed" message with information about the replay status (http://support.gnip.com/customer/portal/articles/477751-powertrack-replay#Data Format). The changes in this pull request extend the Gnip4j model with classes for handling such completion messages.

I rebased the pull https://github.com/zauberlabs/gnip4j/tree/powertrackreplay

I rebased the pull https://github.com/zauberlabs/gnip4j/tree/powertrackreplay again.
Also amended the commit to pass the forbiddenrules plugin (specify the locale in the parser)
I was reviewing http://support.gnip.com/apis/replay2.0/api_reference.html and still makes sense. There is still the case of “Request Failed to Complete” Message that is not mapped.


PHP: php server generator

@stanley-cheung

Hello. Server is a nice feature, good job. I have a question - is that approach scalable? I mean how to add more workers or handle more than one request in time?

Hello. Server is a nice feature, good job. I have a question - is that approach scalable? I mean how to add more workers or handle more than one request in time?

@hotrush Thanks for the interest in this. We are still in an exploratory mode right now to see how far we can take this. Right now our proof-of-concept is only limited to 1 request at a time, CLI-only environments, and other limitations (e.g. lack of proper threading support in PHP). So this likely are not going to be a 'general purpose' server implementation like other languages. We are in the process of looking into how far we can take this while still being useful.

Ok clear. For now i find spiral's roadrunner the best approach to implement
grpc server in php. They have their own abstractions, but maybe in the
future will support official ones, less confusion will be.
сб, 5 дек. 2020 г., 0:37 Stanley Cheung<EMAIL_ADDRESS>
Hello. Server is a nice feature, good job. I have a question - is that
approach scalable? I mean how to add more workers or handle more than one
request in time?
@hotrush https://github.com/hotrush Thanks for the interest in this. We
are still in an exploratory mode right now to see how far we can take this.
Right now our proof-of-concept is only limited to 1 request at a time,
CLI-only environments, and other limitations (e.g. lack of proper threading
support in PHP). So this likely are not going to be a 'general purpose'
server implementation like other languages. We are in the process of
looking into how far we can take this while still being useful.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grpc/grpc/pull/24749#issuecomment-739034162, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJQOHCNIESJYN4ITQMLFGDSTFJAFANCNFSM4TVAUFKQ
.


Include how to change the TLS version used by Invoke-WebRequest

Prerequisites

[X] Write a descriptive title.
[X] Search the existing issues.
[X] I am reporting the documentation problem for the current version of Azure CLI.

Azure CLI version being used
2.34.1
Link to affected document
https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-windows?tabs=azure-powershell
Description of the documentation error
The documentation doesn't explain that the minimum required TLS for the storage account distributing the Azure-cli is TLS1.2.   When using an Azure virtual machine running windows 2016 datacenter I wasn't able to download the CLI following the example powershell command on this page.
Suggested fix
Include a powershell command to change the security protocol as a potental fix if a user encourters the error:

Invoke-WebRequest : TlsVersionNotPermittedThe TLS  version of the connection is not permitted on this storage account.

Powershell command that fixed my issue:
[Net.ServicePointManager]::SecurityProtocol =[Net.SecurityProtocolType]::Tls12

Thanks for bringing this to our attention. We are actively investigating and will get back to you soon.

Hey @JUUTC thanks for the feedback and the PR :) I just want to check with the eng team to make sure that this is something that should be and not something we need to implement.
@jiasli ,Can you confirm that this should be the case?

I think this is more of a question regarding Invoke-WebRequest and out of the scope of Azure CLI.


4119, 4030

#4119 Roxygen IntelliSense does not incrementally search

limit trigger to @
include '@' in the applicable span in comments (normally search stops on non-identifier chars)
add tests

#4030 Update package index on connection change

update list of packages when connection changes

👍


Example doesn't run in Xcode simulator

I'm trying to get the example running on the Xcode IOS simulator and am getting an exception here. The exception is Thread 1: EXC_BAD_ACCESS (code=1, address=0x10). It seems that lookupPrivateKeyRef is returning nil here and generateKeyPairWithAccessControlObject is returning false here. I'm not used to working with iOS stuff, so I'm not really sure how to debug this further.
I've tried running another SEC example, but get a parameter error (-50) from SecKeyGeneratePair. I'm wondering if SEC doesn't work at all in the iOS simulator?
Any help would be appreciated. I'm running

Xcode: Version 7.3.1
Simulator: iPhone 6s / iOS 9.3 (13E230)

Let me know if I can provide any other debugging output or information.

This is due to the simulator not supporting the TouchID interface. There's nothing I can do about it.


fix(*): check for key already exists errors only

refs #3790
This change is necessary as etcdctl globs all server errors as exit code 4, including the infamous all the given peers are not reachable as well as Key already exists. Instead of checking the error code, we can check what's on stderr so we can safely ignore Key already exists "errors".

fixed up the logic to only check for the string. I manually tested this logic via
core@deis-01 ~ $ ERROR="$(etcdctl --no-sync mk /test foo 2>&1 >/dev/null)"
core@deis-01 ~ $ ERROR="$(etcdctl --no-sync mk /test foo 2>&1 >/dev/null)"
core@deis-01 ~ $ if [[ $? -ne 0 && $(echo $ERROR | grep -ive "key already exists") ]]; then echo $ERROR; fi

I've run this many times and I'm confident it filters out only the "key already exists" errors now. Code LGTM.
Jun 05 16:06:40 deis-01 sh[2828]: d9163538dd6c: Download complete
Jun 05 16:06:40 deis-01 sh[2828]: d9163538dd6c: Download complete
Jun 05 16:06:40 deis-01 sh[2828]: Status: Downloaded newer image for <IP_ADDRESS>:5000/deisci/controller:git-b2a77e3
Jun 05 16:06:40 deis-01 systemd[1]: Started deis-controller.
Jun 05 16:07:07 deis-01 sh[3147]: etcd_set_default: an etcd error occurred (Error:  501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0])
Jun 05 16:07:07 deis-01 sh[3147]: aborting...
Jun 05 16:07:07 deis-01 systemd[1]: deis-controller.service: main process exited, code=exited, status=1/FAILURE
Jun 05 16:07:07 deis-01 docker[3696]: Error response from daemon: No such container: deis-controller
Jun 05 16:07:07 deis-01 docker[3696]: time="2015-06-05T16:07:07Z" level="fatal" msg="Error: failed to remove one or more containers"
Jun 05 16:07:07 deis-01 systemd[1]: Unit deis-controller.service entered failed state.
Jun 05 16:07:07 deis-01 systemd[1]: deis-controller.service failed.
Jun 05 16:07:12 deis-01 systemd[1]: deis-controller.service holdoff time over, scheduling restart.
Jun 05 16:07:12 deis-01 systemd[1]: Starting deis-controller...
Jun 05 16:07:12 deis-01 systemd[1]: Started deis-controller.

Could we make a similar change to etcd_safe_mkdir in the builder boot script? I have also seen it fail with the same etcd 501 error.

done

Code LGTM.

Code LGTM. Come on Jenkins...


codenarcRulesets in .groovylintrc.json config file

Allow to link to CodeNarc RuleSet files from .groovylintrc.json, using property "codenarcRulesets". Warning: doing so means that all other properties of config file will be ignored.

Closes #82

Codecov Report

Merging #86 into master will increase coverage by 0.06%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #86      +/-   ##
==========================================
+ Coverage   93.68%   93.75%   +0.06%
==========================================
  Files          72       72
  Lines        1788     1792       +4
==========================================
+ Hits         1675     1680       +5
+ Misses        113      112       -1

Impacted Files
Coverage Δ

lib/codenarc-caller.js
84.67% <ø> (+0.72%)
:arrow_up:

lib/config.js
75.00% <100.00%> (+0.75%)
:arrow_up:

Continue to review full report at Codecov.

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


[HotFix][Zeta] fix after the savepoint job is restored, the checkpoint file cannot be generated #4985

…e generated

Purpose of this pull request

Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

[ ] Update the release-note.

#4985


fixed check all of yii\grid\CheckboxColumn

Q
A

Is bugfix?
yes

New feature?
no

Breaks BC?
no

Tests pass?
yes

When click checkAll,  the 'checked' attribute of sub checkers has been modified, but ui was not changed.

attribute of sub checkers

What is sub checkers?

I guess you are using some beautifier for checkboxes and it does not show that checkbox is checked unless you add a checked class on it, right?
Then the PR is incorrect, because without beautifier it will add a checked class to a <td> tag.
Closing, unless further information provided.

You are right ~~~

Try using iCheck plugin with hiqdev/yii2-asset-icheck and initialize in somehow like it's done here.
I hope it will help you in solving this problem

Thank you , i will try it.


Update support for external resources on services

Description
This adds support for external resources to services.
PR readiness

[x] Relevant documentation has been updated if this PR adds or updates attributes, resources, or data sources.
[x] An entry has been added to the changelog, if necessary.

Hi there. I'm sorry to ping but we would really appreciate it if this PR can be merged and released alongside https://github.com/firehydrant/terraform-provider-firehydrant/pull/121 🙏


Update URL to Beautiful Web Type

Hello,
The URL to Beautiful Web Type has changed. The previous domain was purchased by a spammer who is using it to link to their essay writing services. The new URL also contains a much improved version of the project. Thanks!

Thank you very much dear Chad, I really appreciate your contribution.


build: setup treasury, light-client, whale(meme token)

Type of this PR

Select at least one type

[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Bug fix
[ ] Dependency, Environment, Build related update
[ ] Documentation
[ ] Other tiny fix

Describe your changes
Setup treasury, light-client, whale(meme token).
(기존 PR의 경우 제가 local branch를 최신화 하는 과정에서 rebase 대신 merge를 쓰는 바람에 commit history가 이상했었는데, 이걸 이미 PR 올린 상황에서 수정하는 방법을 모르겠어서 새로 branch 만들어서 PR 다시 올립니다.)
Issue ticket number and other helpful resource
Checklist before requesting a review

[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] Leave reference about this pull request, if exist (ex. discord message, google docs, etc)
[ ] If it is a core feature, I have added thorough tests.

Checklist after creating a pull request

[ ] Mention reviews in discord channel directly

duplicated


Update compilerplugin, scalapb-runtime to 0.11.1

Updates

com.thesamet.scalapb:compilerplugin
com.thesamet.scalapb:scalapb-runtime

from 0.11.0 to 0.11.1.
GitHub Release Notes - Changelog - 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 = "com.thesamet.scalapb" } ]

labels: library-update, semver-patch

Superseded by #31.


[FEATURE REQ] Add Provider block to Microsoft.KubernetesConfiguration

API Spec link
https://github.com/Azure/azure-rest-api-specs/blob/main/specification/kubernetesconfiguration/resource-manager/Microsoft.KubernetesConfiguration/stable/2023-05-01/fluxconfiguration.json#L431
API Spec version
2023-05-01
Please describe the feature.
Description
Flux release new feature which enable us to use OIDC authentication. Now we can pull code from ADO repository using workload identity instead of using PAT token.
FLUX feature release: https://fluxcd.io/blog/2024/09/flux-v2.4.0/#azure-devops-oidc-authentication
Detail on how to set up Azure OIDC: https://fluxcd.io/flux/components/source/gitrepositories/#provider
We are using flux extension on AKS so that we can utilize terraform to configure fluxconfig, gitrepository objects of flux. Apparently, Azure REST API does not support provider block.
Related github issue to update terraform block: https://github.com/hashicorp/terraform-provider-azurerm/issues/27821

Any updates on this? Being able to configure flux from outside cluster is a huge bonus, modifying files via patch inside cluster isnt very ideal.


Composer phpcs lint doesn't work in most cases.

Describe the bug
Since most WordPress projects will have multiple plugins, running phpcs . from the wp-content directory will run out of memeory.
Steps to Reproduce

Install a few plugins
Run composer run lint
See error when it runs out of memory

Code of Conduct

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

This has been fixed by ignoring /plugins/* by default and specifically defining the directories we want to analyse.


Add Table.Unpivot in the known unsupported functions

The section detailing the unsupported functions should be updated to contain the Table.Unpivot, since it is one of the unsupported functions.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6837cab4-07bc-f78a-245d-8edbfc355c7f
Version Independent ID: a6717eae-d851-40bd-4325-89c63ad17106
Content: Data wrangling functions in Azure Data Factory - Azure Data Factory
Content Source: articles/data-factory/wrangling-functions.md
Service: data-factory
Sub-service: data-flows
GitHub Login: @kromerm
Microsoft Alias: makromer

Thanks for the feedback and bringing this to our notice. At this time we are reviewing the feedback and will update the document as appropriate.

@please-close

#please-close


Really bad luck, or a bug?

Looking through the hi scores i found this interesting profile:
https://collectionlog.net/log/Torttunaama/Hard Treasure Trails
I think it is very unlikely that after 319 hard clues they only found 2 uniques? So is this an issue with the display on the site, or does the user just need to re-upload the info?

Reviewing the user now, they have 111/134 slots unlocked. I think after they re-opened the hard clue collection log and uploaded the data, things are fixed on the site's side.


Fix error from slack

hey,
similar to the visualization.py you could try changing
https://github.com/EmmanuelOwusu/SlowFast/blob/f36844ca56c557d01f23b59b5ff5dcff6dc26d79/tools/test_net.py#L49
to
for cur_iter, ((inputs, filenames), labels, video_idx, meta) in enumerate(test_loader):

Look at the newer issue #2 . This is not up to date anymore.


certs

👷 Deploy Preview for vargas-work-portfolio processing.

Name
Link

🔨 Latest commit
7870db6d4120a649b02a989650285b436245e00b

🔍 Latest deploy log
https://app.netlify.com/sites/vargas-work-portfolio/deploys/64e2662e36792e0008aac3af


feat: Create Onsite Order for Tickets

Fixes #1012
Checklist:

[ ] I have checked for PMD and check-style issues
[x] I have read the Contribution & Best practices Guide and my PR follows them.
[x] My branch is up-to-date with the Upstream development branch.

Changes:

Select from multiple tickets available for event.
Create Onsite order with onsite attendees.
Option to clear the selected tickets.

Screenshots for the change:

@iamareebjamal @sridharjajoo @mishuvs Please review.

Show currency. Also, there is no visual feedback as to when user is clicking somewhere

@iamareebjamal I've made the changes. Here is the new gif.

@Masquerade0097 I think the background can be made blue to make it more consistent with app design

@sridharjajoo I've made the changes.


Compiler generated crash

It's seems that there is a crash related to keys of dictionary's in RelativeFormatterLanguage.
I don't have any additionnel informations so here's the stack :)

Any news on this ?

I've not encountered it by compiling with XCode 11. Are you still experiencing it?

Well, some of our users encountered it (4 on 500-600) but only on iOS 12 !


Enhanced Rectangle/Document detection in android

This is an attempt to address issue #29.
This branch is meant to experiment with a different algorithm to find the best rectangle in the image.
Things being tried:

Function that filters and finds the largest/best looking rectangle. UPDATE: Not very effective
Enhancing the filter before attempting to find the edges (brightening the image if it's too dark, etc). UPDATE: This is showing some promising returns
Updating OpenCV.

Filtering issue:
So far, I'm not really liking the solutions. We need to have some sort of check to make sure the ratio isn't too far out of line, as well as something that makes sure it is large enough.
Another thing I will be looking into is the transforms on the image before the contours are found. This may be what is causing issues where the rectangle is just not detected at all.

Latest update. I experimented with changing the alpha and beta channels of the image (gain and brightness) based off of the brightness of the image. This allows for better fitting/high contrast images which makes the edges pop a lot better. In terms of finding rectangles, it looks like it made the android simulator much better at detecting, but maybe no change on my android phone (it's ancient LG G3, so it could be just a weird thing with that). I have one more trick up my sleeve, and that would be to update OpenCV. Maybe it's gotten smarter?
Here's an image (after applying high contrast filters) with a fake receipt that OpenCV is having difficulty finding the receipt/rectangle in. Again, this is on a really old phone, so that could be the issue too.

Any news on this ?

@humphreyja as you mentioned in the thread regarding upgrading openCV, could you give us a hint about how to upgrade openCV for this project?


cgicc does not compile on Ubuntu 18.04 WSL

Hello,
Everything is up to date, I have deleted the downloads and buildtress folder and tried to compile and it still did not compile.
I try to compile cgicc and it does not compile on Ubuntu 18.04 WSL.
I get this message:
odin@Odin:/mnt/c/Projects/vcpkg$ ./vcpkg install cgicc
The following packages will be built and installed:
cgicc[core]:x64-linux
Starting package 1/1: cgicc:x64-linux
Building package cgicc[core]:x64-linux...
-- Downloading http://ftp.gnu.org/gnu/cgicc/cgicc-3.2.19.tar.gz...
-- Extracting source /mnt/c/Projects/vcpkg/downloads/cgicc-3.2.19.tar.gz
-- Configuring x64-linux-dbg
-- Configuring x64-linux-rel
-- Building x64-linux-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:136 (message):
Command failed: /mnt/c/Projects/vcpkg/downloads/tools/cmake-3.14.0-linux/cmake-3.14.0-Linux-x86_64/bin/cmake --build . --config Debug --target install -- -v
Working Directory: /mnt/c/Projects/vcpkg/buildtrees/cgicc/x64-linux-dbg
See logs for more information:
/mnt/c/Projects/vcpkg/buildtrees/cgicc/install-x64-linux-dbg-out.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_build_cmake.cmake:96 (vcpkg_execute_build_process)
scripts/cmake/vcpkg_install_cmake.cmake:24 (vcpkg_build_cmake)
ports/cgicc/portfile.cmake:21 (vcpkg_install_cmake)
scripts/ports.cmake:73 (include)
Error: Building package cgicc:x64-linux failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: cgicc:x64-linux
Vcpkg version: 2019.06.26-unknownhash
Additionally, attach any relevant sections from the log files above.

Hi @odin-loki, thanks for reporting this issue!
I've fixed it, please update vcpkg and rebuild cgicc.
Thanks.


linting: black & isort

Apply black and isort to the code base. It's a relatively big PR so I will add a .git-blame-ignore-revs once this is merged and we know the hash. Config options and flake8 will follow in another PR.

@romatt do you want to set the default merge settings to "squash and merge"?

Yes squash and merge is fine for me! Sorry, I'm currently super busy at work and have almost no energy left for more software dev  in the evenings...

Yes sure thats totally fine!!


Consider account linking

Hello, great work!
I was looking how an account linking strategy could be implemented and looking at a few passport examples, I saw it was possible to access the request (and knowing if a user is already signed in or not). Would you consider having this implemented?
I think it may also need something like #14 if the "already logged in then ignore" behavior is to be kept.
Sources:

https://codeburst.io/account-linking-with-passportjs-in-3-minutes-2cb1b09d4a76
https://github.com/jaredhanson/passport-oauth2/blob/master/lib/strategy.js

Agreed. A potential implementation can be:
At https://github.com/sergiodxa/remix-auth-oauth2/blob/main/src/index.ts#L138, we can add an option: linkAccount.
If user sets this option to true, it simply bypasses the https://github.com/sergiodxa/remix-auth-oauth2/blob/main/src/index.ts#L149 line.
CC: @sergiodxa

In #89 now you can call the authenticate method and it will do the process again, allowing linking accounts.


Scale policy

Scale policy parameter was added to the service object (updatable). Fields:

minScale - minimum number of instances required to be running for the service
maxScale - maximum allowed service scale.
increment - reflects a number of containers being deployed simultaneously as we move from minScale to scale.
Example:

service created policy {minScale:2, maxScale:4, increment:2}.
Durning activate, we try to deploy 2 (=minScale) containers. If it fails, service activation fails as we don't match minScale. If succeeds, move to 3)
We increment scale by 2 (=increment), and wait for these instances to deploy. If at least one of them fails to deploy, we roll back to 2, and reconcile finishes with currentScale=2. If deployment of 2 extra instances is successful, reconcile finishes with currentScale=4

@soumyalj besides testing different combinations of scale policy params, we would have to test scalePolicy update use case

@alena1108, does this new scale policy allow for the use case of testing the health check once to decide whether it is ok to proceed to the next instance(s)? This would allow for rolling upgrades where some synchronization is required between peers (e.g. zookeeper nodes) and the container state (active or not) may not be enough.

@ruimarinho checking health_state check before proceeding to the new batch during in-service upgrade, was fixed as a part of diff issue. Scale policy just lets you bend the scale by saying "try your best, but do the min"

One thing to consider is that the health check waits for the "initializing timeout" before running and advancing to the next batch if the check is successful so, in practice, this means that the batch interval will always be as small as this health check "initializing timeout".
Perhaps this is part of a different issue and I'll be glad to file it separately if you prefer, but shouldn't the "initializing timeout" be the maximum amount of time that repeated health checks can be tested until the container is considered healthy when starting? This way, if a service only takes 10 seconds to boot and the batch interval is set to 30 seconds, then the health check could be repeatedly executed every X seconds (e.g. 2s) until it responds successfully. Otherwise, after a certain amount of time of failed health checks attempts, the upgrade would fail.

Tested with 1.1.0-rc4.


Add muscle frames & update code

I have completed the implementation of code for automatic scaling of muscles frame.

I ran the code and the muscle frames are scaled correctly.

Thanks @AntonellaTatarelli @lrapetti for review. I proceed to merge the code!


Deployment cleaning

This is a big change. This might affect the downstream forks! Please review and approve.
Its primarily motivated by:

Need for secure workflow deployment but yet flexible.
To make what is committed as the sole truth in deployment  across environments.
Clean unwanted stuff.

Changes and How does it affect?

It is different from the current way of deployment in development, testing and production environment.
It might seem annoying/difficult/unwanted but its only one time and will be accustomed to the workflow.
Added couple of new things to setup: 1) to make directory called secrets and 2) to define environment file called .rs-api.env., before actual  deployment.
Any deployment is through multiple-compose files.
Have Added examples to simplify the multiple-compose files deployment. Its at readme/multiple-compose-files.md.

Please suggest any edits or any other suggestions on the commits of this PR.
PS: What is redeployer @rraks ? Its only in the catalogue server and commands are complicated, would love to understand what it does and how it works!

Added clustered resource server single container and multi-container deployment through docker stack deploy in the deployment repository.


refactor: evolve plugin configuration enhancement

Consider adding an Evolve plugin by default - and/or change API for configuring the executionContextModifiers of the StateEvaluator - as currently the dev exp. sucks - ie. in case you want to use custom cache for the DefaultStateEvaluator AND want to use the Evolve plugin - you need to configure from scratch the DefinitionLoader and ExecutorFactory.

@asiaziola , that's a good task for you, so that you get a little more familiar with the SDK


timesRepeatOptimization failing on Pharo10

On Pharo10 the timesRepeatOptimization is failing when tempVar are declared inside the block.
This is not proper fix but a terrible workaround that bypass optimization when there is a temp in the block.

So it seems like the RBAssignmentNode in the block handles temp differently:
on Pharo9:
anAssignmentNode variable >> aRBTemporaryNode

on Pharo10:
anAssignmentNode variable >> aRBVariableNode

Yes indeed. We are in the middle of migrating block transpilation and found several differences between compilers of P9 and P10.

The test extension does capture a bug. But, the fix basically just skip the optimization, instead of actually addressing the root problem.

Fully agree, the point of the PR was more to point out the issue I was facing rather than providing a proper fix.

It looks like the bug is related to the part we are currently addressing.

Is there a working/dev branch I could look at?
Anyway we can close the PR as I don't expect it to be merged. As I said this was a terrible workaround/hack to get the pharJS-examples to work.


RSA support?

I'm curious if there are plans to support any form of asymmetric algorithm with this library.

Yes. For signing I do have support for elliptic curves. RSA as you mention in the headline is a bit of another question since there is not any defined for RSA in COSE yet (a draft exists and should not be that hard).
I have started to look at ECDH for encryption but have not gotten the time to put all the pieces together.

Any update on this? What would it take to implement RSA support?

We have implemented RSA-PSS signature verification in a fork (including cose-wg testcases): https://github.com/JesusMcCloud/cose-js
Implementing signature creation should be straight-forward.
I'm hesitant to submit a PR, since we also added support for synchronous signature verification (without removing the promise-based call)

@JesusMcCloud I'm also interested in a sync interface but probably it should be done in a separate PR. Is there any reason why you didn't use Node's crypto module for RSA-PSS? cose-js already has a dependency on it so it should be fine to use it.

@letmaik we needed something that works without promises (and in the browser)

@JesusMcCloud  I would be happy to review a PR

the PR has been merged and released

Just to clarify, this does not provide RSASSA-PSS as mentioned in the draft on RSA support in COSE https://tools.ietf.org/id/draft-jones-cose-rsa-05.html


abfs produces corrupted files when data is big enough

Hi,
Thanks again for working on azure integration.
I've been hitting a tricky adlfs/abfs bug on a dask data extraction pipeline.
I have a bag containing json data spread in several partitions spread over several workers in a dask cluster hosted in Kubernetes using dask-kubernetes. The whole dataset contains ~1-10 million items. When the partition size exceeds a certain threshold (in my case more than 150_000 items), the export to textfiles produces corrupted files:

If I export to plain jsonl files, the files contain only a subset of the partition's data and they start with an empty line.
If I export to jsonl.gz compressed files, the resulting gzipped files are invalid and can't be read.

I've been unable to reproduce this issue on a local machine using the distributed client, but I'm quite sure the issue comes from adlfs because exporting to amazon s3 using s3fs produces clean files.
I've been trying to reproduce the issue on a distributed cluster in a simple and reproducible way that I could share with you, but I couldn't reproduce the problem. I think that it's my specific pipeline's steps that result in a state where adlfs fails to export the data properly.
Each item in the bag looks like this:
{
    "geohash_aggregation_precision": 8,
    "location": {"type": "Polygon",
                 "coordinates": [[[
<PHONE_NUMBER>4414062,
                     35.201568603515625],
                     [
<PHONE_NUMBER>6689453,
                         35.201568603515625],
                     [
<PHONE_NUMBER>6689453,
                         35.20174026489258],
                     [
<PHONE_NUMBER>4414062,
                         35.20174026489258],
                     [
<PHONE_NUMBER>4414062,
                         35.201568603515625]]]},
    "location_centroid": {"lat": 35.2016544342041,
                          "lon":<PHONE_NUMBER>0551758},
    "short_events_count": 1,
    "long_events_count": 0,
    "total_events_count": 0,
    "utc_datetime": "2019-11-01 00:00:00.000000",
    "local_datetime": "2019-11-01 09:00:00.000000",
    "_id": "KR-wy7b6230-2019-11-01 00:00:00.000000"
}

The partitions are not evenly sized, here is an example of their sizes:
[(0, 82302),
 (1, 59934),
 (2, 230304),
 (3, 46914),
 (4, 114548),
 (5, 140497),
 (6, 69740),
 (7, 80690),
 (8, 134518),
 (9, 99581),
(10, 59099),
(11, 106069)]

In this example partitions 2, 5, 8 result in corrupted files.
I export the data using:
    final_bag.map(json.dumps).to_textfiles(
        'abfs://storage/data/data_part_*.jsonl.gz'
        storage_options=STORAGE_OPTIONS,
        last_endline=True
    )

For the moment I work around the problem by using more and smaller partitions, but because getting balanced partitions efficiently is tricky in dask, the situation is not really ideal.
I'm using:

python 3.6.9
dask 2.9.1
dask_kubernetes master
adlfs 0.1.5

Each worker in the dask cluster has:

1 vcpu
7 GiB of ram

Looking at the implementation differences between s3fs and adlfs I suspect this is due to bad handling of data that comes several chunks. I'll try to dig deeper later.

Update on this issue. This was fixed by PR #37, however it was reverted in commit 7bca626bd1d90ce7de60053862d7e2ddbb911ad3 by @hayesgb
Any particular issue with that PR that needs fixing?

I'm not sure. I've moved to my own, historic, storage lib since then. So I can't really test whether the bug is still present or not. I'm okay with closing the issue.

I integrated @AlbertDeFusco’s PR into master, then attempted to integrate #37, which caused a failure of the 2nd last test (fs.rm), so I reverted the change with the intent to follow-up, but haven’t been able to circle back yet.

On Feb 7, 2020, at 10:36 AM, Cloves Almeida<EMAIL_ADDRESS>wrote:
—

I just created a new PR #38 to resolve the issues. Tests should pass now.

Integrated into 0.2.0 release.


Added Timezones functionality

Added the functionality to get random timezone. I have taken timezone data from here : https://github.com/dmfilipenko/timezones.json/blob/master/timezones.json
Thanks!

Changes Unknown when pulling d52b258218efbfff7b13526dce986a9fb30063a3 on amitmerchant1990:master into ** on chancejs:master**.

Awesome addition, thanks @amitmerchant1990

Be sure to update the documentation!

@victorquinn Are you not updating http://chancejs.com/ ?

@amitmerchant1990 I generally do but it looks like this one slipped through the cracks! I'll update it today

Awesome! Thanks @victorquinn! ✨


Missing ability to change default tooltip placement of TableHead "Sort" tooltip

Currently the placement value of the tooltip used on the TableHeadCell component is a hard coded "bottom-start". It seems like it would be easy to make it so it takes a placement specified by the user or default on "bottom-start". Current way of doing it would be to create a custom Tooltip but even that way is not working for me.

Expected Behavior

A quick an easy way to do this (but perhaps wrong since is not technically a text label) is to allow the user to specify the placement inside the textLabels overrides. For example:
const options = {   ...   textLabels: {     body: {       noMatch: "Sorry, no matching records found",       toolTip: {           title:"Sort",           placement:"top-end"}       ...
Otherwise, tooltipPlacement could be its own property under options.
Current Behavior

I think they only way of doing this currently is to create your custom tooltip component, but even that is not working for me at the moment. See below:

Steps to Reproduce (for bugs)

The way I tried to create a custom Tooltip component:

`const CustomTooltip = (props) => {
return (
<MuiTooltip
placement={'top-end'}
title={'Sort'}
>{props.children}
);
};
return (
<React.Fragment>

<MUIDataTable
title={title}
data={data}
columns={columns}
options={baseOptions}
components={{
Tooltip: CustomTooltip
}}
/>

</React.Fragment>`
Your Environment

Tech
Version

Material-UI
4.0

MUI-datatables
2.6.4

React
16.8.6

browser

etc

The custom Tooltip component was introduced recently, try upgrading to mui-datatables version 3.1.4.

Sounds good, I will do that and report back.
I'm wondering, would it still be worth it to allow the user to change the placement of the tooltip without having to make a custom tooltip?

Since it's doable without an option, I'm not sure an option would make sense, since it would be a pretty obscure feature.
The only drawback I could see would be not wanting to change the tooltip position of the toolbar tooltips, but one could always use the text of the tooltip to differentiate.

That makes sense. Thank you!


Enable LARGEADDRESSAWARE for 32 bit compilation

32-bit executables built with MSVC linker have only 2GB virtual memory address space by default, which might not be sufficient for some tests.
Enable LARGEADDRESSAWARE linker flag for 32-bit targets to allow tests to handle addresses larger than 2 gigabytes.
Fixes #1842
https://learn.microsoft.com/en-us/cpp/build/reference/largeaddressaware-handle-large-addresses?view=msvc-170

@bashbaug  please review.

Merging as discussed in the January 9th teleconference.