Arbitrary self types v2.

This PR suggests small changes to the existing unstable "aribtrary self types" feature to make it more flexible. In particular, it suggests driving this feature from a new (ish) Receiver trait instead of from Deref, but to maintain compatibility by having a blanket implementation for all Deref types.
This is a squashed commit of many edits by various folks including @Urhengulas, @Veykril , @madsmtm and myself. Thanks also to @davidhewitt, @Manishearth and many folks over on Zulip for feedback.
Rendered

Here's the zulip thread where this has mostly been discussed

another good use case for arbitrary self types that may be worth mentioning in the rfc:
#[derive(Default)]
pub struct GCArena {
    objects: Vec<Rc<dyn Any>>,
}

impl GCArena {
    pub fn alloc<T: 'static>(&mut self, value: T) -> Gc<T> {
        let rc: Rc<T> = Rc::new(value);
        let weak = Rc::downgrade(&rc);
        self.objects.push(rc);
        Gc(weak)
    }
}

#[derive(Clone)]
pub struct Gc<T: 'static + ?Sized>(Weak<T>);

impl PartialEq for Gc<T: 'static + ?Sized> {
    fn eq(&self, other: &Gc<T>) -> bool {
        self.0.ptr_eq(&other.0)
    }
}

impl Eq for Gc<T: 'static + ?Sized> {}

impl Hash for Gc<T: 'static + ?Sized> {
    fn hash<H: Hasher>(&self, state: &mut H) {
        (self.0.as_ptr() as *const ()).hash(state);
    }
}

impl<T: 'static + ?Sized> Receiver for Gc<T> {
    type Target = T;
}

impl<T: 'static + ?Sized> Receiver for Gc<T> {
    pub fn get(&self) -> Rc<T> {
        self.0.upgrade().expect("GCArena has been dropped")
    }
}

// demo of using Gc:

pub struct Node<T> {
    pub edges: Vec<Gc<Node<T>>>,
    pub data: T,
}

impl<T> Node<T> {
    pub fn walk(self: &Gc<Self>, seen: &mut HashSet<Gc<Self>>, f: &mut impl FnMut(&Gc<Self>)) {
        if seen.insert(self.clone()) {
            f(self);
            for i in &self.get().edges {
                i.walk(seen, f);
            }
        }
    }
}

@programmerjake I think this is now covered by the paragraph I wrote that is now part of the RFC?

For example, taking &Arc allows me to both clone the smart pointer (noting that the underlying T might not implement Clone) in addition to access the data inside the type, which is useful for some methods. Also, being able to change a method from accepting &self to self: &Arc can be done in a mostly frictionless way, whereas changing from &self to a static method accepting &Arc will always require some amount of refactoring.

This feels like the same case you present: you want the ability to both access the inner type and clone the smart pointer, and simply accessing the inner type isn't enough.

This feels like the same case you present: you want the ability to both access the inner type and clone the smart pointer, and simply accessing the inner type isn't enough.

well, i had intended to demonstrate a type where you can't just impl Deref, since the inner value may have already been dropped -- I didn't do a very good job of that.
another use case: a type where the inner value doesn't exist locally, e.g. for RPC with promise pipelining:
pub struct Id(u32);
pub struct Promise<T>(Id, PhantomData<T>);

impl<T> Receiver for Promise<T> {
    type Target = T;
}

pub struct MyRemoteData;
pub struct SomeIntermediate;

impl MyRemoteData {
    pub fn get() -> Promise<Self> {
        ...
    }
    pub fn foo(self: Promise<Self>, a: i32) -> Promise<SomeIntermediate> {
        ...
    }
}

impl SomeIntermediate {
    pub fn bar(self: Promise<Self>) -> Promise<()> {
        ...
    }
}

pub async fn demo() {
    MyRemoteData::get().foo(5).bar().await;
}

All, I just wanted to say thanks for all the discussion so far! @Urhengulas and I are working through the various things one at a time - sorry if some of your comment threads are awaiting an RFC update from us, we just haven't got to them all yet. (I'm currently poking at lifetime elision.)

@rustbot labels +I-lang-nominated
I'm nominated to take the temperature of the @rust-lang/lang team on this RFC -- I'd like to see it move forward! I'm going to give it a good read before our meeting

Gave this a quick read. One thing I would note is that I think that the RFC should highlight more that it also enables *const self methods -- this is a big win for unsafe code, in my opinion, for all the same reasons. Right now code that wants to take a raw pointer and doesn't want to guarantee reference validity is pretty stuck.

One small point regarding stabilization: the purpose of the current Receiver trait is to tell the compiler which types can be used as a method receiver from code that doesn't have the arbitrary_self_types feature enabled. This way, types like Rc, Arc, and Pin can be defined in std and marked as vetted receiver types that can be used from stable user code, but arbitrary types that implement Deref<Target=Self> cannot be used as method receivers without arbitrary_self_types enabled.
This RFC proposes adding a blanket impl of the new Receiver trait for anything that implements Deref. With that blanket impl, the new Receiver trait will not be useful as a way to mark those vetted receiver types, because every type that implements Deref will implement Receiver. If we want to avoid insta-stabilizing the ability to use arbitrary types that implement Deref as method receivers, we will need some way to tell which ones are the vetted receiver types and which ones aren't, likely with another marker trait that serves the same purpose as the existing Receiver trait. (This marker trait can be removed once arbitrary_self_types is stabilized.)

Another note: I'd like to see some more details of how method resolution and deref coercion would work with this change. Currently, it says that the algorithm would remain the same, but instead of using the Deref trait, it would use the new Receiver trait. I'm not sure this is quite right, because some method calls require deref coercions, and this new trait does not imply Deref.
In the following example, the Deref trait would still need to be involved to check if the calls to frobnicate_ref are allowed.
struct Foo;

impl Foo{
    fn frobnicate_ref(&self) {}
    fn frobnicate_cpp_ref(self: CppRef<Self>) {}
}

fn main() {
    let foo_rc: Rc<Foo> = Rc::new(Foo);

    // this compiles fine, and desugars to `Foo::frobnicate_ref(&*foo_rc)`
    foo_rc.frobnicate_ref();

    let foo_cpp_ref: CppRef<Foo> = CppRef::new(Foo);

    // should not compile because it would desugar to `Foo::frobnicate_ref(&*foo_cpp_ref)`
    // and you can't deref a CppRef
    foo_cpp_ref.frobnicate_ref();

    // should compile, because we're not dereffing the CppRef
    // desugars to `Foo::frobnicate_cpp_ref(foo_cpp_ref)`
    foo_cpp_ref.frobnicate_cpp_ref();

}

Aside: thanks @adetaylor and everyone that's helped for taking on the challenge of this RFC. I can tell there's been a lot of effort put in already and a lot of details have been thought out, and it's pretty nice to be able to walk in now, read a well put-together RFC and give a little bit of feedback.

With that blanket impl, the new Receiver trait will not be useful as a way to mark those vetted receiver types

Assuming we gate the new behavior behind arbitrary_self_types, we can:

Have a blanket impl Receiver for T: Deref gated behind arbitrary_self_types
Retain impl Receiver for Box<T> etc. gated behind receiver_trait
I'm finding we need to do something like that to maintain compatibility with the bootstrap compiler anyway.

@adetaylor it's been a while since I was involved in compiler development, but I don't remember it being possible to gate an impl behind a feature gate. If it is, then maybe that could work.

@adetaylor based on your comments, it sounds like you understand what I was getting at with this example. In the case of foo_cpp_ref.frobnicate_ref(), there should be an error during type checking. If the compiler panic is happening at a later stage, then it should go away once the error is caught earlier during type checking.

Another note: I'd like to see some more details of how method resolution and deref coercion would work with this change. Currently, it says that the algorithm would remain the same, but instead of using the Deref trait, it would use the new Receiver trait. I'm not sure this is quite right, because some method calls require deref coercions, and this new trait does not imply Deref.

Yeah, I caught that too.
I think the RFC is mixing two sets of semantics at times. As far as I understand, the reference as it's currently written doesn't explicitly address Box/Arc/etc as receivers, but it does implicitly address them in this paragraph:

Then, for each candidate type T, search for a visible method with a receiver of that type in the following places:

T's inherent methods (methods implemented directly on T).
Any of the methods provided by a visible trait implemented by T. If T is a type parameter, methods provided by trait bounds on T are looked up first. Then all remaining methods in scope are looked up.

That first bullet point is the part that must be amended to clarify that "T's inherent methods" need to take the Receiver trait into account; the paragraph above about dereferencing chains must be kept untouched.

It's therefore a major compatibility break if existing Deref implementors cease to be usable as self parameters. Just in the standard library, we'd have to add Receiver implementations for Cow, Ref, ManuallyDrop and possibly many other existing implementors of Deref: third party libraries would have to do the same. Without that, method calls on these types would not be possible:

Here too, I think the RFC is confusing "Box<Self> as a receiver" with "Box<Self> as a way to get a &self which is a receiver".
Right now the only custom receivers (outside nightly crates) are the ones defined in the standard library; changing how they're defined isn't a breaking change.

I'd like to give some context to the "smart pointers in GUI" use-case.
In Masonry, I'm trying to create a way to access a widget hierarchy imperatively, that still automatically updates the render tree whenever something is changed. My ideal API looks something like this:
struct Button {
  label: WidgetPod<Label>,
  size: Size,
  color: Color,
  callback: impl Fn(Stuff),
}

impl Button {
    pub fn new(text: impl Into<String>) -> Button {
        Button::from_label(Label::new(text))
    }

    pub fn from_label(label: Label) -> Button {
        Button {
            label: WidgetPod::new(label),
            // ...
        }
    }

    pub fn set_size(self: &mut WidgetMut<'_, Self>, size: Size) {
        self.widget.size = size;
        self.ctx.request_layout();
    }

    pub fn set_color(self: &mut WidgetMut<'_, Self>, color: Color) {
        self.widget.color = color;
        self.ctx.request_paint();
    }

    pub fn set_callback(self: &mut WidgetMut<'_, Self>, callback: impl Fn(Stuff)) {
        self.widget.callback = callback;
    }
}

That is, every widget would be defined in a way that it's not possible for an external user to directly modify the fields of the widget. Instead users would have to use a WidgetMut<MyWidget> receiver. Widgets might have internal methods taking mutable references, but every public method mutating a widget would take a WidgetMut<MyWidget> receiver; that WidgetMut would include methods to notify the system when repaint or relayout is needed, and people writing new widgets would make sure that setters use those methods.
Some widgets would also have children. These widgets would have method to go from WidgetMut<Parent>  to WidgetMut<Child>:
impl Button {
    pub fn label_mut(self: &mut WidgetMut<'_, Self>) -> WidgetMut<'_, Label> {
        self.ctx.get_child_mut(&mut self.widget.label)
    }

    pub fn set_text(self: &mut WidgetMut<'_, Self>, new_text: impl Into<String>) {
        self.label_mut().set_text(new_text.into());
    }
}

So far this RFC looks like it would help me satisfy that use case, so I'm hoping it makes progress! :heart:

I'd like to give some context to the "smart pointers in GUI" use-case.

@PoignardAzur Thanks for adding the additional context - very happy to accept edits if you think any of this should belong in the Motivation section!

I'm not sure it belongs in the motivation section. ^^
I just wanted to have the full explanation in an easy-to-find place.

We talked about this at length in today's @rust-lang/lang meeting, and had several thoughts. Several of us are going to post our thoughts, in separate comments.

The restriction on NonNull and Weak seems unfortunate, for multiple reasons.

These are types that make a lot of sense to use as receivers.
It seems like raw pointers also have lots of methods, and we may well add more in the future, so it's not obvious why it's OK to have raw-pointer receivers but not NonNull/Weak receivers. Is there a reason why the same considerations don't apply?

I'd be enthusiastically in favor of this, but I'd like to find a way that we can allow it for NonNull and Weak as well, and in general for receivers that do have methods people might want to call.
When you add a new method to a trait, that's not a breaking change, because inherent methods get priority.
However, with Deref, we already have the rule that methods directly on the type have priority over methods on the Deref::Target. Which makes it a breaking change to add methods directly on the type.
For Receiver, the other way around seems more robust against breakage, since it seems acceptable for a method impl SomeType { fn method(self: FooPtr<Self>); } to shadow FooPtr::method. However, that would be incompatible with existing usage with Deref, and I don't see any way we could get there even if we wanted to.
That said, I think we should consider (in order from most to least preferable):

Adding some way to make it not a breaking change to add methods on a type that implements Receiver, or to make it reasonable to put it in the category of "acceptable breakage" like we do inference failure. Then, implement Receiver for NonNull and Weak.
Implement Receiver for NonNull and Weak anyway, if we're going to have it for raw pointers. In particular, I don't think it makes sense to have it for raw pointers and not for NonNull.
Making raw pointers not a Receiver. Same argument: it doesn't make sense to have it for raw pointer and not NonNull.
Add a way for us to transition over an edition to moving the various methods on raw pointers and NonNull to associated functions. That seems like a massive amount of churn, though. I'm only mentioning this possibility for completeness, in case it inspires some better idea.

it seems acceptable for a method impl SomeType { fn method(self: FooPtr<Self>); } to shadow FooPtr::method. However, that would be incompatible with existing usage with Deref

Why is it incompatible? From what I understand we could treat Deref and Receiver differently when deciding shadowing precedence. The only types where this could break are types that are already Receiver today, i.e. Box, Rc and friends, but they already don't have inherent methods so that's fine.

Implement Receiver for NonNull and Weak

Once we do those, one might ask: why don't we also allow self: Cell<Self>, self: [Self], self: HashSet<Self> and so on?
So yeah, definitely a good point, I think the motivation for allowing raw pointers was also because it lined up nicely with the proposed changes to the method resolution, but we're changing those anyway, so it might not make so much sense any more?
Will have to consider this further!

Thanks for all the discussion around NotNull, Weak etc. I thought I'd take the liberty of summarizing the different perspectives to see if it helps us reach a consensus:

The existing unstable arbitrary_self_types feature allows use of raw pointers as self types (but not NotNull, Weak etc. because they don't implement Deref)
@scottmcm feels we shouldn't have raw pointer self types, but require people to wrap those pointers in a newtype wrapper (this is my instinct too but just because I'm automatically nervous of larger changes!)
@nikomatsakis is of the view that raw pointer self types are important for better quality unsafe code) and I've heard the same from @Manishearth who says:

raw pointer receivers are quite important for the future of safe Rust, because stacked borrows makes it illegal to materialize references in many positions, and there are a lot of operations (like going from a raw pointer to a raw pointer to a field) where you don't need to or want to do that.

@joshtriplett says we should implement Receiver for NonNull and Weak if we implement it for raw pointers, but hopes we can find a way to avoid it being a compatibility break

I think: it seems like there's enough desire for raw pointers, NotNull, Weak etc. as self types that we should try pretty hard to find a way to avoid compatibility breaks, even if it means we do something a bit unexpected which might confuse users. There are some proposals around that in this comment thread about the RFC which I haven't had a chance to properly get my head around, let alone work into RFC revisions! But further comments on that thread are very much appreciated.

it seems acceptable for a method impl SomeType { fn method(self: FooPtr<Self>); } to shadow FooPtr::method. However, that would be incompatible with existing usage with Deref

Why is it incompatible? From what I understand we could treat Deref and Receiver differently when deciding shadowing precedence.

I mean that it'd be confusing if some type SmartPtr that implements Deref (and thus gets the blanket impl of Receiver) has methods that take precedence over methods of the type it Derefs to if they take a T, but don't take precedence if they take a SmartPtr<T>.

I mean that it'd be confusing if some type SmartPtr that implements Deref (and thus gets the blanket impl of Receiver) has methods that take precedence over methods of the type it Derefs to if they take a T, but don't take precedence if they take a SmartPtr.

I think of it as "most specific impl first" (with caveat and details here). It makes sense in my head, I think we can teach this in a way that's not too confusing

Periodic update on what's happening here:

@madsmtm is kindly fixing up the current method call documentation
I have a PR to try to fix pre-existing bugs in the lifetime elision rules, although current consensus is that we should try to understand and document the current rules before fixing them :) Help and assistance appreciated!
I've been trying to implement this proposal for searching impl blocks (via Receiver) differently from actually probing methods (via Deref) - it's proving fiddly
I'm in the middle of a very busy two weeks so that's why @madsmtm is doing the only actual effective stuff right now :)

@rustbot labels -I-lang-nominated
This was discussed in the T-lang meeting on 2023-11-27.  Some members have left comments above deriving from this.
The general feeling seemed to be that we wanted to find some way to enable this, including for raw pointers, NonNull, etc., but we were feeling unsure about the path to get there.
In light of this, probably further reflection and discussion on this thread or in Zulip is warranted, and a revision to the RFC that addresses this and proposed a plan here would be in order.
Once that is done, please renominate for T-lang so that the team can discuss the changes.

Here's the new problem with NonNull and friends which I allude to in the previous comment.
#![feature(receiver_trait)]

struct MyNonNull<T>(*const T);

#[allow(dead_code)]
impl<T> MyNonNull<T> {
    fn foo<U>(&self) -> *const U {
        self.cast().bar()
    }
    fn cast<U>(&self) -> MyNonNull<U> {
        MyNonNull(self.0 as *const U)
    }
    fn bar(&self) -> *const T {
        self.0
    }
}

This compiles. But if I implement Receiver<Target=T> for MyNonNull<T>, we get:
error[E0282]: type annotations needed
  --> /Users/adetaylor/dev/rust/tests/ui/self/recursive-receiver.rs:13:14
   |
LL |         self.cast().bar()
   |              ^^^^   --- type must be known at this point
   |              |
   |              cannot infer type of the type parameter `U` declared on the method `cast`
   |
help: consider specifying the generic argument
   |
LL |         self.cast::<U>().bar()
   |                  +++++

This is with my working branch here. The only explanation is that the probing must be coing up with more possible method candidates, and this is how the ambiguity is presented. I don't quite understand this yet, but as there's a determination to implement Receiver for NonNull I do think we need to get to the bottom of it before making progress.

Here's how I think method resolution should work after this RFC. This approach allows us to use NonNull method receivers,  using something approximating the approach in this thread, and solves the problem highlighted around non-dereffable types here. It also solves the problem in the last comment.
First, this assumes that there is a blanket impl of Receiver for T: Deref. To abuse UML a little bit, things look like this:
classDiagram
  Receiver <|-- Deref
  Receiver <|-- CppRef
  note for CppRef "or other types that\nimpl Receiver but not Deref\ne.g.NonNull"
  Deref <|-- Box
  note for Box "or other types that\nimpl Deref\ne.g.Rc"
  class usize
  note for usize "or other types that\nimpl neither"

So, for any given type, say A<B<C<D<E>>>>, there's a chain of Derefs which can be followed, and a chain of Receivers. The Receiver chain is always just an extension of the Deref chain.
graph LR
  A --Receiver--> B
  A --Deref--> B
  B --Receiver--> C
  B --Deref--> C
  C --Receiver--> D
  D --Receiver-->E

How method probing works now
This is roughly a diagrammatic version of this excellent page though it includes a few different details which will be important for this RFC. This is all, of course, quite simplified.
Everything is driven from autoderef which knows how to iterate through the chain of Deref links shown above. This is used to check valid receiver types (in wfcheck.rs) and twice in method probing, in probe.rs. At present, the same chain of Derefs is used in all three places.
flowchart TB
  subgraph autoderef
     direction TB
     A --Deref--> B
     B --Deref--> C
  end
  subgraph wfcheck[wfcheck.rs]
     wfchecker[Confirm valid self types in each method]
  end
  autoderef-->wfchecker
  subgraph probe[probe.rs]
    method_autoderef_steps
    candidate_steps[(list of candidate steps with\nself_ty\nnumber of derefs)]
    method_autoderef_steps-->candidate_steps
    probe_op[probe_op & various\n'functions calling push_candidate]
    candidate_steps-->probe_op
    candidates[(list of candidate methods with\nassociated item &\nxformed self ty)]
    probe_op-->candidates
    candidates-->pick_all_method
    pick_all_method[pick which candidate\nby iterating types and\nlooking for matching methods]
    candidate_steps--work out types to which\nreceiver can be converted-->pick_all_method
  end
  autoderef-->method_autoderef_steps
  ambiguity[Report method ambiguity error]
  confirm[confirm.rs]
  pick_all_method--exactly 1 method-->confirm
  pick_all_method--multiple methods-->ambiguity
  e0282[error 0282: type annotation needed]
  method_autoderef_steps--final type was a type variable-->e0282

Note in particular that the candidate_steps are effectively used twice.
How this changes with arbitrary self types
With this RFC, the following changes occur:

Sometimes we follow the chain of Receiver instead of Deref. Specifically,

We do this in wfcheck.rs when checking for well-formed self types
We also do this in probe.rs when assembling the list of candidate functions, but not when we are working out the types to which the actual method call receiver can be converted. For that we continue to use Deref.

Sometimes, if there are multiple candidates, we pick one but show a warning about the ambiguity. (This is what allows us to use impl Receiver for NonNull despite the fact that we might want to add methods to NonNullin future).

So the picture changes like this:
flowchart TB
  subgraph autoderef[autoderef using Deref]
     direction TB
     A --Deref--> B
     B --Deref--> C
  end
  subgraph autoderef2[autoderef using Receiver]
     direction TB
     A2[A] --Receiver--> B2[C]
     B2[B] --Receiver--> C2[C]
     C2[C] --Receiver--> D2[D]
     D2[D] --Receiver--> E2[E]
  end
  subgraph wfcheck[wfcheck.rs]
     wfchecker[Confirm valid self types in each method]
  end
  autoderef2-->wfchecker
  subgraph probe[probe.rs]
    method_autoderef_steps[method_autoderef_steps using Deref]
    method_autoderef_steps2[method_autoderef_steps using Receiver]
    candidate_steps[(list of candidate steps with\nself_ty\nnumber of derefs)]
    candidate_steps2[(list of candidate steps with\nself_ty\nnumber of receiver hops)]
    method_autoderef_steps-->candidate_steps
    method_autoderef_steps2-->candidate_steps2
    probe_op[probe_op & various\n'functions calling push_candidate]
    candidate_steps2-->probe_op
    candidates[(list of candidate methods with\nassociated item &\nxformed self ty)]
    probe_op-->candidates
    candidates-->pick_all_method
    pick_all_method[pick which candidate\nby iterating types and\nlooking for matching methods]
    candidate_steps--work out types to which\nreceiver can be converted-->pick_all_method
  end
  autoderef-->method_autoderef_steps
  autoderef2-->method_autoderef_steps2
  ambiguity[Report method ambiguity error]
  confirm[confirm.rs]
  confirm[confirm but warn of ambiguity]
  pick_all_method--exactly 1 method-->confirm
  pick_all_method--exactly 1 'innermost' method-->confirm_warn
  pick_all_method--multiple methods-->ambiguity
  e0282[error 0282: type annotation needed]
  method_autoderef_steps--final type was a type variable-->e0282

'Innermost' in this context means a viable candidate method on the 'innermost' type, that is, the type we got via the largest number of steps along the Receiver chain.
In practice, the code isn't this complex - we don't have to store two different lists of candidate_steps - but logically this is what we're doing.
Takeaways
The main bits of cunning here are:

We follow the chain of Receiver while identifying candidate methods, but we follow the shorter chain of Deref when working out the types to which the actual method receiver can be converted.
If there's ambiguity about whether to choose a method on A or B in A<B>, we'll choose the method on B but show a warning. This allows us to add new methods on types like NonNull<T>.
The error 0282 discussed in the last comment is solved by considering bad types at the end of the Deref chain not at the end of the Receiver chain.

Thoughts? Does this all make any sense? Can you see any pitfalls?
This is all implemented hackily here though I can't quite work out whether the second bullet above is implemented sufficiently thoroughly - I need to play with that a bit more.
(@madsmtm @Urhengulas!)

looks nice, only thing that occurred to me is to check that the right function is called (there's probably a test for this):
pub struct A;

impl A {
    pub fn f(&self) {}
}

pub struct B(A);

impl core::ops::Deref for B {
    type Target = A;
    fn deref(&self) -> &A {
        &self.0
    }
}

impl B {
    pub fn f(&self) {
        println!("B::f");
    }
}

pub fn f() {
    B(A).f(); // must call B::f
}

Yep, there's a test equivalent to that and it does pass (but definitely we need more tests before landing all of this, especially to confirm that all this stuff works for trait function resolution too). I also confirmed your test works as expected.

@adetaylor First of all, thank you for the very detailed explanations and diagrams!

@adetaylor It definitely seems like a potential source of confusion that Receiver disambiguates to the deepest method in the chain, rather than the shallowest, while Deref disambiguates to the shallowest. (Playground example for Deref ambiguity: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a47a68ab2aa3683bab64d45c80a42705 )
Leaving aside whether it matches people's intuitions, a few other thoughts:

This gives an example of adding methods on NonNull<T>, which will be bypassed with a warning in the case of ambiguity, so adding such methods won't cause user code to stop compiling. What about cases of adding a method on a deeper type that effectively shadows the method in the shallower type? Could that ever cause an issue? It sounds like probably not, and that's just the price you pay to be a Receiver type, but I wanted to ask the question explicitly.

When we give a warning, we should show how to unambiguously call either method. Could you give the syntax for each? Are both of those syntaxes clear? The turbofish syntax you're showing seems unintuitive; if I understand correctly, it's explicitly calling the method on NonNull<Dog>, because the method on Dog doesn't take a generic parameter of Dog?

The help text for the type of self is now very long:

consider changing to self, &self, &mut self, or a type implementing Receiver: for example self: Box<Self>, self: Rc<Self>, self: Arc<Self>, or self: Pin<P> (where P is one of the previous types except Self

Now that it's a non-exhaustive list of examples, I think we should reduce the list to a few representative cases that are easier to list:

consider changing to self, &self, &mut self, or a type implementing Receiver such as self: Box<Self>, self: Rc<Self>, or self: Arc<Self>

Thanks @joshtriplett !

@adetaylor It definitely seems like a potential source of confusion that Receiver disambiguates to the deepest method in the chain, rather than the shallowest, while Deref disambiguates to the shallowest.

I agree. However,

The disambiguation of Receiver to the deepest method results in a warning. So this situation should not normally persist in people's code. Disambiguation to the shallowest remains the norm in all warning-free Rust code.
My sense of the consensus further up this PR was: "it seems like there's enough desire for raw pointers, NotNull, Weak etc. as self types that we should try pretty hard to find a way to avoid compatibility breaks, even if it means we do something a bit unexpected from the user's perspective." I think that's what we're doing here. I think "disambiguate to the deepest in rare circumstances and show a warning until the user makes it explicit" is a good outcome given the strong desires for us to support NotNull etc. WDYT?

I agree with your other points and will work on them. In particular, I definitely want to prove that a shoal of turbofishes can be used to remove all ambiguities.
Incidentally, along with my overly lengthy comment above, and the prototype code, I have a PR to change the RFC text correspondingly - just in case you were wondering. There's no need to read it - it duplicates the big comment.

//   Call to Dog::bark shadows NonNull::bark. Be explicit about which method you're aiming to call,
//   e.g. d.bark::<Dog>()

Shouldn't the disambiguation use UFCS, not some weird application of generics where they don't exist?
Dog::bark(d)

This gives an example of adding methods on NonNull<T>, which will be bypassed with a warning in the case of ambiguity, so adding such methods won't cause user code to stop compiling. What about cases of adding a method on a deeper type that effectively shadows the method in the shallower type? Could that ever cause an issue? It sounds like probably not, and that's just the price you pay to be a Receiver type, but I wanted to ask the question explicitly.

I think this is unlikely to happen. Supposing we have NotNull<Giraffe> and NotNull has a pre-existing eat_leaves(&self) method. If the giraffe crate adds now adds impl Giraffe { fn eat_leaves(self: &NotNull<Self>) {} }, they're explicitly specifying NotNull in their new method signature, so they'd have to be very intentionally conflicting with a NotNull method.
I can't see a circumstance where that would happen accidentally, but I want to be explicit that I've been thinking of this heavily from the perspective of a CppRef<T> type and similar scenarios. Maybe this sort of shadowing could happen when the same primitives are used in a radically different way, but I can't think of a problem.

When we give a warning, we should show how to unambiguously call either method. Could you give the syntax for each? Are both of those syntaxes clear? The turbofish syntax you're showing seems unintuitive; if I understand correctly, it's explicitly calling the method on NonNull<Dog>, because the method on Dog doesn't take a generic parameter of Dog?

Yeah, thanks to @riking I realized I should have suggested UFCs here: Dog::bark(dog) or NonNull::bark(dog). No new syntax is proposed here. (I've pushed a commit to my very prototypey branch which begins to add the lint.)

The help text for the type of self is now very long.

Fixed per your suggestion.

What about cases of adding a method on a deeper type that effectively shadows the method in the shallower type?

This is a mirror of the Deref situation, but easier.
For P<T>: Deref, the crate that defines P mustn't add a .foo() inherent method in case a downstream crate A uses P on a type that has foo(). We can't know what types exist; it's open-world.
For P<T>: Receiver, it's the downstream crate A that must be careful to not add a method already defined on P as that could break its own downstream crates. That's much easier because we can just look up which methods exist; it's (mostly) closed-world.
It's not fully closed-world because versions. To make it fully closed-world, I think we should consider it a breaking change to add methods to a P: Receiver.

To make it fully closed-world, I think we should consider it a breaking change to add methods to a P: Receiver.

This sounds reasonable to me.
I expect we can add a lint to cargo-semver-checks for this. I'd be happy to mentor folks toward doing that, or if not, I will sooner or later get around to adding that lint myself.

well, no, you need a newtype designed to be a receiver

This got me thinking how I might do that in PyO3. I guess a quick-and-dirty way to build that newtype would be a (trait) method.
my_smart_pointer.recv().call_method_taking_receiver()

And then I wondered: is there a way to reduce that further? Maybe with a new operator to switch name resolution to look only at receiver methods? (I realise almost 100% of the time the answer to a new operator is no.)
// The idea being that `->` ignores all inherent methods on the
// smart pointer, and just looks for methods on Receiver::Target
my_smart_pointer->call_method_taking_receiver()

I didn't immediately hate seeing -> in that position, and it's not a million miles away from how -> is used in C/C++ (although there it works more like Deref, I believe). There are probably great reasons not to do this, I thought I'd put it out there for folks to chew on in case it prompted new discussion. Maybe this exact thing has been suggested before anyway.
The interesting thing I saw about using a separate operator to perform arbitrary receiver method lookup is that it can presumably cleanly solve the concerns with ambiguity and breaking changes. Maybe there's a better operator or keyword to use than ->.

I do not find this order confusing personally. It resolved to "the most specific method" (i.e. picks a self: Box<MyType> impl over a generic self: Box<T> over a derefed self: &MyType) which is conceptually as it should be imo.

I agree with @Darksonn that the arbitrary self types are orthogonal to raw pointer self types, and I would actually prefer the alternative "Do not enable for pointers" over adding complexity to make pointer self types work.
I also think that the dynamic dispatch is more important than symbol resolution which is the focus of this RFC. I think the dynamic dispatch issue needs to be taken into full account for anything receiver-related to not narrow down future design space. I've written down my evaluation here https://hackmd.io/z4n40072Tqy8MhQPZn0N-g.

Periodic update, for folks worrying this effort has died: it hasn't! There's been a bit of discussion at recent Rust language team meetings about whether we should do the simple option here (Receiver trait with Target associated type; supported only for newtype wrappers without methods, only small changes to method resolution logic) vs the complex option (support also for raw pointers, Weak, and NonNull; more complex method resolution logic to spot shadowing). Current plan is (likely) to go back to the simple version because we don't think it prevents us from doing the more complex version in future. (There are a few side issues I'm looking into, e.g. digging a little deeper into dynamic dispatch).

@adetaylor, @joshtriplett and I met and discussed this at RustNation. We all aligned on a few points
In general, the complexity of method dispatch with distinct roles for Receiver and Deref seemed too much. We therefore consolidated on the "simple" approach of modifying method dispatch to use Receiver in place of Deref but without "outer loops" and the rest. This means that, if we permit *const Self as a receiver type, adding new methods to *const would potentially be breaking -- and we know that T-libs would like to do that -- so we are not recommending that *const Self be permitted for the time being.
In short, we are sticking to the existing heuristic

auto-deref and avoid adding methods where possible, permit user-defined methods (e.g., Box, &, etc)
define methods arbitrary, but avoid user-defined methods with that receiver type (raw pointers, NonNull)

How can we support *const Self in the future?
If we do want to permit *const Self in the future, we have basically two options...

YAGNI -- permit *const self but advise users that we will continue to add methods to raw pointer types and therefore *const self receivers should be used with caution.

Observation: The same kind of conflicts can happen today with traits that are implemented for *const T receivers, so it is possible to have shadowing, but it is not a big issue in practice.
Observation: In practice, we have not observed conflicts between methods added to stdlib and libraries to be a major issue -- with the notable exception of one particular case, where handy methods from the ecosystem are moved to stdlib for convenience, which is a peculiar kind of shadowing.

Edition -- Use an edition and create some new method dispatch algorithm that combines deref-and-receiver, perhaps the one that was proposed here, or perhaps some future idea we've not had yet.

Use cases for methods on raw pointers
Which of the above options is worthwhile really depends on the use cases for raw pointers, so we talked about those. There were three that we came up with, we'd be curious to hear about others...
Special methods in stdlib, like the fetch_add method on AtomicUsize. This is a particular special case, described in detail by pnkfelix in their blog post How to dismantle an atomic bomb. The short version is that it would be nice if fetch_add and friends took *const self. What's worse is that there isn't really an ergonomic way to invoke them without it. We observed that we could simply add these methods as "special cases" if we wanted. It's noteworthy that if we just said "you can use *const Self, but we recommend you don't", we could still add these methods, no problem, since they are in the standard library. I think the main thing missing here is that we would want something like "auto_addr_of" to complement today's "auto_ref", because otherwise you have to do something like addr_of!(x.foo).fetch_add() which is quite awkward. But that's rather orthogonal.
Trait dispatch, or the "rayon" use case. In rayon, we had a Box<dyn Job> at some point but realized that using safe reference types was not correct. Therefore the code was refactored to use a struct, JobRef that paired together a fn pointer and the *const "self" type. If we could've had something like *const Self this would be nicer. This pattern can be accommodated with this RFC because rayon can easily add a Job<T> wrapper.
Possible pattern: Raw type in stdlib
One thing we talked about was the possibility of adding a
struct Raw<T> {
    pointer: *const T
}

type to the standard library, with the intention that people could define "inherent methods" like fn foo(self: Raw<Self>) and then "opt-in" to using extension methods by doing pointer.raw().foo. This would allow people to explicitly shift between treating the pointer like a pointer versus like a reference to the thing being pointed at. The stdlib would not add inherent methods to Raw<T>.
Note though that making pointer.raw().foo work again requires some kind of "auto-addr-of", or else people would actually have to do something like addr_of!(pointer).raw().foo() or perhaps raw!(foo).foo(), both of which seem like non-starters.
My persona conclusion
This section is just my personal conclusions...currently I feel like it makes sense to continue the tradition we have today, where you either have types (like raw) where the focus is on them being a pointer or you have types that act like a transparent reference (&, Box, etc). The former have methods in stdlib and the latter do not.
I would like to see *const self or auto-addr-of or something to permit more ergonomic methods like fetch_add and raw() but I anticipate most of the usage being either in the stdlib or internal to crates.
I'd like to see more data gathered about conflicts between stdlib and user-provided methods, but I'm less worried, and intrigued by the idea I raised on Zulip of leveraging the crate graph to help in resolving those kinds of cases.

@rfcbot fcp merge
Per my previous comment, I am moving to merge this RFC, and in particular the "simpler" variant of it, in which (effectively) a new trait Receiver is added along with a blanket impl of impl<T: Deref> Receiver for T, and method dispatch is modified to use Receiver instead of Deref. Under this proposal, *const T does not implement Receiver (yet?) and hence is not supported for self-types (without a feature flag, anyway). It can be added later so long as we are willing to go the "YAGNI" route -- adding it later will otherwise require more thought.

Signing off on this. And +1 for the approach of warning people writing methods with raw-pointer receivers to accept that there may be (unlikely) breakage due to new methods on raw pointers.

Major props to @adetaylor for not only driving this over the (very long) road to completion, but considering every use case and point of feedback carefully, and being willing to change your approach when needed. I'm impressed by your tenacity and your patience.
I'm happy with the approach we landed on. I think it might make sense to expand support in the future to types which may add methods, like raw pointers. But I also think it makes sense to take it slow, because this is a major addition to Rust.
Let's go!
@rfcbot reviewed

The lang team has accepted this RFC, and we've now merged it.
Thanks to @adetaylor for pushing forward this important work, and thanks to all of the reviewers who contributed helpful feedback.
For further updates on this work, follow the tracking issue:

https://github.com/rust-lang/rust/issues/44874


Can't connect to Mac via bluetooth

I flashed my keyboard with firmware built from the current head (2562f62), and now I can no longer connect my keyboard via bluetooth. It correctly shows up as "Adv360 Pro" under nearby devices, but when I press "Connect", I get a spinner, and briefly the button changes to "Disconnect" then immediately switches back to "Connect".
In my Console logs I get a constant stream of the following:
2022-11-17 15:34:47.670742 -0800	info	bluetoothd	com.apple.bluetooth	CBStackBLEScanner	Device found changed: CBDevice D06048F3-C746-C12A-EC6F-D4C778F201ED, BDA E0:07:2A:6F:CE:0E, Nm 'Adv360 Pro', DsFl 0x2000000000000 < BLEHID >, RSSI -57, Aprc Keyboard, CF 0x200000000 < RSSI >
2022-11-17 15:34:47.670960 -0800	debug	bluetoothd	com.apple.bluetooth	Server.LE.Scan	Found device "D06048F3-C746-C12A-EC6F-D4C778F201ED with data:"Adv360 Pro", RSSI: 0 dB (non-saturated), Service UUIDs: 0x1812 0x180F, connectable, sourceCore: MainCore, IsELNAOn: 0, IsPassup: 0, IsFromSCCompensation0,  Setting name to Adv360 Pro

I am on the Ventura 13.1 beta, but the keyboard has been working fine with that so far.  I'm going to attempt to flash one of my previous firmware builds.

No luck. I reflashed using my previously working firmware built last month, but it's exhibiting the same problem.

Hi there.
Best bet is to re-pair from scratch.

Forget/Disconnect the keyboard from your PC
Use the Mod + Windows key command to disconnect the PC from your keyboard

Profile LED should resume flashing quickly and you should be able to make a fresh connection.
If that doesn't work, try pairing one of the other 4 channels with a different device like your smart phone and report back.

Back in business. I turned off both halves, reflashed each with settings-reset.uf2, reflashed again with my newest firmware build, turned on the left, then turned on the right. After that I was able to pair the keyboard in Bluetooth settings.
Not sure what I did to get into this state, but I'm glad the reset fixed it.

@KinesisCorporation Thanks for the quick response! I did all of that except the Mod+Windows key. I missed the "Bluetooth clear" section of the manual. That probably would have done the trick easier than the reset I just performed. But problem solved either way, so thanks again!


Add google.auth.crypt

Really great that you added the commands to generate the key files!

@dhermes any outstanding comments?

LGTM

The first module is in!


npm audit security issue

Steps to reproduce:
install angular-cli
install irc-client
npm audit
Result:
     === npm audit security report ===

                                 Manual Review
             Some vulnerabilities require your attention to resolve

          Visit https://go.npm.me/audit-guide for additional guidance

  Critical        Command Injection

  Package         growl

  Patched in      >=1.10.2

  Dependency of   irc-client

  Path            irc-client > irc-protocol > mocha > growl

  More info       https://npmjs.com/advisories/146

  High            Regular Expression Denial of Service

  Package         minimatch

  Patched in      >=3.0.2

  Dependency of   irc-client

  Path            irc-client > irc-protocol > mocha > glob > minimatch

  More info       https://npmjs.com/advisories/118

  Moderate        Regular Expression Denial of Service

  Package         ms

  Patched in      >0.7.0

  Dependency of   irc-client

  Path            irc-client > irc-protocol > mocha > ms

  More info       https://npmjs.com/advisories/46

Also tested in node with the same result.


File not being procesed properly

I'm running the php-cs-fixer lib through atom's beautifier package... and in some cases just not getting proper results...

Any idea why lines 8 and on aren't properly indented?
I tried running the file through command line and same result.

Hi,
Thanks for the report. This could be caused by a few things, like a bug in the fixer or because we don't have the feature to fix what you (yet). I suppose your screenshot is the input for the fixer?
In that case I think your report is the same as https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/1438 (or at least has the same root cause)

Yep that's correct. Thanks @SpacePossum

Closing as feature request duplicate

@raptor235 please, feel free to contribute and propose new fixer for that !


Live Templates intallation

Modificado o instalador do Live Templates, para funcionar com a pasta da Embarcadeiro e não apenas com a do Radstudio.

As it is written this batch file will always favor older versions of Delphi.  Systems that have both new and old versions installed have a 50 50 chance of having a bad outcome.... (or a good one).....  There should perhaps be two batch files, one that favors older versions of delphi and one that favors newer versions.

Adicionei um ajuste no DPR, para o Test Insight

As it is written this batch file will always favor older versions of Delphi.  Systems that have both new and old versions installed have a 50 50 chance of having a bad outcome.... (or a good one).....  There should perhaps be two batch files, one that favors older versions of delphi and one that favors newer versions.

Fechei sem querer.


Visual bugs

[ ] misaligned toast

[ ] nice labels bro

[ ] full screen amount thing should take up full vertical space somehow

[ ] send form should use styled form component

[ ] amount and full bip21 string are both placeholders

[ ] amount and fee display are kind of busted on narrow screen

[ ] style the dropdown just a little bit

[ ] loader is messed up

[ ] icon flashes with blank background

bad close button


process extend for modify async

#274

Changes to process extend triggered by modify async
Fixed error message and return type
Fixed the path for db_cleanup.py tool

@ibaldin Could you please approve the PR too?


CLI to test

Write CLI to test extraction - param should be language, and all the "do_*" flags, maybe a config file?

process.py has the CLI now. Thank  you @justinphan3110 for your help on this.


Add support to copy selected API endpoint to clipboard automatically

Note from @bowtieddeployer:

clicking or double-clicking should copy the API endpoints (one click already gets all the text, but doing this makes the user feel that it is copied on the clip board and it is not)

example:

Hello, @BowTiedDeployer! I know this has been open for a while, and apologies for the delay. We recently added support for testing out API endpoints from the docs, and the "demo panel" provides you the option to run it, test it, change parameters, and copy the cURL or other client code from the panel directly. I think you will love this! 😃
So, yeah, play with it here -> https://docs.hiro.so/api/get-recent-transactions
And here's the "copy" option as a screenshot:


Allow to change the commit's name and email of scaffolder-backend commit function

Hi, as the title has stated, I would like to have a new feature that allow the user to pass in the commit function new username and email, or use something like the user's login email anything apart from the scaffolder default value when creating a new component.
Feature Suggestion

The above function is hardcoded with Scaffolder default value, this could become an issue when using scaffolder backend with Github / Gitlab (I'm not sure about Bitbucket or Azure) Enterprise as the Organization wouldn't be able to recognize this as a member, hence not allowed to push to the repo. In the end result in a creation of an empty repo.

So as mentioned in the other duplicated tickets, I think theres probably step one which we can do pretty simply by supplying config in the app-config.yaml as overrides.
But there's also the option to consider later down the line where we could take the email and name from the IdentityApi and use those details. This hasn't really made any progress yet, but it's something that we've spoken about internally and are looking at implementing maybe later this year. We need to know who the user is to use their Identity to create the Github repos using that authentication method too rather than using a PAT or Github App.

Done in https://github.com/backstage/backstage/pull/6275


Liquid customizations to most of checkout disabled when using checkout UI extension app

Describe the bug
When a merchant uses a checkout UI extension app, any changes to the checkout.liquid file are limited only to the order status page.
The merchant is requesting for automatic expansion of the order summary details (on mobile), and usually this would be possible with a small script within checkout.liquid, but simultaneously using a checkout UI extension app seems to break this behaviour.
I'm not sure if this should be a bug or a feature request, but either way it's not something that was expected. Is there a workaround for this issue by any chance?
Steps to reproduce the behavior:

Create checkout UI extension app
Active app in checkout editor within a Plus store
Navigate, within the theme files, to checkout.liquid

Expected behavior
Changes to checkout.liquid would apply to checkout pages as usual
Screenshots

When a merchant utilizes checkout extensions, it replaces checkout.liquid as the checkout that renders extensions is incompatible with checkout.liquid.
I do think your point is worth discussing in that some merchants need control over the dom to handle common requests:

Open cart on mobile by default
Hide discount code form

These were both possible prior to extensions but no longer possible.


allow numpy 1.23

numpy commits between the latest 1.22 (currently allowed on master) and latest 1.23 (which would be allowed by this PR):
https://github.com/numpy/numpy/compare/v1.22.4...v1.23.5
This will enable my team to upgrade packages in our development environment.

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

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @Zhangyx39
would you be able to review? thank you!!

oops, sorry i meant to open this PR against upstream


feat(prow/config): add color to some labels

Signed-off-by: wuhuizuo<EMAIL_ADDRESS>
What problem does this PR solve?
Issue Number: close #xxx
Problem Summary:
What is changed and how it works?
What's Changed:
How it Works:

/approve


ipcache: Better logging for conflicting named ports

Fixes: #11423

test-me-please

Coverage decreased (-0.01%) to 36.87% when pulling e39f8f843b0002891028053d355fd48cd4d0c105 on pr/jrajahalme/named-ports-cleanup into 2c03d318b666654e56e64476dc851b7a6e898b9f on master.

known flakes only

test-me-please

The CI was green https://github.com/cilium/cilium/pull/11702#discussion_r431088767 merging since the only requested changes were log messages.


Add a query page to the admin UI, change to dotenv

This change adds a query page to the admin-ui.
It supports:

Querying

Querying Bigdawg from the browser admin ui

Tabular Results

Displays the results inline in a formatted table in the browser

Export CSV

Exporting the results to CSV

In addition it makes the following change:

dotenv support

Delete catalog_config.txt

Removes catalog_config.txt and ports the variables to dotenv format

env.sample

Adds a env.sample file to get started

README.md

Adds a README.md to help users get up and running

Please see #4


Update physics informed darcy examples

Modulus Pull Request
Description
Some updates to the gradient computation and PDE usage for the Physics Informed Darcy examples.
Checklist

[x] I am familiar with the Contributing Guidelines.
[x] New or existing tests cover these changes.
[x] The documentation is up to date with these changes.
[ ] The CHANGELOG.md is up to date with these changes.
[ ] An issue is linked to this pull request.

Dependencies

/blossom-ci

/blossom-ci


doc: add documentation for pkgs.{substitute,substituteAll,substituteAllFiles}

Fixes https://github.com/NixOS/nixpkgs/issues/65252
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Converting to draft due to inability to build locally: https://github.com/NixOS/nixpkgs/issues/326380
Based on conventions, looks like I may need to:

Add subheadings for inputs and examples?

@NixOS/documentation-team can you take a look and let me know about next steps?

Bump for @NixOS/documentation-team -- anyone able to take a look and provide a little guidance for my first documentation contribution?

@hsjobeki thank you for your review! I've implemented many of the changes in the latest push.

@hsjobeki thank you for your attention to detail! Updated accordingly.

@fricklerhandwerk thank you for your input and sorry for the delay -- I moved this month, so it's been a little busy.


ENH AWS remove availibity zone group from the setting up instance

by setting availability zone group we are limiting our possible resources, therefore it is better not to set it.

REGION_NAME_FIELD is still used somewhere?

REGION_NAME_FIELD is still used somewhere?

Yes:
https://github.com/paris-saclay-cds/ramp-board/blob/b2bd7e398c27a9a3842d087c301ba07a393f46e4/ramp-engine/ramp_engine/aws/api.py#L897

Yes:
https://github.com/paris-saclay-cds/ramp-board/blob/b2bd7e398c27a9a3842d087c301ba07a393f46e4/ramp-engine/ramp_engine/aws/api.py#L897

Thx

Thx


Algolia Events triggered from Segment but not shown in algolia dashboard

I have used the algolia_helper_flutter: ^0.3.1 as the zip and integrated directly to the project, because the plugin is not merged properly so we don't have the click anayltics param.After integrating it directly i can trigger the event of segment using algolia params also.
Segment.track(eventName: 'test', options: {
'product_id': '507f1f77bcf86cd799439011',
'sku': 'G-32',
'category': 'Games',
'name': 'Monopoly: 3rd Edition',
'brand': 'Hasbro',
'variant': '200 pieces',
'price': 18.99,
'quantity': 1,
'coupon': 'MAYDEALS',
'position': 3,
'url': 'https://www.example.com/product/path',
'image_url': 'https://www.example.com/product/path.jpg',
//algolia params
'index': 'my-algolia-index',
'eventType': 'click',
'queryID': _shoeSearcher.responses,
'objectID': '131280270'
});
Algolia Events triggered from Segment but not shown in algolia dashboard
I have used the algolia_helper_flutter: ^0.3.1 as the zip and integrated directly to the project, because the plugin is not merged properly so we don't have the click anayltics param.After integrating it directly i can trigger the event of segment using algolia params also.
Segment.track(eventName: 'test', options: {
'product_id': '507f1f77bcf86cd799439011',
'sku': 'G-32',
'category': 'Games',
'name': 'Monopoly: 3rd Edition',
'brand': 'Hasbro',
'variant': '200 pieces',
'price': 18.99,
'quantity': 1,
'coupon': 'MAYDEALS',
'position': 3,
'url': 'https://www.example.com/product/path',
'image_url': 'https://www.example.com/product/path.jpg',
//algolia params
'index': 'my-algolia-index',
'eventType': 'click',
'queryID': _shoeSearcher.responses,
'objectID': '131280270'
});
In segment the event delivered successfully, but i cannot see any trace in the algolia dashboard.

Am expecting to visible the event in algolia.

@Abisheik-IAN sorry, can you reword your question? I dont totally understand your issue.
As far as I can understand you can see the event in segment and thats what this library does, now on the Algolia side, this has nothing to do with it so Im not sure how to help.


branch name conflict upon git fetch on mac

MacOS filenames are case-preserving but not case insensitive. In this repository, there are two branches named docs and DOCS/docs_initializing_mkdocs_documentation. The branches live as directories in .git/refs/remotes/origin, and the slash becomes a subdirectory; hence the git fetch tries to create both docs and DOCS in the .git file structure, and fail to do so because they are the same to the MacOS filesystem. Is it possible to rename either branch to avoid the conflict?

Hi @maparent , I renamed and deleted this branch from the remotes. Let me know if this is now resolved!

Thank you!


main: change port with $PORT, log http.ListenAndServe errors

I have 8080 in use on my machines already.

looks great, merging :+1:


Avoid resource dependency when having both Redis Server & Sentinel

When running Redis Server & Redis Sentinel on the same node, avoid a
resource dupplication with package resource.

wow, fast merge :-)
probably another patchset later

keep 'em coming ;)


docs: Add documentation to clarify how to tell whether a custom tap uses catalog vs properties

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2683
Originally created by @nickhamlin on 2021-03-29 21:27:24

This is pretty easy to determine if you know to look for usage of args.catalog vs args.properties, and having that pointer more clearly mentioned in the documentation for implementing custom taps would be useful.

View 5 previous comments from the original issue on GitLab

This is still relevant - I don't think the spec or Hub docs make this distinction super clear.


Nginx performance optimization

Came across a nice article. Need to check if EE is doing it right.
https://t37.net/nginx-optimization-understanding-sendfile-tcp_nodelay-and-tcp_nopush.html
By the way, if anyone has any other performance optimization ideas/articles, please share here.

I would love to find out what's the perfect config for EasyEngine to get around 500 million hits a day (let's say 10000 users per min with blitz.io).
Like I have the 320$ droplet from DO, I have a remote MariaDB with 16GB of ram, installed the EE stack with Redis and HHVM, and when I get close to 5000 users per sec, everything goes down.

Recently found out that Google has a PageSpeed module for apache/nginx. Haven't used it, so I can't if it's effective or if it may have any conflicts. It should also be noted that the [packages on the download page] (https://developers.google.com/speed/pagespeed/module/download) are apache only, and that for nginx, it has to be built from source.
https://developers.google.com/speed/pagespeed/module
https://developers.google.com/speed/pagespeed/module/build_ngx_pagespeed_from_source

@rahul286 ,
Found that, keeping sendfile, tcp_nopush and tcp_nodelay on will speed up static content time upto 0.2secs.
We are allready doing that in EasyEngine.


ndingest tutorials

ndingest

[ ] 8-bit single channel volume
[ ] time-series
[ ] multichannel
[ ] add "Paint"channel
[ ] add RAMON channel

for each, in notebook,

[ ] ingest
[ ] xy plane to check
[ ] propagate
[ ] xy plane to check that propagate works

directory containing tutorials: https://github.com/neurostorm/tutorials/tree/master/ndstore

that's awesome.
these work?
shall we differentiate ones that are "complete" and "drafts"?
On Sun, Dec 18, 2016 at 10:00 PM, Greg Kiar<EMAIL_ADDRESS>wrote:

directory containing tutorials: https://github.com/neurostorm/
tutorials/tree/master/ndstore
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/neurostorm/meta/issues/1#issuecomment-267871575, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACjcv_eF9Vj_fBmbpVL5FgXGbslu1Isks5rJfMxgaJpZM4LB5lg
.

--
the glass is all full:  half water, half air.
neurodata.io, jovo calendar
https://calendar.google.com/calendar/embed?src=joshuav%40gmail.com&ctz=America/New_York
starting in 2017, i will be responding to emails approximately weekly,
so that i can focus more on the people around me.
thank you for your understanding.

Great point! I put those not yet ready into drafts/. Of note: no links between them are currently active


[backport] Fix overlapping out in matmul and (tensor)dot

Backport of #6216 by @toslunar

/test mini


wip: Add c_char type

Some preliminary work on adding a c_char type to correspond to the char c type. Any questions/discussion is welcome.
Why do we need this?
Currently a char type is translated from c as a u8. This is wrong for two reasons.
First, the sign of a char for each platform is implementation defined. This causes issues since it means both u8 and i8 are not compatible with char. This is easy to see when trying to create an exportable zig function which takes a char compatible parameter (impossible with the status quo). Even common targets differ; arm for example uses an unsigned char vs. x86_64 using a signed char.
Second, a char is not necessarily 8 bits. However, on all common platforms this is true (and I think all LLVM support?). This is of much lower concern and I think the assumption that it is always 8-bits is fine to keep right now.
What to add

[x] translate-c needs to convert char to c_char types
[ ] translate-c needs to check the requested target environment and generate different headers depending on the targets char signedness.
[x] documentation updates
[ ] update stdlib os functions to handle different c string type (see questions).
[ ] the stdlib needs to be updated at the os level to handle the change of type for cstring types which now are of type []const c_char instead of []const u8.

Questions
Would implicit casting from []const c_char to []const u8 make sense? I've had a brief look at changing the required os functions and it makes usage a fair bit more annoying to use c strings with low-level os zig functions. I may follow up with a port of the linux os functions and see how that fares. We can always do an explicit @ptrCast.

My original rationale for not having a c_char type is this:

C leaves the signed-ness up to the implementation, and therefore C source code which uses char is defined to be correct regardless of the signedness that is used for char.
Therefore we can just pick unsigned, and C source code will be correct. For example when doing translate-c, I believe it is sound to translate char to u8.
Having the signed-ness be (non-implementation-) defined is desirable

You have pointed out a use case where this falls short:

This is easy to see when trying to create an exportable zig function which takes a char compatible parameter (impossible with the status quo).

I agree that zig should be able to export a function (or type) that uses the char C type. Although I think that explicitly using unsigned or signed is better in new C APIs, one of Zig's use cases is matching a C library's interface but having a different implementation.
But is there another use case for c_char?  If not, here's an idea: c_char is exactly the same as u8, except for the purposes of generating .h files, in which case it generates char instead of unsigned char. Translate-c would still translate char as u8. We would not need to modify the zig std lib.
One more thing:

translate-c needs to check the requested target environment and generate different headers depending on the targets char signedness.
I believe clang takes care of this automatically, provided that we are passing the correct -triple argument; I don't remember if we implemented this yet or not.

One more thing: if this is for #514 (libc in zig), I suspect that the best strategy here may be to ignore the .h file generated by zig and instead manually create (or copy from musl) the .h file, and then have zig provide the implementation only. I believe the libc spec requires specifically named headers and certain kinds of macros and other one-off requirements, to the point where I would not try to wrangle zig's auto .h file generation for this particular use case.

Good points. The conversion of c_char to u8 seems like a good fit in general and is a good solution for now I think. I'll modify this PR to provide that behavior.
Partly inspired by the libc work but that was always going to need separate headers anyway due to the many macro requirements so no issues there.

Closing for now since it isn't immediately pressing and if we want c_char as a u8 alias except for the header generation it seems to require a few changes to how we deal with the type entries for u8 everywhere.
Refer to #875.


Change game executable location

I accidentaly set the location of the executable of one of my games to the installer instead of the game, so when I click play it tries to install.
An option to change the path to the game's executable would be extremely helpfull.

It is a planned feature (#118)
Until this feature is implemented, an alternative option to solve your problem would be: remove the game from your library and then add it again. It will ask you to choose an .exe location and you could set the right one

In 2.0 we added a new window which gives you this possibility


Solar Activity Plugin

The plugin should be able to display Solar disk with active sunspots and data for them in a separate tool window.
Solar region summary can be obtained from ftp://ftp.swpc.noaa.gov/pub/forecasts/SRS/
The tool should be able to show sunspots positions and data for desired day entered by user.
Also it will be nice if user can have ability to specify image for the Sun. Images can be downloaded automatically from https://sohowww.nascom.nasa.gov/data/realtime-images.html

SRS (Solar Region Summary)
Data can be obtained from anonymous FTP:
ftp://ftp.swpc.noaa.gov/pub/warehouse/{YYYY}/SRS/{YYYY}{MM}{DD}SRS.txt
File format description: ftp://ftp.swpc.noaa.gov/pub/forecasts/SRS/README
SGAS (Solar and Geophysical Activity Summary)
Data can be obtained from anonymous FTP:
ftp://ftp.swpc.noaa.gov/pub/warehouse/{YYYY}/SGAS/{YYYY}{MM}{DD}SGAS.txt
File format description: ftp://ftp.swpc.noaa.gov/pub/forecasts/SGAS/README
RSGA
TBD
GEOA
TBD


Remove NIOHTTP2StreamDelegate Sendable requirement

Motivation:
Remove NIOHTTP2StreamDelegate Sendable conformance requirement. This wasn't needed in the first place because NIOHTTP2Handler is not Sendable, therefore it never leaves the thread on which it is created.
The delegate may still be Sendable depending on the implementation but it is not a strict requirement.
Modifications:
Remove NIOHTTP2StreamDelegate Sendable requirement
Result:
Sendable is no longer required for NIOHTTP2StreamDelegate conformance

API breakage is expected and is okay because we haven't cut a release since this API was added.


TabularNueralNetTorchModel not yet able to use more than 1 GPU

I am trying to train the tabular models on 2 GPUs but it seems NeuralNetTorch only supports 1 GPU. Here is the log message:
"
TabularNeuralNetTorchModel not yet able to use more than 1 GPU. 'num_gpus' is set to >1, but we will be using only 1 GPU.
"
Is there any plan to support multiple GPUs in the future? Thanks in advance for your help.

Closing this issue in favor of #4214


$stateProvider documentation isn't obviously available

$stateProvider.state is the most logical place to start learning about how ui-router can be configured, and yet, the documentation for this method is not easily viewable in the docs made available here: http://angular-ui.github.io/ui-router/site
The $stateProvider module is not listed in the Table of Contents/sidebar. When you access the ui.router.$state module, all you see is the documentation for $state itself (as expected).
If, however, you search for $stateProvider first, and then click on ui.router.$state, only then will you see the documentation for $stateProvider.
The search also yields only two other documents containing references to $stateProvider, and in both cases, the text is found in a code example and is not hyperlinked.

I'm not sure how it could be made any more obvious than this:

Ah. I knew I was missing something. Thanks!
It's a bit of a confusing interface element, in my opinion. If you look at the rest of the ToC, the right column is used to group and qualify the elements in the left column:

ui.router.router is a module
$urlRouter is a service
ui-sref is a directive, etc.
I saw the Provider label, but because it was in the right column, I read that as $state is a Provider. It didn't occur to me that this was a separate entry.
Also, the selected state doesn't distinguish between the main or the Provider entry, making it seem as one.

They kind of are one.
The Provider link is differentiated from the grouping because of the different styling (color, size, casing, icon).
While I agree its not the most intuitive, its does work and after the first clicking it, it should be more clear. If you have a suggestion on how to improve it while still keeping things automated, please feel free to submit a pull request.

It's a standard template for Angular projects, so it's kind of a wider 'issue', if you can call it that.


IndexError: dimension specified as 0 but tensor has no dimensions

🐛 Bug
TPUs training throwing the following error during validation.

Expected behavior

Environment
Note: Bugs with code are solved faster ! Colab Notebook should be made public !

IDE: Please, use our python bug_report_model.py template.

Colab Notebook: Please copy and paste the output from our environment collection script (or fill out the checklist below manually).

You can get the script and run it with:
wget https://raw.githubusercontent.com/PyTorchLightning/pytorch-lightning/master/tests/collect_env_details.py
# For security purposes, please check the contents of collect_env_details.py before running it.
python collect_env_details.py

PyTorch Version (e.g., 1.0):
OS (e.g., Linux):
How you installed PyTorch (conda, pip, source):
Build command you used (if compiling from source):
Python version:
CUDA/cuDNN version:
GPU models and configuration:
Any other relevant information:

Additional context

@kaushikb11 Any code to share ?

@tchaton https://colab.research.google.com/drive/1rHBxrtopwtF8iLpmC_e7yl3TeDGrseJL?usp=sharing
The one, Will shared.


Unable to download binocular videos correctly when downloading 180 degree VR 3D videos, only monocular 2D flat videos are available

Version
V1.12.2
Platform
WIN11
Steps to reproduce
Unable to download binocular videos correctly when downloading 180 degree VR 3D videos, only monocular 2D flat videos are available
Details
Unable to download binocular videos correctly when downloading 180 degree VR 3D videos, only monocular 2D flat videos are available
Checklist

[X] I have looked through existing issues to make sure that this bug has not been reported before
[X] I have provided a descriptive title for this issue
[X] I have made sure that this bug is reproducible on the latest version of the application
[X] I have provided all the information needed to reproduce this bug as efficiently as possible
[ ] I have sponsored this project
[ ] I have not read any of the above and just checked all the boxes to submit the issue

Can you provide an example video?

This may have been fixed by #519. Please re-open if the issue persists.


Remove Guzzlehttp version restriction

Can you please change to "guzzlehttp/guzzle": "^5.3.1|^6.2.1",. It works fine and resolves compatibility issue in composer with other libraries, which use recent version of guzzle.

ok thanks


Show email if user's name is empty

#40 Fixed

Codecov Report

Merging #46 (3cc2e18) into main (ffa4021) will decrease coverage by 0.02%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main      #46      +/-   ##
==========================================
- Coverage   52.18%   52.15%   -0.03%
==========================================
  Files          50       50
  Lines        1922     1923       +1
  Branches      121      122       +1
==========================================
  Hits         1003     1003
- Misses        898      899       +1
  Partials       21       21

Impacted Files
Coverage Δ

frontend/src/components/Settings.tsx
16.66% <0.00%> (-3.34%)
:arrow_down:

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 ffa4021...3cc2e18. Read the comment docs.


RAID WW2 weapons FR update.

In reality, I've just translated the RAID WW2 missions, Since the only potential weapon that could be translated is the "Springfield Armory M1 Garand", but since the name of the armory seems to be "Springfield Armory", I didn't decide to translate it.
Also, Fixed a little typo Motorola.

thanks for the update


mag field consistency

Make mag_1_field more consistent (propogate 'g','r','i' throughout)

I don't really remember what this meant (and I don't notice it as a problem), so closing.


Show all Cells within the battery on console detail screen

My current BMS can either be connected to BT or Serial connection to VenusOS.  I get to see all cell voltages in BMS , but would like to have the BMS sending the low and high cell to the VenusOS to control charge / discharge of the battery.
I would like to display all 16 cells in the detail, and have this accessible using the Console.
I have decided to return my current BMS and replace with one that supports dual connection.  This functionality would still be very useful for single connection devices.

What benefit do you see in having all the cell voltages available vs. just the min/max cell voltages that VenusOS currently support?
I know it will be nice to see. I am just trying to guage priority and if this is only a nice to have or has some benifit not currently available elsewhere.

The detail about batteries don't have concrete benefits.  I find it is easier to see if the min/max when compared to the average.  It is easier for me to interpret the state of each battery cell that way.  Even with lower priority , I might take this one up on myself to complete.

The Chargery BMS driver  has support to display all the cells. The QML will need to be changed to add to the display (see gui\qml).
In Victron land anything that is None will not be displayed, and this would be preferred as the driver support batteries with few to many cells (3-32 mostly).
Also if we bring in the extra battery banks then this will complicate the display more. Something to keep in mind.

+1 .. one of the things I look a the most in the BMS app right now (about to actually connect this to Venus soon) is individual cell voltages.   it let's you know if a particular cell is going rogue, or is it just .05v deviation from the rest.
With the QML, are you saying if someone wanted that data, just add the pointers / references in the QML and it will work?

@neoneddy , The VenusOS only contain the min/max cell voltages. If you have a rogue cell you can see it as either the min or the max will have larger differenaces from the other. This is also there the BMS min/max cell graph come in.
However, if we would want to show all the cell voltages, then these will need to be populated as non standard extra fields on VenusOS, and we also need to create/edit a view to display them with the QML.
So no, it will not work only adding QML.

@Louisvdw Ok, makes sense. I think the min/max will work fine.

Showing the Delta between the cells, a be a very useful visual indicator of a problem.

@Louisvdw, I had the same need as @ddarek2000, so I added this feature. If you are interested I can send you required changes.
Updated files are : battery.py (making available individual cell voltages + cell balancing), dbushelper.py (publishing cell voltages to /Voltages/ and balancing to /Balances/), PageBattery.qml (added submenu for Cell Voltages, if available) and new file PageBatteryCellVoltages.qml.
4 cells are visible per line. When the cell is balancing the background on the cell turns red.

This is awesome!  I love the Red balancing background.

@Louisvdw, I had the same need as @ddarek2000, so I added this feature. The pull request #87 is in queue. Updated files are : battery.py (making available individual cell voltages + cell balancing), dbushelper.py (publishing cell voltages to /Voltages/ and balancing to /Balances/), PageBattery.qml (added submenu for Cell Voltages, if available) and new file PageBatteryCellVoltages.qml. 4 cells are visible per line. When the cell is balancing the background on the cell turns red.

What if one uses 18 cells on 48v system?
Is that possible, today being the exception, slowly becoming a viable option between 16/17 and 18 cells.

@neoneddy thanks. I am just giving back to the community.
@Jaco-TTT the backend publishes 24 cells, so all you need to do is to edit the gui file - /opt/victronenergy/gui/qml/PageBatteryCellVoltages.qml
after the line :
	property VBusItem _b16: VBusItem { bind: service.path("/Balances/Cell16") }
add :
	property VBusItem _b17: VBusItem { bind: service.path("/Balances/Cell17") }
	property VBusItem _b18: VBusItem { bind: service.path("/Balances/Cell18") }
after the line :
	property string c16: _b16.valid && _b16.text == "1" ? "#ff0000" : "#ddd"
add :
	property string c17: _b17.valid && _b17.text == "1" ? "#ff0000" : "#ddd"
	property string c18: _b18.valid && _b18.text == "1" ? "#ff0000" : "#ddd"
and after the :
		MbItemRow {
			description: qsTr("Cells (13/14/15/16)")
			values: [
				MbTextBlock { item { bind: service.path("/Voltages/Cell13") } width: 70; height: 25; color: c13 },
				MbTextBlock { item { bind: service.path("/Voltages/Cell14") } width: 70; height: 25; color: c14 },
				MbTextBlock { item { bind: service.path("/Voltages/Cell15") } width: 70; height: 25; color: c15 },
				MbTextBlock { item { bind: service.path("/Voltages/Cell16") } width: 70; height: 25; color: c16 }
			]
		}
you need to add :
		MbItemRow {
			description: qsTr("Cells (17/18)")
			values: [
				MbTextBlock { item { bind: service.path("/Voltages/Cell17") } width: 70; height: 25; color: c17 },
				MbTextBlock { item { bind: service.path("/Voltages/Cell18") } width: 70; height: 25; color: c18 }
			]
		}
the file can be edited using for example this command : nano /opt/victronenergy/gui/qml/PageBatteryCellVoltages.qml
then you need to restart the gui using these commands :
svc -d /service/gui
svc -u /service/gui

Nice work @piapiacz
Thanks for sharing your changes. I'll review the PR as soon as I can

@Louisvdw ok, thanks.


[Bug] The session is cleared when the client is redirected back from the payment gateway

Describe the bug
When the client is done with the payment and the payment gateway redirects them back to the website (to /invoice/thank-you/*), the session is destroyed.
How to reproduce

Do a payment
Get redirected to the "thank you" page
See if your session is destroyed

Expected behavior
The session should persist
FOSSBilling version
0.4.3

#1630 is probably related to this.

#1630 is probably related to this.

It is not. This never effected the stripe integration & is specific to other payment gateways.
More specifically, I think this was replicated using the Mollie integration and I am unaware of it happening with other ones, but I haven't tried to replicate it.

Yes I had the same issue with other payment modules (Mollie)


Quickturn Fix for Matilda

Describe the feature you'd like to see added
this is just a simple request to add the quickturn that you can do with other weapons to the matilda
Example:
https://user-images.githubusercontent.com/103059961/170780773-fff5f984-3456-4440-9966-eb9c5b89f4ab.mp4
Edit: User Qingsheng has shared on how to enable it in the exe
515C3D change to 8BECE8DCC8DDFF8B86D8070000D95830EB04CC55EBEA
516640 change to E90B4AFEFF90
Im not sure if the lower code is for the matilda or something else this would need to be tested

User Qingsheng has shared on how to enable it in the exe

Do you know what version of EXE those are for? Tried checking in both 1.1.0 & 1.0.6 and looks like those addrs aren't valid in either (both are in the middle of an instruction...)

im not entirely sure but i know it works for 1.0.6 i just tried it and it worked here is the exe if you wanna check it out
https://drive.google.com/file/d/15Tn3hZLxMcJAva0tiIvsLoIqlHBtYOag/view?usp=sharing

Ohh right they're file offsets, thought they were memory addrs lol, I'll try having another look at it later.

Just had a look at those patches, they're pretty smart, qingsheng is on another level than me lol
Seems he patches wep17_r3_ready00 to use CameraControl::getCameraDirection and store result inside this+0x7D8+0x30, and also patches wep17_r3_ready10 to jump to wep02_r3_ready00 instead, pretty neat way of doing it.
Will try looking into it more soon.

Made a PR for it at #218, any chance you could check that build and make sure it works the same as the EXE patch did?
Build artifact can be found at https://github.com/nipkownix/re4_tweaks/actions/runs/2506930793


Create Zenodo release

Please provide a valid and accessible web-link of Zenodo (for the archived data, growth_phenology repository of the ForestGEO Ecosystems & Climate Lab ) data here in the reporting summary and the 'data availability' section of the manuscript.

Do this after issue #149

This is now awaiting issue #152 .

Done! Here it is in Zenodo: https://zenodo.org/record/6632091#.YqNnp2DMLCU.
DOI 10.5281/zenodo.6632090


(Inviting Guests) Inviting Guests

Ready for review. @simong and I will have a call regarding high-level overview of what this is introducing.
Note the consolidated "Inviting Guests" portion of the bottom of the upgrade guide: https://github.com/oaeproject/Hilary/wiki/OAE-Upgrade-Guide

Self-review complete. To @simong for review

@simong lets have a call first thing tomorrow morning (my first thing...) to go over a high-level run through of what the heck just happened.

I've gone through how a guest can be invited, create an account and link his new account with the invited resources. This took me a while to figure out and I had a pretty good idea of how this all fits together. I can imagine that for new devs this might be completely overwhelming. Could you sketch out how all of this fits together in a wiki document perhaps?

I have a public user "Alice" in the "Cambridge" tenant and a loggedin user "Bob" in the guest tenant.
When Alice tries to create a public link and adds Bob (through his email address) she gets:

The current user does not have access to add the specified principals

Is that expected?

I have a public user "Alice" in the "Cambridge" tenant and a loggedin user "Bob" in the guest tenant.
When Alice tries to create a public link and adds Bob (through his email address) she gets:

The current user does not have access to add the specified principals

Is that expected?

Only if either of the tenants are private. Can you ensure the member in the POST request looks like bobs@email.address:u:bobs:userid ?

No, both tenants are public (Bob is on the guest tenant if that matters).
The UI tries to add Bob by doing:
viewers=u:guest:123456

FWIW, I triggered the above issue (adding Bob from a loggedin tenant to a new content item) in the UI. When I manually send bobs@email.address:u:bobs:userid in the create content request, it works fine. I'm going to assume that's a UI issue

Yea that's a UI issue. I'll try and reproduce.

@simong that bug should be fixed if you update your 3akai-ux branch

@simong I wrote up the process here: https://github.com/oaeproject/Hilary/wiki/Inviting-Guests
Let me know if this is what you were looking for.

Can confirm latest 3akai-ux#inviting-guests fixes it

@simong can you give a review to the (InvitingGuests)-tagged commits that were added after after my followup? I've added some performance improvements in tenant indexing for doing email domain matching.

In the _updateCachedTenant method we're performing tenantEmailDomainIndex.update twice. That seems unnecessary?

Other than that double update, this LGTM

Merged!!!


fix: make camera target position relative

The movePlayerTo action, takes both a position and a camera rotation.
The problem is that the position was relative, but the cameraTarget had to be global for it to work. We are now fixing that
Fixes https://github.com/decentraland/explorer/issues/1777

This PR should be merged on 2021, after all XMas events are over


(feat) add $ROOT variable in the shift operation to perform root payload shifting

Signed-off-by: Noah Kreiger<EMAIL_ADDRESS>This change would support a variable $ROOT in the shift operation to move everything in the root payload under that key, it maintains backwards comp...and makes logical sense, aka, if you add a variable before you shift the root, it will shift with that variable, if you store a variable after the shift, you need to specify the path taking into account the shift...etc
Examples:
  context:
    - operation: store
      paths:
        - key: $id
          value: id
  data:
    - operation: store
      paths:
        - key: $tstore
          value: test
    - operation: add
      paths:
        - key: context.transaction
          value: $id
        - key: shifted.test
          value: noah
        - key: noah
          value: $tstore
    - operation: shift
      paths:
        - key: $ROOT:data

input ->
{
    "test": "teststore",
    "Shifter": {
        "some": "values"
    }
}

outputs from tsf ->
{
    "data": {
        "Shifter": {
            "some": "values"
        },
        "context": {
            "transaction": "say-hello"
        },
        "noah": "teststore",
        "shifted": {
            "test": "noah"
        },
        "test": "teststore"
    }
}

I didn't abstract the code as much as it could've been, because I couldn't think of another use case, so I thought I would keep it simple :)

@nkreiger would you mind running make fmt on your local branch? That should fix the last test.

Also... I dont think you are in our community slack -> https://join.slack.com/t/triggermesh-community/shared_invite/zt-1e0wvv0ud-CoM_73OBunIDoYR29eMo8A @nkreiger  jump in so I can bug you! 😁

pre-approving, before test fixes.

@JeffNeff it looks like the linting failed on a code file unrelated to my chagne, would you like me to resolve this as well?

@nkreiger Thanks for the PR. Before I review the code, does this change somehow correlate with this https://github.com/triggermesh/triggermesh/pull/1049 ?

@nkreiger Thanks for the PR. Before I review the code, does this change somehow correlate with this #1049 ?
@tzununbekov yes lol, exactly, I guess I should've looked at open PRs/Issues first but it was a quick thing so I didn't my bad...I can close this PR


Bump to Alpine version

Bump to Alpine version to fix some CVEs in the base image.

@jiaqiluo thanks for the info. Since this is the first time that I'm doing this kind of version bump, after I create the new tag, could you point me to where in Rancher (or the charts?) do I need to update to reflect the new tag, please?

@macedogm  AFAIK, rancher/fleet is the only place where the image rancher/tekton-utils is used: https://github.com/rancher/fleet/blob/master/charts/fleet/charts/gitjob/values.yaml#L5-L7
You can search in the rancher/fleet repo for relevant commits/PRs


How To clear Directions

Is there a set directions Display to true or false option in ngmaps or the possibility to clear a route completely off of the map.

Please look into the directionsRendered api reference. https://developers.google.com/maps/documentation/javascript/3.exp/reference#DirectionsRenderer,  If it's not there, it's not in ng2-map either.

Thanks for the feedback i will post back what my findings are.

You can also remove the directive using ng-if or try it manually.
http://stackoverflow.com/questions/5645920/remove-directions-from-google-map-api-v3


Text with inline styles disappears from pdf.

When using text, certain combinations of inline styles and text contents cause the text to not appear in the generated pdf file.
I can't discern a pattern in what strings cause this, but it doesn't happen when parse_styles=False.
Here's a minimal example:
import nelsie

deck = nelsie.SlideDeck(width=320, height=240)

@deck.slide()
def _(slide: nelsie.Slide) -> None:
    s = "~monospace{s} specifi"
    slide.text(s, parse_styles=False, bg_color="#fa8080")
    slide.text(s, parse_styles=True, bg_color="#80fa80")

deck.render("repro", "svg")

The cut-off is expected due to slide deck dimensions being small. But the second line looks very strange in the .svg and doesn't appear at all in the .pdf.
This is using version 0.6.0

Thank you for your report. I can reproduce it and I will look at it.

Thanks for looking at this. I just ran into the bug again with new strings:
slide.text("~code{start} creates a ~code{From} value.")
slide.text("~code{finish} takes a ~code{To} value.")

Both lines don't appear in the pdf.

My first investigation is that it is a bug in an upstream crate usvg that converts text in to paths. It seems that the bug is already fixed but because of another dependency (svg2pdf) we are still on the buggy version. In next days I will try to investigate how to upgrade without breaking dependencies.

I have tested dev version of svg2pdf and it seems to work. The main problem is now that the new version of usvg made substantial changes in API. I have started to work on port of Nelsie to the current version of usvg but it will take some time.

Btw: It seems that the text disappears when ligature is created, so a temporary workaround is to use a monospace font that usually does not create ligatures. I know, not a great solution ...


Credentialed Response returning "True" mismatch with "true"

when setting "allow-credentials": true, getting error:
Credentials flag is 'true', but the 'Access-Control-Allow-Credentials' header is 'True'. It must be 'true' to allow credentials.
In ControllerHandler, line 85, bools converted via ToString() which returns "True" rather than "true". Was able to use ToString().ToLower() and it seems to be working fine. Sorry didn't have time to set up a pull but will try to get there.

Thanks Joseph. I have made the fix along with some refactoring in the latest commit.

Also, published Frame.Cors v0.2.1 to nuget.


There is a Fade In/Out effect?

There is a Fade In/Out effect?

No sorry , but you can create pr for it.
It should be relatively easy , but it is mostly based on what do you want to do.

Can you create a class for it?
/**
 * Set this PageTransformer on a ViewPager. It will be invoked anytime it's pages are scrolled.
 * This transformer has the effect of fading in and out pages on top of each other.
 */
public class FadePageTransformer implements ViewPager.PageTransformer {

    @Override
    public final void transformPage(final View view, final float position) {
        final int pageWidth = view.getWidth();

        /*
         * When a page's alpha is set to 0 it's visibility should also be set to gone.
         * Even though the view isn't visible it can still be interacted with if it isn't gone and is drawn on top.
         */

        /*
         * Position is checked right up next to -1 and 1. The reason is because sometimes the position doesn't seem to come
         * all the way through as a whole number. Meaning it seems it would stop so very close to -1 or 0 (for example) and
         * the code to make necessary views 'gone' never gets called. So then there could be an invisible view on top that is
         * still able to be interacted with.
         */

        if (position < -0.999f) { // [-Infinity,-1)
            // This page is way off-screen to the left so hide it.
            view.setAlpha(0);
            //view.setVisibility(View.GONE);
            view.setTranslationX(pageWidth);
        } else if (position <= 0.999f) { // (-1, 1)
            // The further the page is from being center page the more transparent it is.
            view.setAlpha(getAlpha(position));
            // Counteract the default slide transition
            view.setTranslationX(pageWidth * -position);
            // Make sure the page is visible
            //view.setVisibility(View.VISIBLE);
        } else { // (1,+Infinity]
            // This page is way off-screen to the right so hide it.
            view.setAlpha(0);
            //view.setVisibility(View.GONE);
            view.setTranslationX(-pageWidth);
        }
    }

    /**
     * Get the alpha value that should be applied to a position.
     *
     * @param position Position to find an alpha for.
     * @return An alpha value.
     */
    private static final float getAlpha(final float position) {
        return getSlowQuadraticAlpha(position);
    }

    private static final float getLinearAlpha(final float position) {
        if (position <= 0) {
            return 1 + position;
        }
        return 1 - position;
    }

    private static final float getFastQuadraticAlpha(final float position) {
        final float linearAlpha = getLinearAlpha(position);
        return linearAlpha * linearAlpha;
    }

    private static final float getSlowQuadraticAlpha(final float position) {
        return 1 - position * position;
    }

}

@prsolucoes I will test it and upload it today.

@prsolucoes doesn't work correctly while scroll forward. backwards works correctly