[RFC] Separate Actor and Provider SDKs

[RFC] Separation of Guest and Provider SDKs
Summary
This Request for Comment is soliciting feedback on the plan for separating the wasmCloud guest and provider SDKs. The suggested changes would create separate libraries for guests (actors) and capability providers and do so in a way that takes into account a component-based future while being an example of when not to create shared dependencies.
Rationale
Today, we have wasmbus_rpc, a library that provides an RPC foundation to allow capability providers to communicate with actors via hosts and perform routine functions like applying link definitions. Additionally, this exact same library also provides a foundation on which code is generated to give guest modules (actors) the ability to communicate bi-directionally with capability providers.
This creates an unfortunate tight coupling where both actors and providers share a common dependency or even a sub-tree of dependencies. The library is chock full of conditional compilation that checks for a wasm target architecture or non-wasm. At first this may not seem like that bad of a pattern because of the convenience of "one crate to rule them all", however, the real workflow-breaking problems occur with transitive dependencies. wasmbus-rpc forces both providers and actors to share a common dependency tree when the vast majority of projects don't need those common libraries.
Problematic Use Cases
The most common problem case is when the provider and actor both depend on different versions of the same shared dependency. This breaks builds in Rust and would also break builds for Go-based actors and providers.
One of the worst examples of how this pattern causes problems is the lattice-controller capability provider, a provider that gives an actor the ability to interact with a lattice's management interface.
In this scenario, the lattice provider uses wasmbus-rpc which, in turn, uses a fixed version of async-nats (the NATS client library for Rust). However, the wasmCloud control interface is also exposed over NATS, and so the capability provider needs to create its own instances of types in async-nats. At best this forces the provider and wasmbus-rpc to be in lock-step on the same version of the shared dependency, and at worst actually prevents features and bug fixes from being used by either of these crates. If Go follows the same shared common library pattern, it too will have conflicting NATS dependencies in the shared dependency tree.
There are myriad other scenarios that arise from having code generated from interface definitions that only works on specific versions of wasmbus-rpc, even though only a small portion of generated code needs access to RPC functionality, and even then, that is only needed by providers. Actor "RPC" with providers and other actors is really just a host call, which is managed entirely by the Wasm interface and not RPC.
Implementation
This section describes how we intend to implement this separation of concerns and the impact to existing actors, providers, and generated code.
wasmcloud-actor (Phase 1)
Today there are two so-called ABIs available to wasmCloud developers: the stable one, that we call the wasmCloud ABI, and the volatile one called Wasm components based on the WebAssembly component model. As the Wasm component standards and ecosystem stabilize, wasmCloud will move away from its own stable ABI toward embracing components by default.
The wasmcloud-actor Rust crate in this phase will provide developers with a consistent library used for building actor components on the stable (legacy) ABI. This will use smithy-generated code for data types that use the low-level guest primitives.
⚠ Developers working with components will be left to their own devices for creating the appropriate wasifills, though we will support these efforts as best we can.
For developer ergonomic benefits, this crate will come "out of the box" with easy to use wrappers around the most common interfaces:

All wasmCloud builtins (number generation, logging, etc)
Key-Value Store
HTTP Server and Client
Messaging
Blob Store

Because the actors are using just the interfaces and not implementations, there's no waste overhead in including these by default. It also gives us the ability to optimize the experience of these for developer ergonomics in cases when the raw generated code is high friction.
❓But isn't this more tight coupling ❓ On the surface it does look like that. For example, we would have to issue a new version of the SDK if we change the messaging API even though the key value one didn't change. This looks like a violation of the single responsibility principle.
ℹ If we absolutely need to patch just one of the core interfaces and releasing a new version of the wasmcloud SDK seems cumbersome (unlikely), then we can always have someone just generate from Smithy via wasmcloud-bindgen directly into their actor, effectively using an alternate core interface.
The flip side to that is if we keep our "core" API (limited to builtins + the most common contracts) at a slightly higher level than the smithy contracts, then we can actually shield developers from volatility at the lower contract level.
Regardless, this tight coupling of the "core" modules will only be done during phase 1, so the question then becomes - is the added benefit of having more ergonomic interfaces on the core worth the short-term coupling we'll incur during phase 1? I think it is, because of the low risk of interface change during this phase.
ℹ Rust will remove unused interfaces from compiled Wasm code during release builds.
wasmcloud-provider (Phase 1)
During phase 1, this crate should largely represent a "copy and paste" effort from the existing wasmbus-rpc crate, just grabbing only the code that applies to capability providers. Note that today we have a core crate of shared data types that both actors and providers rely upon (e.g. the LinkDefinition and Invocation types). This will go away and core types will be generated directly into this crate as needed.
The following is a list of responsibilities of this crate:

Expose basic primitives for defining handlers and clients for contracts (the code "below" the codegen)
Accept host configuration via stdin at provider start
Communicate via NATS to send/receive invocations with actors

Includes signing and verifying invocation JWTs

Subscribe to changes in the appropriate key value store for link definitions

Ensure providers aren't invoked multiple times for the same link (de-dupe)

wasmcloud-bindgen (Phase 1)
Today's wasmCloud developer environment relies on multiple crates within the weld repository. Not only is the name weld confusing to new developers, but recent creations like smithy-bindgen can be leveraged to help make the developer experience for third party interfaces be nearly as smooth as that of our baked-in first party interfaces.
This phase of wasmcloud-bindgen will only support Smithy-based interfaces and will be used to generate common data types, guest ABI wrappers, and provider handler wrappers.
The choice as to which pieces are generated will be up to the developer. Each individual project should use wasmcloud-bindgen inside build.rs with the appropriate parameters (e.g. actor vs provider) and not create a shared crate. (remember the share nothing principle).
Legacy code generation tasks from build.rs may be retired in favor of exclusively using the work now found in smithy-bindgen.
⚠ Code generated with this crate will only work with the wasmcloud-actor or wasmcloud-provider crates, and will not be compatible with the legacy wasmbus-rpc crate. The host should be unable to tell the difference, however.
wasmcloud-actor (Phase 2)
This library will expose ergonomic wrappers around the core first party interfaces, with as few breaking changes from phase 1's API as possible. Underneath those interfaces, the ABI primitives will rely on the actor wit component/world interface for communicating with the host.
It will be easy for developers to use standard wit files, world files, and public Bytecode Alliance/Wasm standard tooling to generate the code necessary to work with wasmCloud.
wasmcloud-provider (Phase 2)
This library supports all of the activities required by the provider crate in phase 1. This library will continue to support all RPC activities between hosts, providers, and actors. If there are pieces of code that need to be upgraded to use wit, then that will be done here. If changes are handled properly by the host(s) and components, this crate should have relatively few breaking changes during the transition to phase 2 since the provider<->host RPC doesn't use any Wasm primitives.
wasmcloud-bindgen (Phase 2)
Unless there are specific convenience things that we still want in this crate, we can remove most (if not all) of the code from it. Instead, wash will be upgraded such that wash build will know how to do all of the component linking and management to build the right kind of components that will be compatible with this phase and the host(s) released during this phase.
During this phase if there are wit-bindgen language bindings that either need work or don't exist, then we will evaluate whether it makes sense for us to create or contribute those.
If this crate remains, it cannot be required to build code for wasmCloud during this phase. It can only make things easier or simpler.
Requirement - using nothing but Bytecode Alliance/standard Wasm tooling, developers must be able to create an actor that can work in a wasmCloud host. Providers will still be Rust-first and will continue to rely on the existing wasmcloud-provider (phase 2) crate.
Timeline and Gate Conditions
The following outlines the planned road from today to the ideal end state for this effort.
Phase 1
All actors and providers using these crates will be compatible with Elixir OTP Host v0.62+ without modification. The ABI expected by the host from actors and the RPC mechanism for providers will not change.
During this phase, early adopters looking to work with components on their own will be responsible for managing their own wasifills and linking using BA tools. wasmCloud will make no support guarantees for components, though we will of course attempt to remain as far up on the leading edge of component development as possible with wasmtime.

wasmcloud-actor (p1) - isolated crate providing ergonomic wrappers and core primitives for actors
wasmcloud-provider (p1) - isolated crate providing ergonomic wrappers and core primitives for providers
wasmcloud-bindgen (p1) - crate that can be used to generate code from Smithy contracts suitable for use by actors or providers that depends on primitives from the preceding 2 crates

Additional changes that will take place during phase 1 include the removal of the use of async code from within an actor for synchronous activities. We will also probably no longer have actors respond to a health request. There are a number of reasons for this, but the short version is that stateless actors have no health: they're either available or not.
Here is an example of what an actor might look like on phase 1 libraries to build our standard key-value counter:
use wasmcloud_actor::{kv, http};

#[handles(HttpServer)]
struct MyDemo;

impl HttpServer for MyDemo {
    fn handle_request(request: &HttpRequest) -> Result<HttpResponse> {
        let trimmed_path: Vec<&str> = req.path.trim_matches('/').split('/').collect();

        let count = match (req.method.as_ref(), trimmed_path.as_slice()) {
            ("GET", ["api", "counter", counter]) => {
                kv::increment(counter, 1)?
            },
            _ => 0
        };

        let output = json!({
            "counter": count
        });
        Ok(HttpResponse::ok(output))
    }
}

Note how the boilerplate and ceremony is gone from the use of kv. If an actor needs to communicate with a different link name, then that can be set by calling a new function:
set_link_name("wasmcloud:keyvalue", "cache");

// do work on `cache` key value store
kv::increment("alice", 5)?;

reset_links(); // reset to "default"

The use of this new function to set link names will prepare developers for when this kind of thing becomes mandatory when using the component model (since wit doesn't know what a link name is).
Here's what it might look like to add in the use of a third-party contract generated from Smithy via wasmcloud-bindgen (p1). In this sample, we'll use the wasmcloud:sensors contract to report the current temperature of the BBQ at request time:
use wasmcloud_actor::http; // stock interface
use sensors::*; // generated module

mod sensors; // bindgen-generated into src/sensors.rs

#[handles(HttpServer)]
struct BbqDemo;

impl HttpServer for BbqDemo {
    fn handle_request(request: &HttpRequest) -> Result<HttpResponse> {

        let value = query_sensor(SensorQuery {
            network_id: Some("home".to_string()),
            sensor_id: "BBQ_ONE".to_string()
        })?.data[0]; // e.g. 375.31 (assuming fahrenheit)

        let output = json!({
            "temperature": value
        });

        Ok(HttpResponse::ok(output))
    }
}

Note that the sensors code is generated directly into this actor, and is not part of a shared library.
Actor-to-Actor Calls
Actors calling actors will still be a very common, fully supported scenario. Our own pet clinic sample uses the API gateway pattern with an actor calling other actors depending on their role.
Today's code uses a rather clunky way of telling the host that the target is an actor rather than a capability provider. While preparing for wit based contracts (e.g. non-wasmCloud-proprietary), we can set the stage using the set_target function:
set_target("petclinic/visits");
visits::record_visit(Visit {
    owner: "kevin".to_string(),
    pet: "sage".to_string(),
    . . .
})?;
clear_target();

This function sets the current actor target for all subsequent host calls. That target will remain the same until either set to something else or cleared via clear_target. Setting targets this way will help pave the way for when we have "off the shelf" wit contract support.
Phase 2
This phase will use the component model ABI and wit. The crates in this phase are not backwards compatible with the Smithy-based legacy wasmCloud ABI.
If developers want to build Smithy-based projects, they will need to continue to use deprecated Phase 1 tooling.
The Elixir OTP host v0.63+ will continue to support the wasmCloud legacy API (deprecated) and the new component ABI by virtue of the Rust wasmcloud crate. As of phase 2, there will be no wasmCloud-proprietary code. The smithy "walled garden" will be gone.

wasmcloud-actor (p2) - isolated crate providing ergonomic wrappers and wit/component-based core primitives for actors
wasmcloud-provider (p2) - isolated crate providing ergonomic wrappers and core primitives for providers
wasmcloud-bindgen (p2) - crate that may largely go away and be replaced by publicly available wit tooling and wash build

The following is an example of what code might look like for Rust guests on phase 2 (which should be indistinguishable from "regular" component code).
wit_bindgen::generate!("httpserver.wit");

use httpserver::*;

struct MyServer;

impl HttpServer for MyServer {
    fn handle_request(request: &HttpRequest) -> Result<HttpResponse, String> {
        Ok(HttpResponse::default())
    }
}

export_host!(MyServer);

Phase 3
Elixir OTP host (and any other host) no longer supports smithy-based contracts and associated code generation. Deprecated entities from phase 2 will no longer be supported. In other words, as of phase 3, the Rust wasmcloud crate will only support components and will no longer recognize the legacy wasmCloud ABI. It is for this reason that there could conceivably be a pretty long gap between Phase 2 and Phase 3 while we await component stabilization in W3C specs and Bytecode Alliance tooling.
Other Languages, C, and FFI
We were originally thinking of exposing the various SDKs as a C-compliant FFI layer so that other languages could take advantage of the shared code. However, since the ultimate goal is to "simply" use components and wit, the effort that would otherwise be placed here will likely be spent making sure that the wit-bindgen experience is smooth and supports all of the component-capable Wasm-targeting languages.
Creating a common C FFI layer that allows Go libraries to utilize the non-Wasm RPC functionality from Rust is out of scope for this RFC, though that work may be done during Phase 2 or 3.

Specifically, I am thinking of adding a wasmcloud-actor and wasmcloud-provider and wasmcloud-bindgen set of folders to the wasmcloud/wasmcloud repository.

I may have missed this, so I apologize if this is covered in a phase already, or if it is not on topic. Something I have been wondering is how the move to component model in providers will affect deploying a provider in wasmcloud host with wash. Will one be able to deploy a wasm/wasi targetted provider instead of par.gz? Does that happen in phase 2 if so?
I imagine that with wasm/wasi provider, one can just deploy as an actor? But I really like the language of capability provider when it comes to traceability of what is happening in a system.
I think my simplified question is: "Will moving wit-bindgen tooling need to align with wasmcloud provider deployment changes?"

I think my simplified question is: "Will moving wit-bindgen tooling need to align with wasmcloud provider deployment changes?"

The changes outlined in this RFC aren't directly related to wasmCloud provider changes. When actors first get the ability to be defined as components, the host will still communicate with providers the "old fashioned" way. This gives us total control over how and when we have providers be "component" ready. Providers won't really need to be able to communicate directly via components until they are able to be built as WASI components. While they're communicating with hosts via NATS, they still need to serialize data on the wire, which is something wit doesn't dictate.

Understood, thanks Kevin!

@autodidaddict Big fan of what's proposed here. Thanks for the information bullets around the standard contracts, I think it's going to be something that changes rarely enough that it shouldn't be a big issue. I do worry here around what happens to the Go interfaces that we currently support, and if we'd take on similar efforts (or if the actor-tinygo repository just continues to live on, since it's using the same ABI with the host.)
I know Wasm is single threaded and all the async things are faked atm, but I do notice the examples remove the async functions. I think that'll be awesome for 99% of use cases, but what if I use a crate that only uses async APIs? What do I have to do in the actor?

Well, I am very excited to learn about block_on. I also wonder how easy it will be to incorporate wasi_threads if async is faked at the moment. Was it designed in a way to make the cutover to leverage a threads component easy?  From a user perspective would that be along the lines of removing block_on?

wasi_threads doesn't work within the component-model unfortunately. Async is faked with callbacks so it's still async.

Darn, glad I asked haha. I thought a thread as a component may be along the lines of granting access to specific OS thread(s) through a component import. My bad. I think I conflated async and threads because a lot of async crates use Tokio as scheduler. I am not sure how block_on plays in that scenario now. But I will definitely try.

You're right on for the idea. The version of wasi-threads that's out there does basically this for Wasm modules. Where it breaks down is how to this cooperates with multiple components within one Wasm Component. The current plan is to push towards a structured concurrency implementation within core Wasm rather than only a WASI interface so that each Wasm Component can cooperate in a concurrent model.
Somewhat separate but Luke Wagner's design ideas for async in WASI Preview 3: https://docs.google.com/presentation/d/1MNVOZ8hdofO3tI0szg_i-Yoy0N2QPU2C--LzVuoGSlE/edit?usp=sharing

@autodidaddict, if these changes are going to affect wasmbus-rpc, will there be any concerns related to event emission or handling?

Thankfully wasmbus rpc isn't responsible for event publication, that happens at the top level of the host.

Sweet, thanks Kevin. I wasn't sure if actors and providers currently had some mechanism to publish events to wasmbus rpc, or if there were any messaging scenarios where that was done.

Now that both wasmcloud-actor and wasmcloud-provider-sdk exist, can this be closed?

I believe so! Do you concur @autodidaddict?

Consider me concurrent.

I shouldn't have been concurrent on this. There's a few core requirements around link names and actor-to-actor functionality that is missing from the implementation.


An inference step number which evenly divides the training step number causes out of bounds indexing

DDIMScheduler's first time step is effectively inference_steps * train_timesteps / inference_steps, which if there is no truncation, puts it exactly at train_timesteps, just out of bounds.
thread '<unnamed>' panicked at 'index out of bounds: the len is 1000 but the index is 1000'
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\panicking.rs:584
   1: core::panicking::panic_fmt
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\core\src\panicking.rs:142
   2: core::panicking::panic_bounds_check
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\core\src\panicking.rs:84
   3: core::slice::index::impl$2::index<f64>
             at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\slice\index.rs:250
   4: core::slice::index::impl$0::index
             at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\slice\index.rs:18
   5: alloc::vec::impl$16::index<f64,usize,alloc::alloc::Global>
             at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\alloc\src\vec\mod.rs:2628
   6: diffusers::schedulers::ddim::DDIMScheduler::step
             at diffusers-0.1.2\src\schedulers\ddim.rs:74

I guess we can either do some rounding to help with this or at least check that the numbers are divisible and if not make a nicer error message so that the underlying issue is easier to diagnose.

I just pushed a very simple fix for this, feel free to re-open if you run into further issues.


NetX Dimension Seems Lost

Hello,
I have trained  the 3 fully connected layer network using NMNIST dataset ( using the tutotorial notebook )
When I try to convert this model to the process network I have got the dimension different.
The network blocks in Slayer was;
self.blocks = torch.nn.ModuleList([
slayer.block.cuba.Dense(neuron_params_drop, 34342, 512, weight_norm=True, delay=True),
slayer.block.cuba.Dense(neuron_params_drop, 512, 512, weight_norm=True, delay=True),
slayer.block.cuba.Dense(neuron_params, 512, 10, weight_norm=True),
])
However when I convert it using NetX it becomes:
There are 3 layers in network:
Dense : Process_1 , shape : (512,)
Dense : Process_4 , shape : (512,)
Dense : Process_7 , shape : (10,)
There might be something wrong with what I am doing but I could not figure it out.
Simply  I have used
net = netx.hdf5.Network(net_config='Trained/network.net')
print(net)
Just like what has been done in the NetX tutorials.
All the best,
Ahmet Akman

Objective of issue:

Lava DL version:

[ ] 0.3.0 (feature release)
[ ] 0.2.1 (bug fixes)
[x] 0.2.0 (current version)
[ ] 0.1.2

Lava version:

[ ] 0.4.0 (feature release)
[ ] 0.3.1 (bug fixes)
[x] 0.3.0 (current version)
[ ] 0.2.0
[ ] 0.1.2

I'm submitting a ...

[ ] bug report
[ ] feature request
[ ] documentation request
[x] I really do not know right now it might be a bug , might be a documentation request.

@ahmetakman your network, as you defined in self.blocks, has two hidden layers and one output layer of dimensions 512, 512, and 10 respectively. So it does make sense to get the dimension of the network as 512, 512, and 10 when you load the network, isn't it?

I though the dimension should be
Dense : Process_1 , shape : (34342,512)
Dense : Process_4 , shape : (512,512)
Dense : Process_7 , shape : (512,10)
As were in the NetX examples.

Look at the dense block definition in PilotNet SDNN training

and the shapes in PilotNet SDNN inference with NetX

I have mistaken the error about the dimensions I got when was connecting the processes. I will try again soon ,and write back. Thanks for the reply.

Let me come back to here,
First of all, I am not sure my environment is fully utilized but at some point I have a system with barely passing unit tests with hanging code block issue #55 .
Here my interpretation about NetX dimensions is still because of the current error I am getting. Let me summarize my goal then give the error.
I would like to run trained NMNIST model with lava core by using NetX network exchange. The result of the conversion is given above.
When I try to connect processes with the code block:
gt_logger = io.sink.RingBuffer(shape=(1,), buffer=num_steps) output_logger = io.sink.RingBuffer(shape=net.out_layer.shape, buffer=num_steps) dataloader.ground_truth.connect(gt_logger.a_in) dataloader.s_out.connect(net.in_layer.neuron.a_in) ***** issue line ******** net.out_layer.out.connect(output_logger.a_in)
I get the error
AssertionError: Shapes torch.Size([2312]) and (512,) are incompatible.]()
First, my interpretation was the dimension was lost since it is 512 not 2312

Aren't you supposed to connect the dataloader.s_out to net.in_layer.synapse.s_in ? It seems you are bypassing the syanpse of the first layer!
dataloader.s_out.connect(net.in_layer.syanpse.s_in)

Yeah that was it, now I have connected processes the run config is running right now.
Thank you very much for the explanation. I sincerely thank for your patience.
I am actively learning the lava-ecosystem, SNNs ,and the new computers I am running them on.
Until I completely got the structure, I think it is natural to misunderstand some concepts.
I am closing the issue,
All the best,
Ahmet.

No problem @ahmetakman, happy to clarify any confusion.


Adding content for the new Notifications plugin

Adds the Notifications plugin
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.
Site URLs:
../ism/policies.md
https://opensearch.org/docs/latest/im-plugin/ism/policies/
_monitoring-plugins/alerting/monitors.md
https://opensearch.org/docs/latest/monitoring-plugins/alerting/monitors/
(new pages/not yet on site):
_notifications-plugin/api.md
_notifications-plugin/index.md

@keithhc2  - I'd be happy to sign off on this, but I don't see the option. Do you have to add me?

If you go to the Files changed tab, you should see a green Review changes button. Click that, and you can comment/approve/request changes/etc.


[Map] MH-Edge-Of-Reason

It should be noted that the author of the map is FNB - FragNBrag.  The stated author has simply put in some ScriptedPawns.
It's a large CTF map - can't remember the name - it still contains the SmartAlternativePath and DefencePoint actors of a CTF map!!
I just feel FNB deserves some credit in this - making the map is difficult - sticking the SPs in is the easy bit, made even simpler by Buggie's MHGen tool!

URL: https://unrealarchive.org/maps/unreal-tournament/monster-hunt/E/mh-edge-of-reason_11d62e07.html
Hash: 11d62e078b6c030a976f785b7a0ba67abe5a96a5
Current name: MH-Edge-Of-Reason

The map is CTF-AMC-BigandUgly - made/finished for UT99.org's Awesome Mapping Contest.
In passing the mapper with 20 years experience has given the Krall and Merc Elites UnrealShare.Plasma projectiles - these do no damage.  Presumably this was not intentional?


Fixes #28385

Adds clarification code on how  init prevents assignment after constructor. Added clarification on the usefulness of init. Changed the property of the example (seconds) to a one that more likely would benefit from init (YearOfBirth in a Person class, for example). Lowered verbosity on the expression-bodied examples, as they really didn't add anything useful in the specific context of the init article.
Fixes #28385

edit by @billwagner  Add Fixes tag in the description for automation and linking.

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

Indeed your version is more eloquent and precise @BillWagner. Glad I could be of help!


Remove ActiveAdmin

Describe your change in plain English.
Removes ActiveAdmin from the project.
Link to the issue
Fixes #13

Thank you @kasugaijin! I missed that, it's fixed now

Tests are failing but looks like they are unrelated to my changes (broken on main)

Yup @marlena-b it was just fixed in main, I feel pretty good about merging this in


feat(DevTools): Binding Info tooltip

What does the pull request do?

What is the current behavior?

What is the updated/expected behavior with this PR?

How was the solution implemented (if it's not obvious)?

Checklist

[ ] Added unit tests (if possible)?
[ ] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

Obsoletions / Deprecations

Fixed issues

Partial address:
#15633
#6571

@workgroupengineering hi! I am currently working on a major devtools refactoring, which I want to complete this year (with something to show publicly earlier). Big new features might be problematic to backport one by one. It would be ideal to pause devtools contributions for this specific project.
But I agree that binding information is a useful feature that should be included as well. Thanks.

Thanks for your work, but I'm going to close this for now.
As mentioned in https://github.com/AvaloniaUI/Avalonia/pull/16679#issuecomment-2287059126, DevTools are currently under a major internal refactoring and we won't accept impactful PRs in this area for the time being.


archiv extractor

Current Behavior
Hello, unfortunately i cannot erase the extractet archiv. the archiv yourself can i erease, pass the permissions is correct over the compose file.
Expected Behavior
No response
Steps To Reproduce
erease the folder with extractet files under defined/expected permission
Environment

OS:
OS version:
CPU:
Docker version:
Device model:
Browser/OS:

Container creation
over compose file
Container log
not log/error in myjdownloader

Container inspect
No response
Anything else?
No response

Are you talking about the delete functionality of JDownloader (right-click -> Delete)?  This action only deletes the downloaded files, not the extracted ones.

Closing this issue. Please re-open is needed.


Remove ASM based CFG generation by codesourcery and ASM

This PR builds on top of #26, for easy review of this PR click here.

This PR removes ASM based CFG generation and removes ASM as a dependency.

Codecov Report

Merging #27 into master will increase coverage by 33.28%.
The diff coverage is 70.45%.

@@             Coverage Diff              @@
##             master     #27       +/-   ##
============================================
+ Coverage     41.41%   74.7%   +33.28%
+ Complexity      187      77      -110
============================================
  Files            20      10       -10
  Lines           903     170      -733
  Branches        194      55      -139
============================================
- Hits            374     127      -247
+ Misses          461      23      -438
+ Partials         68      20       -48

Impacted Files
Coverage Δ
Complexity Δ

...afejojo/schaapi/patterndetector/PatternDetector.kt
93.33% <ø> (ø)
20 <0> (ø)
:arrow_down:

...jo/schaapi/usagegraphgenerator/DotGraphRenderer.kt
100% <100%> (+9.52%)
6 <5> (-3)
:arrow_down:

...g/cafejojo/schaapi/usagegraphgenerator/SootNode.kt
50% <50%> (ø)
1 <1> (?)

...jo/schaapi/usagegraphgenerator/ControlFlowGraph.kt
57.14% <57.14%> (ø)
4 <4> (?)

...schaapi/usagegraphgenerator/filters/ValueFilter.kt
60.97% <60.97%> (ø)
30 <30> (?)

...api/usagegraphgenerator/filters/StatementFilter.kt
81.81% <81.81%> (ø)
8 <8> (?)

...schaapi/usagegraphgenerator/UsageGraphGenerator.kt
85.71% <92.3%> (+85.71%)
0 <0> (ø)
:arrow_down:

... and 1 more

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 e584101...ed77084. Read the comment docs.

DO NOT MERGE before #26

@casperboone I've added a nice label :)


Prefer hasOwn

We can use hasOwn here as it's safer and is intended as the modern replacement to hasOwnProperty

Not related to performance this one


No matrix transpose function

We do not have a function for transposing hmm_mat4s. Adding one seems like the responsible thing to do! Probably call it HMM_Transpose(hmm_mat4 Matrix).

What does a matrix Transpose function do?

Transposing a matrix swaps its rows and columns

Heh if you know how to write one off the top of your head it'd be awesome if you could do it. If not then i will figure it out


Update README.md

In the README.md file, there is a correction for the 'GitHub Stats Contributor Badge.'

@ghulamyazdani

Thanks for pointing this out @arsheelsheikh


Suggestion to use tailwind and new build tools

Hi @halkeye , how are you mate? I have created https://www.npmjs.com/package/sirocco-wc which is a Scaffolding Tool for the fusion of lit with tailwind. which may allow you to mock away your infrastructure and use tailwind for css. I currently use it for cloudbees plugin.

Thanks for the clarification. I am using tailwind as clue CSS for placing, etc. It is not like bootstrap where you are supposed to use the whole css but rather you only get what you really need.


:bug: Agents stop update managedcluster status when clock is out of sync.

Summary
This patch aim to stop agents from updating managed cluster status when clock is already out of sync.
The issue occurs when the hub sets the managed cluster status to unknown due to an outdated lease, while the agent simultaneously sets the managed cluster status to available because the API server is accessible. This conflict causes the managed cluster status to flap back and forth frequently, triggering numerous reconciliations and resulting in performance issues.

what are the consequences of not been able to update the ManagedCluster status? Do we lost any kind of feature? It would happen that we would need to have different clocks. Like a managedcluster, testing different functionalities related with time, ptp, ntp, and therefore, it would be "playing" with the clock.

The OCM is not designed to work when clock is not sync, if clocks are not synced, the first priority is to fix it.

/assign @qiujian16

/assign  @elgnay

We need also document this change in the website.

/approve

We need also document this change in the website.

Agree, will add tasks for it.

@qiujian16  A task of updating doc is added: https://github.com/open-cluster-management-io/open-cluster-management-io.github.io/issues/443

/lgtm


How to output long description

Thanks for sharing your work.
Following the inference guide in README, I'm trying to inference for scene description task.
It seems working correct, but the output result is quite short.
I changed max_context_len, max_out_len in vicuna7b.yaml, from 256 to 2048, but it still outputs very short as shown below.
Could you tell me how to extend the output length?
Loading checkpoint shards: 100%|
[2024-07-24 17:15:12,236][model.leo_agent][INFO] - Build Vicuna7B from ~/embodied-generalist/LEO_data/model_weights/weights_LLM/vicuna-7b
[2024-07-24 17:15:12,238][model.leo_agent][INFO] - Freeze LLM
[2024-07-24 17:15:12,894][timm.models._builder][INFO] - Loading pretrained weights from Hugging Face hub (('laion/CLIP-convnext_base_w-laion2B-s13B-b82K', 'open_clip_pytorch_model.bin'))
[2024-07-24 17:15:13,543][model.vision2d][INFO] - Build Backbone2D: convnext_base_laion2b, pretrain = True, freeze = True, pooling = avg
[2024-07-24 17:15:13,568][model.pcd_backbone][INFO] - Build PointcloudBackbone: PointNetPP
[2024-07-24 17:15:13,571][model.pcd_backbone][INFO] - Load PointNetPP weights from ~/embodied-generalist/LEO_data/model_weights/weights_3D_encoder/pointnetpp_vil3dref.pth
[2024-07-24 17:15:13,572][model.pcd_backbone][INFO] - Freeze PointNetPP
[2024-07-24 17:15:13,581][model.vision3d][INFO] - Build 3D module: OSE3D
[2024-07-24 17:15:13,598][model.leo_agent][INFO] - Apply LoRA with configs: {'flag': True, 'rank': 16, 'alpha': 16, 'target_modules': ['q_proj', 'k_proj', 'v_proj', 'o_proj', 'gate_proj', 'up_proj', 'down_proj'], 'dropout': 0.0}
[2024-07-24 17:15:59,711][inference][INFO] - Probe: load model from ~/embodied-generalist/LEO_data/model_weights/weights_leo
[2024-07-24 17:15:59,832][trainer.leo_trainer][INFO] - Successfully loaded from ~/embodied-generalist/LEO_data/model_weights/weights_leo, load_model_only = True
  0%|                                                                                | 0/1 [00:00<?, ?it/s]2024-07-24 17:16:03.869742: I tensorflow/core/platform/cpu_feature_guard.cc:193] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  SSE4.1 SSE4.2 AVX AVX2 AVX512F AVX512_VNNI AVX512_BF16 AVX_VNNI AMX_TILE AMX_INT8 AMX_BF16 FMA
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-07-24 17:16:03.931943: I tensorflow/core/util/port.cc:104] oneDNN custom operations are on. You may see slightly different numerical results due to floating-point round-off errors from different computation orders. To turn them off, set the environment variable `TF_ENABLE_ONEDNN_OPTS=0`.
[2024-07-24 17:16:04,754][inference][INFO] - {'source': 'scannet', 'scene_id': 'scene0601_00', 'situation': '', 'instruction': 'Describe this scene.', 'response': 'In this room, there is a red leather sofa. It is to the right of a brown wooden table. There are two picture hanging on the wall, one to the left and one to the right of each other. The ceiling is flat and white.'}
100%|
[2024-07-24 17:16:04,765] - Launched

The longest output during training is scene captioning and task planning. So the reason why the model cannot output a longer description is due to its inherent skill. And extending the max_out_len would not work because the output has not been truncated.

The above result is from scene captioning. Do you mean the result is the longest output that LEO can make?
The annotation for scene captioning in train DB is not that short.
Is it because LEO has trained with the limited output size on scene captioning task?
How can I make the longer output as depicted in the paper below?

If you want an expert in scene captioning (e.g., can produce longer responses), probably you should try the checkpoint without SFT (align.pth). The key is that SFT tasks are not so relevant to scene captioning and thus may degrade the capability of scene captioning.

I tried scene captionin task with align.pth, but the result is worse than sft_noact.pth.
It even results out same outputs for different test scene as below.
I ran the same scripts/inference.sh with same yaml configs for the different tasks. Should I change some config or script in the code?
[2024-07-26 16:31:51,344][inference][INFO] - {'source': 'scannet', 'scene_id': 'scene0603_00', 'situation': '', 'instruction': 'Describe this scene.', 'response': 'find the chair that is far away from the tv.'}
[2024-07-26 16:27:16,364][inference][INFO] - {'source': 'scannet', 'scene_id': 'scene0703_00', 'situation': '', 'instruction': 'Describe this scene.', 'response': 'find the chair that is farthest from the cabinet.'}

The reply for 'hello' is also different from what I expected. Is this the model's capability or am I doing incorrect?
[2024-07-26 16:58:43,537][inference][INFO] - {'source': 'scannet', 'scene_id': 'scene0702_00', 'situation': '', 'instruction': 'hello', 'response': 'select the trash can that is farthest from the toilet paper.'}

@huangjy-pku
Can I improve the accuracy of LEO for only scene description task by fine-tuning? For instance, from the pretrained checkpoint align.pth, I'd try fine-tuning on scene description task using only the dataset 3rscan_scenecap_train.json.
or Would you suggest some other approaches for it?

I think other tasks may distract the learning of scene captioning skill. I believe finetuning solely on scene captioning task could mitigate this problem.

Thanks for replying.
I'm currently trying to reproduce the entire process in the paper, by training the model from the beginning scratch.
I have only a single GPU(48G), so I modified train_align_lora.sh as
python launch.py --mode python \
                 --name leo_align \
                 --qos lv0b \
                 --mem_per_gpu 100 \
                 --time 48 \
                 --config configs/default.yaml \
                 --port 2020 \
                 --gpu_per_node 4 \
                 --num_nodes 1 \
                 --partition HGX \
                 task=align \
                 note=align_lora \

also in configs/default.yaml , I changed batchsize to 3 (default) because of the out of momory size.
In your paper, you're using 4 GPUs with 4 batchsize for 80GB memory size.
Can you tell me how long it takes to train with the configurations? Also, why did you choose batchsize=4 for your config? I think you could have set more batch size.

For the first stage, it takes 2~3 days with 4 × A100. The second stage uses more GPU memory due to the long context length and response length of dialogue and planning. So, we select batchsize=4 from the exponential list [1,2,4,8,...], and keep this consistent across the two stages.


The external link redirects to port 5001 (302)

$ curl -vk https://bake.kennethreitz.org/
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to bake.kennethreitz.org (<IP_ADDRESS>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=home.kennethreitz.org
*  start date: Aug 13 05:54:00 2017 GMT
*  expire date: Nov 11 05:54:00 2017 GMT
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify result: certificate has expired (10), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fcd6c006400)
> GET / HTTP/2
> Host: bake.kennethreitz.org
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 302
< server: kreitz
< date: Mon, 16 Sep 2019 13:57:03 GMT
< content-type: text/html
< content-length: 138
< location: https://bake.kennethreitz.org:5001/

Also, the cert used is expired.

oops, fixed


adding text to disable SP for implicit flow

@madansr7 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@madansr7 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@psignoret , @msmimart can we please get this merged?

#sign-off

@jborsecnik : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Fix filter pushdown on unnest column: need to filter twice.

Fixes this issue: https://github.com/apache/druid/pull/13892#discussion_r1131557916

Closing in favor of #13922, which also fixes the same bug.


[stable/etcd-operator] Fix Tolerations to be a list

What this PR does / why we need it:
Fix regression introduced in https://github.com/helm/charts/pull/16085
Tolerations  (https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)
should be a [], not {}.
Error log from etcd-operator:
E0911 13:06:03.699355       1 reflector.go:134] github.com/coreos/etcd-operator/pkg/controller/informer.go:78: Failed to list *v1beta2.EtcdCluster: v1beta2.EtcdClusterList.Items: []v1beta2.EtcdCluster: v1beta2.EtcdCluster.Spec: v1beta2.ClusterSpec.Pod: v1beta2.PodPolicy.Tolerations: []v1.Toleration: decode slice: expect [ or n, but found {, error found in #10 byte of ...|rations":{}},"size":|..., bigger context ...|ry":"128Mi"}},"securityContext":{},"tolerations":{}},"size":3,"version":"3.2.25"}}],"kind":"EtcdClus|...

cc @lachie83 @alejandroesc

As an experienced consumer of etcd and etcd-operator charts, this change is necessary and works on my end.

@mattymo i approved this already. I need a chart maintainer to chime in.

@alejandroEsc Considering the fix is straightforward, can you try to /lgtm this change?
If not, how do we escalate this further to get it merged?

/gtm

/lgtm

/approve

/ok-to-test

@alejandroEsc Cool, thanks!


⚠ Bofrost.es has degraded performance

In ee2dcd1, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1563 ms

Resolved: Bofrost.es performance has improved in 543bf1a after 7 minutes.


Update compilerplugin, scalapb-runtime, ... to 0.11.9

Updates

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

from 0.11.4 to 0.11.9.
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, early-semver-minor, semver-spec-patch, commit-count:1

Superseded by #860.


'width' key must be a positive number

after recent update of my neovim, fidget seems to be having issues

here is my neovim version
NVIM v0.7.0-dev+nightly-397-gdeb33a977
Build type: Release
LuaJIT 2.1.0-beta3

here is a possible fix
diff --git a/lua/fidget.lua b/lua/fidget.lua
index ce73d80..70e47c0 100644
--- a/lua/fidget.lua
+++ b/lua/fidget.lua
@@ -168,6 +168,12 @@ end
 function base_fidget:show(offset)
   local height = #self.lines
   local width = self.max_line_len
+  if width < 1 then
+    width = 1
+  end
+  if height < 1 then
+    height = 1
+  end
   local row, col = get_window_position(offset)
   local anchor = (options.align.bottom and "S" or "N")
     .. (options.align.right and "E" or "W")

Thanks for reporting! I'll fix this shortly.
I'm curious to know which language server you are getting your issue from?
On Wed, Feb 16, 2022, 5:04 AM Abouzar Parvan @.***>
wrote:

after recent update of my neovim, fidget seems to be having issues
[image: Screen Shot 2022-02-16 at 1 25 57 PM]
https://user-images.githubusercontent.com/10992695/154241250-79e858f0-494b-4236-86cd-c5a90010ac18.png
here is my neovim version
NVIM v0.7.0-dev+nightly-397-gdeb33a977
Build type: Release
LuaJIT 2.1.0-beta3
here is a possible fix
diff --git a/lua/fidget.lua b/lua/fidget.lua
index ce73d80..70e47c0 100644--- a/lua/fidget.lua+++ b/lua/fidget.lua@@ -168,6 +168,12 @@ end
function base_fidget:show(offset)
local height = #self.lines
local width = self.max_line_len+  if width < 1 then+    width = 1+  end+  if height < 1 then+    height = 1+  end
local row, col = get_window_position(offset)
local anchor = (options.align.bottom and "S" or "N")
.. (options.align.right and "E" or "W")
—
Reply to this email directly, view it on GitHub
https://github.com/j-hui/fidget.nvim/issues/46, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC2A5DD2PX6GH3WWJUP2A6LU3NZBBANCNFSM5ORDQC7A
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Thanks for reporting! I'll fix this shortly.
I'm curious to know which language server you are getting your issue from?
On Wed, Feb 16, 2022, 5:04 AM Abouzar Parvan @.***>
wrote:

after recent update of my neovim, fidget seems to be having issues
[image: Screen Shot 2022-02-16 at 1 25 57 PM]
https://user-images.githubusercontent.com/10992695/154241250-79e858f0-494b-4236-86cd-c5a90010ac18.png
here is my neovim version
NVIM v0.7.0-dev+nightly-397-gdeb33a977
Build type: Release
LuaJIT 2.1.0-beta3
here is a possible fix
diff --git a/lua/fidget.lua b/lua/fidget.lua
index ce73d80..70e47c0 100644--- a/lua/fidget.lua+++ b/lua/fidget.lua@@ -168,6 +168,12 @@ end
function base_fidget:show(offset)
local height = #self.lines
local width = self.max_line_len+  if width < 1 then+    width = 1+  end+  if height < 1 then+    height = 1+  end
local row, col = get_window_position(offset)
local anchor = (options.align.bottom and "S" or "N")
.. (options.align.right and "E" or "W")
—
Reply to this email directly, view it on GitHub
https://github.com/j-hui/fidget.nvim/issues/46, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC2A5DD2PX6GH3WWJUP2A6LU3NZBBANCNFSM5ORDQC7A
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Sumneko_lua

I'm able to reproduce with both Sumneko_lua and tsserver. For me, it happens when I have an outdated node_modules for some reason.

^ Same as @mrjones2014 I was getting the same errors for tsserver, null_ls, and others.

I've not been able to reproduce myself, but it definitely makes sense to handle this edge case. My suggested fix does not attempt to create a 1x1 window; instead, it just closes the fidget.
Can folks here give #49 a try and let me know if it fixes the issue?

I've not been able to reproduce myself, but it definitely makes sense to handle this edge case. My suggested fix does not attempt to create a 1x1 window; instead, it just closes the fidget.
Can folks here give #49 a try and let me know if it fixes the issue?

thank you, it seems to be fixed for me


FaceFilter is freezing on Xiaomi Mi 9 Lite

First of all, thank you @xavierjs for this wonderful library! It was the best face detection library that my team found after some long research. Although we are having a great experience with it, we found a strange behavior while testing it with a Xiaomi Mi 9 Lite. We tried 3 different demos (Babylon.js boilerplate, Statue Of Liberty and CSS3D boilerplate), and all of them reproduced this bug below:

Expected behavior: FaceFilter should not freeze because of any user movement.

How to reproduce: We found the behavior above while randomly moving the user's head and device. The video below shows these movements and how FaceFilter freezes (0:23):
https://drive.google.com/file/d/1UQBPTv0PD_Rqd4DQlri7KuqS51D0w6j3/view

Additional bug info: After FaceFilter freezes, refreshing the webpage does not solve the problem. The only solution that we found was to suspend the browser, go to another app, and return to the browser. The page automatically refreshes and FaceFilter starts working properly again.

Device info:

Browser: Google Chrome 81.0.4044.138
Operating System: Android 10 QKQ1.190828.002 with MIUI Global 11.0.2
Device Model: Mi 9Lite
GPU: Adreno 616

Hi Lucas,
What is the output of the JS console?
It looks a hardware/browser problem, and unfortunately I don't have a Xioami phone to test it...
You can try to set a slight animation delay between rendering loops by running:
JEEFACEFILTERAPI.set_animateDelay(2);

(Run it only once, after FaceFilter init, it will set a 2 ms delay between each rendering loop).
It will introduce an additional latency but may help the browser / GPU to not be too overwhelmed.

Hi Lucas,
What is the output of the JS console?
It looks a hardware/browser problem, and unfortunately I don't have a Xioami phone to test it...
You can try to set a slight animation delay between rendering loops by running:
JEEFACEFILTERAPI.set_animateDelay(2);

(Run it only once, after FaceFilter init, it will set a 2 ms delay between each rendering loop).
It will introduce an additional latency but may help the browser / GPU to not be too overwhelmed.

@xavierjs Sorry, I forgot to say that there wasn't any error logs. The only logs that we got while testing it were face detected and face lost. We will test the delay and see if we have any results.

Arggg it looks a nasty browser / GPU driver / OS bug :(

Hi,
What's about the animateDelay? Does it help?

Hello Xavier,
We tested it with 2 ms but the error still persisted. Then we increased it to 25, 50 and 100 ms and got the same results. In all tests we tried different gestures and movements with the camera (even standing still), but we couldn't find a way to easily reproduce the error, so we got different times for each test. Do you recommend any other solutions?

Hi Lucas,
Did you tested on several Xiaomi Mi 9 Lite or it is always the same device?

Unfortunately we only have one Mi 9. We tried to reproduce the problem on other devices (including other Xiaomi devices), but we couldn't.

Maybe this one has a GPU a bit fucked.


Processing Data

Hi,
I was wondering how other users processs the data generated with tweetf0rm. Since I need the data in some kind of spreadsheet format, I was going to use open refine to import he JSON file containing the tweets I crawled. The issue here is that I can only import one of the nodes from every tweet, and not all of them. e.g. the tweet might look like this:

{
text: (...)
retweeted status: {...}
retweeted : {...}
(...)
}
open refine is only able to extract one of these nodes at a time, (e.g. ‘retweeted status: { (...) }' but not 'text: (...)'.

Another method I tried is to use a script for google spreadsheets called "=importJSON()", but without success.
I further noticed that both methods work fine with a JSON file i pulled "directly from the twitter API, but I have not been able to find out what exactly the the difference was between the two JSON files. If you care to have a look at this other file, you can find it here: https://www.dropbox.com/s/detv4ttvlsgbtz0/cop21.11.1301_07.txt?dl=0
Anyway, I was wondering If any other users have experience with convertinf the tweetform data into spreadsheet format, and what your workflow is.
best, Mark
Information on using open refine with twitter data can be found here: http://blog.ouseful.info/2012/10/02/grabbing-twitter-search-results-into-google-refine-and-exporting-conversations-into-gephi/
Information on the google spreadsheets extension can be found here: https://medium.com/@paulgambill/how-to-import-json-data-into-google-spreadsheets-in-less-than-5-minutes-a3fede1a014a

The result from tweetf0rm is just the aggregated raw json data from the  Twitter API.
Each line is a valid json, however, the entire file won't be.
People normally write their own scripts (in whatever language they do) to process the raw data in tweetf0rm then transform to whatever format they need.
I do the same, I have a general process ingesting the aggregated raw data, pick out the fields I need, process it (e.g., clean text, geocoding, etc.), and spill it out into csv (or keep it in json).
In Python, it's fairly easy:

    fieldnames = ['id', 'created_at', 'text', 'location', 'city', 'state', 'uid', 'friends_count',  'followers_count', 'user_created_at', 'statuses_count']

    with open(raw_json_file, 'r') as f, open(output_file, 'a', newline='') as out:

        writer = csv.DictWriter(
                        out, fieldnames=fieldnames, delimiter=',', quoting=csv.QUOTE_ALL)
        writer.writeheader()

        for line in f:
            tweet = json.loads(line)
            user = tweet['user']
            output = {
                'text': tweet['text'],
                'city': xxx,
                'state': xxx,
                'id': tweet['id'],
                'location': user['location'],
                'created_at': tweet['created_at'],
                'uid': user['id'],
                'friends_count': user['friends_count'],
                'followers_count': user['followers_count'],
                'user_created_at': user['created_at'],
                'statuses_count': user['statuses_count']
            }

            writer.writerow(output)

cool, thanks! I had to adapt it a little because with my python version the csv package does not handle utf-8, but now it works fine.
cheers


Adds Code Coverage

This patch adds code coverage via CodeCov.io.

Current coverage is 44.63% (diff: 100%)

No coverage report found for master at 53fd611.

Powered by Codecov. Last update 53fd611...466b3e4


Enhance MONAI Bundle tutorial

Here I wish to provide some suggestions about MONAI Bundle tutorial: see here

In the section of Execute training with bundle script - run, the cells cannot be run in the notebook directly, thus should we change them into markdown cells?
As for the override function, it is a very helpful feature, but we may need to add this part in the doc: https://docs.monai.io/en/latest/bundle_intro.html (it seems missing). In addition, the sign \ confuses me since it is not existing in the doc-strings of def run in the source code.

Thanks for your feedback, I will try to enhance them ASAP.


Check if analysis already exists

Is it possible to implement if, when adding a sample, there is a check if that sample was already analyzed, like at malwr.com with the possibility to run it again or the view previous analyses ?
Thanks

Thanks for this feature request, we will take care of it.


Sorting for family view

Allow table to be sorted by the header columns on the family index page.

What sorts do you think would be helpful?

I would imagine all of them. Just do it in JS is my vote.

We could probably use DataTables and make our lives super easy. We could also then get rid of the mongo search on the server side and just return the giant list of families for the year.

This sounds a like a great idea if the result of it is still pretty. You wanna do it @jzarob?


card list items with badges

[ ] bug
[x] feature request
[ ] enhancement

Expected behavior

Actual behavior

is it possible to add badge-icon on the right side of list item? or maybe any other span block?

I'll let UX decide if this is a valid request. In the meantime, here is an easy way to do it in your app without waiting for the feature: https://plnkr.co/edit/4203nv?p=preview
All I did was give the list group with a badge the following styles:
.list-item-with-badge {
  display:flex;
  justify-content: space-between;
  align-items: center;
}

Hallo @youdz!
Great! Thank you!
I need it not urgent :) we can say - this issue has prio-4 :)
it will be very helpful later, because sometimes I have in templates list items with arrows or badges on the right side.


Severely slows down login after update to kernel 4.13 (Meltdown/Spectre)

An almost 250 second delay is caused while automounting Google Drive after login ever since the kernel 4.13 update was installed. I have a desktop and a laptop both running Ubuntu 16.04 affected similarly. This is probably not the fault of this program, and is caused by the fuse filesystem used under the hood, but I have no idea about the filesystem, and therefore am raising the issue here. The following is relevant output from dmesg.
[   18.335623] [drm:ci_dpm_set_power_state [radeon]] *ERROR* ci_upload_dpm_level_enable_mask failed
[  242.405892] INFO: task pool:1816 blocked for more than 120 seconds.
[  242.405901]       Tainted: G           OE   4.13.0-32-generic #35~16.04.1-Ubuntu
[  242.405904] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  242.405907] pool            D    0  1816      1 0x00000004
[  242.405913] Call Trace:
[  242.405926]  __schedule+0x3c2/0x890
[  242.405931]  schedule+0x36/0x80
[  242.405935]  schedule_preempt_disabled+0xe/0x10
[  242.405939]  __mutex_lock.isra.2+0x2ae/0x4e0
[  242.405946]  ? kmem_cache_alloc_trace+0x19d/0x1b0
[  242.405951]  __mutex_lock_slowpath+0x13/0x20
[  242.405955]  ? __mutex_lock_slowpath+0x13/0x20
[  242.405958]  mutex_lock+0x2f/0x40
[  242.405965]  fuse_lock_inode+0x2a/0x30
[  242.405969]  fuse_lookup+0x31/0x140
[  242.405975]  ? lookup_fast+0xcf/0x2f0
[  242.405980]  lookup_slow+0xa5/0x160
[  242.405985]  walk_component+0x1bf/0x350
[  242.405989]  ? path_init+0x1d9/0x310
[  242.405993]  path_lookupat+0x76/0x230
[  242.405998]  filename_lookup+0xb8/0x1a0
[  242.406005]  ? ttwu_do_activate+0x7a/0x90
[  242.406011]  ? __check_object_size+0xfc/0x1a0
[  242.406015]  ? strncpy_from_user+0x4d/0x170
[  242.406021]  user_path_at_empty+0x36/0x40
[  242.406025]  ? user_path_at_empty+0x36/0x40
[  242.406030]  vfs_statx+0x77/0xe0
[  242.406036]  SYSC_newlstat+0x3d/0x70
[  242.406040]  ? SyS_futex+0x7f/0x180
[  242.406047]  SyS_newlstat+0xe/0x10
[  242.406052]  entry_SYSCALL_64_fastpath+0x33/0xa3

Google drive is being automounted as per the fstab method here. Commenting out the lines in fstab causes the system to boot in 18 seconds (the radeon error is the last activity in dmesg). I require Google Drive to be automounted at startup to maintain file synchronisation. Please let me know if any alternate method of automounting will be a feasible workaround till this issue is resolved.

I think I was totally off track when I opened the bug report. The issue was not kernel 4.13, but the fact that one of my Google accounts is managed by my university, and has a policy that external apps will be granted access only for 30 days. This is something that is new, probably, because I had been using this program for well over a year without it this hanging business happening before (hence also my confusion about the kernel update, compounded by the fact that quite a few programs were glitchy after the update).
So, I think it is safe to close this bug report. I would like to open a new one, with a feature request that there be something to "refresh" the access tokens. Thanks!


MailMerge style reporting on sessions

Generate a report per session within the current query scope that outputs user specified formatting with all meta including session payload/encoding options being accessible by the report operation.

Example?  This can already be done with the viewer decoders I think

Thoughts:

Operators will be able to upload jade fragment into settings
should everyone, or controlled by a setting?
would be nice to have a global set also (this goes for views too while we are at it) that are shared that admins can set.  (Maybe have a global user that all users inherit from)
Would be nice if at least 2 different fragment types are supported
Session - Simple kind where the fragment is per session, can't have headers or anything (unless some kind of hack ...)
Document - Advanced kind where the fragment is the whole document so you can do headers and stuff and maybe the session forloop is inside the fragment
New sub menu in viewer that shows the possible mail merges
New URI that takes the mail merges, expression, ... and processes
Need to think about if jade fragments can be used to hack the planet
Obviously XSS bad javascript is possible, but not sure we care about that
Can jade template do stuff to file system, such as read /etc/passwd or write flies, if so how do we protect
Need a better name then mail merge

@awick
Heh. Never meant to have it called mail merge. This is what you called it during lunch, and reused the term to refresh your memory. I think of it as 'session reporting' / 'SPI report'

Still would like to do this but, ...

@awick but what? 🦋How does this differ from the summary (https://github.com/aol/moloch/issues/12) or narrative features (https://github.com/aol/moloch/issues/842)? Just that a user can provide a template/format?


Handle ajax requests to not redirect

change in garpinc fork commit ba3c351
diff --git a/pac4j-http/src/main/java/org/pac4j/http/client/indirect/FormClient.java b/pac4j-http/src/main/java/org/pac4j/http/client/indirect/FormClient.java
index e70528f..edfd5cf 100644
--- a/pac4j-http/src/main/java/org/pac4j/http/client/indirect/FormClient.java
+++ b/pac4j-http/src/main/java/org/pac4j/http/client/indirect/FormClient.java
@@ -79,12 +79,6 @@
credentials = getCredentialsExtractor().extract(context);
logger.debug("usernamePasswordCredentials: {}", credentials);
if (credentials == null) {

  		// it's an AJAX request -> unauthorized (instead of a

  		// redirection)

  		if (getAjaxRequestResolver().isAjax(context)) {

  			logger.info("AJAX request detected -> returning 401");

  			throw RequiresHttpAction.unauthorized("AJAX request -> 401", context, null);

  		} else {
  			String redirectionUrl = CommonHelper.addParameter(this.loginUrl, this.usernameParameter, username);
  			redirectionUrl = CommonHelper.addParameter(redirectionUrl, ERROR_PARAMETER, MISSING_FIELD_ERROR);
  			logger.debug("redirectionUrl: {}", redirectionUrl);

@@ -92,15 +86,9 @@
logger.debug(message);
throw RequiresHttpAction.redirect(message, context, redirectionUrl);
}

       }
       // validate credentials
       getAuthenticator().validate(credentials);
   } catch (final CredentialsException e) {

  	// it's an AJAX request -> forbidden (instead of a redirection)

  	if (getAjaxRequestResolver().isAjax(context)) {

  		logger.info("AJAX request detected -> returning 403");

  		throw RequiresHttpAction.forbidden("AJAX request -> 403", context);

  	} else {
  		String redirectionUrl = CommonHelper.addParameter(this.loginUrl, this.usernameParameter, username);
  		String errorMessage = computeErrorMessage(e);
  		redirectionUrl = CommonHelper.addParameter(redirectionUrl, ERROR_PARAMETER, errorMessage);

@@ -109,7 +97,6 @@
logger.debug(message);
throw RequiresHttpAction.redirect(message, context, redirectionUrl);
}

   }

   return credentials;

}

The source code is hardly readable. Can you explain what is the issue and the fix you propose?

When an ajax client attempts to authenticate with pac4j to get a cookie originally in pac4j a redirect occured. Browsers redirect before the javascript gets back control and hence javascript doesn't work correctly. The correct behavior for ajax requests is not to redirect.

You're right. As the FormClient performs some specific redirections, the AJAX capability should be taken into account. Waiting for the pull request (expecting some test to confirm the behaviour as well).

Expecting a pull request for this change.


ROX-8799: Refactoring of roxctl scanner command

Description
Following changes are made:

introduced environment.Environment.Logger() to scanner commands. Relevant only for upload-db
refactored scanner commands to follow: construct -> validate -> execute flow
added unit tests

Checklist

[x] Investigated and inspected CI test results
[x] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required - changes are not relevant for CHANGELOG
[ ] Determined and documented upgrade steps - not required
[ ] Documented user facing changes (create PR based on stackrox/openshift-docs and merge into rhacs-docs) - not required, since commands are not changed

Testing Performed

For scanner upload-db zip with scanner definitions is required. I have fetched one here: https://docs.openshift.com/acs/3.68/configuration/enable-offline-mode.html#download-scanner-definitions_enable-offline-mode
I have used that file and tested upload-db with following command:

./bin/darwin/roxctl --insecure-skip-tls-verify --insecure --endpoint https://localhost:8000 -p $ROX_PASSWORD scanner upload-db --scanner-db-file ./scanner-vuln-updates.zip

That command reaches execution path where environment.Environment.Logger() is used. And I have got expected output:
Successfully stored the offline vulnerability definitions

For scanner generate main changes are in validation of command parameters. I have used following commands to test validation:

should work since Istio version is supported

./bin/darwin/roxctl --insecure-skip-tls-verify --insecure --endpoint https://localhost:8000 -p $ROX_PASSWORD scanner generate --istio-support 1.7

should fail because Istio version is not supported

./bin/darwin/roxctl --insecure-skip-tls-verify --insecure --endpoint https://localhost:8000 -p $ROX_PASSWORD scanner generate --istio-support 2.2

should work because Istio version is not provided

./bin/darwin/roxctl --insecure-skip-tls-verify --insecure --endpoint https://localhost:8000 -p $ROX_PASSWORD scanner generate

We will address the following problems in separate PR:

improving unit tests for update-db
add e2e tests for generate command
add e2e tests for update-db command


After adding the configuration, all routes are inaccessible

Problem

Steps To Reproduce
Steps to reproduce the behavior:

According to the official document, after adding tailwindcss, all routes are inaccessible

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment:

Dioxus version: [e.g. v0.4.0, master]
Rust version: [e.g. 1.72.0, nightly]
OS info: [e.g. ubuntu]
App platform: [e.g. web]

Questionnaire

[ ] I'm interested in fixing this myself but don't know where to start
[ ] I would like to fix and I have a solution
[ ] I don't have time to fix this right now, but maybe later

my configure:
[application]
App (Project) Name
name = "Tailwind CSS + Dioxus"
Dioxus App Default Platform
desktop, web, mobile, ssr
default_platform = "web"
build & serve dist path
out_dir = "dist"
resource (public) file folder
asset_dir = "public"
[web.app]
HTML title tag content
title = "dioxus | ⛺"
[web.watcher]
when watcher trigger, regenerate the index.html
reload_html = true
which files or dirs will be watcher monitoring
watch_path = ["src", "public"]
uncomment line below if using Router
index_on_404 = true
include assets in web platform
[web.resource]
CSS style file
style = ["app.css"]
Javascript code file
script = []
[web.resource.dev]
serve: [dev-server] only
CSS style file
style = []
Javascript code file
script = []

cargo.toml:
[dependencies]
dioxus = "0.4.0"
dioxus-router = "0.4.1"
dioxus-web = "0.4.0"
gloo = "0.10.0"

Directory structure that can be accessed and refreshed normally

Inaccessible directory structure

Configuration and directory structure of CSS

package.json:
{
"name": "styles",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo "Error: no test specified" && exit 1",
"dev": "NODE_ENV=production node_modules/.bin/postcss main.pcss -o ../public/app.css --watch"
},
"author": "",
"license": "ISC",
"dependencies": {
"autoprefixer": "^10.4.15",
"postcss": "^8.4.29",
"postcss-cli": "^10.1.0",
"tailwindcss": "^3.3.3"
},
"devDependencies": {
"daisyui": "^3.7.3"
}
}
tailwind.config.js:
module.exports = {
purge: [
'../src/**/.rs'
],
darkMode: 'class',
theme: {
extend: {
"tailwindCSS.experimental.classRegex": ["class: "(.)""],
"tailwindCSS.includeLanguages": {
"rust": "html"
},
},

},
variants: {
extend: {
},

},
plugins: ["daisyui"],
}
postcss.config.js:
module.exports = {
plugins: {
tailwindcss: { config: './tailwind.config.js' },
autoprefixer: {},
'postcss-nested': {},
}
}
main.pcss:
@tailwind base;
@tailwind components;
@tailwind utilities;

my  dioxus  code:
#![allow(non_snake_case)]
use dioxus::prelude::;
use dioxus_router::prelude::;
fn main() {
dioxus_web::launch(App);
}
fn App(cx: Scope) -> Element {
render! (
Router::{}
)
}
#[derive(Routable, Clone)]
enum Route {
#[route("/login")]
Login {},
#[nest("/main")]
#[layout(MainMaster)]
#[route("/")]
MainHome {},
#[end_layout]
#[end_nest]
#[route("/:..route")]
PageNotFound {
route: Vec
}
}
fn Login(cx: Scope) -> Element {
cx.render(rsx! {
div {
"登录页面"
}
})
}
fn MainMaster(cx: Scope) -> Element {
cx.render(rsx! {
div {
"后台主页"
}
Outlet:: {}
})
}
#[inline_props]
fn PageNotFound(cx: Scope, route: Vec) ->Element {
cx.render(rsx! {
div {
"没有这个页面"
}
})
}
fn MainHome (cx: Scope) -> Element {
render! {
div {
"这是后台主页面"
}
}
}

@ys2rice2yangsong I appreciate the clarification in the title, but this looks like exactly the same issue as #1468 and #1467. If you would like to modify the title of an issue you can click the edit button at the top:

I am closing this as a duplicate, but I would be happy to help more with this issue in https://github.com/DioxusLabs/dioxus/issues/1468 if adding index_on_404 does not fix your issue


illegal Argument by channel

it seems I have a problem to setup the right arguments to switch channels on DVBC ..... may you can help (btw: the catch of favorites didn't work on DVBC, but on DVBT)
Bildschirmfoto config.pdf
Bildschirmfoto log.pdf

I have never tested the plugin with DVBC because I only have DVBT, I'll take a closer look


Preserve link text in Markdown

When serialising to Markdown, the link text is lost, replaced by by the link URI in the generated legacy entities and the MD representation.
Ideally, links should be rendered to Markdown as per the spec, i.e. Link text -> [Link text](http://example.com), but this might break Symphony clients, so discretion is advised in handling this issue.

Reverted in 73291d69bad60a61580423a33ebb291dee0b111a to avoid breaking legacy clients.


Internal team should be able to collect information about how the product is used

(from @nokierae): Since our first installations will be isolated from the internet, we can’t use typical logging strategies. We will obviously ask our clients for feedback on the app, but they might not be able to articulate exactly what they’ve experienced over months of using it.

This is completed (see Activity page in v2.1


RabbitMQ pods takes more time to deploy when used with AWS EFS as a storage class

Version of Helm and Kubernetes:
Helm Version:
version.BuildInfo{Version:"v3.3.4", GitCommit:"a61ce5633af99708171414353ed49547cf05013d", GitTreeState:"clean", GoVersion:"go1.14.9"}
Kubectl Version:
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"e19964183377d0ec2052d1f1fa930c4d7575bd50", GitTreeState:"clean", BuildDate:"2020-08-26T14:30:33Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.12-eks-7684af", GitCommit:"7684af4ac41370dd109ac13817023cb8063e3d45", GitTreeState:"clean", BuildDate:"2020-10-20T22:57:40Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}
Which chart:
https://github.com/bitnami/charts/tree/master/bitnami/rabbitmq/
What happened:
RabbitMQ pod takes more than 20 mins to deploy when used with AWS EFS as a storage class. But it works fine when I use gp2 as a storage class.
Here is output of kubectl get pods

What you expected to happen:
Expected RabbitMQ pods to be in ready state withing few minuets(<2 min).
How to reproduce it (as minimally and precisely as possible):
Install the rabbitmq chart with EFS as a storage class.

raised against wrong branch. Hence closing.

raised against wrong branch. Hence closing.


[BUG] Cannot connect to host

Please help me with the following problem: Cannot connect to host hello-world-long-bird-0f21.bydymainit.workers.dev:443 ssl:default [The semaphore timeout has been exceeded]. My domain was entered without http prefixes, etc., what could be the problem? it is possible that the domain was created incorrectly, but it is unlikely... help please. (this is Qt 1 if anything)

Please set up a usable proxy.


NTR: smFISH assay evidence

smFISH
A single molecule fluorescence in situ hybridization (smFISH) is a technique optimized for studying gene expression in single cells but is distinct in its ability to localize and quantify individual RNA molecules.
I guess this would be a child of
ECO:0005518
RNA detection assay evidence

Hi @ValWood
We already have a term for 'fluorescence in situ hybridization evidence' ECO:0001047.
This new term could be a child of that.
Currently, we don't have DNA and RNA versions of these FISH terms (they are just under 'nucleic acid localization evidence') but if if you think that we should, we can work on how to structure that.
Best,
Michelle

Your call, I can stick with ECO:0005518 RNA detection assay evidence, since that is the critical part. The smFISH tends to be used for quantification.

@ValWood @mgiglio99
Here is what the term is going to look like. In case it needs edits, I can do them for the next release.
Term: 'single molecule fluorescence in situ hybridization'
Definition: 'A type of fluorescence in situ hybridization evidence resulting from the use of fluorescent probes to localize and quantify individual RNA molecules in single cells for studying gene expression.'
Parents: 'fluorescence in situ hybridization evidence' ECO:0001047 and 'RNA detection assay evidence' ECO:0005518.
Thanks,
Suvvi

Thanks! looks good.

HI @Val,
The requested term and associated assertion terms have been created and released.
Term: single molecule fluorescence in situ hybridization evidence
Parents: 'fluorescence in situ hybridization evidence' ECO:0001047 and 'RNA detection assay evidence' ECO:0005518.
The 'single molecule fluorescence in situ hybridization evidence used in manual assertion ' is mapping to GO Evidence Code 'IEP' and 'single molecule fluorescence in situ hybridization evidence used in automatic assertion' is mapping to GO Evidence Code 'IEA'.

ECO_id
ECO_label

ECO:0008009
single molecule fluorescence in situ hybridization evidence

ECO:0008017
single molecule fluorescence in situ hybridization evidence used in automatic assertion

ECO:0008016
single molecule fluorescence in situ hybridization evidence used in manual assertion

Thanks,
Suvvi


[Doc Issue][Update auth-oauth-provider]

Acrolinx Scorecards
We currently enforce a minimum score of 80.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard
Processed

msteams-platform/tabs/how-to/authentication/auth-oauth-provider.md
90
11
link
:white_check_mark:

More info about Acrolinx
Use the Acrolinx extension, or sidebar, in Visual Studio Code to check spelling, grammar, style, tone, clarity, and key terminology when you're creating or updating content. For more information, see Use the Visual Studio Code extension to run Acrolinx locally.

Docs Build status updates of commit d1324db:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/tabs/how-to/authentication/auth-oauth-provider.md
:white_check_mark:Succeeded
View

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


Material node values do not initially reflect the displayed control/slider values.

Current Behavior
When a new material is created, the Material Properties sliders and controls do not reflect the actual default values of the nodes in the created material node tree.  This appears to be a problem with initialization when a new material is created.  A work-around is to manipulate the control slider/value once, and that will make the control/node values equal.
Expected Behavior
The parameters of relevant nodes created by the MSFS Standard Material should reflect the values set in the node tree of the instance created.
Steps To Reproduce

Create new object
Create a new texture for the object.  Assume a simple Base Color to start; this invokes the default white value.
In the material stack, set MSFS Material Params to Standard.
Without doing anything else, especially changing the Base Color, switch to a Blender view of the Shading Editor, the shader tree generated by the creation of the new material.
In the Shader Editor, navigate to the Base Color RGB node, near the top of the screen.
Click the flippy arrow of that node to expand the node.
Note that that node is defaulted to a gray color while the Base Color control in the properties panel is pure white (1.00).
In the Properties panel, click the Base Color control to get the Color Picker dialog.  Note that the Color Picker dialog shows full white.
With your mouse, move the gray scale slider on the right of the Color Picker dialog up and down a little once.
Note the value in the node controlled by the Color Picker dialog now repeats the Base Color control.

Environment
- OS: Windows 10 Home
- Blender:3.1
- glTF-Blender-IO-MSFS:1.1.3

Anything else?
Best guess as to the solution for this problem:
In the init portion of the material class instance constructor, there should be a segment that scans the visible default settings of the material properties controls to make the nodes reflect the visible settings.  This problem is apparent in many of the control/node pairings.
Minor Consideration:
Controls like Metallic Factor, Roughness Factor, Normal Scale, Emissive RGB and the like should be defaulted to reasonable values if they are used in the material.  The default set in the Principled BSDF Shader in Blender would be a reasonable set.
Summary comment:
I have been using this new exporter extensively for the past week, and I find it a very agreeable tool.  I am currently recompiling many of my projects using it.  My thanks to all the developers for this well-organized tool.  I await the resolution of the order of LOD keys in the .xml file.  Thank you all for the work on this tool.

Hey i think this is also the same like #89 but better detailed.

I actually have it "fixed" and am testing.  You'll have to take care of the changes, as I am not qualified to get anywhere near a code repository.  I'll detail it here for you.  The fix is not optimal, but it will point to the problem.  Help!  I'm being dragged into the jungle by a large snake!

I just looked at the changes in 1.1.4 released a few hours ago, and they are a better fix than mine.  All I did yesterday was comment out the attempt to set the color mode to Non-Color.  That's where the update was hanging and not being caught.  I found that problem using the Blender Console.  Thanks to lpieriabella for this fix that incorporates several other fixes also.  The fix should be solid.


(iOS) overdrag boolean prop for TabView

Motivation
When swipeEnabled is true, sometimes on iOS the app does or doesn't want to allow for overscrolling after reaching the very end or very beginning of pages. overdrag is one of the props from react-native-pager-view for this, but it wasn't presented in react-native-tab-view. This is also important for the latest @react-navigation/material-top-tabs which uses react-native-tab-view.
Test plan
import { SceneRendererProps, TabView } from 'react-native-tab-view';

export default function MaterialTopTabView({
  overdrag,
  ...
}: Props) {
  return (
    <TabView<Route<string>>
      overdrag={overdrag} // boolean: true or false. Optional. Defaults to false.
      ...
    />
  );
}

Before when it was not configurable, it's always over-scrollable.
https://user-images.githubusercontent.com/4941095/136645109-741c7352-d6ae-48fa-ba82-869b959826da.MP4
But now when it's set to false, over-scrolling can be prevented.
https://user-images.githubusercontent.com/4941095/136645121-b60a421a-eb7d-4e66-b8d2-b45852d844be.MP4

On that note...there are several other properties that show up in typescript that are not transferred to the SceneView.
Something is definitely wrong here... we probably should be using the spread ...props and passing it into the PagerComponent...
https://github.com/satya164/react-native-tab-view/blob/main/src/TabView.tsx#L79

Closing this since overdrag now defaults to false in react-native-pager-view. Passing more props to PagerView can be addressed in separate PR.


Updated the image in How Keploy Works Page

Signed-off-by: prayatharth<EMAIL_ADDRESS>Pull Request Template
Description
The image provided with of new logo was updated as to the image named "how-it-works.png" and the resolution of the new image provided was resized as the previous image used , to prevent any size mismatch to the new image.
Fixes #52
Type of change

[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist:

[ ] My code follows the style guidelines of this project.
[ ] I have performed a self-review of my own code.
[ ] I have made corresponding changes to the documentation.
[ ] I have added corresponding tests.
[ ] Any dependent changes have been merged and published in downstream modules.

Wohoo. Great Job @prayatharth


Suggestion: alignment about VM status types with CB-Tumblebug

Suggestion: alignment about VM status types with CB-Tumblebug
CB-Tumblebug defined the following VM status types,
Final status category :
	Running
	Suspended
	Failed
	Terminated
Transitional status category :
	Creating
	Suspending
	Resuming
	Rebooting
	Terminating
CB-Spider provides the following status types which are not aligned with CB-Tumblebug.
type StatusInfo struct {
        Status string
// PENDING | RUNNING | SUSPENDING | SUSPENDED | REBOOTING | TERMINATING | TERMINATED

There are missing status types for VM. (Failed)
And "PENDING" status can be changed to "Creating" status

Thank you for your suggestion.
I'll check it ASAP ~


[BUG] EventHubConsumerClient properties are not mockable

ConsumerGroup, EventHubName, FullyQualifiedNamespace, IsClosed.
Haven't found any mentions in https://github.com/Azure/azure-sdk-for-net/issues/9117

These are not something that we'd set using the model factory.
The first three are properties of the consumer itself, derived from either the connection string or the items used for creation.   They can be set during construction, either directly or from the connection string.
IsClosed represents the state of the object and can be set by calling CloseAsync after creating the client.   It does not require opening the connection to the service to do do.

Interesting. Am I correct in understanding that there would be no network IO until some async client method is called?

Am I correct in understanding that there would be no network IO until some async client method is called?

Correct;  the connection to the service is not made until the first service operation is invoked.   If you create the client and close it, there's no network communication taking place.

If you wanted more control, you could also mock out the EventHubConnection and call this overload.


Settings Clarity, Rephrasing & Typos

While this isn't an immediate issue, it may deter new users who are less familiar with the plugin and its configuration. I feel therefore it is definitely something to consider and improve if possible.
Below are a few examples and how they could be improved:

"These settings are kept locked while synchronisation is in progress."

"Enabled - empty folders stored locally are synced to the remote database.
Disabled - empty folders stored locally are not synced to the remote database, and those that become empty on another device will not sync to other devices."

"There is no corrupted data."

I would like to also point out, though, that I very much like the new settings layout. It is far more organised and structured compared that of earlier releases. This combined with improvements to the text will make the plugin far easier to use.
If you'd like any help with re-writing anything, including anything in the docs, I'd be more than happy to help!

Very very thank you for your check! Actually, I'm not so good at English writing.
Please feel free to let me know if it is strange or difficult to understand.
This is a big chance to improve this plugin and my English :)
Reading is not so bad, so if there's something misunderstanding in each other, I will explain.
Of course, any pull requests are welcome too.
First, I'll brush the plugin up like this issue.

@kwjfef I wrote some ideas, to add a little detail. Could you check it?

"These settings are kept locked while synchronisation is in progress."

"These settings are kept locked while you turn on any automatic synchronization." is ok?
(Yes, you have a good point. I have to lock this setting while synchronization is in progress, in addition to current behavior.)
So, finally, this note would be like this? : "These settings are kept locked while you turn on any automatic synchronization or in progress."

"Enabled - empty folders stored locally are synced to the remote database.
Disabled - empty folders stored locally are not synced to the remote database, and those that become empty on another device will not sync to other devices."

How is the below?
Disabled - Delete the folder if it becomes empty by replication.
Enabled - Do nothing to the folder, even if replication has deleted any files.

I'm not so good at English writing.

No worries, you've done a great job so far! It's just a case of fixing minor grammatical errors now.

"These settings are kept locked while you turn on any automatic synchronization or in progress."

The addition of "automatic" I think is better than my initial suggestion, as automatic implies that there are settings enabled causing replication to take place whenever an edit is made. As this isn't happening at all times, I feel that "in progress" becomes redundant.
It might be better to rephrase this instead as:
"These settings are kept locked while automatic synchronisation options are enabled. Disable these options in the "Sync Settings" tab to unlock."

"Disabled - Delete the folder if it becomes empty by replication.
Enabled - Do nothing to the folder, even if replication has deleted any files."

This suggests that if a folder is detected as empty during replication, it will be deleted from both the local vault as well as the remote vault if the setting is disabled, which isn't the case as the folder is still kept intact locally.
I think it is important to specify this as the setting can be changed per device.
Please correct me if I'm misunderstanding the role of this setting, but from my testing, this is what I've found it does.

Thank you for your kindness! I'm very encouraged!

"These settings are kept locked while automatic synchronisation options are enabled. Disable these options in the "Sync Settings" tab to unlock."
This is awesome! Thank you!

which isn't the case as the folder is still kept intact locally.
Oh... really? I think it is a problem.
I'll investigate more.

Close this issue once.


Document that base64 encoding padding must be removed from bearer token

Closes #202. I've documented the issue with base64 encoding padding and I've included a code sample to show users how to construct the token as it's very difficult to find this information. The reason why I've chose to use Python and not Go is because anyone writing in Go would be using the IAM Authenticator Go client directly and it has this functionality built in already.

Thank you for this @svozza.

/lgtm

/approved

/assign @christopherhein

/approve


How to generate grpc client?

Hi, I was attempting to add GeoPolygon Filter to the local mode. However, after I added GeoPolygon into proto file, I found the script used to generate python grpc client was not working. It seems that the given script in generate_grpc_client is trying to get the proto files from master branch which will overwrite my changes.
Then I was trying to directly use the line python -m grpc_tools.protoc --proto_path=qdrant_client/proto/ -I ./qdrant_client/grpc ./qdrant_client/proto/*.proto --python_out=./qdrant_client/grpc --grpc_python_out=./qdrant_client/grpc for generation. However, I found it changed lots of files. And some code lines are missing after the change, eg:
ReadConsistency = _reflection.GeneratedProtocolMessageType('ReadConsistency', (_message.Message,), {
  'DESCRIPTOR' : _READCONSISTENCY,
  '__module__' : 'points_pb2'
  # @@protoc_insertion_point(class_scope:qdrant.ReadConsistency)
  })
_sym_db.RegisterMessage(ReadConsistency)

PointId = _reflection.GeneratedProtocolMessageType('PointId', (_message.Message,), {
  'DESCRIPTOR' : _POINTID,
  '__module__' : 'points_pb2'
  # @@protoc_insertion_point(class_scope:qdrant.PointId)
  })
_sym_db.RegisterMessage(PointId)

I was wondering what is a correct way to generate the python client?

Hi @zzzz-vincent
You don't need to generate grpc client to add a new feature to the local mode, since it does not make any requests and just operates with local structures.
AFAIK, the script in tools is correct, but requires a particular version of protoc.
protoc started to generate oython clients with Builder entity, we need to use previous version.
I think @generall can tell more details

Thanks, I see what you mean. Yes this makes sense.


CodeChunk component: position of horizontal scroll bar for source

When the source code is wide, the horizontal scroll bar appears - but, jarringly, after the code content, not at the bottom of the component:

sigh… This came up as a result of fixing a Safari specific bug with pre elements being super tall when rendered inside iFrames (as in /Open). I'll look into a browser specific fix.


Issue feeds sync

HI, I got an error during feeds sync.
What should I do?

# curl -v -H 'x-anchore-password: pbiU2RYZ2XrmYQ'<EMAIL_ADDRESS>

* About to connect() to ancho.re port 443 (#0)
*   Trying <IP_ADDRESS>...
* Connected to ancho.re (<IP_ADDRESS>) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*       subject: CN=sni189579.cloudflaressl.com,OU=PositiveSSL Multi-Domain,OU=Domain Control Validated
*       start date: Mar 30 00:00:00 2019 GMT
*       expire date: Oct 06 23:59:59 2019 GMT
*       common name: sni189579.cloudflaressl.com
*       issuer: CN=COMODO ECC Domain Validation Secure Server CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
> GET<EMAIL_ADDRESS>HTTP/1.1
> User-Agent: curl/7.29.0
> Host: ancho.re
> Accept: */*
> x-anchore-password: pbiU2RYZ2XrmYQ
>
< HTTP/1.1 403 Forbidden
< Date: Wed, 10 Apr 2019 05:20:50 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=d35dd8b81efa5f8eecb8bf654606deab61554873649; expires=Thu, 09-Apr-20 05:20:49 GMT; path=/; domain=.ancho.re; HttpOnly
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 4c5246173ec9ae93-KIX
<

403 Forbidden

403 Forbidden
nginx/1.10.3 (Ubuntu)

* Connection #0 to host ancho.re left intact

curl --verbose -H 'x-anchore-password: pbiU2RYZ2XrmYQ'<EMAIL_ADDRESS>
About to connect() to ancho.re port 443 (#0)
Trying <IP_ADDRESS>...
Connected to ancho.re (<IP_ADDRESS>) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Server certificate:

  subject: CN=sni189579.cloudflaressl.com,OU=PositiveSSL Multi-Domain,OU=Domain Control Validated

  start date: Mar 30 00:00:00 2019 GMT

  expire date: Oct 06 23:59:59 2019 GMT

  common name: sni189579.cloudflaressl.com

  issuer: CN=COMODO ECC Domain Validation Secure Server CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB

GET<EMAIL_ADDRESS>HTTP/1.1
User-Agent: curl/7.29.0
Host: ancho.re
Accept: /
x-anchore-password: pbiU2RYZ2XrmYQ

< HTTP/1.1 403 Forbidden
< Date: Wed, 10 Apr 2019 05:10:48 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da8390ecc086bdfa2db62245fb68ede711554873048; expires=Thu, 09-Apr-20 05:10:48 GMT; path=/; domain=.ancho.re; HttpOnly
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 4c5237679f38aeb1-KIX
<

403 Forbidden

403 Forbidden
nginx/1.10.3 (Ubuntu)

hi @jymun
Can you please try a feed sync again?  We've updated some of our site settings which may have been responsible for the 403 responses you were seeing.

Thanks. 200 code is output.


Update rust to ffc111889e93bcd38222d9d74a70fdc26a78fcb5/rust-0.13.0-dev

For https://github.com/servo/servo/pull/4554.


Vcpkg and Kits don't mix well

Brief Issue Summary
The current design of Kits don't mix well with Vcpkg, an invaluable tool for Windows OSS developers. It's practically a package manager written in CMake. I recently started using it and went straight to contributing 3 packages into it.
The problem is, that Vcpkg abuses toolchain files for dependencies only, but not the compiler itself. Because Kits rightfully expect a compiler to be defined when using toolchain kits, it chokes on vcpkg.cmake, because it does not define a compiler, but just about everything else.
Expected:
I would like CMake Tools to allow toolchain files to be specified in any of the Kit types.
Strange workaround:
I though of going for the Visual Studio 15 2017 Win64 generator to implicitly find the compiler when using Vcpkg. However, using this generator it chokes saying
The Platform for project 'VCTargetsPath.vcxproj' is invalid.  Platform=' Win64'.

By changing the generator to Visual Studio 15 2017Win64 it works as expected, it's just CMake Tools that throws an error that it doesn't know this generator, otherwise it works.
Platform and Versions

Operating System: Windows
CMake Version: 3.10.0
VSCode Version: 1.19.0
CMake Tools Extension Version: 0.11-beta4
Compiler/Toolchain: Visual C++ 2017

It worked like a charm! Awesome! Thanks for the tip. For others (future reference):
[
  {
    "name": "MSVC 15.6-beta5",
    "visualStudio": "a2f9235f",
    "visualStudioArchitecture": "amd64",
    "preferredGenerator": {
      "name": "Visual Studio 15 2017",
      "platform": "x64"
    },
    "cmakeSettings": {
      "CMAKE_TOOLCHAIN_FILE": "C:/Users/mnagy/Source/Repos/vcpkg/scripts/buildsystems/vcpkg.cmake"
    }
  }
]