initContainer does not set permissions

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What version of the Traefik's Helm Chart are you using?
traefik-26.0.0
What version of Traefik are you using?
v2.10.6
What did you do?
Follow the instructions to install traefik with an init container to set permisisons for acme.json.
I run on a Talos cluster v1.6.1 with OpenEBS Jiva as explained here:
https://www.talos.dev/v1.6/kubernetes-guides/configuration/replicated-local-storage-with-openebs-jiva/
Specifically for installing Traefik:
helm show values traefik/traefik > custom-values.yaml
I set:
additionalArguments:
  - "--certificatesresolvers.letsencrypt.acme.tlschallenge=true"
  -<EMAIL_ADDRESS>  - "--certificatesresolvers.letsencrypt.acme.storage=/data/acme.json"
  - "--certificatesresolvers.letsencrypt.acme.caserver=https://acme-v02.api.letsencrypt.org/directory"

I set:
ports:
...
    redirectTo:
      port: websecure

I set persistence:
persistence:
  enabled: true
  name: data
  accessMode: ReadWriteOnce
  size: 1Gi
  path: /data
  annotations: {}

I enable init-container:
  initContainers:
    - name: volume-permissions
      image: busybox:latest
      command: ["sh", "-c", "touch /data/acme.json; chmod -v 600 /data/acme.json"]
      securityContext:
        runAsNonRoot: true
        runAsGroup: 65532
        runAsUser: 65532
      volumeMounts:
        - name: data
          mountPath: /data

I create namespace:
---
apiVersion: v1
kind: Namespace
metadata:
  name: traefik
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/audit: privileged
    pod-security.kubernetes.io/warn: privileged

helm upgrade --install traefik traefik/traefik --values custom-values.yaml -n traefik
Pods get created, pv's and pvc's but this pod crashes:
traefik          traefik-5bbd794b64-5l6cf                                          0/1     Init:CrashLoopBackOff
What did you see instead?
kubectl logs -n traefik pods/traefik-5bbd794b64-5l6cf
Defaulted container "traefik" out of: traefik, volume-permissions (init)
Error from server (BadRequest): container "traefik" in pod "traefik-5bbd794b64-5l6cf" is waiting to start: PodInitializing

Not sure how much info is relevant, but:
Events:
  Type     Reason     Age                   From               Message
  ----     ------     ----                  ----               -------
  Normal   Scheduled  13m                   default-scheduler  Successfully assigned traefik/traefik-5bbd794b64-5l6cf to worker-01
  Normal   Pulled     13m                   kubelet            Successfully pulled image "busybox:latest" in 765ms (765ms including waiting)
  Normal   Pulled     13m                   kubelet            Successfully pulled image "busybox:latest" in 732ms (732ms including waiting)
  Normal   Pulled     13m                   kubelet            Successfully pulled image "busybox:latest" in 682ms (682ms including waiting)
  Normal   Created    12m (x4 over 13m)     kubelet            Created container volume-permissions
  Normal   Started    12m (x4 over 13m)     kubelet            Started container volume-permissions
  Normal   Pulled     12m                   kubelet            Successfully pulled image "busybox:latest" in 714ms (714ms including waiting)
  Normal   Pulling    12m (x5 over 13m)     kubelet            Pulling image "busybox:latest"
  Normal   Pulled     11m                   kubelet            Successfully pulled image "busybox:latest" in 742ms (743ms including waiting)
  Warning  BackOff    3m19s (x48 over 13m)  kubelet            Back-off restarting failed container volume-permissions in pod traefik-5bbd794b64-5l6cf_traefik(fea5c5db-340f-4c7a-b335-2dde3fa62b38)

What is your environment & configuration?
Talos cluster v1.6.1 with OpenEBS Jiva
Additional Information
No response

The events says
[...] Back-off restarting failed container volume-permissions in pod traefik-5bbd794b64-5l6cf_traefik(fea5c5db-340f-4c7a-b335-2dde3fa62b38)

did you take a look at logs on volume-permissions ? you can select it with kubectl logs [...] -c volume-permissions

# kc logs -n traefik pods/traefik-5bbd794b64-k8lgg -c volume-permissions
touch: /data/acme.json: Permission denied
chmod: /data/acme.json: No such file or directory

Yeh sorry that was silly. I just noticed that 😛
Well, to ask the obvious, shouldn't those be changed to run as root?

There are many ways to fix this storage rights issue, depending on your precise setup.
It's out of scope here. This repository is dedicated to issue on Traefik Helm Chart.
=> I'll close this issue.

@Hr46ph I am facing he same issue? Did you found a solution for this?

@Hr46ph I am facing he same issue? Did you found a solution for this?

Yeh its called Ciium 😉


bevy_reflect: Consistent reflect_hash and reflect_partial_eq

Objective
Fixes #6601
The issue already describes the problem in detail but here's a quick description of what we want.
A reflected (dyn Reflect) type should share the same reflect_hash and reflect_partial_eq behavior as a proxy of that type.
Additionally, reflect_partial_eq should be symmetric. In other words, a.reflect_partial_eq(b) produces the same result as b.reflect_partial_eq(a).
This means that the following should test should succeed:
let value: Box<dyn TupleStruct> = Box::new(Foo(123));
let dynamic: DynamicTupleStruct = value.clone_dynamic();

// `reflect_hash` values are the same
assert_eq!(value.reflect_hash(), dynamic.reflect_hash());

// `reflect_partial_eq` works and is symmetric
assert_eq!(Some(true), value.reflect_partial_eq(&dynamic));
assert_eq!(Some(true), dynamic.reflect_partial_eq(&value));

Solution
Both reflect_hash and reflect_partial_eq now make use of stored type information in order to perform their computations. Furthermore, they are now consistent and symmetric.
This replaces the old system of registering Hash and PartialEq like #[reflect(Hash, PartialEq)]. Although, this still exists for value types via #[reflect_value(Hash, PartialEq)], since value types base their implementation on the actual traits.
Any field that cannot be hashed or compared, may opt-out of the computation using #[reflect(skip_hash)] and #[reflect(skip_partial_eq)], respectively.
#[derive(Reflect)]
struct Foo {
  a: i32,
  // `f32` doesn't implement `Hash` so its `reflect_hash` will
  // always return `None`, causing our container to return `None`
  // unless we opt it out of the hashing computation.
  #[reflect(skip_hash)]
  b: f32,
}

#[derive(Reflect)]
struct Bar {
  id: u32,
  // We can exclude certain fields from comparison as well.
  #[reflect(skip_partial_eq)]
  _temp: u32,
}

If any field returns None during one of these operations, the entire container will return None.
reflect_partial_eq Behavior
The behavior of reflect_partial_eq is a bit more intuitive now that it is consistent between concrete and proxy types. We essentially only consider types equal if they all share the same non-skipped fields and those fields are equivalent between them.

Example Behavior
Here's an example comparing a type, Foo, to a dynamic type.

Note that we use a dynamic type here to just make demonstrating the existence and nonexistence of fields simpler. The same would be true when comparing against another concrete type.

#[derive(Reflect)]
struct Foo {
  a: u32,
  #[reflect(skip_partial_eq)]
  b: u32,
  c: u32,
}

let foo = Foo {
  a: 1,
  b: 2,
  c: 3,
};

let mut dynamic = DynamicStruct::default();

// 1.
assert_eq!(Some(false), foo.reflect_partial_eq(&dynamic));

// 2.
dynamic.insert("a", 1u32);
assert_eq!(Some(false), foo.reflect_partial_eq(&dynamic));

// 3.
dynamic.insert("c", 3u32);
assert_eq!(Some(true), foo.reflect_partial_eq(&dynamic));

// 4.
dynamic.insert("c", 3u32);
assert_eq!(Some(true), foo.reflect_partial_eq(&dynamic));

// 5.
dynamic.insert("b", 555u32);
assert_eq!(Some(true), foo.reflect_partial_eq(&dynamic));

// 6.
dynamic.insert("d", 4u32);
assert_eq!(Some(false), foo.reflect_partial_eq(&dynamic));

#[derive(Reflect)]
struct Bar {
  #[reflect(skip_partial_eq)]
  d: u32,
}

// 7.
dynamic.set_represented_type(Some(Bar::type_info()));
assert_eq!(Some(true), foo.reflect_partial_eq(&dynamic));

#[derive(Reflect)]
struct Baz {
  b: u32,
}

// 8.
dynamic.set_represented_type(Some(Baz::type_info()));
assert_eq!(Some(false), foo.reflect_partial_eq(&dynamic));

Explanation for the code above:

false: Foo requires fields a and c, but dynamic is missing both of them.
false: Foo requires fields a and c, but dynamic is missing c.
false: Foo and dynamic share the same required fields, but have different values for c.
true: Foo and dynamic share the same required fields and are all equivalent.
true: Despite the b fields not being equivalent, Foo skips it so it is not considered for comparison.
false: Foo does not contain a d field but dynamic does.
true: dynamic has become a proxy of Bar which skips d, making only fields a and c relevant for comparison.
false: dynamic has become a proxy of Baz which requires b even though Foo skips b

***Meta Types
This PR also adds the concept of "metadata" on info types. This is meant to capture various attribute ("meta") data on containers and their fields. For example, the docs attribute has been moved to these types rather than on the info type directly.
These meta types are also where we keep track of skip_hash and skip_partial_eq so they can be utilized within dynamic contexts.

Rationale
There were a few ways to accomplish this: add getters and setters to the meta fields, create separate builders for each meta type, or just make all members pub. I went with that last one as it was the simplest and the others felt like possible overkill with the data we have now. Also, there's no concern over accidental mutations since types always share their type information as a static immutable reference.
I also decided to make the constructor for this type const. This might be controversial, but my thought was that this helps force us to:

Strive to be const-ready. The main reason the info types aren't const is because TypeId and type_name are not const-stable. Stabilization is probably a ways out for them, but it's probably best we don't establish any patterns that would prevent us from easily making the switch to being const.
Store only necessary data. Since we're storing additional metadata, we might be tempted to store everything: type data registrations, custom attributes, etc. And while I think that's worth considering, there's also a concern that it creates a split between stuff stored on the type and stuff stored in the registry. Users shouldn't be able to configure the names of fields or certain other metadata at runtime. However, they should be able to register type data structs on types they don't own (whether they created the type data or not). With such a split, we would be asking users and library authors to check both the type and the registry for type data, which is prone to error.
Simplify the API. At the end of the day, this is a public interface. We should avoid complex, crate/case-specific fields and methods that make this interface more difficult to understand and use. This is another reason I went with just making the fields pub— it indicates that these fields are standalone and no additional care is needed in using them.

With all that being said, I'm definitely open to changing how meta types are constructed and what they're allowed to contain. This was all a very opinionated implementation on my part and I understand it might enforce restrictions prematurely when we could just wait until it's absolutely needed. So feel free to leave a comment telling me I'm wrong so that we can find a pattern the community can agree on.

Notes

Concrete vs Reflected
This change now means that the corresponding concrete impls may give different results than the reflected ones:

Reflect::reflect_hash = / ≠ Hash::hash
Reflect::reflect_partial_eq  = / ≠ PartialEq::eq

This could be an issue when comparing results between the concrete realm and the reflected one. However, this is likely not a major issue for the following reasons:
Hash vs reflect_hash
The general usage for hashing is to interact with maps and sets. Most users are not manually creating a hasher and calculating the u64 of a value. Because of this, they are unlikely to run into the scenario where they would be comparing the results of Hash and reflect_hash.
PartialEq vs reflect_partial_eq
This could be a potential issue for users who rely on PartialEq to establish and maintain contracts guaranteeing that two values are equal. If they then try to use reflect_partial_eq, the result may go against that supposed guarantee.
In most cases, though, the results should be the same. This is because in most cases PartialEq is derived, which means it essentially performs the same operations that reflect_partial_eq does: ensure that all fields are equal recursively.
However, if the user has a custom PartialEq implementation  or marks their fields as #[reflect(skip_partial_eq)], then the divergence is more likely.
User Responsibility
In either case, the best course of action would be for the user to decide which solution they want to use and be consistent in using it— or at least not rely on the results being identical across concrete and reflected implementations.

Transitivity
One aspect of PartialEq that reflect_partial_eq does not fully guarantee is transitivity. That is, if A == B and B == C, then A == C.
While concrete types and their proxies should respect transitivity, dynamic types (ones without a represented TypeInfo) do not.
Example
#[derive(Reflect)]
struct Foo {
  #[reflect(skip_partial_eq)]
  a: u32,
  b: u32,
}

#[derive(Reflect)]
struct Bar {
  #[reflect(skip_partial_eq)]
  c: u32,
  b: u32,
}

let foo = Foo { a: 1, b: 2 };
let bar = Bar { c: 1, b: 2 };

// `foo == bar` -> ✅
assert_eq!(Some(true), foo.reflect_partial_eq(&bar));

let mut baz = DynamicStruct::default();
baz.insert("c", 1u32);
baz.insert("b", 2u32);

// `bar == baz`  -> ✅
assert_eq!(Some(true), bar.reflect_partial_eq(&baz));

// `foo == baz` -> ❌ (not transitive)
// Not equal because `foo` doesn't contain `c`
assert_eq!(Some(false), foo.reflect_partial_eq(&baz));

// Make `baz` a proxy of `Bar`
baz.set_represented_type(Some(Bar::type_info()));

// `foo == baz` -> ✅ (transitive)
assert_eq!(Some(true), foo.reflect_partial_eq(&baz));

As you can see, comparison between concrete values and proxy values are transitive. It's when comparing against a dynamic type that transitivity starts to no longer be guaranteed.

Hashing and Equality
The docs for Hash state the following:

When implementing both Hash and Eq, it is important that the following property holds:
k1 == k2 -> hash(k1) == hash(k2)

In other words, if two keys are equal, their hashes must also be equal. HashMap and HashSet both rely on this behavior.

While the idea is that these Reflect methods uphold this property, there is a chance for this to be broken when skipping fields (see example below). This could be problematic for cases where users expect two "equal" values to result in the same hash.
Currently, we just warn against it in the documentation. But there may be other solutions.
Additionally, it's not certain whether or not this truly applies to us since reflect_partial_eq is meant to be used like PartialEq, and PartialEq cannot make these same guarantees as Eq. If anything, we would probably need something like reflect_eq to match Eq behavior.
Example
#[derive(Reflect)]
struct Foo {
    a: u32,
    #[reflect(skip_partial_eq)]
    b: u32,
}

let foo1 = Foo { a: 123, b: 456 };
let foo2 = Foo { a: 123, b: 0 };

// OK!
assert_eq!(Some(true), foo1.reflect_partial_eq(&foo2));
// PANIC!
assert_eq!(foo1.reflect_hash(), foo2.reflect_hash());

In the above case foo1 == foo2 but hash(foo1) != hash(foo2).  Again, this property might not be applicable due to the differences between PartialEq and Eq, but it should nevertheless be noted.

Open Questions

Should we make these operations opt-in only? Should we allow entire containers to opt out?
Should we return None during reflect_partial_eq if a field has differing skip configuration (i.e. type A skips field x while type B requires it)? Should we make reflect_partial_eq return a Result to allow users to branch on this versus other causes for failures?
Should we have a convenience attribute that does the same as #[reflect(skip_hash)] and #[reflect(skip_partial_eq)] combined? Such as a #[reflect(skip_equivalence)] attribute.

Future Work
There are some things we could  possibly consider adding in a future PR:

Add a reflect_eq method to mimic Eq
Improve proxy types to be more robust so we can possibly branch and reduce the number of lookups and redundant checks

Changelog
Changed

Reflect::reflect_hash and Reflect::reflect_partial_eq are now consistent between concrete types and proxies of those types (proxies are simply dynamic types like DynamicStruct that contain the TypeInfo for a concrete type )
Reflect::reflect_hash and Reflect::reflect_partial_eq no longer rely on Hash and PartialEq implementations

This also means they no longer need to be registered via #[reflect(Hash)] and #[reflect(PartialEq)] for most types, and doing so will result in a compile error
All items that derive Reflect now opt into this behavior by default

Accessing a type's docs has moved from its info type (e.g. StructInfo) to its meta type (e.g. StructMeta)

Added

Added #[reflect(skip_hash)] and #[reflect(skip_partial_eq)] attributes for controlling the implementations of Reflect::reflect_hash and Reflect::reflect_partial_eq, respectively
Added "meta types" which are accessible through a type's info type (e.g. StructInfo):

ValueMeta
TupleMeta
ArrayMeta
ListMeta
MapMeta
TupleStructMeta
StructMeta
EnumMeta
VariantMeta
FieldMeta

Migration Guide
Hash and PartialEq registrations
Registering Hash and/or PartialEq now results in a compile error. Such registrations will need to be removed.
// BEFORE
#[derive(Reflect, Hash, PartialEq, Default)]
#[reflect(Hash, PartialEq, Default)]
struct MyType(u32);

// AFTER
#[derive(Reflect, Hash, PartialEq, Default)]
#[reflect(Default)]
struct MyType(u32);

This does not apply to value types created with #[reflect_value]:
#[derive(Reflect, Hash, PartialEq, Default)]
#[reflect_value(Hash, PartialEq, Default)]
struct MyType(u32);

New Reflect::reflect_hash behavior
Reflect::reflect_hash no longer relies on a concrete Hash implementation. All types that derive Reflect come with a built-in implementation of Reflect::reflect_hash that is purely based on reflection.
If a particular field is not hashable, you will need to mark it with #[reflect(skip_hash)]:
// BEFORE
#[derive(Reflect)]
#[reflect(Hash)]
struct MyType {
  id: String,
  _temp: f32,
}

impl Hash for MyType {
  fn hash<H: Hasher>(&self, state: &mut H) {
    self.id.hash(state);
  }
}

// AFTER
#[derive(Reflect)]
struct MyType {
  id: String,
  #[reflect(skip_hash)]
  _temp: f32,
}

New Reflect::reflect_partial_eq behavior
Reflect::reflect_partial_eq no longer relies on a concrete PartialEq implementation. All types that derive Reflect come with a built-in implementation of Reflect::reflect_partial_eq that is purely based on reflection.
If a particular field is not comparable or should not be considered for comparison, you will need to mark it with #[reflect(skip_partial_eq)]:
// BEFORE
#[derive(Reflect)]
#[reflect(PartialEq)]
struct MyType {
  id: String,
  _temp: f32,
}

impl PartialEq for MyType {
  fn eq(&self, other: &Self) -> bool {
    self.id == other.id
  }
}

// AFTER
#[derive(Reflect)]
struct MyType {
  id: String,
  #[reflect(skip_partial_eq)]
  _temp: f32,
}

This also means that some types that might have been considered equal or unequal before may no longer provide the same result. This is especially true for comparison against dynamic types since they now aim to be consistent with their concrete counterparts.
docs access
Those using the documentation feature to access doc strings will now need to get it from a type's meta type rather than the info type directly:
// BEFORE

/// Some documentation...
#[derive(Reflect)]
struct MyType;

let docs = MyType::type_info().docs();
assert_eq!(Some("Some documentation..."), docs);

// AFTER

/// Some documentation...
#[derive(Reflect)]
struct MyType;

let docs = MyType::type_info().meta().docs;
assert_eq!(Some("Some documentation..."), docs);

One thing I'm getting hung up on here is that we'll no longer use Hash and PartialEq implementations on the concrete types.  The follow-on effects of this behavior you've documented are the Concrete vs Reflected Hash mismatch, possible lack of transitivity in PartialEq, and that this may break the Hash/Eq behavior.  Another effect is that we'll disregard any custom implementations of these traits for types.
I'm curious why we can't fall back to the concrete type implementation for proxies.
There's one note in #6601 about using the concrete implementations:

To do this, we can add two new TypeData structs: ReflectHash and ReflectPartialEq. Both will simply contain function pointers that can be be used to perform the concrete implementations. This data can then be retrieved from the TypeRegistry. And since getting TypeData returns an Option, the functions stored in these structs no longer need to return Option and Option like they currently do. They can simply return bool and u64.

Looking at the PR (ex: tuple_hash()), it doesn't look like this is being used.
Why did the PR move away from falling back on the concrete implementations?  How difficult would it be to use them if implemented?

I'm curious why we can't fall back to the concrete type implementation for proxies.
There's one note in #6601 about using the concrete implementations:

To do this, we can add two new TypeData structs: ReflectHash and ReflectPartialEq. Both will simply contain function pointers that can be be used to perform the concrete implementations. This data can then be retrieved from the TypeRegistry. And since getting TypeData returns an Option, the functions stored in these structs no longer need to return Option and Option like they currently do. They can simply return bool and u64.

Looking at the PR (ex: tuple_hash()), it doesn't look like this is being used.
Why did the PR move away from falling back on the concrete implementations? How difficult would it be to use them if implemented?

This is a great callout! I should have mentioned this in the PR description, but I'll mention it here instead.
The reason we can't rely on concrete implementations, even though I at one time thought we could, is that proxies are not those concrete types. And this becomes even clearer when we look at an example.
This will fail to compile:
#[derive(Reflect)]
struct Foo {
  id: usize,
  data: String
}

impl Hash for Foo {
  fn hash<H: Hasher>(&self, state: &mut H) {
    self.id.hash(state);
  }
}

let foo = Foo { id: 123, data: String::new() };
let proxy: DynamicStruct = foo.clone_dynamic();

let mut hasher = AHasher::default();

Foo::hash(&proxy, &mut hasher); // ERROR

We can't pass DynamicStruct in the &self position for Foo::hash because it isn't Foo. And if these were instead dyn Reflect objects, we'd still run into the same problem (since we'd need to cast them back to the concrete forms internally in order to make use of the function pointers).

Note: Another reason is that you can't store generic function pointers, which would make storing Hash::hash::<H> unviable.

So that's why I abandoned that original approach in the issue. Hopefully that helps. Please let me know if you need more clarification or if you have any other questions!

So I've dug pretty deeply into this.  There is nightly support for creating a fat pointer for something like dyn Hash from a pointer & the vtable (https://rust-lang.github.io/rfcs/2580-ptr-meta.html), but that's only in nightly.
From that RFC, there is a unsafe (probably cursed) method to do it in stable (https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=bbeecccc025f5a7a0ad06086678e13f3).  Using this method it's possible for us to store the vtable for dyn Hash in the type registry.
Admittedly this is unsafe and cursed and there's real support coming in nightly (whenever it gets into stable).  I just want to put this here so it's discussed.  I'll understand if this is a scary direction to go in.
use std::fmt::Debug;
use std::mem;

#[derive(Debug)]
#[repr(C)]
struct FatPtr {
    data: *mut (),
    meta: *mut (),
}

fn build_fat_ptr<T: ?Sized>(ptr: *mut (), meta: *mut ()) -> &'static T {
    let fat_ptr = FatPtr { data: ptr, meta };
    unsafe { mem::transmute_copy::<FatPtr, &T>(&fat_ptr) }
}

#[derive(Debug)]
struct DerivedDebug;

struct ImplDebug;
impl Debug for ImplDebug {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "ImplDebug (manual impl)")
    }
}

fn main() {
    assert_eq!(mem::size_of::<&dyn Debug>(), mem::size_of::<FatPtr>());

    // example using derived debug
    let m = DerivedDebug;
    let dyn_debug: &dyn Debug = &m;
    let repr = unsafe { mem::transmute_copy::<&dyn Debug, FatPtr>(&dyn_debug) };
    // rebuild the &dyn Debug from `mut *` and the vtable
    let dyn_debug: &dyn Debug = build_fat_ptr(repr.data, repr.meta);
    println!("m {:?}, dyn_debug {:?}", m, dyn_debug);

    // Do the same thing with a manually implemented debug
    let m = ImplDebug;
    let dyn_debug: &dyn Debug = &m;
    let repr = unsafe { mem::transmute_copy::<&dyn Debug, FatPtr>(&dyn_debug) };
    // rebuild the &dyn Debug from `mut *` and the vtable
    let dyn_debug: &dyn Debug = build_fat_ptr(repr.data, repr.meta);
    println!("m {:?}, dyn_debug {:?}", m, dyn_debug);
}

So I've dug pretty deeply into this. There is nightly support for creating a fat pointer for something like dyn Hash from a pointer & the vtable (https://rust-lang.github.io/rfcs/2580-ptr-meta.html), but that's only in nightly.
From that RFC, there is a unsafe (probably cursed) method to do it in stable (https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=bbeecccc025f5a7a0ad06086678e13f3). Using this method it's possible for us to store the vtable for dyn Hash in the type registry.
Admittedly this is unsafe and cursed and there's real support coming in nightly (whenever it gets into stable). I just want to put this here so it's discussed. I'll understand if this is a scary direction to go in.

Yeah the unsafe stuff is a little out of my comfort zone haha. However, this still would be an issue because I'm pretty sure the vtable means nothing to a type that isn't the type that vtable expects, right?
And that's the bigger issue with trying to store a function pointer to the conrete impl: dynamic types are not guaranteed to have the same layout as their concrete counterparts.

I’m also a little uncomfortable with unsafe in rust, which is kind of silly with the number of years I’ve been writing C & assembly.

dynamic types are not guaranteed to have the same layout as their concrete counterparts.

Understood. My initial thought was for those dynamic types that are proxies, we reflect to the concrete type as dyn Hash and use the per-type impl. For those pure dynamic types without concrete types, we use the pure dynamic implementations you have here.
There are performance & caching things to sort out, but it’s a pattern for ensuring reflection leverages user impls.
That said, I still don’t know how comfortable the bevy project is with adding unsafes in cases like this.
I can take some time to flesh out an example to make it easier to see how scary things get. Something that shows how we’d go from MyStruct to &dyn Reflect to DynamicMap to MyStruct as dyn Hash.

Understood. My initial thought was for those dynamic types that are proxies, we reflect to the concrete type as dyn Hash and use the per-type impl. For those pure dynamic types without concrete types, we use the pure dynamic implementations you have here.

Oh are you suggesting we construct the concrete types using FromReflect whenever we need to create a hash and stuff like that? I don't think that'll be much faster tbh since both this PR and using FromReflect need to recurse down the structure. And there's no other way to construct the concrete type from a dynamic one.

There are performance & caching things to sort out, but it’s a pattern for ensuring reflection leverages user impls.

Yeah, that makes sense. Though, I'm wondering how much users really need to rely on these custom impls. The skip_hash and skip_partial_eq attributes should help most cases. For fully custom implementations, we'd need a clever way of allowing users to define a custom reflect_hash function (likely via attribute) while still supporting dynamic proxies. And ideally users wouldn't need to worry about handling all the edge cases.

That said, I still don’t know how comfortable the bevy project is with adding unsafes in cases like this. (edit) And probably more importantly, is this level of complexity really even worth it. Perhaps this can wait until someone encounters a real case where they need the type impl to be executed before doing the complex, unsafe thing.

We should probably avoid as much unsafe as we reasonably can. That being said, I don't think Bevy is uncomfortable adding unsafe code (the entire ECS relies on it). Reflection doesn't have much, but we could consider it if it solves a real problem (#6042, for example, uses unsafe code).

I can take some time to flesh out an example to make it easier to see how scary things get. Something that shows how we’d go from MyStruct to &dyn Reflect to DynamicStruct to MyStruct as dyn Hash.

Sounds good! I think it will also be more helpful (for me anyways) to see it using Reflect since I'm still having trouble understanding how it's supposed to work.
Also, keep in mind that if we did decide to go the unsafe route for Hash, we should probably do the same for PartialEq (and maybe Debug eventually).

For now my approach of storing the vtable for dyn Hash for each registered type will not work.  I'm unable to find a way to get the vtable for dyn Hash as I can't make it into an object, or a boxed object.
Until https://doc.rust-lang.org/std/ptr/trait.Pointee.html#associatedtype.Metadata becomes stable, we'll have to stick with dynamic-only implementations for Hash and PartialEq.
As MrGVSV already explained, it's unlikely the dynamic-only implementations for these traits will cause any problem for users.

Update, it is possible for us to save off Hash and PartialEq functions during type registration.  It doesn't require anything unsafe either; we literally just save the function pointer for each type, and DefaultHasher, and any other hashers we may care about.
By doing this we are able to use the implementations on the concrete types.
use std::collections::hash_map::DefaultHasher;
use std::hash::{Hash, Hasher};

#[derive(Eq, PartialEq)]
struct Location {
    x: u32,
    y: u32,
}

impl Hash for Location {
    fn hash<H>(&self, _state: &mut H)
       where H: Hasher
    {
        println!("ran hash function")
    }
}

// fake "registration" function that really just returns the function pointer for <T as Hash>::hash
pub fn register<T: std::hash::Hash + 'static, H: std::hash::Hasher + 'static>() -> impl Fn(&T, &mut H) {
    T::hash::<H>
}

pub fn main() {
    let loc = Location { x: 1_u32, y: 1_32 };
    let hash_func = register::<Location, DefaultHasher>();
    let mut hasher = DefaultHasher::new();
    hash_func(&loc, &mut hasher);
    println!("Hash result {:x}", hasher.finish())
}

Playground: https://godbolt.org/z/7bYPn9b9a


Update logout flow for when PIN is set/unset

IMPORTANT: Where possible all PRs must be linked to a Github issue
Fixes #1883
Checklist

[x] I have written Unit tests for any new feature(s) and edge cases for bug fixes
[x] I have added any strings visible on UI components to the strings.xml file
[ ] I have updated the  CHANGELOG.md file for any notable changes to the codebase
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the project's style guide
[x] I have built and run the fhircore app to verify my change fixes the issue and/or does not break the app

QA/Acceptance criteria checks based on the implementation:

[ ] Whether you exit the app (or remove it from recents), OR you log out manually, you'd have to log back in
[ ] Logging in is either via PIN if configured OR via username + password (regardless of how you exited the app)
[ ] The PIN Activity/Screen is only shown when the PIN is configured as enabled and a PIN is set
[ ] On login with username and password the access token is only retrieved from the Keycloak endpoint if there's no active session (available access token) otherwise the user is logged in locally
[ ] The local and Keycloak session is only cleared if you log out while the app/device is online


Safari: ArrayBuffers are sometimes not instanceof ArrayBuffer

Summary
I'm storing and retrieving ArrayBuffer objects from IndexedDB, and I noticed that in my test environment, the ArrayBuffer objects are not always instanceof ArrayBuffer in Safari. As a result, the Buffer package throws the following exception:

TypeError: First argument must be a string, Buffer, ArrayBuffer, Array,or array-like object.

This behavior does not occur in any other web browser.
Detailed Explanation
The test environment is that of the Karma test runner, which uses an iframe to isolate test code from the runner's code. As a result, the ArrayBuffer constructor object in the code's context is not referentially equivalent to the ArrayBuffer constructor object in the main window context. This is similar to the age-old Array problem, where arrays from other contexts are not necessarily instanceof Array, necessitating the use of Array.isArray.
Safari chooses the main window's constructor for the ArrayBuffer object retrieved from IndexedDB, so it is not an instanceof ArrayBuffer in the test code's context.
Here's a screenshot, just so you know I'm not totally mad here. This is evaluated at a breakpoint in the stack frame that throws the TypeError:

I do not have a good solution to the problem without resorting to some hack (e.g., is the byteLength property present?).

Interesting... instanceof is really quite terrible, isn't it?
Please see this PR with a potential solution: https://github.com/feross/buffer/pull/170 Let me know if that works for you. If so, I'll merge it and do a new release.

Interesting... instanceof is really quite terrible, isn't it?

I want to agree with you, but I can't really blame JavaScript on this one! instanceof is only intended to check if the object was constructed by a particular function, which is totally reasonable. I'd blame the unnecessarily complex native interface between JavaScript code and the web browser, which makes it possible to have multiple constructors for the same type of object! Really, browsers should have a special type of handoff between contexts that appropriately adjusts native objects like this one to use the appropriate constructor object. (Sharing constructors is a no-go for security reasons.)
With that said, it seems like the other browsers do not have this issue; perhaps they already use the appropriate constructor object from the context in which programs invoke native APIs that create ArrayBuffer objects. (That sentence is a mouthful...)

Please see this PR with a potential solution: #170 Let me know if that works for you.

I just ran my test suite against it, and it appears to work wonderfully!
Safari 10.1.2 (Mac OS X 10.12.6): Executed 667 of 667 SUCCESS (24.15 secs / 20.861 secs)

Thanks for fixing this!

Released as 5.0.7

Hi!
I found this bug report while investigating a similar issue (not using the buffer library) and wanted to add two things:

Thank you very much for saving me a lot of time!
I've filed an issue on Webkit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=185906, so that it might be fixed some day.

Best regards,

@maximerety Thanks for sharing. Hope it gets fixed one day so we can remove this hack!

@maximerety Thanks for reminding me of this issue! I just added a minimal complete test case to that bug report.


RCTAEPCore is undefined

Expected Behaviour
Both Android and IOS device run without error
Actual Behaviour
IOS device runs with error saying that RCTAEPCore is undefined.
Reproduce Scenario (including but not limited to)
Run React Native in IOS device
Steps to Reproduce
react-native: 0.72.6
@adobe/react-native-aepcore: ^5.0.0
Yarn/pnpm
Followed all the steps for IOS and Android documented on the readme.
Platform and Version
Mac M2
Sample Code that illustrates the problem
MobileCore.collectPii({ myPii: 'data' });
Logs taken while reproducing problem
 TypeError: Cannot read property 'collectPii' of null
This error is located at:
    in App
    in RCTView (created by View)
    in View (created by AppContainer)
    in RCTView (created by View)
    in View (created by AppContainer)
    in AppContainer

I wonder if there is any configuration for IOS missing on the readme. Thank you very much for your help!

You followed this
https://github.com/adobe/aepsdk-react-native
(https://github.com/adobe/aepsdk-react-native#ios-development)
and
https://github.com/adobe/aepsdk-react-native/tree/main/packages/core
Have you
import { MobileCore } from '@adobe/react-native-aepcore' ?
https://github.com/adobe/aepsdk-react-native/tree/main/packages/core#importing-the-mobile-core-package

Hi. Yes, I did follow the instructions in the links you sent - added the configurations in both AppDelegate.h and AppDelegate.mm and imported the package the way as you mentioned. I got the error on both M1 and M2 Mac laptops. Meanwhile, I am able to run the sample app without any error.

You need to add import { MobileCore } from '@adobe/react-native-aepcore'  to your React Native side of the code, not on the Native platform code.
Similar to the sample app here - https://github.com/adobe/aepsdk-react-native/blob/main/apps/AEPSampleApp/extensions/CoreView.tsx#L15
Did you do that?

Yes, I imported the package in a tsx view file, just like the sample app.

Is it possible to share your sample project, we can take a look?

Sure, that would be really helpful. I created a new repo using react-native-cli (https://github.com/Issactoto/adobe-analytics-test/tree/main). I just changed all the files accordingly as mentioned above and the function is used in App.tsx. I am using Yarn and IOS 17.2 for your information. Thanks!

@Issactoto
When I tried to build the repo you provided in Xcode, I saw errors which can be resolved with these two known workaround:
https://github.com/adobe/aepsdk-react-native/issues/247#issuecomment-1642944117
https://github.com/adobe/aepsdk-react-native/issues/263#issuecomment-1498393770
 post_install do |installer|
    # https://github.com/facebook/react-native/blob/main/packages/react-native/scripts/react_native_pods.rb#L197-L202
    react_native_post_install(
      installer,
      config[:reactNativePath],
      :mac_catalyst_enabled => false
    )
    installer.pods_project.targets.each do |t|
      if t.name.start_with?("AEP")
        t.build_configurations.each do |bc|
            bc.build_settings['OTHER_SWIFT_FLAGS'] = '$(inherited) -no-verify-emitted-module-interface'
        end
      end
    end
  end
end

Please give them a try and see if you can build.
These are for iOS.
Did you have the issue on Android?

Thank you very much for the reply and solution. It works for the new repo I shared earlier. However, I am actually using a monorepo for the project I am developing and I am still facing the same error. Unfortunately, I am unable to share the code here. Do you happen to know if there are any specific changes that need to be made in this context? Additionally, I want to note that I don't experience any problems when running the code on Android.

For the original log, we thought it is possible due to the import statement in the react native side.
import { MobileCore } from '@adobe/react-native-aepcore'
This error is located at:
    in App
    in RCTView (created by View)
    in View (created by AppContainer)
    in RCTView (created by View)
    in View (created by AppContainer)
    in AppContainer

But it seems like you have that correctly in the sample app you shared.
If using the same react native code and Android platform is working, then the issue is on the iOS side.
Have you tried to run the iOS app from the Xcode and see if there is any other error shown on the Xcode native platform?  Or you can monitor the logs in the Xcode debug windows.

Yes, I think there were some errors on the Xcode native platform. I got it sorted now, thank you very much for your help!


TODO

- Natural replace Done

Currently, the selection is combined into a single string before translation, but if you translate one line at a time, the "output/replace" should be natural. However, if multiple lines make one long sentence, the translation may be unnatural. If there is a blank line in the selection, I can use it as a separator, but otherwise I have to separate lines depends on the grammar of each language, which is difficult for me.

I am a native Japanese speaker and know a little English, so if the original language is either of these I would be able to determine if the end of a line is the end of a sentence and properly separate the sentences.
To support other languages, I need the cooperation of native speakers of those languages.
Also, to use this feature, the source option of the command must be used to specify the language before translation.

 If this could be separated, it would be possible to select and translate only a portion of a multi-line comment. This can be accomplished with rectangular selection as it is now, but it would be easier.


getAll is not generic

Hi,
I am using this library in a TypeScript-heavy project and I noticed that the getAll function does not properly infer the generic type of the database entity. The properties still exist in the object, but TypeScript doesn't know about it so it can't auto-complete the properties or provide any type checking for them.
Screenshot:

Here is a CodeSandbox which should highlight the issue:
https://codesandbox.io/s/mswjs-getall-typescript-error-1cde3?file=/src/App.tsx

Opened a PR (#75) to fix the TypeScript definition for this function.

Hey, @camchenry. Thank you for raising this and preparing a pull request! I'll review it and let's have these typings improved.


Move initial search initialization into a web worker so as not to block UI on app load

Hey @etown is this resolved?

Resolved


v3.0.1 cherry-pick

[x] Simon Behar: fix: Switch InsecureSkipVerify to true (#5575) 4e450e250
[x] BOOK: fix(controller): clean up before insert into argo_archived_workflows_labels (#5568) ed54f158d
[ ] Yuan Tang: fix: Remove invalid label value for last hit timestamp from caches (#5528) 2b3655ecb
[x] Alex Collins: fix(executor): GODEBUG=x509ignoreCN=0 (#5562) 2ba0a4369
[ ] Alex Collins: docs: Updated README.md (#5560) 17ff2c17c
[ ] Kishore Chitrapu: docs: added Intralinks (#5561) 3df62791d
[ ] Simon Behar: fix: Build static files in engineering builds (#5559) 3c3754f98
[ ] BOOK: fix(cli): exit when calling subcommand node without args (#5556) 23ccd9cf3
[x] Tim Collins: fix: Reference new argo-workflows url in in-app links (#5553) aa0494859
[ ] Iven: docs: Add Zhihu as user (#5555) 26ca3fab9
[x] Alex Collins: fix(server): Disable CN check (Go 15 does not support). Fixes #5539 (#5550) 20f00470e
[ ] Riccardo Piccoli: fix: allow mountPaths with traling slash (#5521) 872897ff9
[ ] Shoubhik Bose: fix: certs in non-root (#5476) fee4d0613
[ ] Shoubhik Bose: fix: Run controller as un-privileged (#5460) c96a3257a

I've remove Shuoubhik's PRs as they risk introducing new problems.
I've added 20f0047, but I think you might end up reverting.

I've remove Shuoubhik's PRs as they risk introducing new problems.

:+1: we can test those and if all good include them in v3.0.2

I think we don't need them.

Released


data file

what does the notes in data file contains ?
how can I open it ?

That is a pickle dump of the notes used to train the model. You can load it using the pickle library (https://github.com/Skuldur/Classical-Piano-Composer/blob/master/predict.py#L16)


[AIRFLOW-2471] Fix HiveCliHook.load_df to use unused parameters

Make sure you have checked all steps below.
JIRA

[x] My PR addresses the following Airflow JIRA issues and references them in the PR title. For example, "[AIRFLOW-XXX] My Airflow PR"

https://issues.apache.org/jira/browse/AIRFLOW-2471
In case you are fixing a typo in the documentation you can prepend your commit with [AIRFLOW-XXX], code changes always need a JIRA issue.

Description

[x] Here are some details about my PR, including screenshots of any UI changes:

This PR fixes HiveCliHook.load_df to pass
load_file the parameter called create and
recreate, which are currently ignored.
Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:

tests.hooks.test_hive_hook:TestHiveCliHook.test_load_df_with_optional_parameters
Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[x] In case of new functionality, my PR adds documentation that describes how to use it.

When adding new operators/hooks/sensors, the autoclass documentation generation needs to be added.

Code Quality

[x] Passes git diff upstream/master -u -- "*.py" | flake8 --diff

@sekikn Do we really need this? Can't we just pass these parameters as **kwargs should handle it?

Thanks for the review @kaxil, updated the PR.

Codecov Report

Merging #3390 into master will increase coverage by 0.2%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master    #3390     +/-   ##
=========================================
+ Coverage   76.28%   76.49%   +0.2%
=========================================
  Files         203      203
  Lines       15015    15015
=========================================
+ Hits        11454    11485     +31
+ Misses       3561     3530     -31

Impacted Files
Coverage Δ

airflow/hooks/hive_hooks.py
62.32% <100%> (ø)
:arrow_up:

airflow/models.py
87.03% <0%> (+0.08%)
:arrow_up:

airflow/jobs.py
82.8% <0%> (+1.15%)
:arrow_up:

airflow/utils/dag_processing.py
88.88% <0%> (+1.28%)
:arrow_up:

airflow/executors/__init__.py
63.46% <0%> (+3.84%)
:arrow_up:

airflow/executors/sequential_executor.py
100% <0%> (+50%)
:arrow_up:

Continue to review full report at Codecov.

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


More build tweaks

Hi @cclarkson, you're going to love me... I just merged some more tweaks to the build setup, you'll need to rebase your master and any working branches on upstream/master. The rebase should be straightforward, i.e., no merge conflicts, but let me know if you do hit any conflicts and I can advise.

 Sometimes when rebasing you may encounter a
conflict, in which case you'd need to do something slightly different, but
we can cross that bridge if/when we come to it. If you don't know the right
git magic you can end up literally going round and round in git hell
circles, which is what happened to me first time, until I was saved by the
Lord of Git (@benjeffery).

Reply to this email directly, view it on GitHub
https://github.com/malariagen/agam-vgsc-report/pull/21#issuecomment-282101225,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq8Qmq5-qfrU6t0HgAGvdTxfYupr9ASks5rfeNxgaJpZM4MKAUF
.

--
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health http://cggh.org
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Email<EMAIL_ADDRESS>Web: http://purl.org/net/aliman
Twitter: https://twitter.com/alimanfoo
Tel: +44 (0)1865 287721


TagSet popover content is overlapping another TagSet values

What package(s) are you using?
"@carbon/ibm-products": "2.0.0-rc.2"
"@carbon/react": "^1.16.0",
Carbon v11
Detailed description
When we clicking on TagSet component, the popover container of it overlaps next TagSet Component. And it just overflow its parent component. In Prev version, tooltip component was implemented, which was not overlapping another TagSet.

Is this issue related to a specific component?
Yes TagSet Component of "@carbon/ibm-products": "2.0.0-rc.2"

What did you expect to happen? What happened instead? What would you like to
see changed?
Popover container of a TagSet shouldn't overlap another tagset

What browser are you working in?
All Browser

What version of the @carbon/ibm-products (or @carbon/ibm-cloud-cognitive)
package are you using?
"@carbon/ibm-products": "2.0.0-rc.2"

Please create a reduced test case in CodeSandbox
https://codesandbox.io/s/nostalgic-cherry-ygp2bu?file=/src/App.js

Screenshots or code
Notes

This appears to be the same issue. Looks like a PR is already opened to address this. 🤞
https://github.com/carbon-design-system/carbon/issues/12142


Conditional fields lose their value when not present

Describe the bug and the expected behavior
If an element disappears from the form it's value is then wiped from the form.value.
I'd built quite a deeply nested tab-based form and discovered that when React removes an element from the DOM then conform also removes that value from form.value. I'd expect the data to stay as it was in the last state before the element was removed from the DOM.
Conform version
v1.0.1
Steps to Reproduce the Bug or Issue

Go to the sandbox
Change the dropdown to a different value
See that the bike or car object is removed from the form.value

For the sake of this demo I've used a select but this was initially discovered when I was using tabs
What browsers are you seeing the problem on?
Chrome, Firefox, Microsoft Edge, Safari, Others
Screenshots or Videos
No response
Additional context
No response

Conform does not keep any value of your form. What you get from Conform is just a value synced with the FormData API. If you want to persist the value, you need to eithe make the input visually hidden or render a hidden input yourself.
The DOM is the source of truth of your formdata as that's what will be sent to the server regardless you are using Remix route action or NextJS server action. It would be bad if a library tells your the value exists, but it is not actually sent out to the server :)


Face-api with another HTML5 video element

Hi,
I am trying to implement face recognition in an electron app.
I am using tfjs and node-cpu js in one of the browser window for face detection. The face detection window is hidden.
In another browser window, I am playing 4k video in HTML5 video element.
The problem is, the 4k video drop frames and choppy. But if I stop the face detection browser window, the video plays smooth.
The coding is done on Jetson nano 4gb development kit using vs code, electron 13, ubuntu 18.04 os.
I am unable to npm install node-gpu of tensorflow library.
I have tried various chrome switches as well as chromium ffmpeg codec updates but none has worked.
Any pointer to how to optimise face api or resolve the drop frames issue would be appreciated.
Thanks
Rex

javascript by definition is single-threaded and while face-api is performing processing, other tasks will wait - so your video appears choppy. only solution is to run intensive tasks in a separate web worker thread
but here is what i don't understand - you talk about detection in browser while using node-cpu - which is it? is it nodejs solution or browser solution?
anyhow, face-api is not compatible of running in a web worker as it uses DOM elements and rewrite to make it compatible is outside of my scope (library is in maintenance). you may want to check my human library which CAN run in web workers.

Hi vladmandic
thanks for your prompt reply. much appreciate.
I have modified my question above with more details of what i am trying achieve.
any guidance would be appreciated.
thanks
rex

so (electron or not) detection workflow happens in the browser - in that case, tfjs-node is irrelevant, that is only for nodejs workflows. and in browser, you can use tfjs-backend-cpu (which is included in main tfjs) or tfjs-backend-wasm or tfjs-backend-webgl (which are addons on top of main tfjs bundle)
wasm is again x86 only, so that wont work. and raspberry pi doesnt have a real gpu, so performance of webgl is questionable (but worth a try).
now, if it were me, i'd change the workflow completely - instead of two browser windows, i'd change it to main window capturing webcam and extracting imagedata from it, send it to nodejs process which runs faceapi to detect it and send results back to main window so it can do whatever it wants now
why? because there is tfjs-node compiled for ARM, it explicitly shipped as part of tfjs-node 3.8.0

hi vladmandic
thanks for the clarification.
i am using visual studio code and when i execute following npm command:
npm install @tensorflow/tfjs-node
i get error : Unsupported system: cpu-linux-arm64
all the files which are downloaded are automatically removed by the process so if i do following;
npm rebuild @tensorflow/tfjs-node --build-from-source
it doesn't help. i did research but could not find a way to resolve this.
so where do i find tfjs-node package for ARM architecture?
thanks
rex

i did say tfjs-node version 3.8.0 had arm binaries, not every version does:
pi@pi:~/dev $ uname -a
Linux pi 5.10.17-v7l+ #1421 SMP Thu May 27 14:00:13 BST 2021 armv7l GNU/Linux
pi@pi:~/dev $ npm install<EMAIL_ADDRESS>added 136 packages, and audited 137 packages in 2m
found 0 vulnerabilities


Close threads on exec()

I'm realizing this is a bug that we never addressed in NaCl-Lind which is incorrect, we should do this correctly here. The spec for exec says that all threads should be terminated on exec: https://stackoverflow.com/questions/36588387/what-happens-to-threads-when-exec-is-called
This issue is closely related to the issues with exit() we've been talking about here: https://github.com/Lind-Project/RawPOSIX/issues/50

Yeah, this is also an existing bug on exit syscall in lind-wasm that threads aren not terminated when when the main process exit. I wonder what are reliable ways to forcely terminate a running thread? Like pthread_cancel?

We were handling this using pthread_cancel in lind-nacl, but it was always sort of a workaround since cancelling threads is pretty scary.
I talk a bit about a potential solution here: https://github.com/Lind-Project/RawPOSIX/issues/50#issuecomment-2462589581


:osx support in Podfile?

Can we have osx support?

It should be support osx, however I never test it. You are welcome to test osx support and make changes on podfile.


undo regression in pre-2.0 pandoc support

As mentioned in #146, there are a lot of earlier versions of pandoc out there (e.g. the version on Travis is 1.12 AFAIK). This PR adds support back pre-2.0 pandoc support that was eliminated in https://github.com/mpastell/Weave.jl/commit/4cd0b92792e219cb77a42d1a74000234f00b5880.

Coverage decreased (-0.2%) to 87.115% when pulling 1b7fcad42c974921263b844067274921f2ddd689 on tlnagy:tn/unbreak-pandoc-pre2.0-support into bf57bf8a0717b035afeb030799beb763113a2c2f on mpastell:master.

Bump @mpastell

Thanks and sorry for leaving this hanging for so long. There are other changes (unfortunately I haven't kept a log of problems I've run into) in pandoc 2.0, at least the same change should apply also to the html output.


Group messages

When i do command without "/" bot executes the command in private message, but in group chat bot executes the command only with "/" in the beginning of the message. Adding the "/" at the beginning of the message by "/" + update.message.text does not help. What to do?

That's because by default a bot is in privacy mode. See here


Hero image on postlight.com/insights pages

Expected Behavior
The hero image should show up in the reader view.
Current Behavior
The hero image does not show up.
Steps to Reproduce

Go to this page https://postlight.com/insights/reintroducing-postlight-reader
Enable the reader to view
Notice the hero image is not shown

Detailed Description
The hero images should appear in the reader view.
Possible Solution
Enable the hero image in the reader view.

I've looked into this a bit. Here's an update in case anyone's following along.
The parser does see the hero images on Insights and it emits it to the reader as lead_image_url. The reader, however, doesn't make use of lead_image_url so my first thought was to just implement it somewhere in the ArticleHeader. I've got a working version of this locally. Might could use some buy-in/tweaking from product or design.
Another thing I want to look into, though, is if the hero image should get picked up with the images in the article's content and displayed that way. With my local code, I hopped over to a few other news sites to make sure I wasn't causing any new headaches. In some cases, the lead image was getting duplicated: once in the header and once in the content. So it seems that the parser sometimes sees an image as both a lead image and as included in the body. I want to understand this better because it may lead to an easier fix in the parser that doesn't involve markup changes to the reader.

Ok yeah, found a cleaner fix, I think - adjusting the selectors for Postlight.com's custom extractor. PR coming shortly.

Awesome! Thank you for investigating!


Documentation

Could you please put up a little documentation and usage examples for the functions mentioned in endpoints.py? I want to start from a website and recursively get the links of other domains connected to it, along with the number of redirects. A clear documentation would be welcome.

Hey @AvijitGhosh82 —thanks for checking out Pyscape! A few places to start:

Moz documentation for that API: http://moz.com/help/guides/moz-api/mozscape/api-reference/link-metrics
The way the CLI calls batch_url_metrics()
The comments in endpoints.py that define what the function expects to see

The Moz API is very frustrating and difficult to understand. I designed the library to return reasonable info based on what most people would want to see. You might just try to call the endpoint function and see what it returns. The "params" object passed to the endpoint is where you control what the API will return. If you don't specify an object, a default is created which will return something that usually meets expectations.
Unfortunately I haven't touched this library in a year or so now and it's not a priority to invest in documentation for it.


Ratelimit configuration: extract multiple headers and send a tuple of descriptors

Hi,
I am looking to extract values from multiple headers and send it as a tuple of descriptors to the rate limit service,  but I only seem to be able to use request_headers once; I have tried both
rate_limits:
- actions:
 - {request_headers: {"header_name": "plan","descriptor_key": "plan"}}
- actions:
 - {request_headers: {"header_name": "clientId","descriptor_key": "clientId"}}

or
rate_limits:
- actions:
 - {request_headers: {"header_name": "plan","descriptor_key": "plan"}}
 - {request_headers: {"header_name": "clientId","descriptor_key": "clientId"}}

With either configuration, I only see one of the descriptor_key in the ratelimit service.
Thanks,
Brent

@qbrent I am searching for a solution for very similar requirements. Did you find a solution?


Update network client name to Lotus from Bitcoin ABC

As per title

Not "lotusd" ?

Not "lotusd" ?

Debatable. It wasn't bitcoind before.

Debatable. It wasn't bitcoind before.

It was Bitcoin ABC, which used to be the client name for Bitcoin Cash. Having a distinct name allows others to have their own node implementation.
lotusd makes sense, as that's the name of the repo.


Add example for swift_grpc_library

This was mostly copied from rules_swift, witthout the
@com_google_protobuf dependency.
Signed-off-by: Thi Doãn<EMAIL_ADDRESS>

To keep the number of CI jobs down, can this be another top-level target inside of examples/integration?

I wasn’t awake yet, you already did that. Thanks!


Example of optional argument

Do we have an example of an optional argument?

What do you mean by optional argument?

Sorry did not explain well.
I mean in Excel you have a UDF with some arguments a, b, c.
I want argument c to be optional, so when I don't specify anything in XL it called into C.

Excel UDFs do not have default arguments. If an int, number, or string is missing in the call from Excel you will see 0, 0, or "", respectively. If the argument is an LPOPER and is not specified in the call from Excel you will get an OPER of type xltypeMissing. Up to you to figure out what default to supply.
(Thought you might have see the default arguments from the old version of xll. I will eventually fold those in.)

P.S. If the type is XLL_FP, then you cannot leave it missing.


Pasting causes indentation

Whenever I paste one or multiple lines while using fstar-mode (through the fstar-layer), that line (or lines) get indented. This is mostly deterministic, but in rare cases, indentation of copied code stays intact and in other cases, all indentation is preserved (which I would consider expected behaviour). I am not very familiar with the internal workings of emacs (and thus also spacemacs) and have thus not done much debugging. I'd be happy to investigate, though, if you have any pointers.

OK, reproduced. Thanks for the report; I'll look into it.

Can you try adding (add-to-list 'spacemacs-indent-sensitive-modes 'fstar-mode) to your .spacemacs somewhere? It should fix it.

That somewhere should be in dotspacemacs/user-config. Confirmed that it fixes it.

FTR, here's how I debugged this: I got a repro, then I pressed C-h k C-y to see what command pasting ran. Then I looked at the docs and saw that it was "advised" (meaning that extra code had been added to run around it), because it said :around advice: ‘ad-Advice-yank’. I clicked on that and saw this:
Around-advice ‘yank-indent’:
If current mode is not one of spacemacs-indent-sensitive-modes
 indent yanked text (with universal arg don’t indent).

Then I looked at the sources and found the original code and convinced myself that adding to indent-sensitive-modes was indeed the best solution.
Hope this makes the process more transparent :)

It seems to fix it for pasting. As the behaviour has been somewhat non-deterministic in the past, I'll keep an eye on it in the next few days.
However, it still indents whenever I move a line via the dotspacemacs-visual-line-move-text t. Its a really minor issue which I thought was related.

Thanks a lot! I'll try to debug that "moving text" issue myself then :-)

Will look into that one too.
Amusingly, reading through that code revealed a bug :) https://github.com/syl20bnr/spacemacs/pull/1485

I'll need your help to debug the second one — J and K seems to invoke Evil macros, and I have no idea how these work, unfortunately

https://github.com/syl20bnr/spacemacs/commit/ec35ede5b607b3f22332208e2e70806502999efd
No idea why these macros do the things they do :)

Sounds like some evil behaviour in spacemacs ;-)
I can live with it. The copy-pasting behaviour was much more annoying.

Closing this, since it's a generic spacemacs issue.  Feel free to reopen if you think there's something more I can do :)


Override schacHomeOrganization based on e-mail domain

This is a feature request as an addition on 'use_deny_allow_list'.
If the list is used, each allowed e-mail domains should have a configurable schacHomeOrganization. This should override the value provisioned during sign-up.

https://github.com/OpenConext/OpenConext-myconext/commit/26b76617059ac547580c88f079a0e7142adca6a0
Do note that the format of the feature.use_deny_allow_list.allow_location file has changed. See https://github.com/OpenConext/OpenConext-myconext/blob/master/myconext-server/src/main/resources/deny-allow/allowed.json for an example


Selecting Chart / Table radio buttons changes daily deaths to 14

To reproduce, do as follows:

Click Table radio button
Click Chart radio button
Daily deaths value changes to 14

issue solved


PolicyBased link for PaloAlto invalid

The link is invalid and forwards to the "main" community site, instead of the instructions

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

ID: 779fbece-f67b-28ef-143e-f58ecfa29b1d
Version Independent ID: fe532684-022f-9006-9179-c534fd923171
Content: About VPN devices for cross-premises Azure connections
Content Source: articles/vpn-gateway/vpn-gateway-about-vpn-devices.md
Service: vpn-gateway
GitHub Login: @yushwang
Microsoft Alias: yushwang

@MichelZ Thanks for the feedback! i have confirmed that the PolicyBased link for PaloAlto is no longer correct.
I have assigned the issue to the content author to evaluate and update as appropriate.

@MichelZ Very sorry for the long radio silence - unfortunately, we still could not get an updated link from Palo Alto. I've removed the broken link, but currently no other instruction page we can use for now. We are working on that.
#please-close

we still looking for proper doc...


uv fails to install pytorch3d, while pip succedes

I'm trying to install pytorch3d on Mac, following these instructions.
I have created an environment and already installed torch:
uv venv p3d -p 3.10 --seed
uv pip install torch torchvision torchaudio

I'm running this command:
MACOSX_DEPLOYMENT_TARGET=10.14 CC=clang CXX=clang++ uv pip install "git+https://github.com/facebookresearch/pytorch3d.git" --verbose

and get the following:
DEBUG uv 0.2.36 (Homebrew 2024-08-13)
DEBUG Searching for Python interpreter in system path
DEBUG Found `cpython-3.10.14-macos-aarch64-none` at `/Users/rafailf/Documents/projects/envs/p3d/bin/python3` (active virtual environment)
DEBUG Using Python 3.10.14 environment at p3d/bin/python3
DEBUG Acquired lock for `p3d`
DEBUG At least one requirement is not satisfied: git+https://github.com/facebookresearch/pytorch3d.git
DEBUG Using request timeout of 30s
DEBUG Fetching source distribution from Git: https://github.com/facebookresearch/pytorch3d.git
DEBUG Acquired lock for `https://github.com/facebookresearch/pytorch3d`
DEBUG Updating git source `Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("github.com")), port: None, path: "/facebookresearch/pytorch3d.git", query: None, fragment: None }`
DEBUG Attempting GitHub fast path for: https://api.github.com/repos/facebookresearch/pytorch3d/commits/HEAD
DEBUG Performing a Git fetch for: https://github.com/facebookresearch/pytorch3d.git
DEBUG Acquired lock for `/Users/rafailf/Library/Caches/uv/built-wheels-v3/git/0c0d4c037a64738f/38afdcfc6826bb41`
DEBUG Preparing metadata for: git+https://github.com/facebookresearch/pytorch3d.git
DEBUG No static `PKG-INFO` available for: git+https://github.com/facebookresearch/pytorch3d.git (MissingPkgInfo)
DEBUG No static `pyproject.toml` available for: git+https://github.com/facebookresearch/pytorch3d.git (MissingPyprojectToml)
INFO Ignoring empty directory
DEBUG Solving with installed Python version: 3.10.14
DEBUG Adding direct dependency: setuptools>=40.8.0
DEBUG Found fresh response for: https://pypi.org/simple/setuptools/
DEBUG Searching for a compatible version of setuptools (>=40.8.0)
DEBUG Selecting: setuptools==72.2.0 [compatible] (setuptools-72.2.0-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/6e/ec/06715d912351edc453e37f93f3fc80dcffd5ca0e70386c87529aca296f05/setuptools-72.2.0-py3-none-any.whl.metadata
DEBUG Tried 1 versions: setuptools 1
DEBUG Split specific environment resolution took 0.001s
DEBUG Installing in setuptools==72.2.0 in /Users/rafailf/Library/Caches/uv/builds-v0/.tmpKz5wsx
DEBUG Requirement already cached: setuptools==72.2.0
DEBUG Installing build requirement: setuptools==72.2.0
DEBUG Calling `setuptools.build_meta:__legacy__.get_requires_for_build_wheel()`
error: Failed to build: `git+https://github.com/facebookresearch/pytorch3d.git`
  Caused by: Build backend failed to determine extra requires with `build_wheel()` with exit status: 1
--- stdout:

--- stderr:
Traceback (most recent call last):
  File "<string>", line 14, in <module>
  File "/Users/rafailf/Library/Caches/uv/builds-v0/.tmpKz5wsx/lib/python3.10/site-packages/setuptools/build_meta.py", line 327, in get_requires_for_build_wheel
    return self._get_build_requires(config_settings, requirements=[])
  File "/Users/rafailf/Library/Caches/uv/builds-v0/.tmpKz5wsx/lib/python3.10/site-packages/setuptools/build_meta.py", line 297, in _get_build_requires
    self.run_setup()
  File "/Users/rafailf/Library/Caches/uv/builds-v0/.tmpKz5wsx/lib/python3.10/site-packages/setuptools/build_meta.py", line 497, in run_setup
    super().run_setup(setup_script=setup_script)
  File "/Users/rafailf/Library/Caches/uv/builds-v0/.tmpKz5wsx/lib/python3.10/site-packages/setuptools/build_meta.py", line 313, in run_setup
    exec(code, locals())
  File "<string>", line 15, in <module>
ModuleNotFoundError: No module named 'torch'
---
  Caused by: This error likely indicates that git+https://github.com/facebookresearch/pytorch3d.git depends on torch, but doesn't declare it as a build dependency. If git+https://github.com/facebookresearch/pytorch3d.git is a first-party package, consider adding torch to its `build-system.requires`. Otherwise, `uv pip install torch` into the environment and re-run with `--no-build-isolation`.
---

While running the same command, but with pip install  instead of  uv pip install works:
MACOSX_DEPLOYMENT_TARGET=10.14 CC=clang CXX=clang++ pip install "git+https://github.com/facebookresearch/pytorch3d.git"

with output:
Collecting git+https://github.com/facebookresearch/pytorch3d.git
  Cloning https://github.com/facebookresearch/pytorch3d.git to /private/var/folders/hw/0k21gtlx6k5_2mtjy3_mf2jh0000gp/T/pip-req-build-kps4ilpm
  Running command git clone --filter=blob:none --quiet https://github.com/facebookresearch/pytorch3d.git /private/var/folders/hw/0k21gtlx6k5_2mtjy3_mf2jh0000gp/T/pip-req-build-kps4ilpm
  Resolved https://github.com/facebookresearch/pytorch3d.git to commit 38afdcfc6826bb41bbc414404937fab58dc24e85
  Preparing metadata (setup.py) ... done
Collecting iopath (from pytorch3d==0.7.7)
  Downloading iopath-0.1.10.tar.gz (42 kB)
  Preparing metadata (setup.py) ... done
Collecting tqdm (from iopath->pytorch3d==0.7.7)
  Downloading tqdm-4.66.5-py3-none-any.whl.metadata (57 kB)
Requirement already satisfied: typing_extensions in ./p3d/lib/python3.10/site-packages (from iopath->pytorch3d==0.7.7) (4.12.2)
Collecting portalocker (from iopath->pytorch3d==0.7.7)
  Downloading portalocker-2.10.1-py3-none-any.whl.metadata (8.5 kB)
Downloading portalocker-2.10.1-py3-none-any.whl (18 kB)
Downloading tqdm-4.66.5-py3-none-any.whl (78 kB)
Building wheels for collected packages: pytorch3d, iopath
  Building wheel for pytorch3d (setup.py) ... done
  Created wheel for pytorch3d: filename=pytorch3d-0.7.7-cp310-cp310-macosx_14_0_arm64.whl size=929835 sha256=77d9144c4eda7ef3ff2be1422ef786ff25472b4c582cd9f8b060c90cd41bb20c
  Stored in directory: /private/var/folders/hw/0k21gtlx6k5_2mtjy3_mf2jh0000gp/T/pip-ephem-wheel-cache-jch7vouh/wheels/dd/74/cc/b9266c863f19026f796e59a04e1cd9eb3754474a52ce1b66ce
  Building wheel for iopath (setup.py) ... done
  Created wheel for iopath: filename=iopath-0.1.10-py3-none-any.whl size=31528 sha256=e3a30ad2c9ba029c5fe04b6a448745088f10d1bbbe7f3d8267a53b74e8e334c1
  Stored in directory: /Users/rafailf/Library/Caches/pip/wheels/9a/a3/b6/ac0fcd1b4ed5cfeb3db92e6a0e476cfd48ed0df92b91080c1d
Successfully built pytorch3d iopath
Installing collected packages: tqdm, portalocker, iopath, pytorch3d
Successfully installed iopath-0.1.10 portalocker-2.10.1 pytorch3d-0.7.7 tqdm-4.66.5

Version of uv:
0.2.36 (Homebrew 2024-08-13)

After actually reading the error until the end and adding --no-build-isolation, I was able to install pytorch3d :)

Thanks for following up!


start and stop meeting

Hello Guys !
So here is the problem we are facing :
We first launch a meeting with 2 people (one on the web and another one on an iPhone).
Then, the one on the iPhone close the app without actually calling stopMeeting() method.
After that, we go back on the app and call back the startMeeting().
In the code there is a condition in the method startMeeting() in the file NativeMobileSDKBridge.m
  if (meetingSession != nil) {     [meetingSession.audioVideo stop];     meetingSession = nil;   }
In order to prevent that kind of behavior i am describing. Except that is doesn't work. In a sense that the stop function does not seem to finish to execute before starting the meeting.
We replaced the code above by this :
  if (meetingSession != nil) {     [meetingSession.audioVideo stop];     meetingSession = nil;     [NSThread sleepForTimeInterval:3.0f];   }
=> The problem vanishes then.
However, it's not very pretty code. And I am not sure if behind stopMeeting() there is an API Rest call. Because if that's the case the 3s value I put might change according to the network quality.
Thanks for the feedback !

Hi @LilianAlvarez123 ,
Thanks for trying out the demo app. You're right, the example we provided is just a very simple use case and may not handle race conditions gracefully due to asynchronicity of the stop operation.
Ideally in a real world production app, you may want to create different meeting session objects for different meetings/calls instead of sharing a single variable, and properly terminate the audio/video session if a call is supposed to end.
Let me know if that makes sense.

Hello ! @haifengx
Thank you very much for the quick answer.
Do the stop operation is making a networking call ?
Actually, my case is a bit different. I wan't to join the same meeting again. But if I join it without stopping it first, i get an "Illegal state error".
Here is the precise stack trace :
API/DefaultAudioVideoFacade/stop
Stopping VideoClient
Running Amazon Chime SDK (0.10.0)
Failed to start meeting, error: illegalState
{ type: 'chime:set:live:host:uuid',
payload: { liveHostUuid: '2b60c10b-bba0-42fd-824e-2e119e3066e7' } }
'Visio.OnError', 'Failed to start meeting, error: illegalState'
'Visio.OnMeetingEnd', undefined
NativeMobileSDKBridge - videoClientDidStop
NativeMobileSDKBridge - VideoClient is being destroyed

@haifengx @LilianAlvarez123 how did you solve this?


Missing gradle configuration for EDX modules.

Missing gradle configuration for EDX modules.

I don't think they need configurations. We just need alprojects{} in the main build.gradle.

@calclavia May you fix that, i'm not able to get this running in my IDEA.

Fixed.


website link added in readme file

@mrbhatt2348  i also make some changes in index.html and style.css file because i add footer section ...........
please tell me changes are done or not ??

@Ritu-2001 kindly add a video demonstrating the changes you made

Ok
On Fri, 17 Feb 2023, 20:13 Rajkumar Bhatt, @.***> wrote:

@Ritu-2001 https://github.com/Ritu-2001 kindly add a video
demonstrating the changes you made
—
Reply to this email directly, view it on GitHub
https://github.com/mrbhatt2348/iBlog/pull/51#issuecomment-1434743391,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AX35RPHTWT3W2AJS7JQ2QD3WX6E77ANCNFSM6AAAAAAU7DKBSY
.
You are receiving this because you were mentioned.Message ID:
@.***>

i make this footer ,,, that's why changes other file ,,,,,,,,
But as per my issue i want to add website link to readme file , If you say I will only change the read me file  please give me response

add website link in readme file please check it


added Round H

will be adding solutions of the Google Kickstart Round H 2020

You've just added the Readme files. Right now maintainers are having semesters so this repo is not maintained. If want to work on the repo, kindly lookout for the existing issues and if want to get assigned for any question, comment on the issue and wait till you get assigned. I'm closing this PR.


chatlistener

i currently send messages with success but i dont know how to pull or get the responses of the person is talking to me

can you help me to using this chat library?


Changed select CodeIgniter log messages from 'debug' to 'info'

Changed select CodeIgniter log messages from 'debug' to 'info' so the debug log isn't junked up
In response to discussion in #1522

Manually applied, see commit referenced above.


Note build profile in cargo build output

Currently the output of the cargo build command does not reference the build profile (debug/default or release) anywhere in its output. This creates two issues:

It hurts discoverability of the release profile, especially those coming from JIT'ed/interpreted languages where that's usually not user-visible
Makes saved build logs harder to decipher unless the commands themselves are echoed

I propose that the output of cargo build and similar "building" commands go from:
   Compiling foo v0.0.1 (file:///Users/tanadeau/foo)

to
   Using debug build profile. Optimizations are off. Use --release to turn them on.
   Compiling foo v0.0.1 (file:///Users/tanadeau/foo)

and
   Using release build profile. Optimizations are on. Remove --release to turn them off.
   Compiling foo v0.0.1 (file:///Users/tanadeau/foo)

From @Valloric on this thread, yet another story of a user not knowing about optimizations and the --release flag in Cargo: http://www.reddit.com/r/rust/comments/2vzxjr/poor_http_performance_iron_framework/

I'd like to add a suggestion that this nag message could be disabled via a Cargo config flag.
Also, it isn't necessarily true that the release profile is optimized and the debug profile is not, so Cargo should probably check these things before printing those messages.

I do agree that this does seem like a problem, but I really do worry about non-newbie users. As soon as you know the difference you never want to see this message again, and I suspect that all Rust programmers will eventually know the difference. This means that if configuration is required it will mean that all Rust programmers will want that configuration. This indicates to me that it may be the wrong default.
It's definitely a tricky problem figuring out the best way to show this, but I just wanted to lay out some of my own personal worries.

@alexcrichton I'm not sure I understand why it would be an issue. It's a one-line message that should only show up when the "Compiling foo..." notice would appear anyway. Even for non-newbie users it would be useful as a configuration check like "whoops, I forgot to pass --release that time".
I would definitely agree more if cargo build gave only error output unless a --verbose flag was added, but that's not the case.

In general, I tend to prefer the Unixism of 'dont print anything unless it's unexpected'

@steveklabnik If Cargo did that, then all of the current notices about compiling, downloading dependencies, etc. would not be printed either.

I know.

I don't know of any build systems off the top of my head that are completely silent by default.

I wouldn't like extra lines in the output, but perhaps the existing "Compiling…" line could be changed accordingly from:

Compiling foo v0.0.1

To something like:

Building debug/unoptimized foo v0.0.1

For cargo run we already print "Running target/examples/blah" we could append " with optimisations OFF" or similar.

Having the debug/release folders has ended up meaning that I haven't seen this in quite some time, so I'm going to close this for now as the debug/release folder seems to be sufficient.

Running a "debug" binary provides zero indication to developers coming from Ruby, Python, Java, JavaScript, C# or the other languages that together make up 90% of all modern development that the binary is much slower than a release build. We've been over this many, many times now. Dozens of people have pointed this out in discourse threads, RFC comments, r/rust discussions etc.
"Debug" is not enough. There needs to be something telling these users that an unoptimized build is being produced. Running a binary from a debug folder does not convey this information.


Continued/pr 1144 fix resizing

Closes https://github.com/gregnb/mui-datatables/pull/1144 and continues by refactoring logic slightly.

Coverage decreased (-2.9%) to 73.572% when pulling 2b4c808ee0bc85507450185fb29c3f54e275076b on continued/pr-1144-fix-resizing into 4f836096a56be93ee1322f3c98cbaca485f0b064 on master.

@gabrielliwerant Hi, all looks OK.


conception: modification / enrichment  of own master data in CX-portal by CX-registred company

Description
see https://jira.catena-x.net/browse/CXAR-1085
Impact

Additional information

[ ] I'm willing to contribute to this feature

Closed by NSC because no progress. Please reopen and assign an upcoming release if needed.


Rename -plugin flag to -plugins

To be consistent ith other CLI flags (db-hosts) plugin should be plural.

Actually, it's more useful if it's a separate flag for every plugin.


Ethernet SRIOV

s/phisical/physical
And please run spell-checker to ensure that there are no other typos.
Also, please change commit name and description for README: update readme for 0.8.3 release

Acked-by: Volodymyr Babchuk<EMAIL_ADDRESS>


[BETA] Slack messages get sent twice

The slack bot forwards messages from slack back to slack causing messages to be sent twice

You should open this issue on your fork, since it's an issue with the other PR you made (the command handler one)