Partial borrowing (for fun and profit)

Consider the following struct and impl for 2D coordinates:
struct Point {
    x: f64,
    y: f64
}

impl Point {
    pub fn x_mut(&mut self) -> &mut f64 {
        &mut self.x
    }

    pub fn y_mut(&mut self) -> &mut f64 {
        &mut self.y
    }
}

fn main() {
    let mut point = Point { x: 1.0, y: 2.0 };
    // ...
}

Even in this simple example, using point.x and point.y gives us more flexibility than using point.mut_x() and point.mut_y(). Compare following examples that double the components of a point:
{
    // Legal:
    point.x *= 2.0;
    point.y *= 2.0;
}
{
    // Legal:
    let x_mut = &mut point.x;
    let y_mut = &mut point.y;
    *x_mut *= 2.0;
    *y_mut *= 2.0;
}
{
    // Legal:
    let ref mut x_ref = point.x;
    let ref mut y_ref = point.y;
    *x_ref *= 2.0;
    *y_ref *= 2.0;
}
{
    // Legal:
    *point.x_mut() *= 2.0;
    *point.y_mut() *= 2.0;
}
{
    // Illegal:
    let x_mut = point.x_mut();
    let y_mut = point.y_mut();
    //          ^~~~~
    // error: cannot borrow `point` as mutable more than once at a time
    *x_mut *= 2.0;
    *y_mut *= 2.0;
}

The lifetime elision rules make it pretty clear why this happens: x_mut() returns a mutable borrow that has to live at least as long as the mutable borrow of self (written as fn x_mut<'a>(&'a self) -> &'a f64).
In order to 'fix' the above example, there needs to be a way to say that a borrow only has to live as long as the mutable borrow of self.x. Here's a modification to the above impl block for a possible syntax to express partial borrows using a where clause:
impl Point {
    pub fn x_mut<'a>(&mut self)
        -> &'a f64
        where 'a: &mut self.x
    {
        &mut self.x
    }

    pub fn y_mut<'a>(&mut self)
        -> &'a f64
        where 'a: &mut self.y
    {
        &mut self.y
    }
}

While the above examples aren't particularly encouraging, allowing for this type of change could be very powerful for abstracting away implementation details. Here's a slightly better use case that builds off of the same idea of representing a Point:
struct Vec2(f64, f64) // Represents a vector with 2 coordinates
impl Vec2 {
    // General vector operations
    // ...
}

// Represents a coordinate on a 2D plane.
// Note that this change to `Point` would require no change to the above
// example that uses `Point::x_mut` and `Point::y_mut` (the details of
// the structure are effectively hidden from the client; construction could
// be moved into `Point::new` as well)
struct Point(Vec2);
impl Point {
    pub fn x_mut<'a>(&mut self)
        -> &'a mut f64
        where 'a: &mut self.0.0
    {
        &mut self.0.0
    }

    pub fn y_mut<'a>(&mut self)
        -> &'a mut f64
        where 'a: &mut self.0.1
    {
        &mut self.0.1
    }

}

For a more involved example of an API that requires mutable borrows, see this gist that describes a possible zero-cost OpenGL wrapper.
There has been some discussion about partial borrows in the past, but it hasn't really evolved into anything yet, and it seems like the idea hasn't been rejected either.

An alternate syntax (adds a new keyword (that could easily just be contextual), but in my opinion makes more sense and is clearer):
impl Point {
    pub fn x_mut(&mut self borrowing x) -> &mut f64 {
        &mut self.x
    }
}

// With a non-self parameter:
pub fn point_get_x(x: &Point borrowing x) -> &f64 {
    // ...
}

@P1start I think either of those syntaxes would work fine as well! But, there would need to be a way to annotate explicit lifetimes for either syntax as well; something like this:
pub fn x_mut<'a>(&mut self borrowing 'a x) -> &'a mut f64 { ... }

or this:
pub fn x_mut<'a>(&mut Point { 'a ref mut x, .. }: &mut Self) -> &mut f64 { ... }

...which would be necessary where lifetime elision would be ambiguous (such as a bare function that takes multiple &mut and returns a &mut).

I want a green roof on the bikeshed:
impl Point {
    pub fn x_mut<'a>(self: &'a mut Self::x) -> &'a mut f64 {
        self.x
    }
}

for borrowing multiple fields you'd use Self::{x, y}.
Also this needs a lint that denies specifying all fields.

I don't like the idea of the type signature only making sense given knowledge of private fields, and if the field is public of course there's not much point. The use case of borrowing multiple fields at the same time can be addressed at a slight cost to ergonomics by just having a single method return both, for example fn x_y_mut(&mut self) -> (&mut f64, &mut f64).

Yes, exposing names of private fields doesn't sit well. There's another way. Composite lifetimes allow borrowing of individual parts of a type. Two mutable borrows with composite lifetimes '(a, _) and '(_, b) of a struct are possible if no field has both 'a and 'b assigned in the struct declaration. Here, _ is a free lifetime variable.
Example.
(I think the syntax Self::x is incompatible with lowercase associated types.)
struct Point<ref '(a, b)> where ref x: 'a, ref y: 'b {
    x: f64,
    y: f64
}

impl Point {
    pub fn x_mut<'a>(&'(a,) mut self) -> &'a mut f64 {
        &mut self.x
    }

    pub fn y_mut<'b>(&'(_, b) mut self) -> &'b mut f64 {
        &mut self.y
    }
}

// Typical lifetime parameters work.
struct PointRef<'a> {
    borrowed: &'a Point
}

// type signature.
fn draw<'a>(point: PointRef<'a>) {}
// equivalent type signature, for some 'c, 'd.
fn draw<'c, 'd>(point: PointRef<'(c, d)>) {}

I really, really like this proposal. I had some cases where I could choose to either rewrite the same piece of code a lot of times (because it borrows self) or clone the values before mutation (which, potentially, is costy).
However, the syntaxes proposed here seems noisy and non-obvious. The syntax should be something that's easy to spot and write.

@Ticki What does your use case look like? Does the fn x_y_mut(&mut self) -> (&mut f64, &mut f64) pattern not work?

Just a vote for wanting this in some form.
It'd be nice to be able to get immutable references to the keys in a hashmap while also being able to get mutable references to the values later.

pub fn point_get_x(&Point { ref x, .. }: &Point) -> &f64 {

I've mentioned pub fn point_get_x(p: &Point { x }) -> &f64 { &p.x } before, on reddit.
What makes this attractive to me is that it's refinement to include only specific fields, which would interact not only with borrowing, but many other language features, such as partial moves, ..default syntax and variant types.

Here is some motivation fuel from a contributor to the sdl2 crate: https://cobrand.github.io/rust/sdl2/2017/05/07/the-balance-between-soundness-cost-useability.html

I think this interacts well with #1546.
Also, there is a cute color for shed door if you permit multiple self arguments, like :
trait Foo {
    position: usize,
    slice: &[u8],
    fn tweak(&mut self.position, &'a self.slice) -> &'a [u8];
}

It does not play so nicely with non-self arguments, but maybe it could be short hand for the green roof suggested by @oli-obk.  It works with some sort of destructing function call syntax too :
fn foo((ref x,ref 'a mut y) : (usize,[u8])) -> &'a [u8] { .. }

I really would love to see this as well. But for partial self borrowing to happen I guess someone™ needs to write up an RFC, summarizing up everything in this issue.

Since we probably don't want to expose the names of private fields in a public API, there should be a way to declare abstract "borrow regions" for your type as part of the public API. You can then privately declare which fields belong to which region. Multiple fields can belong to one region.
Here is an (arbitrary) example:
// Note that this is just pseudo-syntax, I'm not proposing any particular syntax.
// This example uses a new keyword called `region`.

struct Vec<T> {
    /// Data belonging to the `Vec`.
    pub region data;
    /// Length of the `Vec`.
    pub region length;
    #[region(data)] ptr: *mut T,
    #[region(length)] len: i32,
}

impl<T> Vec<T> {
    // Needs mutable access to `data`, but doesn't mutate `length`.
    fn as_mut_slice(&region(mut data, length) self) -> &mut [T] {
        do_something_with(self.ptr, self.len)
    }
    // Only needs to access the `length` region.
    fn len(&region(length) self) -> usize {
        self.len
    }
    // This one borrows everything, so no need for special region annotation.
    fn retain<F>(&mut self, f: F) where F: FnMut(&T) -> bool {
        // ...
    }
}

This would allow disjoint borrows, while still not exposing private fields in the public API or error messages.
fn main() {
    let mut v = vec![1, 2, 3];
    // This is fine, `as_mut_slice` and `len` access different regions.
    for num in v.as_mut_slice() {
        println!("{} out of {}", num, v.len());
    }
    // Not valid:
    v.retain(|num| num == v.len());
    // Error: Cannot borrow region `length` of `v` as immutable, because it is also borrowed as mutable.
    // v.retain(|&num| num == v.len());
    // -        ^^^^^^        -      - mutable borrow of `length` ends here
    // |        |             |
    // |        |             borrow occurs due to use of `v` in closure
    // |        immutable borrow of `length` occurs here
    // mutable borrow of `length` occurs here
}

That sounds like the disjointness rules in #1546

The fields in traits will resolve some of these issues. However they can't be used in case the struct/trait involves multi-field invariants, which are maintained by controlling their modification. An example of this would be data/len of Vec<T>
While the region syntax might be a bit of an overkill for this scenario, I personally like it a lot. Here is another example with it that includes traits as well.
I encountered the need in a scenario where the user impling their own type and they were holding immutable borrow for one field while wanting to call a method on self, which would have modified other disjoint fields.
struct Sphere {
    // Field belonging to two regions would allow callers to acquire two mutable
    // references to the field by using two different mutable regions.
    // Since we don't want this, we don't need to support defining fields in multiple
    // regions. This allows us to use scopes instead of attributes here.

    pub region position { x: f64, y: f64, z: f64 }
    pub region size { radius: f64 }
    pub region physics { weight : f64 }
}

impl Foo {
    // Borrows everything.
    fn copy_from(&mut self, other: &Sphere) { ... }

    // Mutably borrows position.
    fn move(&mut self borrows { &mut position }, x: f64, y: f64, z: f64) { ... }

    // Immutable borrow of size.
    fn get_size(&self borrows { &size }) -> f64 { ... }

   // Bikeshedding: If we are using 'regions', any syntax that relies on field
   // destructuring probably won't work.
}

When it comes to traits, these could be implemented using specific regions. There's no reason borrowing for Display would need to borrowck fields that are not used for display.
// Subtracting a point only alters the sphere position.
pub trait SubAssign<Point3D> for Sphere using { mut position } {

    // 'self' is valid only on fields under 'position' here.
    fn sub_assign(&mut self, rhs: Point3D) {
        self.x -= rhs.x;
        self.y -= rhs.y;
        self.z -= rhs.z;
    }
}

Also traits could possibly describe their own regions.
trait Render {
    region geometry;
    region texture;
    ...
}

// Render is implemented on Sphere using position and size.
// Borrowing 'physics' region is still valid while the sphere is being rendered.
impl Render for Sphere using { position, size } {

    // Rendered geometry inludes both position and size.
    region geometry = { position, size }

    // Sphere doesn't contain texture data. It'll use static values
    // for any method that would need textures.
    region texture = {}

    ...
}

// Acquiring reference to the trait will automatically borrow the used regions.
let r : &Render = &sphere;

// OK:
// increase_weight mut borrows only 'physics' region, which isn't used by 'Render' impl:
increase_weight( &mut sphere );

// FAIL:
// grow mut borrows physics and size. This fails, as &Render is holding borrow to size region.
grow( &mut sphere );

I think regions are not a good idea.
They do not convey anything about the reasons for being laid out in a particular way and they are at best tangent to describing which parts of the struct need to be borrowable separately as opposed to which parts lay close in whatever mental model.
Overall I think the information about which part of a struct to borrow should be specified or inferred at the point at which it is borrowed.

We now have arbitrary self types in traits. I think whatever syntax we use should approximate or mimic it. Personally, I lean towards the following:
impl Point {
    pub fn x_mut(self: Point { ref mut x, .. }) -> &mut f64 {
        &mut self.x
    }

    pub fn y_mut(self: Point { ref mut y, ..}) -> &mut f64 {
        &mut self.y
    }
}

I doubt Point could/should destrtucture in type position like that, but you could destrtucture in argument position like:
pub fn x_swap_y<T>(
    Point { ref mut x, .. }: Point<T>,
    Point { ref mut y, .. }: Point<T>
) {
    mem::swap(x,y);
}

impl Point<f64> {
    pub fn x_foo_y(Point { ref mut x, .. } = &mut self) -> &mut f64 { x }
    pub fn y_mut(Point { ref mut y, ..} = &mut self) -> &mut f64 { y }
}

In particular, these methods have no self argument because the calling convention destrtuctures it for them.
One should decide that a series of destructuring borrows works this way too though.

Maybe fn a (&mut self { ref mut x }){}?

The thing is we already have an appropriate syntax for having a trait with a different receiver than Self, which is used for Pin in stable already: https://github.com/rust-lang/rust/issues/44874
I believe straying too much from that already established syntax would be a bad idea.

We always have binding : Type everywhere else, including arbitrary self types, so anything else departs much more from the existing syntax and parser.

@estebank I agree, we should build upon existing syntax.
@burdges But why use an equal sign there?
Wouldn't this be the most natural syntax be?
impl Point {
    fn x_mut(Point { ref mut x, .. }: &mut Self) -> &mut i32 { x }
    fn y_mut(Point { ref mut y, .. }: &mut Self) -> &mut i32 { y }
}

Considering that this already works:
fn f(_: &mut i32, _: &mut i32) {}

let p = &mut Point { x: 1, y: 2 };
f(
    { let Point { ref mut x, .. } = p; x },
    { let Point { ref mut y, .. } = p; y },
);

The advantage of using this syntax would be that it wouldn't only work for f(p.x_mut(), p.y_mut()) but also for f(Point::x_mut(p), Point::y_mut(p)).
And even more generally, shouldn't we strive to make it work for free functions, too?
E.g.:
fn x_mut2(Point { ref mut x, .. }: &mut Point) -> &mut i32 { x }
fn y_mut2(Point { ref mut y, .. }: &mut Point) -> &mut i32 { y }

f(x_mut2(p), y_mut2(p)); // currently: error, cannot borrow `*p` as mutable more than once at a time

If the goal is to ONLY make it work for methods: Why?
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=9f02f57616eb13e8389440471b6fee53
(Regardless of which syntax gets used, it should allow borrowing some fields mutably while simultaneously borrowing other fields immutably.)

Wouldn't this be the most natural syntax?

Afaik, there is no semantic difference between
impl Point {
    fn x_mut(Point { ref mut x, .. }: &mut Self) -> &mut i32 { x }
    fn y_mut(Point { ref mut y, .. }: &mut Self) -> &mut i32 { y }
}

and
impl Point {
    fn x_mut(Point { ref mut x, .. } = &mut Self) -> &mut i32 { x }
    fn y_mut(Point { ref mut y, .. } = &mut Self) -> &mut i32 { y }
}

Ask someone who knows the parser if either one complicates anything.
I'll note however that neither admits method call syntax because we've set a strong precedent that names besides self disallow method notation, ala
impl<T> Arc<T> {
    fn try_unwrap(this: Arc<T>) -> Result<T, Arc<T>>
}

We cannot make &mut Self admits method call syntax  because fn foo(x:&mut Self, y:&mut Self) or similar.
If you want method call syntax then you'll need
impl Point {
    fn x_mut(Point { ref mut x, .. }: self: &mut Self) -> &mut i32 { x }
    fn y_mut(Point { ref mut y, .. }: self: &mut Self) -> &mut i32 { y }
}

or
impl Point {
    fn x_mut(Point { ref mut x, .. } = self: &mut Self) -> &mut i32 { x }
    fn y_mut(Point { ref mut y, .. } = self: &mut Self) -> &mut i32 { y }
}

At which point = makes considerably more sense.
I think this alters the fn type, so we cannot make the first item of the method body special, like
impl Point {
    fn x_mut(self: &mut Self) -> &mut i32 {
        let Point { ref mut x, .. } = self;
        x
    }
    fn y_mut(self: &mut Self) -> &mut i32 {
        let Point { ref mut y, .. } = self;
        y
    }
}

I do not understand @eddyb suggestion per se but it sounds like a reason not to rush on this.

What about this?
impl Point {
    fn x_mut(self @ Point { ref mut x, .. }: &mut Self) -> &mut i32 { x }
    fn y_mut(self @ Point { ref mut y, .. }: &mut Self) -> &mut i32 { y }
}

Btw, was it already decided if we only want to allow partial borrowing for the methods/self or in general for all arguments (e.g. args of free functions or non-self args of methods)?
I think it makes sense to make it work for all args (for consistency)..
What do y'all think?
You might think it doesn't make as much sense for free functions / non-self args, because you can just partial-borrow before calling the function, BUT to that I say:
You can also do that now with methods/self. In fact, that's my current workaround, but it's very inconvenient having to call methods in this way:
Foo::method(&mut foo.bar, &mut foo.baz, &foo.asd, other_arg), and it's similarly inconvenient for free functions, especially if you need to call multiple such functions inside a scope, that partially borrow disjoint subsets of the fields of a struct instance!
In several projects I have a lot of small helper functions that simultaneously partially borrow such subsets, some are methods but others are free functions.
I really hope we can make it work for all args in general.

For non-self arguments I think one of the big issues is how does the call site look like?

let a = foo(&mut x);
let b = bar(&mut x);

Won't work as a full mutable borrow is made first.

let y = &mut x;
let a = foo(y);
let b = bar(y);

Works but is inconvenient and can't work as a desugaring for method calls

So we need a new syntax for explicit partial borrows.
After brain storming a few ideas (&mut x._ &mut x... &mut x. .. &mut x.(..) &..mut x) I came up with &partial mut x which also works as a type name so we can put it in the signature of function that take partial borrows.
fn method(&partial mut self @ Point { x, ..});
fn funtion(Point { x, .. }: &partial mut Point);

It's possible @ makes sense, and @ is so rare the parser can do whatever, but..
All existing uses have the pattern continue on the left while the binding appears on the right, but you propose the pattern still continues on the left, while the right now just names the value being destructured.
At first blush, it makes more sense to do
fn x_mut(Point { ref mut x, .. } @ &mut self) -> &mut i32 { x }

except we end up with patterns continuing on both sides, like
match foo() {
    Point { ref mut x, ... } @ Point { y: 5 } => ...

which sounds worse than repurposing the right like you propose.
I suppose nested calls create another problem here:
impl Point {
    fn x_log(&self @ Point { ref x, .. }) -> &i32 { .. }
    fn x_mut(&mut self @ Point { ref mut x, .. }) -> &mut i32 {
        self.x_log();  // Is this valid?
        x
    }
    ...
}

I suspect the comments by @eddyb addressed nested calls better

Thing to the left of @ is always an identifer, not a pattern, isn't it? I though that would serve as most natural way to indicate thr argument as self, as well as a way to omit the obvious type, either would nested calls be legal or not. In case nested calls will be legal, same goes for arbitrary arguments as well: Other { .. } @ &other or Other { .. } @_ instead of  Other { .. } @ other: &Other. That syntax for arbitrary arguments would be less natural as of today, though

Non-self arguments
If type T implements a method bar that can be used with a partial borrow of T { &foo }, I'd imagine we'll soon start needing ways to pass a T in to another function just so that function can then invoke bar without having to borrow the whole T.
fn do_stuff_with_partial_t(t: ???) {
    t.bar()  // Partial borrow occurs here
}

Usage of @ in parameters
The following is already usable in nightly with feature(bindings_after_at)
fn parameter_pattern(s @ S { s1, .. }: &S) {
   println!("{}, {}", s, s1);
}

I feel the use of @ or anything resembling a pattern on the binding side of the parameter definition would be confusing. Especially when it comes to non-self arguments, having foo(Foo { ref x, .. }: &Foo) suddenly become a partial borrow would be a compatibility hazard as currently crates can use that syntax while still being able to add other fields in the pattern without breaking backwards compatibility. If that syntax becomes a partial borrow, then the callers might hold a mutable borrow of Foo::y while calling that method, so adding ref y in the pattern breaks semver compatibility.
Call site with &mut x
I feel this could be made work by changing the semantics of the &mut operator by having it borrow as much as possible and then dropping the unneeded borrows afterwards:
let a = partial_a_of_x(&mut x)  // Initially results in full borrow of all fields
                                // but only keeps x::a borrowed

let b = partial_b_of_x(&mut x)  // Initially results in borrow of everything
                                // but x::a, which was already borrowed

use_all_of_x(&mut x)            // Results in borrow of everything but x::a, x::b,
                                // which turns into an error:
                                //
                                // Error: Cannot mutably borrow x as whole.
                                //        Previous borrows exist.

I still favor eddyb's approach. The "partial borrow" is much more closer to "type information" than "binding information". Also I feel the issue is somewhat orthogonal from arbitrary self types:

Partial borrows needs a way to subtype the existing borrow-type &Foo.
Arbitrary self types concerns a way to use a non-Self type as a receiver.

If we consider the partial borrow as a type level construct, then arbitrary self types should already work for it. Having partial borrow as a real type-level construct would also play much better with other use cases:
// .. ignoring the fact that this would be pain to parse:
impl Foo for MyType { &a, &mut b }
{
    fn foo(&self) {
        // Self = MyType { &a, &b }
    }
    fn bar(&mut self) {
        // Self = MyType { &a, &mut b }
    }
}

I'm not saying "implementing a trait for a partially borrowed type" should be a requirement for any partial borrow support, but keeping that option open would be good here. There's no reason the use of my Display implementation would need to conflict with a mutable borrow of the internal_cache field.
I guess the parsing issues could be solved with the use of MyType &{ a, mut b } - here &{ .. } would be the partial borrow specification and distinguishable from a simple { .. } block that might follow the type (such as in the impl block above).

The discussion about backwards compatibility and bindings is convincing to me, and also reminds me of the optimization discussed in Closures Capture Disjoint Fields. It also wants a way to store only a single pointer to a struct while semantically borrowing only a subset of it.

What if someone wants to allow partially borrowing a struct with private fields?
Take for example Vec or slices. The following code doesn't compile but it could if we allow partial borrow of data and len it would. (Actually for slices this works only when they're viewed as FatPtr, while for Vec the relevant field is named buf and not data)
let mut vec = vec![1, 2, 3];
let first = &mut vec[0]; // Here we mut borrow `data` from vec
println!("vec length is {}", vec.len()); // Here we borrow the `length`
*first = 4; // Use the mut borrow so it doesn't immediately go out of scope

(Note that pushing or removing elements wil still need to borrow both data and len to be safe.)
I though of two possible solution

Add a new visibility modifier, something like pub(partial) which allows using fields only in partial borrows but doesn't allow to actually get references to said fields. So for example Rantanen's example wouldn't work if s1 was marked as pub(partial)

fn parameter_pattern(s @ S { s1, .. }: &S) {
   println!("{}, {}", s, s1);
   // Error, s1 is only pub(partial), can't reference it directly
}

Allow users to define new types of partial borrow. This would mean reconsider the syntax for partial borrows as destructuring since there's no longer a direct relation to fields. We could default it to pub fields since it would be the prevalent usage, but it would still break destructuring. On a positive note, this allows better handling of cases like Vec and slices.

And what about partial borrowing nested structs? For example:
struct A {
   a: u32,
   b: u32,
}

struct B {
   c: u32,
   d: A,
}

What if we want to partially borrow c and d.a from an instance of B? What would the syntax be? I think we should also consider this when deciding the general syntax for partial borrowing.

Would this be implicit or something developers can declare explicitly? Because if it is implicit, what fields are used in internal functions is now part of the API. This could affect combining two fields into a new enum or debugging implementations which perform extra sanity checks with different feature flags.

Would this be implicit or something developers can declare explicitly? Because if it is implicit, what fields are used in internal functions is now part of the API.

It would have to be explicit for exactly that reason.

this allows better handling of cases like Vec and slices.

I would like to see the borrow checker eventually supporting let mut (x, y) = (&mut v[..2], &mut v[2..]); on its own, but it feels orthogonal to this feature.

orthogonal

I think they are different feature because for slice it requires borrowing checker to tracking value of const fn parameter, which is more 'dynamic' and difficult to implementation.
And unfortunately, seems like we have no const fn version slice currently.

Would this be implicit or something developers can declare explicitly? Because if it is implicit, what fields are used in internal functions is now part of the API.

It would have to be explicit for exactly that reason.

this allows better handling of cases like Vec and slices.

I would like to see the borrow checker eventually supporting let mut (x, y) = (&mut v[..2], &mut v[2..]); on its own, but it feels orthogonal to this feature.

I think they are different feature because for slice it requires borrowing checker to tracking value of const fn parameter, which is more 'dynamic' and difficult to implementation.
And unfortunately, seems like we have no const fn version slice currently.

As the discussion here has shown, any general syntax for partial borrowing will tie a function's signature very closely to its "private" implementation, either through explicit declarations about which disjoint structure fields are borrowed or through implicit analysis of the same performed automatically by the borrow checker.  Either case has the undesired consequence of increasing the potential surface area for API-breaking changes.
On the other hand, Rust really needs this feature to be an object-oriented programming language.  At this point a lot of developers feel that that being object-oriented is actually undesirable (i.e. "objects tend to be bags of mutable state"), but @nikomatsakis does a great job laying out how unergonomic the current situation is in this blog post.
It feels like we've been spinning our wheels on the general problem of partial borrowing for a few years now with no general solution in sight, but it may be much easier to solve partial borrows in the narrower but very common use case of interprocedural conflicts between private methods.  What do the discussants here think about @crlf0710's proposal to opt-in to non-local borrow checking, in particular @kornelski's suggestion of limiting non-local borrow checking to private methods so as to avoid changing the public signatures of functions?  Full example on Rust Playground.
mod my_mod {
    pub struct MyStruct {
        somethings: Vec<SomeType>,
        // ...
    }
    impl MyStruct {
        pub fn do_something(&mut self)
        {
            for something in &self.somethings {
                // Can't borrow all of self as &mut while &self.somethings is borrowed immutably.
                #[inline_private_borrowchk]
                self.do_something_else();
            }
        }

        // Function is private, no effect on public API.
        fn do_something_else(&mut self) {
            // Do whatever we want to other members of MyStruct,
            // but borrow checker will make sure we don't mutate self.somethings.
        }
    }
}

Anyone doing object oriented design could usually employ interior mutability like self: &RefCell<Self> because (a) they could afford the minuscule performance penalty and (b) they'd do some more careful non-object-oriented design if race conditions, etc. looked risky.  Ignoring that argument..
Yes, I agree opt-in less-local borrowck sounds interesting, but maybe heavy development and rustc runtime costs, so not necessarily worth resources anytime soon.
In the shorter term, we have Borrow abstract over immutable borrows using Rc and Arc, so maybe we should consider a BorrowMut-like trait that abstracts over RefCell and BorrowMut:
pub trait RefCellLike<T> {
    ...
}

impl<T> RefCellLike<T> for RefCell<T> { .. }
impl<T,B> RefCellLike<T> for B where B: Borrow<T>+BorrowMut<T> { .. }

You'd then abstract over this within methods using self: impl RefCellLike<Self>.

Posted a question in the Rust Discord and was suggested to copy my problem here as an example of how the lack of split borrows can be unergonomic:
I have a struct like this:
struct WorldMap {
    tiles: Vec<Tile>,
    width: usize,
    height: usize,
}

impl WorldMap {
    pub fn get_tile_mut(&mut self, x: usize, y: usize) -> Option<&mut Tile> {
        self.tiles.get_mut(y * self.width + x)
    }

    pub fn tile_to_position(&self, x: usize, y: usize) -> (f32, f32) {
        // basically compute diff from x, y to center of tile map, then
        // multiply by tile length to determine a position on the screen
    }
}

I have a function in which I'm checking and updating all the tiles that need updating via get_tile_mut, the computing the position on the screen they need to be at afterward. The problem is that WorldMap#tile_to_position can no longer be used since I've already mutably borrowed WorldMap when updating the tiles, even though self.width and self.height will be the only properties used in tile_to_position.

You could reverse your call order there, so no need for tiles: RefCell<Vec<Tile>> or tiles: Vec<Cell<Tile>>.  It's trickier if both methods require &mut self of course.

https://internals.rust-lang.org/t/pre-rfc-field-as-an-item-and-borrows/13886

https://internals.rust-lang.org/t/pre-rfc-field-as-an-item-and-borrows/13886

It seems that "row polymorphism" can play with this sense?

There are some crates that let you do something like this: partial_borrow partial_ref and borrow_as.  For people wanting something like this, it might be a good idea to experiment with them and see whether these approach are worthwhile.
Full disclosure: I'm the author of partial_borrow.

@nikomatsakis's blog post on "view types" is definitely relevant here: https://smallcultfollowing.com/babysteps//blog/2021/11/05/view-types/

What is the state of partial borrowing in Rust in 2022?
Are there newer or related RFCs that would allow some of these cases to work?
Right now, in a library I'm prototyping, I'm stuck with exposing plain struct fields to get proper lifetime checking and partial borrows.
// This is a singleton type representing a piece of hardware.
// (https://docs.rust-embedded.org/book/peripherals/singletons.html)
//
// Depending on the Mode, the display allows using one or more layers,
// which themselves are singletons, since they're bound to specific memory addresses.
//
// The layers must not be kept past a mode change, since their
// behaviour and access changes depending on the mode.
//
// However, we want partial borrows because the DisplayControl has
// functions that can be used independently of the layers.
pub struct Display<M: Mode>  {
    pub control: DisplayControlRegister<M>,
    pub layers: M::DisplayLayers,
}

impl<M: Mode> Display<M> {
    // Consumes self, so all references to layers must be cleaned up first
    pub fn change_mode<N>(self) -> Display<N> {
        /* ... */
    }
}

Which is fine enough, but not particularly ergonomic, since any structural change is now a breaking API change:
use video::{DisplayControl, Mode0, Mode3};

fn main() {
    let mut display = hw::init_display::<Mode3>();

    let bg2 = &mut display.layers.bg2;

    // This should still work
    display.control.write(
        DisplayControl::new().enable_bg2()
    );

    bg2.write_pixel(120, 80, 0x001F);
    bg2.write_pixel(136, 80, 0x03E0);
    bg2.write_pixel(120, 96, 0x7C00);

    // Not sure if this works if we promise not to touch bg2 past this point
    let mut display = display.change_mode::<Mode0>();

    let bg0 = &mut display.layers.bg0;
    // and so on...
}

Hi all,
I'm not an expert on rust (so forgive me if I make any mistakes!) but as I've been using rust more and more, I've found this issue to be one of my biggest frustrations. As far as I understand, the biggest blocks with any proposed solution are as follows:

Any ability to partially borrow fields of a structure exposes information about that struct (violating the "black box" philosophy)
Some of the proposed syntax doesn't seem to be intuitive, and would be a break from standard syntax. Additionally, some of the syntax is a little verbose! (in my eyes).
Partial lifetimes should fit in with other rust constructs (such as traits)
No clear path for inferred partial lifetimes -- this could have major effects on code readability, especially when the lifetime should be intuitive
Partial borrowing could increase the volatility of what should be a stable interface (breaking changes may be needed as the internal structure of an API changes)
These are the main issues I saw while skimming over this thread -- let me know if I've missed anything!

I've been brainstorming for a solution, and I think I have a really simple solution. In short, adding the ability to create "associated lifetimes". For example:
`struct Planet {
// who knows!
}
impl Planet {
// declare some associated lifetimes
type 'creature;
type 'building;
pub fn addCreature(&'creature mut self, name: &str, loc: Location) { ... }
pub fn addBuilding(&'building mut self, structure: StructureType, loc: Location) { ...}
// .. so on
// but 'creature and 'building lifetimes are completely normal lifetimes, so you can use them the in combination (or however!)
// 'a is a lifetime that borrows both 'creature and 'building
pub fn enterBuilding<'a: 'creature + 'building>(&'a mut self, creature: CreatureId, building: BuildingId) { ... }
// 'a is a lifetime that borrows both 'b (for fireball) and 'creature
pub fn explodeCreature<'b, 'a: 'b + 'creature>(&'a mut self, fireball: &'b mut Fireball) { ... }
}`
The next question becomes how the lifetimes are used for an API designer (what makes them work). The idea here is pretty simple; any singular field borrowed by any code must always borrow the same associated lifetime.
For example:
`// lets define "Planet" as before, but with some fields
struct Planet {
creatures: Vec,
buildings: Vec,
}
impl Planet {
// we'll declare the same lifetimes as before
type 'creature;
type 'building;
pub fn addCreature(&'creature mut self, name: &str, loc: Location) {
// because "creatures" vec is accessed in a method borrowed for "creature" lifetime, "creatures" vec is now locked to "creature" lifetime. Any access of the "creatures" field is a borrow of 'creature
self.creatures.push(Creature(name, loc));
}
pub fn addBuilding(&'building mut self, structure: StructureType, loc: Location) {
// same as before. "buildings" vec is now locked to "building" lifetime; any borrow of "buildings" object borrows "building" lifetime
self.buildings.push(Building(structure, loc));
}
pub fn badFunction(&'building mut self) {
self.creatures.push(Creature::default()); // compiler error! self.creatures cannot be borrowed under "building" lifetime, since it was already borrowed under "creature" lifetimes
}
pub fn goodFunction<'a: 'creature + 'building>(&'a mut self) {
self.creatures.push(Creature::default()); // valid -- 'creature lifetime is borrowed
self.buildings.push(Building::default()); // valid -- 'building lifetime is (also) borrowed
}
}`
If a user has internal access to a structure (such as accessing a structure with public fields) they are still going to have to borrow the partial lifetimes as mentioned above. This is leaking of the internals, but is only caused by the fields being public (or in other words, it only applies when the internals are already being used).
If a user does not explicitly borrow any individual associated lifetime, they are borrowing 'self -- that is, every associated lifetime.
There is one partial (get it? hahaha) problem with inferring lifetimes here. Consider the following:
`struct Structure {
a: u32,
b: u32,
c: u32,
}
impl Structure {
type 'x;
type 'z;
type 'common;
fn first<'a: 'common + 'z>(&'a mut self) {
self.a + self.b; // lock "a" and "b" to either "common" or "x"
}
fn second<'b: 'common + 'x>(&'b mut self) {
self.b + self.c; // lock "b" and "c" to either "common" or "x"
}
}`
In this case, it's not immediately clear which fields are managed under which lifetime. It's still very much possible to deduce ('common is shared between both functions accessing b, and must therefore be responsible for managing b; "a" can belong to either "z" or "common") but it might be somewhat less intuitive, and more challenging to implement (+ debug).
But on the other hand, this should only be a problem if a user exclusively combines associated lifetimes (and does not lock any field to a specific lifetime). And, ultimately, this doesn't seem like a largely practical thing to do (though again -- it is possible to deduce, as needed, pretty sure this is just introductory level linear algebra).
There is an additional edge case, where a user may want to design an API where two associated lifetimes are always required for a specific field. In this case, it may make sense to allow users to define an associated lifetime as follows:
`impl Structure {
type 'a;
type 'b
type 'both: 'a + 'b; // combination of both 'a and 'b
}'
(Though this ^^ is a last minute thought).
I think this syntax solves most of the mentioned issues. For example (in the mentioned order):

Associated lifetimes have no direct relations to the fields; users of the API borrow specific lifetimes in the object, with no forward facing relationships between fields and lifetimes. APIs could even define a lifetime that isn't directly associated with any field as a way to "block" invalid API combinations at compile time (e.g. in the "OpenGL" example gist linked by @LunarLambda, users would be unable to create multiple binds to the same target at the same time. Instead, users would have to bind to a target, then drop the borrow before rebinding to the same target).
In my eyes, this is very easy to grasp, and ergonomic, too. It's easy to read and understand, adds no new syntax (or punctuation).
Partial lifetimes would be, in most ways, completely normal lifetimes. This would enable them to become first-class citizens, as they would simply opt into existing syntax. Hopefully this would also make implementation a low-complexity change. This would also enable them to be used in traits, or impl blocks, or wherever.
Partial lifetimes are inferred! It should be straightforward to implement, easy to understand, and possible to write clear, concise, and understandable compiler errors (when needed).
Since partial borrows aren't explicitly tied to structure fields, a well designed API should not need breaking changes when there are internal changes. This is assuming a well designed API with clear boundaries between abstract components, but IMO this is the responsibility of an API designer; additionally, the current workaround (using multiple objects that are related/passed around) faces the same issue.

Phew. Hopefully I explained myself well (and I'm not missing anything!). In short:

Allow structures/traits to declare "associated lifetimes", which are a public part of the implementation
An associated lifetime divides the lifetime of 'self into several smaller lifetimes. 'self is a superset of all of it's associated lifetimes, and so borrowing 'self is also a borrow of all associated lifetimes
A structure without any associated lifetimes that only has 'self is unchanged
Associated lifetimes are inferred. Each structure field is locked into one associated lifetime. The associated lifetime for each field is inferred based on which lifetime a field is accessed under. If a field is accessed under 'b, the field must always be accessed under b. In this sense, the 'self lifetime could be defined as the combination of all associated lifetimes of a structure.
I'm running out of things to write!

I'd love any feedback/criticism/tips anyone can provide. Thanks!

@KevinThierauf wouldn't this require deep changes to how lifetimes and references work? AFAIK the act of borrowing is intrinsic in references, that is &'something mut self will borrow Self no matter what 'something is, while 'something can only change how much the borrow can last. Your proposal feels like mixing the responsabilities.

@KevinThierauf wouldn't this require deep changes to how lifetimes and references work? AFAIK the act of borrowing is intrinsic in references, that is &'something mut self will borrow Self no matter what 'something is, while 'something can only change how much the borrow can last. Your proposal feels like mixing the responsabilities.

Conceptually, I don't think so. Essentially, instead of borrowing self, the borrow checker would borrow self.creatures or self.buildings. Lifetimes themselves aren't becoming anything new, or anything different -- there's just more lifetimes -- lifetimes which are under the umbrella of (and associated with) self. Kind of a hierarchy of lifetimes, which I think fits neatly into the hierarchical nature of OOP code (with composition).
Implementation wise, though, this may be a whole different story. I'm not familiar with compiler internals, so someone more experienced than I will have to say!

Instead of borrowing all of self, you borrow one of it's lifetimes

In my eyes you don't "borrow a lifetime", you "borrow for a lifetime", that is the lifetime only affect the point until you can borrow something.
Also, this doesn't play well with lifetime bounds. Normally you add a bound to restrain the caller to a sufficiently long lifetime, however in your example the lifetime bounds are restraining the implementation of the function because they're no longer able to access the whole self. Unless you change how the default lifetimes work, by making fn foo<'a>(&'a mut self) not able to access any field, which seems counterintuitive to me.

@KevinThierauf, thank you for sharing your idea.  It's clear that you've given this problem a lot of thought.  How would your "associated lifetimes" be substantially more ergonomic than @pczarn's "composite lifetimes" or @crumblingstatue's "borrow regions"?
As an aside, since we're discussing this again, note that you can achieve some of the benefits of partial borrows on stable Rust using projection references to specify which members of a struct can be mutated disjointly.

In my eyes you don't "borrow a lifetime", you "borrow for a lifetime", that is the lifetime only affect the point until you can borrow something.

I think you're exactly right -- the lifetime is a duration, not an object. The lifetime

Also, this doesn't play well with lifetime bounds. Normally you add a bound to restrain the caller to a sufficiently long lifetime, however in your example the lifetime bounds are restraining the implementation of the function because they're no longer able to access the whole self. Unless you change how the default lifetimes work, by making fn foo<'a>(&'a mut self) not able to access any field, which seems counterintuitive to me.

The

In my eyes you don't "borrow a lifetime", you "borrow for a lifetime", that is the lifetime only affect the point until you can borrow something.

I agree -- sorry if my terminology isn't quite right! A more accurate statement on my behalf might be that you borrow a part of self for a lifetime, with the specific fields borrowed specified by the associated lifetime.
So, if we have the associated lifetime defined as:
type 'creatures;
Then instead of borrowing all of self, we can borrow only the part of self under the umbrella of 'creatures.

Also, this doesn't play well with lifetime bounds. Normally you add a bound to restrain the caller to a sufficiently long lifetime, however in your example the lifetime bounds are restraining the implementation of the function because they're no longer able to access the whole self. Unless you change how the default lifetimes work, by making fn foo<'a>(&'a mut self) not able to access any field, which seems counterintuitive to me.

I think you are still restraining the caller to a sufficiently long lifetime (the lifetime of 'creatures, or 'buildings), but also restraining access to specific fields to prevent accessing the whole of self.
In the case of fn foo<'a>(&'a mut self), this would normally be no different than fn foo(&mut self), which would be to borrow all of self, that is, all partial lifetimes (if they exist) which is the same as borrowing all of self normally. So foo would have full access to all fields, but callers would only be able to use foo so long as they are not partially borrowing self.

@KevinThierauf, thank you for sharing your idea. It's clear that you've given this problem a lot of thought. How would your "associated lifetimes" be substantially more ergonomic than @pczarn's "composite lifetimes" or @crumblingstatue's "borrow regions"?
As an aside, since we're discussing this again, note that you can achieve some of the benefits of partial borrows on stable Rust using projection references to specify which members of a struct can be mutated disjointly.

Thank you! I think the underlying concept is more or less the same, but there are a couple of notable differences.
I really liked @pczarn's "composite lifetimes" idea, but I found the syntax to be confusing (and something beginners especially would really trip up on). I also wanted to shift the lifetime parameters away from being a generic parameter to an associated type, since because I don't think they are as much a part of the type declaration as they are a part of the type interface. But the principle idea of creating a lifetime that applies to specific fields is pretty much the same!
I think the concept of associated lifetimes is very similar to @crumblingstatue's proposed "borrow regions", with the changes largely being syntax based. I really liked how the regions worked nicely with traits and how they abstracted away from any fields, and the ability to have clear and understandable compiler errors is a big plus. I think the syntax is much clearer, but it does still feel like the programmer is forced to explicitly define what could cleanly be inferred by the compiler. I do a lot of iterative prototyping when designing interfaces, and so I'd love for the compiler to infer as much as it reasonably can (without sacrificing readability)!
One notable advantage of the borrowing regions that the associated lifetimes concept does not provide is the ability for a function to partially borrow multiple regions with different mutability in the same function. I'm not sure how significant of a issue this is, but I do feel like it's worth (at the very least!) making a note of.
I really liked the other contributions on this thread (and I definitely incorporated many of the other ideas provided!) but I found the syntax proposed to be largely confusing, so that was one of my main changes. I think the associated lifetime syntax is more intuitive, but maybe I'm just getting inside my own head! Additionally, I really want any partial borrow implementation to be inferred, since I think that is a major source of ergonomics.

I think you are still restraining the caller to a sufficiently long lifetime (the lifetime of 'creatures, or 'buildings), but also restraining access to specific fields to prevent accessing the whole of self.

I don't think the two "restraining" are the same:

bounding the length of the lifetime to a sufficiently long one is something that restricts the caller, and so gives more power to the method body because it can do more assumptions on the lifetime of self. In other words, the caller can only do the same or less, while the method body can only do the same or more.

bounding to "partial borrows lifetimes" instead is something that restricts the method body, and so gives more power to the caller because it can call the method even if it doesn't have full access to self. In other words, the caller can only do the same or more, while the method body can only do the same or less.

So even though both actions "restrict" someone, they kinda have the opposite effects. Thus I would be against using the same syntax for both.

So even though both actions "restrict" someone, they kinda have the opposite effects. Thus I would be against using the same syntax for both.

Yeah I think you're right. If an associated lifetime is not be the proper way to express this, what about specifying the partial borrow as a part of the self parameter directly?
I.e. instead of:
fn foo(&'creatures self) { ... }
We might express as something more like:
fn foo(&Self::Creatures)
This might be a more correct way of expressing the concept, since the idea behind partial borrowing is to borrow only a specific part of the structure, instead of the structure as a whole. In this way, creatures is more of a partial type than it is a partial lifetime, so I think this makes sense.
(The syntax here is more of an example than anything concrete, I'm open to alternate proposals).
Is this more of what you had in mind?

For future reference. One can solve many problems by deconstructing self. Here is an example.
struct B;
struct C;

fn foo(b: &mut B, c: &mut C) {}

struct System {
    bs: Vec<B>,
    cs: Vec<C>
}

impl System {
   fn apply_foo(&mut self, i: usize, j: usize) {
        let System {bs, cs} = self;
        foo(&mut bs[i], &mut cs[j])
    }
}

@nielsle Deconstructing doesn't allow any borrowing pattern that isn't possible otherwise.
foo(&mut self.bs[i], &mut self.cs[j]) works just as well.
The problem is that borrows can't be made partial across function boundaries, not that they don't work within a single function.

In the meantime, I've implemented a crate that allows for a pretty nice syntax for partial borrows. Unless we have it built-into the language, it works nice in some of my projects: https://crates.io/crates/struct-split .

At least in traits, it would be possible to infer the fields for partial borrowing:
https://github.com/nikomatsakis/fields-in-traits-rfc/issues/20
https://internals.rust-lang.org/t/infered-fields-for-partial-borrowing/18766
In the trait, we'd have several lifetimes the trait delclares as disjoint with which the trait author promisses non-conflicts between trait methods, and then impls must satisfy this promiss.


inconsistent handling of graphemes 👩🏽🌾🧟🧞♀🦹♂🧔🧛🏾♂

Describe the bug
In various places, the length used for offset calculation is used in bytes, which breaks Dow when multicharacter graphemes are used in literals.
To Reproduce
Currently there is a lack of unit tests to cover this issue sufficiently ( = none)
Expected behavior
Spans must be calculated based on graphemes (superset of chars) OR bytes consistently.

Requires an external library https://crates.io/crates/unicode-segmentation since String does not handle that too well https://doc.rust-lang.org/std/string/struct.String.html#method.chars
CC @laysauchoa

Since graphemes are not even displayed in vscode, I think it's safe to say that operations on unicode chars is sufficient.

My vscode actually shows emojis and I see that it gets read as it was a misspelled word.

although, I am not sure if it is common to use emojis in documentation. ^^

It's more common than you'd expect, and you can see the issue already above, it should be one ^ instead of 4 (and it's not even a grapheme)

@laysauchoa this should not be the case anymore, is it?

cc @drahnr
yes ^^, this is not the case anymore.
error: spellcheck(Hunspell)
   --> /home/tmhdev/Documents/cargo-spellcheck/src/suggestion.rs:23
    |
 23 | ..ation. This is a very logn sentence with some errors and emojis Search Resul 😋😋
    |                                                                          ^^^^^
    | - Result or Restful
    |
    |   Possible spelling mistake found.
    |

How did it ignore emoji now or do not recognize as an error? Just curious!

Although, would this issue still be relevant due to some misalignment when emojis are present?
error: spellcheck(Hunspell)
   --> /home/tmhdev/Documents/cargo-spellcheck/src/suggestion.rs:23
    |
 23 | ... This is a very logn 😋😋😋😋 sentence with some errors and emojis Search Resul 😋😋
    |                                                             ^^^^^^
    | - emoji
    |
    |   Possible spelling mistake found.
    |

Would you like to look into the offset issue, I would have expected this to be ok with the 0.3.0 release at least.

Hi @drahnr.
Do you mean the offset issue when the emojis are being used, such as the example above?
Do you mean a test such as those ones [0]:
[0] https://github.com/drahnr/cargo-spellcheck/blob/master/src/suggestion.rs#L699?
If yes, then yes, I can try to add. If not, please give me more info, and I will check it.

Hi @drahnr.
Do you mean the offset issue when the emojis are being used, such as the example above?
Do you mean a test such as those ones [0]?
[0] https://github.com/drahnr/cargo-spellcheck/blob/master/src/suggestion.rs#L699
If yes, then yes, I can try to add. If not, please give me more info, and I will check it.

Yes, that's what I meant :)

The largest remaining issue here is that the display of graphemes might be individual smilies but also combined into a single character so the width / offset of ^^^^ might be wrong.
The resolution here would be a way to probe the terminal and resolve that, plus a grapheme library, but this smells like distant future.

This is an edge case, and unless somebody actually uses graphemes AND a terminal that can display them, this won't be an issue. This is not on the agenda for any-time-soon™. Closing.


chat_loaders refactoring

Replaced unnecessary namespace renaming
from langchain.chat_loaders import base as chat_loaders
with
from langchain.chat_loaders.base import BaseChatLoader, ChatSession
and simplified correspondent types.
@eyurtsev

cc @hinthornw @hwchase17


Auto-download systems

For system archives that are publicly accessible, there should be a way to specify their location as a URL (together with an MD5 hash) and auto-download them as part of the setup phase of the execution lifecycle.

I'm on this.

Resolved by 292c62fe441108c694d75427960ca509349763ab.


Multiple Instances of same App is created while clicking DeepLink

Hi i am facing an issue with the Deeplink functionality. After integrating deep linking when i tried to click on the link created from branchio i noticed that it creates a new instance of the app and launches it instead of opening the app which is already in the background. So when you try to open different links it creates different instance of the same app. I have attached a screen shot of the background apps in my phone and you can see two different instances of the same app. When try to open it will crash. Please let me know a solution  for this.

I have also created a POC for this and have posted it on github on the following link

Hi @arunprabhus87 , try to add
LaunchMode.SingleTask

@antonargunov i am using LaunchMode = LaunchMode.SingleTask|LaunchMode.SingleInstance only to launch the application

Due to the age of this issue, I am closing this now. If you are encountering this problem still, please reach out to our support team (support.branch.io) or open a new github issue and we would be happy to help you out!


demo_tuples produces malformed HighLevelGraph

The demo_tuples test helper function produces a malformed HighLevelGraph.dependencies graph. This in turn causes failures in dependency-crawling utilities, such as _toposort_layers:
>>> from dask.graph_manipulation import checkpoint
>>> from dask.tests.test_graph_manipulation import demo_tuples
>>> t1, _, _ = demo_tuples(layers=True)
>>> cp = checkpoint(t1)
>>> cp.__dask_graph__()._toposort_layers()
KeyError: 'a'

I've also cherry-picked this over to #8316 to fix CI there. I'm happy to keep it that way, or drop the commit if you want to merge this first.


Can't create html table

http://www.fpdf.org/en/script/script50.php
Creating  table at my site from above link getting below error.
FatalThrowableError in Facade.php line 215:
Call to undefined method Anouar\Fpdf\Fpdf::WriteHTML()

@ZaheerAbbasAghani  this is was new feature that added  to FPDF since this package was build. but what i can see this just extends the parent class and added the WriteHTML which is something you can do very easily in your side otherwise wait until we have new release that will include this new things.


net/http: avoid casting and extra function calling (http.HandleFunc, http.DefaultServeMux.HandleFunc)

Looking at the net/http package I notice that HandleFunc and ServeMux.HandleFunc have a func(ResponseWriter, *Request) as parameter instead of HandlerFunc, this means that this functions need to call one extra fuction and an explicit casting respectively.
So if they are written in this way, it can be avoided:
HandleFunc
Since HandlerFunc implements the Handler interface, DefaultServeMux.HandleFunc should be replaced by DefaultServeMux.Handle.
From:
func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
  DefaultServeMux.HandleFunc(pattern, handler)
}

To:
func HandleFunc(pattern string, handler HandlerFunc) {
  DefaultServeMux.Handle(pattern, handler)
}

ServeMux.HandleFunc
Since the handler argument is implicitly casted (or something else happens here?), an explicit casting is not necessary.
From:
func (mux *ServeMux) HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
  if handler == nil {
    panic("http: nil handler")
  }
  mux.Handle(pattern, HandlerFunc(handler))
}

To:
func (mux *ServeMux) HandleFunc(pattern string, handler HandlerFunc) {
  if handler == nil {
    panic("http: nil handler")
  }

  mux.Handle(pattern, handler)
}

@ntrrg The golang/go issues are meant for bugs or feature requests - not general questions.
I recommend closing this issue and taking the following steps until you get a satisfactory answer to your question:

Read this explanation of DefaultServeMux: https://stackoverflow.com/a/36921591/1168364
Ask a question in https://groups.google.com/forum/#!forum/golang-nuts or https://stackoverflow.com/questions/ask
If the discussion in 2 shows there's a bug in the standard library or that there is some standard behavior missing I recommend opening a new issue.

This is definitely the right place to create a proposal, but to be honest your "proposal" is not very clear. I leaned toward assuming this was just a question because of the word "wonder".
If you'd like to try again to explain, please reply with more detail on what exactly your proposing.

Your are right :laughing: I will try to make it clearer, so please, read the description again. I am still learning English btw :sweat_smile:

Please send a change when the Go 1.12 cycle opens in a few months. Thank you.

Great! :smile: I suppose that this issue should keep open, right?

As it stands now, the proposed change cannot happen in Go 1, as it is changing the signature of public methods.
The only way this might be able to work is if HandlerFunc was also changed to a type alias of func(ResponseWriter, *Request), i.e.:
type HandlerFunc = func(ResponseWriter, *Request)

Someone who knows the code better would be able to explain any problems in making such a change.

@FiloSottile I think that this could be added in the next release because doesn't break any code and is invisible to any user. But this needs a modification in api/go1.txt, this file can't be modified? Even if the modification doesn't break the API?

Go 1.11 is frozen. https://github.com/golang/go/wiki/Go-Release-Cycle.

Yep, sorry, the next next release (1.12) i mean :laughing:

This is an API change that is forbidden by the Go 1 guarantee.  It would break code that said
var x func(string, func(http.ResponseWriter, *http.Request)) = http.HandleFunc

So this issue is correctly labeled as a Go 2 issue.
Closing this issue in favor of #5465, where this change could be made as part of a future net/http/v2.

Yes, you are right, sorry about that 😅


Add ServiceFabricUpdateAppVersions utility task

Hi @mthalman-msft, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Matt Thalman). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


SubmissionQRCodeScanFragment usage

More of a question than an issue:
I noticed a barcode scanner activity was included in the manifest, and in the German package I've noticed a SubmissionQRCodeScanFragment class, but I can't find if (or where) it's used in the Belgian version.
Is there a functionality in the pipeline to be able to submit test results via a qr code?
Of is there a different purpose for this?

It is not used in the Belgian version, and no current plan to add a qr scanner. That fragment & dependency could be entirely removed.


[W4.11e][T13-2]Daniel Khoo

This PR/issue should be against a repo in the org nus-cs2103-AY1819S1 not against the repo in se-edu org :-)
Closing...


add info and warning

Since we have WithSuccess() and WithError() are you able to add the following?
WithInfo() and WithWarn()
By doing this it enables it to work well with a lot of css frameworks that support these alerts.
Thanks

@mybigman Added the functions. Please check latest commit: https://github.com/sujit-baniya/flash/tree/v0.1.5


Can't change Server/TLS info for Active Directory

Rancher versions: v1.6.6-rc1
Steps to Reproduce:

Log into AD using tad.rancher.io info with TLS on
Disable access
Change the server to the IP and turn off TLS

Results:
The info comes back as hostname with TLS on

Version - v1.6.6-rc2
Verified fixed


Render layout without view

First, I'm new to Elixir and Phoenix, so apologies in advance for any seemingly obvious answers.
I am attempting to create a layout that can be used as a wrapper, but without a view.  The Bamboo examples seem to imply this is possible, but my layout does not render when using put_html_layout.  The email simply sends html_body and text_body without the layout wrapper.  Instead, I need to use render("foo.html"), but then I am not sure how to receive the html_body to inject into the view.  Do I now need to use assigns instead?
Thanks.

@bjunc If you've been unable to find a solution to your question above, would you mind positing it on StackOverflow (https://stackoverflow.com/questions/tagged/elixir+bamboo)? It will get attention from more people than in this issue tracker. Thanks!


Multilanguage

Provide the project and website in multiple languages:

[x] English
[ ] German

https://webpack.js.org/loaders/i18n-loader/

Depending on navigator.language either German or English


update python-pep8 to install Python2 version in xenial

See: http://packages.ubuntu.com/search?suite=default&section=all&arch=any&keywords=python-pep8&searchon=names

It caused my dev job to fail: http://build.ros.org/job/Kdev__capabilities__ubuntu_xenial_amd64/1/consoleFull

+1

Back to normal: http://build.ros.org/job/Kdev__capabilities__ubuntu_xenial_amd64/2/


[Improvement][Seatunnel-web] Rename package com.whaleops.datasource to org.apache.seatunnel

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
There are some references of package com.whaleops.datasource. These should be renamed to  org.apache.seatunnel
SeaTunnel Version
NA
SeaTunnel Config
NA

Running Command
NA

Error Exception
NA

Zeta or Flink or Spark Version
No response
Java or Scala Version
No response
Screenshots
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

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

issue is fixed
https://github.com/apache/seatunnel-web/commit/ddd25bf0ee30874bf276045a3493b0905e4ef34f


Add component for performing account operations

This adds AccountOperationsComponent along with its associated spec file. Other changes were made to support this component.
Note that the specs for AccountOperationsComponent don't interact with the component template.

@khalidabuhakmeh Objects are now emitted (rather than strings) per your feedback. See https://github.com/kendaleiv/angular2-bank/commit/bb907d557c0ec951708b15c4b74114bc378c6142 for details.


Update astropy-helpers to v1.3

This is an automated update of the astropy-helpers submodule to v1.3. This includes both the update of the astropy-helpers sub-module, and the ah_bootstrap.py file, if needed.
This is intended to be helpful, but if you would prefer to manage these updates yourself, or if you notice any issues with this automated update, please let @astrofrog know!

@cdeil - I wasn't sure about the status of the 0.2 release so milestoned it to 0.3. Ideally it can go into 0.2.


Add basic poetry instructions to README + .gitignore

Please confirm these are correct and make sense

Poetry is not needed. A user can do:
pip -m venv venv
source venv/bin/activate
pip install pypanther

Poetry is not needed. A user can do:
pip -m venv venv
source venv/bin/activate
pip install pypanther

I think this should be pip install . to get all of the dependencies, but otherwise looks reasonable


Ignore NaNs in detect_clearsky by only applying to continuous chunks

[x] Closes #xxxx .
[x] I am familiar with the contributing guidelines.
[x] Tests added.
[x] Updates entries to docs/source/api.rst for API changes.
[x] Adds descriptions to appropriate "what's new" file in docs/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
[x] New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
[x] Maintainer: Appropriate GitHub Labels and Milestone are assigned to the Pull Request and linked Issue.

Evaluates detect_clearsky in validator.detect_clearsky_ghi only on continuous not-NA periods. Previously, if one tried to validate a period with missing times from the index, no clearsky validation would take place at all. Another option would be to reindex the input to a set frequency and insert nans. The current approach avoids applying detect_clearsky to any NaN values at all, but may reduce the length of the series that detect_clearsky sees.
For example, the approach in this PR works like
ghi = pd.Series(data, index=[2020-01-01T12:00Z, 2020-01-01T12:15Z, 2020-01-01T13:00Z, 2020-01-01T13:15Z])
out = detect_clearsky(ghi[2020-01-01T12:00Z:2020-0101T12:15Z]) +
    detect_clearsky(ghi[2020-01-01T13:00Z:2020-01-01T13:15Z])

if reindexing were used instead, a longer series would be fed in to detect_clearsky
ghi = pd.Series(data, index=[2020-01-01T12:00Z, 2020-01-01T12:15Z, 2020-01-01T13:00Z, 2020-01-01T13:15Z])
inp = ghi.reindex(...) # pd.Series([data, data, NaN, NaN, data, data],
                                       index=pd.date_range(start=2020-01-01T12:00Z, end=2020-01-01T13:15Z, freq='15min'))
out = detect_clearsky(inp)

I can go either way.
I currently have a slight preference for inserting nans because it decouples the performance/accuracy of the algorithm from the raw data. For example, when analyzing N months of data at a time, a cloud-free, high AOD period may not be classified as clear. If that period occurs between two gaps in the data so we analyze that period in isolation, the clear sky profile can be scaled down enough that it is now classified as clear. If instead we insert nans so that we analyze the original N months simultaneously then the gaps don't effect the result and thus the performance is more under our control.
@cwhanse recently refactored the algorithm and likely has a better perspective than me.

I think both approaches (partition to non-nan sequences and apply detect_clearky, or insert nan and apply to the whole time series), would yield about the same result. The "insert nan" approach is more consistent with the published algorithm behind the pvlib method. But I don't know how many nans scattered in the data would start to affect the statistical tests.

Ok, I've switched to the "insert nans" method


issues for llm folader

Hi, it seem like the llm folder (only contains a test python file) is uncompleted and missing many essential code for running models such as llama, could you please update the code?

Thank you for your friendly reminder! We update the codes in commit d9bff319cbff669426b7e65c2dd74e701a44638d. You can use models/llm/inference.py to inference by LLMs in zero-shot setting now.


"Test have failed: the operation is insecure"

Html5test.com doesn't work on my Firefox nightly 43 on Android 5.1.1 (oneplus one) and à pop up say the message of the title of this issue.
I have the uBlocko extension.
Sorry for my bad english :)

Could you try temporarily disabling that extension and see if the test works? It would help me a lot to know the extension is causing this, or not.

Thank you for your rapid answer !
I have retry with the lastest Android nightly 43, without my addons, and it's the same error warning.
The web site work on my Firefox 40, 41 and 42.
So maybe it's a New Firefox security Feature which block your website because it test all the HTML elements (Firefox can suppose that it's a try of security exploit), of course it's Just a simple supposition.
Maybe it's a Firefox bug (but I use everydays and it's the only site which don't work)
Note that I have my cookies disabled and the do not track flag open (but normally it's not à problem).
So good luck :p
I can do tests for you.
Again sorry for my bad english.

Always don't work on my Firefox mobile nightly (now v45)  and the same issue with my Firefox mobile aurora v43 (it worked on aurora 42)

I'm not seeing any issues anymore with Firefox 47 on Android. I'm closing this bug, if it ever pops up again, please reopen.

Thank you for the answer.
It work on Firefox stable but still not on Firefox aurora and nightly (49 and 50) That's strange.

The issue is fixed when cookies are enabled, before it worked without cookies. You should at least send à message saying "please enable your cookies"
But the results are still surprising, Firefox stable have 483 of score while aurora have only 455

Ah, that was the clue I needed. It turns out that simply accessing the indexedDB property when cookies are disabled will cause an exception.
So I've added some extra code to handle this. When we see this exception we know indexedDB is supported, but disabled by the user. So I do award points for that. However, I cannot do some extra tests, so these will be listed as unknown and will not get points. That can't be helped.
Could you test if it now works?
http://alpha.html5test.com

Sorry for the late and thank you ! Now it works on my latest aurora and nightly without enabling cookies :)


Update Python SDK for receipts and events

This depends on #844

I also suggest removing the rename of State->Contexts from this PR as there is probably a significant amount of documentation that would need to be reviewed and updated.

Added docstring to add_event. Passed on other commits and doc updating work to @RyanLassigBanks

Added tests


downloadChunk does not pass the Authorization header to the registry

What is the issue?
In #5994 , regOpts were removed from the blobDownload.downloadChunk method as unnecessary. While it's true that the ollama library only offers public blobs, the lack of regOpts means that all GET /v2/<image>/blobs/... requests with a Range header cannot be accompanied by an Authorization header.
This removal now breaks the mirrored behavior with blobUpload.uploadPart where the RegOpts and corresponding Authorization header are still passed to each invocation.
I tried adding the Authorization: Bearer token to the request, but it looks like pulls from registry.ollama.ai are breaking with this change, most likely because the header is being passed to the cloudflarestorage.com URLs.

### OS

macOS

### GPU

Apple

### CPU

Apple

### Ollama version

0.3.11

Do you mind sharing what goal you're trying to accomplish? It would also be very helpful to have instructions for reproducing the behaviors you are seeing, accompanied by a description of what you expected to see.

Note: For the time being, our registry API is not "official" and is subject to change. This may change in the near future, but for now it should be considered in flux.


[dvsim, testplanner] use ordered dict instead of dict

Fixes #1748
minor fix to the path to 'rm'

@imphil
I am merging this in, considering this is a fairly small change. I will fix the os.system calls in the other PR. Let me know if there is anything else that needs to be addressed.


I want to install to jetson Xavier Nx

"I want to install Cuda OpenCV on the Jetson Xavier NX device, but it's giving an error saying 'nano model not recognized'. Is there any possibility to install it? I'm using Jetpack 5.1.2."

You have to do it manually. See https://qengineering.eu/install-opencv-on-jetson-nano.html
It is targeted for the Nano, but it works also for the Xavier NX.
BTW, the script here is identical to the one on the website.


feat: Update to have optional path

Hi @marcel-ploch
Can you please update this PR once you have time so we can take another look at it?
Thanx!

Superseded in #83


ParseError in PHP 7 results in FatalThrowableError

Running Laravel 5.1.26 on Homestead PHP7.0.0RC5 I got this error:
FatalThrowableError in FlattenException.php line 76:
Type error: Argument 1 passed to Symfony\Component\Debug\Exception\FlattenException::create() must be an instance of Exception, instance of ParseError given, called in /home/vagrant/www/ambulance/myshift/vendor/symfony/debug/Exception/FlattenException.php on line 98

in FlattenException.php line 76
at FlattenException::create(object(ParseError)) in FlattenException.php line 98
at FlattenException::create(object(ReflectionException)) in ExceptionHandler.php line 209
at ExceptionHandler->createResponse(object(ReflectionException)) in Handler.php line 155
at Handler->convertExceptionToResponse(object(ReflectionException)) in Handler.php line 98
at Handler->render(object(Request), object(ReflectionException)) in Handler.php line 55
at Handler->render(object(Request), object(ReflectionException)) in Kernel.php line 281
at Kernel->renderException(object(Request), object(ReflectionException)) in Kernel.php line 91
at Kernel->handle(object(Request)) in index.php line 53

I had a syntax error in my PHP code - but I couldnt work it out for ages (because the error message wasnt helpful). In my FormRequest object I had this:
return [
            'date' => 'required|string|date_format:d-m-Y'
            'area_list' => 'required|string|exists:area_staff_sheet_lists,id'
            'shift_type' => 'required|string|in:day,night,oncall'
        ];

Notice the missing 'commas' at the end of each row.
Looks like it is related to this - but it is already fixed? https://github.com/symfony/symfony/issues/15245

This looks pretty impossible to me. ;?

at FlattenException::create(object(ReflectionException)) in ExceptionHandler.php line 209

Is this the exception handler in your own app?

Is your exception handler custom?

After some debugging, it;s clear that is a bug in Symfony's flatten exception class.

See how it's recursively going through the previous exceptions: https://github.com/symfony/debug/blob/2.7/Exception/FlattenException.php#L98.

It needs to only do that if the previous is actually an instance of Exception

I'm going to send a PR to symfony for you.

There we go: https://github.com/symfony/symfony/pull/17052.
Thanks for reporting,

Thanks @GrahamCampbell

Getting a similar problem running 4.2 on php 7 with the Whoops file handler. I basically had to register a custom error handler that would log all Throwable types in order to get anything other than a Whoops error.
Can this be addressed just by updating the Whoops dependency (looks like they have resolved this filp/whoops#352)?

@pnoonan Sorry, but Laravel 4.2, and the related symfony version will never get fixed. You need to upgrade to Laravel 5.1.

Can this be addressed just by updating the Whoops dependency (looks like they have resolved this filp/whoops#352)?

Sorry, it can't. That won't work.

Laravel 5.1 is the first version of laravel to support php 7.0.

@TheShiftExchange Symfony have merged and tagged my fix now btw. ;)

For anyone ending up on this thread. Laravel 4.2.20 is out and supports PHP7.


Cache generated environment map

Description
Currently any model that uses the default environment map will each generate their own, but they're all identical. IIRC the original intention was possibly to have multiple tints, or different parameters to tweak the default environment. Since that's not yet the case, we should probably cache it, probably in the TextureUtils for now.

@cdata, as I was debugging it seems this has already been fixed, as this is now cached. However, if we apply a PMREM pass to it, that is applied once for each model (using the same cached environment as input, but generating a new PMREM texture).


nushell: Error: nu::shell::cant_convert upon esc or Ctrl-C

hey, it's not a big deal, but the integration with nushell, when you trigger atuin then exit with "esc" or "Ctrl-C" nushell throws the following error
Error: nu::shell::cant_convert

  × Can't convert to range.
   ╭─[entry #7:1:1]
 1 │ # 4cf6bc0a-973e-4fe2-b0c7-e2d99c7dd373
 2 │ commandline (RUST_LOG=error run-external --redirect-stderr atuin search "--interactive" "--" (commandline) | complete | $in.stderr | str substring ',-1')
   ·                                                                                ──┬──
   ·                                                                                ╰── can't convert string to range
   ╰────

Just in case you are interested

Fixed in this pr: https://github.com/ellie/atuin/pull/840

Thank you !


fixed divider flicker when dragging

https://github.com/caduandrade/multi_split_view/assets/51524705/79285dcd-e03b-4037-8bb5-0e2a65185108
divider Still flickering when dragging on desktop app


jetpack: Fix link to Boson for FRAMOS Orin NX page

The existing link points to the Boson Xavier page, not the Boson Orin page.
fyi @GiulioRomualdi

Hi, I just saw this PR and I'd like to do a clarification about this change.
Actually, for the Orin NX we have a hybrid configuration of hardware and software (@maggia80 should be aware of this) since the hardware is the one I've linked (our carrier is the NGX007, the BSP installed on that board is the one for the Orin NX.
cc @Nicogene @pattacini @traversaro

yes, it's true. The NGX020 was not available at that time.
I created the new code in Wingst for this board and we will purchase this one next time

18413 | CONNECTTECH_NGX020
-- | --


Cookie names not available

In the documentation it says to use the following:
cookie = {
  "s_v_web_id": "<your_key>",
  "tt_webid": "<your_key>"
}

But after logging in to Tiktok, there is no cookie by these names.
Seems like tt_webid has changed to ttwid.
But cant figure out what or where to locate the s_v_web_id
Does anyone know?

are you sure you need login? Some task can be done anonymous

are you sure you need login? Some task can be done anonymous

Even without login, the cookie names specified in the documentation dont exist.
Cookie names are just these:
cmpl_token
msToken
bm_sv
sessionid_ss
sessionid
sid_tt
msToken
sid_ucp_v1
uid_tt_ss
odin_tt
_abck
ssid_ucp_v1
passport_csrf_token_default
passport_csrf_token
sid_guard
cookie-consent
uid_tt
bm_mi
csrf_session_id
ak_bmsc
ttwid
bm_sz
tt_csrf_token

Even without login, the cookie names specified in the documentation dont exist.
Cookie names are just these:
cmpl_token
msToken
bm_sv
sessionid_ss
sessionid
sid_tt
msToken
sid_ucp_v1
uid_tt_ss
odin_tt
_abck
ssid_ucp_v1
passport_csrf_token_default
passport_csrf_token
sid_guard
cookie-consent
uid_tt
bm_mi
csrf_session_id
ak_bmsc
ttwid
bm_sz
tt_csrf_token

can you clarify what task you are trying to do?

can you clarify what task you are trying to do?

Just trying to get started with this and found that as per the documentation, those two cookie names do not exist. So even before im trying to do anything, the first step of the documentation seems a bit confusing.
Get your keys from Cookie. You can get them from the Applications tab in Chrome developer console.
By default it used hardcoded values which may not work after some time.
The keys to extract are s_v_web_id and tt_webid

Just trying to get started with this and found that as per the documentation, those two cookie names do not exist. So even before im trying to do anything, the first step of the documentation seems a bit confusing.
Get your keys from Cookie. You can get them from the Applications tab in Chrome developer console.
By default it used hardcoded values which may not work after some time.
The keys to extract are s_v_web_id and tt_webid

for certain task you dont need cookie, so if you can clarify your objective, I might be able to help

for certain task you dont need cookie, so if you can clarify your objective, I might be able to help

Ok, so my eventual goal is to use the:
api.getLikesByUserName(user_name, count=3)
api = TikTokAPI(cookie=cookie)
and cookie essentially takes the s_v_web_id and tt_web_id

Ok, so my eventual goal is to use the:
api.getLikesByUserName(user_name, count=3)
api = TikTokAPI(cookie=cookie)
and cookie essentially takes the s_v_web_id and tt_web_id

can you please provide example user?

can you please provide example user?

from TikTokAPI import TikTokAPI as tta
cookie = {"s_v_web_id": '',"tt_webid": ''}
api = tta(cookie=cookie)
user_name = 'fcbarcelona'
api.getLikesByUserName(user_name, count=3)

from TikTokAPI import TikTokAPI as tta
cookie = {"s_v_web_id": '',"tt_webid": ''}
api = tta(cookie=cookie)
user_name = 'fcbarcelona'
api.getLikesByUserName(user_name, count=3)

same problem here

For downloadVideoByIdNoWatermark, you dont need cookies:
http://api2.musical.ly/aweme/v1/aweme/detail/?aweme_id=7038589018707070213

It doesn't run tho, just lockup. It should take so long?
api = TikTokAPI()
api.downloadVideoByIdNoWatermark(video_id = "6981810792173735194", save_path="./yes/")

I have an alternate API that works for videos. It doesnt work for users yet:
https://github.com/89z/mech/blob/master/cmd/tiktok/tiktok.go

if you take cookies from browser it changes to:
s_v_web_id = s_v_web_id
tt_webid => sid_ucp_v1

cookie = {
"s_v_web_id": "<your_key>",
"tt_webid": "<your_key>"
}

I have sid_ucp_v1 in my cookies, but i don't have s_v_web_id. How to fix it?


EXSWHTEC-76 - Implement additional tests for Malloc/Free API

Implement positive and negative tests for hipMallocMipmappedArray based on existing hipMalloc3DArray tests
Implement positive and negative tests for hipFreeMipmappedArray based on existing hipFreeArray tests
Memory leak fix in Unit_hipMalloc3D_Basic

PR has been merged into develop branch via commit 10594ecb3a4bb1a7e26da627419de9e916866c34.


APM history is gone after application upgrade

Upfront explanation:

application in this context is a CRX package that contains *.cqsm files and saves them in JCR repository under /etc/cqsm/import/jcr:content/cqsmImport and /etc/cqsm/import/jcr:content/cqsmInclude

APM execution date displayed on http://localhost:4502/etc/cqsm/import.html comes from JCR property that's stored directly under given script as cqsm:executionLast. Upon application update APM scripts get replaced and this property is gone. Eventually, even though given script was executed and hasn't changed in the new app, /etc/cqsm/import.html will show that this script was never executed, which is not true. If script has changed then this is absolutely expected.
At the same time there's a full history under /etc/cqsm/history/jcr:content, which I rely on at the moment in my Chef cookbook to verify if script has or hasn't been run yet.
All in all execution history is stored in 2 places - directly under given script as well as under /etc/cqsm/history/jcr:content. Is this really a reasonable approach?
This is not a big deal, but affects user experience and can lead to misleading conclusions sometimes.
Possible considerations and solutions:

ideally execution history should be stored in a single place
application (custom CRX package) should never overwrite /etc/cqsm/import/jcr:content/cqsmImport and /etc/cqsm/import/jcr:content/cqsmInclude. MERGE filter should be used instead (to avoid unwanted removal of cqsm:executionLast property from scripts)
even though above change will preserve the cqsm:executionLast property it doesn't really mean that information about last execution on /etc/cqsm/import.html will be accurate, as content of given script can change with application upgrade
whenever Created at date is newer than cqsm:executionLast (please note that it may happen if MERGE filter was used in my application package), given script should be considered as not yet executed (in other words cqsm:executionLast should get removed). This is not ideal, as create/update date of given node doesn't really mean that something has been updated in a script
for higher execution accuracy different approach can be taken into consideration - each script is identified by its content. Whenever that changes, APM should mark script as not yet executed. It probably means we need to introduce some sort of a script checksum. It can be a brand new JCR property that's attached to each script. Thanks to that whenever user opens import console, history is searched to see if there's an entry that contains that checksum property. Don't know what are the performance implications of such change though, in particular for an instance that contains hundreds of history entries. Additionally APM should recalculate script's checksum if file was modified (either by a package installation or an in-place update). I imagine that as a sort of a listener.

Internal ticket reference: CQSM-245

It's done in version 5.0.0


Upgrade bimmer_connected to 0.6.2

Description:
Upgrade bimmer_connected to 0.6.2
Related issue (if applicable): fixes #25447
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist

If the code communicates with devices, web services, or third-party tools:

[x] The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
[x] New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.

Thanks Martin.
Will first remove the sleep as we tested it without and that worked fine as well. This allows the PR to be merged and in the meanwhile we can have a look at your suggested solution.
cc @timmccor

Removed time.sleep from the library in bimmer_connected 0.6.2.


Added web compatible libraries

To help push adoption of universal components forward, I really want native.directory to be a one stop shop for people looking for RN libs that work on web.
I went ahead and added libs that I know for sure work on web (we used them in prod at MLS). Over the next few days, I'm going to be adding more once I write a script to determine a lib's web compatibility %.
I also added react-native-create-bridge to the directory. 😀

@peggyrayzis you rock! Thank you so much
LGTM


Revert "chore(deps): update dependency semantic-release to v20"

Reverts openedx/edx-bootstrap#100 to fix failing release

https://github.com/openedx/wg-frontend/issues/158


feat: S3Resource improved getURL handling

:loudspeaker: Type of change

[ ] Bugfix
[ ] New feature
[x] Enhancement
[ ] Refactoring

:scroll: Description
Improves the S3Resource getURL handling and received the url from the s3Client itself.
:bulb: Motivation and Context
The s3Client provides a URL that fits better to the remote resource.
:green_heart: How did you test it?
Not yet - the Integration tests and unit tests may need to be adjusted.
:pencil: Checklist

[ ] I reviewed submitted code
[ ] I added tests to verify changes
[ ] I updated reference documentation to reflect the change
[ ] All tests passing
[ ] No breaking changes

:crystal_ball: Next steps

[ ] adjust unit and integration tests

#794 needs to be fixed before

https://github.com/awspring/spring-cloud-aws/pull/798 needs to be done before

For a bucket s3resourcetest-bucket and key new-file.txt getURL() returns:

before PR: https://s3resourcetest-bucket.s3.amazonaws.com/new-file.txt
after PR: https://s3resourcetest-bucket.s3.eu-west-1.amazonaws.com/new-file.txt
after PR with spring.cloud.aws.s3.path-style-access-enabled=true: https://s3.eu-west-1.amazonaws.com/s3resourcetest-bucket/new-file.txt

The upside is that getURL() starts respecting path style access, the downside is that it returns different URL - so maybe - but very unlikely, breaking for someone who relies exactly on the value.

Thanks for PR @klopfdreh


Calculated income is wrong for 2022

According to https://www.masslegalservices.org/content/federal-poverty-guidelines-2022, 125% of the poverty level for a family of 3 is $28,788. However, this package will calculate the value to be $34,687.50, which is the value for a family with one additional person.
Household size: 3
household_income_limit: 34687.5
poverty_base: 13590
poverty_increment: 4720
poverty_level_update: "2022"
poverty_multiplier: 1.25

From https://aspe.hhs.gov/topics/poverty-economic-mobility/poverty-guidelines/prior-hhs-poverty-guidelines-federal-register-references, it looks like the issue isn't in the values, but how we suggest interviews use them. The suggested use in the README should change to:
  additional_income_allowed = max(household_size - 1, 0) * poverty_increment
  household_income_limit = (poverty_base + additional_income_allowed) * poverty_multiplier

  household_income_qualifies = int((household_income_limit)/12) >=  int(household_monthly_income)

And should change in ALAffidavitOfIndigency.


Endpoint Config :path Change Breaks Live Reload Path Match

After altering the :path in my phoenix project's config.exs file to:
url: [host: "localhost", path: "/newsite"],

and my endpoint.ex file to:
...
 if code_reloading? do
    socket "/newsite/phoenix/live_reload/socket", Phoenix.LiveReloader.Socket
    plug Phoenix.LiveReloader
    plug Phoenix.CodeReloader
  end
...

The Phoenix.LiveReloader plug's call function will never match on the path info.
i.e. This function definition won't match as long as the path has been prepended:
def call(%Plug.Conn{path_info: ["phoenix", "live_reload", "frame"]} = conn , _) do

I've modified this locally and it looks to be working well. I'll send a PR for your review.
Cheers,
Tony

On second thought, I think this isn't a good idea. I can get it working very well for me but this wouldn't be a good modification for the broader community. It can be efficient for one level deep such as prepending /newsite/ to the path but to accommodate anything longer means trying to match the last 3 elements of :path_info with ["phoenix", "live_reload", "frame"] on every request. Then ensure the full path is actually the same as the user defined prefix + /phoenix/live_reload/frame and not something random like "/xyz/phoenix/live_reload/frame".
An example of how this could be handled is here: https://gist.github.com/tesp0/9582e2937047f1f031bcfa100962b086#file-live_reloader-ex-L68-L81
Perhaps it would be a good idea to not grab the endpoint.path() in reload_assets_tag/1. So at least if someone sets their path to something non-standard it won't break live reload. I think that this should just be a static path that is always /phoenix/live_reload/frame.
What are your thoughts?

@tesp0 thank you for the report. There is a slightly disconnect here. When you use the :path option, it is typically because you are running Phoenix inside a server (like Apache or Nginx) which makes itself think it is at root while it is actually inside "/newsite". So you need to change the URL generation so it knows where it is pointing to.
According to your changes, it seems like you are using /newsite but still effectively accessing it all directly through Phoenix, without the proxying, hence it doesn't work.
Is this interpretation correct or am I missing something?

Thanks for getting back so quick @josevalim :)
Indeed I am trying to run a phoenix site behind a reverse proxy.
I should've rewrote the urls with rewrite ^/newsite/(.*)$ /$1 break; and now I understand the purpose of the path option, it makes perfect sense now! I really wish I thought of that before hand :(
I just set it all up correctly and it's working like a dream with original code as well.
Thanks for taking the time, you saved me a lot of time!
Cheers,
Tony


Add support for bootstrap-style alert boxes in notebooks

This PR fixes microsoft/vscode-jupyter#8399

IMO this is too specific to belong in core VS Code. It should come from an extension, either a custom one or jupyter

blockquote is a built-in html element. Bootstrap is just a 3d party framework

Sure, but the bootstrap alert styles seems to have become a defacto feature of jupyter notebooks: They're supported in:

Jupyter's own web renderer
Github's web renderer; see this notebook for instance:
https://github.com/sigproc/cued_sf2_lab/blob/6a63558466eb147a640f5b19ab5e7ce3621833f4/1-4-intro-and-familiarisation.ipynb
nbsphinx's renderer: https://nbsphinx.readthedocs.io/en/0.2.7/markdown-cells.html#Info/Warning-Boxes

It sounds like it may belong in Jupyter then. This code or core VS Code applies to every kind of notebook. Bootstrap specific stuff does not belong here

This code or core VS Code applies to every kind of notebook.

I think this sounds like the source of my confusion; what other types of notebook are there?

Anyway, thanks for the review! Would you be able to advise on https://github.com/microsoft/vscode/pull/149368#discussion_r871638930 so that when I PR this downstream to the jupyter plugin I don't make the same mistake?

You can use the webview css variables for this: https://code.visualstudio.com/api/extension-guides/webview#theming-webview-content


Duplicate concept definition found

created a circular reference in .cpt file then "Duplicate concept definition found" error shows up even after you delete the circular reference in the project.

no logs

I could also see this happening even when there is no duplicate concepts in vscode, the tests run fine though.


A sample folder structure of a Python package published in JOSS

Here is the sample package that has submitted and published in JOSS
https://github.com/mnets/pymnet
Could you please refactor the project folder structure as the sample package has?

I think this issue is completely resolved and I'm closing.


TypeError: Cannot read property 'indexOf' of undefined

https://errortracking.prod-preview.openshift.io/openshift_io/fabric8-launcher-frontend/issues/4565/
TypeError: Cannot read property 'indexOf' of undefined
  at validateRepo (~/ngx-forge/src/app/launcher/step-indicator/step-indicator.component.js:72:1)
  at t.validateProjectName (~/ngx-forge/src/app/launcher/step-indicator/step-indicator.component.js:108:1)
  at handleEvent (~/@angular/core/@angular/core.es5.js:11998:86)
  at handleEvent (~/@angular/core/@angular/core.es5.js:12717:68)
  at dispatchEvent (~/@angular/core/@angular/core.es5.js:8614:1)
...
(8 additional frame(s) were not displayed)

Seems to be resolved. Closing


Cataloger filtering cross matches wrong catalogers

Adding the following test to https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/cataloger_test.go#L27 shows that when requesting only java-cataloger, the javascript-package-cataloger and javascript-lock-cataloger are both enabled, which IMHO is wrong.
                {
			name: "don't cross match",
			patterns: []string{
				"java-cataloger",
			},
			catalogers: []string{
				"javascript-package-cataloger",
				"java-cataloger",
			},
			want: []string{
				"java-cataloger",
			},
		},

Entirely agreed -- this is not correct behavior. We could change the behavior to require matching exactly (instead of contains) or make hard coded exceptions (not ideal, but could be a fine workaround for now if we wanted something quick that didn't break existing behavior).
Additionally there is a PR that we're looking to get in that would change this behavior for the better https://github.com/anchore/syft/pull/1383 (specifically at https://github.com/anchore/syft/pull/1383/files#diff-e7cb9915335df0e3ab997cf8a7b0574e4a0ecc5dc8db5a9e6ed8ba28eccb325b). The cataloger selection is more explicit and doesn't rely on the contains approach as done now.

I've additionally opened up https://github.com/anchore/syft/issues/1578 to capture the fact that this cataloger name is not specific enough for what it does.


Allow "major" as a value for assemblyVersion.precision

All tests passing now. Thanks for all of your assistance in getting the environment working.

(Fixes #97)