Add generalized arity tuples

This is another proposal for a generalized tuples solution. Compared to similar RFCs, this RFC

only needs one key idea implemented in the compiler
does not add any new syntax
does not add any special traits
does not change the way Rust reasons about types

Rendered

@Centril Thank you very much for your feedback. I will address your comments and update this RFC once I find the time for it. :blush:

This was essentially what I was thinking about proposing for variadic tuples, plus or minus some names and implementation details and such. I'll put my support behind it.
That said, my incubated proposal avoids specifying anything about tuple layout (mostly to avoid edge cases where alignment concerns cause tuples to be up to an order of magnitude larger than a similarly defined struct), and instead specifies a heterogeneous iteration mechanism, then augments tuples so that this heterogeneous iteration mechanism can be used to iterate over and destructure the tuple's fields by reference, by mut reference, or by move.

Some thoughts:
When I implemented the initial version of size layout optimizations, we discovered that this can let some very small tuples and structs fit into registers when making function calls, i.e. (u8, u16, u8) becomes (u16, u8, u8).  No one did a detailed analysis of how much this mattered because it was an emergent behavior; the reaction was "huh, that's cool and it might help." Given Rust's increased adoption in the embedded space, this may have practical implications on someone at this point.
Dropping layout optimizations also means that sequences of tuples take a real hit, if the program likes to build containers containing tuples.  In practice (I don't have the reference handy) I think the largest gain we saw from field reordering was 72 bytes.  I would expect the gains for reordering tuples to be much less since you usually use a struct for a large number of fields, but it can be a surprisingly significant drop.
I don't think these optimizations can be swept under the rug at this point.  It's one thing for Rust to deoptimize memory usage on a PC, but quite another for it to deoptimize memory usage on a small microcontroller, where the line between "runs" and "doesn't run" can be small enough that a few extra bytes matters.
With variadics, you can for example pass 10 4-to-8 byte arguments in registers on some platforms.  With tuples you can't, short of complicated optimizations that are hard to reason about as an end user of the language. For instance the compiler could elide tuples constructed at call sites, but probably couldn't if they're stored in variables.  You can, however, arguably get forward compatibility with variadics using current tuples by making the compiler understand that a call myVariadic(my_tuple) should desugar to myVariadic(my_tuple.0, my_tuple.1, ...).  In practice this behavior would probably need to be behind a macro or special syntax because there's no way to distinguish between calling a variadic function with one tuple argument, or wanting to expand a tuple, but it allows for much of the same effect.
Either way, I don't think that tuples can replace variadics in practice because variadics have a lot more potential around being faster.  Perhaps there's a clever way to implement this in the compiler so that the gap closes, but if there's not I don't expect this will put that discussion to rest.

@camlorn @Centril What if the compiler would not use Tuple<ELEM, TAIL> or Tuple<INIT, ELEM> as a representation but Tuple<LEFT, RIGHT, ELEM> which would be equivalent to (LEFT.0, ..., LEFT.n-1, ELEM, RIGHT.0, ..., RIGHT.m-1)?
The compiler could reorder an arbitrary tuple (A, D, B, C, G, E, F) to the desired memory layout (A, B, C, D, E, F, G) using the following strategy:
(A, D, B, C, G, E, F)
  ELEM = G
  LEFT = (A, D, B, C)
    ELEM = D
    LEFT = (A,)
      ELEM = A
      LEFT = ()
      RIGHT = ()
    RIGHT = (B, C)
      ELEM = C
      LEFT = (B,)
        ELEM = B
        LEFT = ()
        RIGHT = ()
      RIGHT = ()
  RIGHT = E F
    ELEM = F
    LEFT = (E,)
      ELEM = E
      LEFT = ()
      RIGHT = ()
    RIGHT = ()

As ELEM is in the last position, unsized types should work as well. However, this approach would require at least one new language features that enables matching TUPLE<(), SUB, ELEM> with TUPLE<SUB, (), ELEM> and so on.
This means, in particular, when writing a generalized mapping function from, let's say, (u32, u16, u8) to (u8, u8, u8), we have to deal with the fact that the Tuple trees differ from each other and they need to me mapped at the value level. After all, I strongly believe that this structural mapping needs to be implemented anyway at some point in the future, no matter what the solution for the variadic tuples/generics problem will be.

What if the compiler would not use Tuple<ELEM, TAIL> or Tuple<INIT, ELEM> as a representation but Tuple<LEFT, RIGHT, ELEM> which would be equivalent to (LEFT.0, ..., LEFT.n-1, ELEM, RIGHT.0, ..., RIGHT.m-1)?

That sounds like it has nasty implications for parametricity.
fn func<A, B, C>(tup: (A, B, C)) {
    // Does this have type A, B, or C?
    let x = get_elem(tup);
}

fn get_elem<L, R, E>(tup: Tuple<L, R, E>) -> E {
    tup.2
}

@ExpHP The compiler would not accept tup.2 since tup being Tuple<L, R, E> is not a well-formed tuple.
On the other hand, if tup was Tuple<Tuple<(), (), usize>, Tuple<(), (), char>, String>, then tup.2 would evaluate to char.

I meant .elem, I edited the post.

You can accomplish most of the same tasks using a tuple trait.  This would avoid the need to define tuples as having a particular structure, and also opens the door to more flexibility in the future, especially regarding references.
Here is a playground link where I've implemented the three examples in the RFC in today's Rust; I had to use a macro to define two base traits (HeadTail and Prepend) for different sizes of tuples, but Join, Last, and Halve themselves are implemented without any macros.  However, Last does not actually compile, because rustc thinks the two impls could conflict even though they don't.  That seems like it should be possible to improve.
With GATs, instead of having a HeadTail trait and a Prepend trait, you could pack everything into one trait:
trait Tuple {
    type Head;
    type Tail;
    fn head(self) -> Self::Head;
    fn tail(self) -> Self::Tail;

    type Prepend<N>;
    fn prepend<N>(self, n: N) -> Self::Prepended<N>;

    // more operations...
}

Anyway, if you read my implementation, the obvious downside is the stuttering:
impl<T> Join for T where
    T: Copy,
    T: HeadTail,
    <T as HeadTail>::Head: Join,
    <T as HeadTail>::Tail: Join,
    <<T as HeadTail>::Tail as Join>::Joined: Prepend<<<T as HeadTail>::Head as Join>::Joined> {
    type Joined = <<<T as HeadTail>::Tail as Join>::Joined as Prepend<<<T as HeadTail>::Head as Join>::Joined>>::Prepended;

However, this could potentially be mitigated in a few different ways:

If the (already accepted) implied bounds RFC is ever implemented, especially if it's extended to type aliases, you could get most of those bounds introduced implicitly.
Even without that, use of type aliases could make the above snippet much shorter.
rustc can get smarter about inferring the appropriate trait for type projections.  Currently, you can write T::Foo and have rustc guess which trait Foo belongs to based on impls in scope, but if you have a nested projection likeT::Foo::Bar, rustc requires explicitly specifying the trait for Bar.

You can accomplish most of the same tasks using a tuple trait. Using a trait (which the compiler could automatically implement for tuple types) would avoid the need to define tuples as having a particular structure, and also opens the door to more flexibility in the future, especially regarding references.

This seems like a great idea. One issue that people may have with is it, is that it allows other types to masquerade as tuples, but I think that is fine.

Edit: Actually, that's not great because it would imply defining a head and tail for (). What we really need is some way to express disjunction: a tuple either has a head and a tail, or is (). Ideally it would be possible to write a separate impl of a trait for each case, and then be able to convince the compiler that you've impled the trait for all T: Tuple.

This can be solved with some unit types.
struct NoHead;
struct NoTail;

impl Tuple for () {
    type Head = NoHead;
    type Tail = NoTail;
    // ...
}

impl<T> Tuple for (T, ) {
    type Head = T;
    type Tail = NoTail;
    // ...
}
// ...

Anyway, if you read my implementation, the obvious downside is the stuttering:

Can we get some compiler magic to ignore this until implied bounds comes along (if it does)?

One issue that people may have with is it, is that it allows other types to masquerade as tuples, but I think that is fine.

The compiler could simply prevent any manual implementations of the Tuple trait. Such a restriction could always be relaxed in the future, without breaking backwards compatibility.

Thinking about this some more, with @Aaron1011's idea of limiting who can implement the trait, and with the NonEmpty trait we can implement algorithms recursively.
impl<T: NonEmpty> Debug for T {
    fn fmt(&self, f: &mut Formatter) -> Result {
    }
}

@Woyten and everyone else:
Unless something has significantly changed since I did my work on the compiler (it has been a very long time as these things go at this point) making a tuple a tree is going to be just as hard to optimize as making a tuple list-like (there are proper terms for these, but I haven't done serious functional programming in a long time).  The compiler is written such that assuming that a type-of-types-of... will in some way combine the layouts of the lower levels.  There's been some movement away from that, for example the niche optimizations, but something this fundamental would be a pretty big change.  I believe tuples are actually the same variant of ty::layout as structs, and that the rest of the pipeline after that gets to treat them as effectively the same--that is to say either we can optimize nested structs and this representation of tuples, or do neither, and since we can't do this optimization on nested structs because of pretty bad performance implications and borrowing, we can't do it at all (specifically if a.b is itself a struct, &a.b can't borrow if we optimize layout using a global thing that looks at all fields of all nested types).
Someone more up to date on the compiler's internal workings should perhaps chime in here.
There's a lot of paths forward without these downsides:

Many traits can be implemented by implementing the trait for one item of the tuple, then effectively saying "for all items do...".  @comex's proposal can be made to do this, and it could be given a convenient syntax (i.e. a macro in std).
The type system can be extended (@comex  again). How is an interesting discussion that I don't have the background for, but most of the proposals around that bring other interesting benefits in addition to "we fixed tuples" and are worth it for that reason in my opinion.
One of the most common uses for this that I've seen is being able to write generic future combinators, which are better served by variadics anyway (because then you don't have to wrap everything in an extra set of parens).

In general I favor approaches that don't deoptimize memory to make this work.  having to do some extra copies makes a program slower. Having to use more memory makes a program run out of memory.  In hindsight someone should probably have raised concerns around never being able to undo field reordering once it was stabilized for this reason, but we are nonetheless in a state where I would be hesitant to do that; CPU is a more bountiful resource than memory, in the sense that if you don't have enough you run slower vs if you don't have enough you can't run at all.  Also reordering tuple fields to fix your memory issue is not nearly so easy as reordering struct fields, since the order of tuple fields is their names--that is to say if we disabled this for structs we could fix programs that had this issue by changing the struct definition, but for anything else that might suddenly break or balloon in memory usage, someone has to find all the places it's used too.
No one will pay for the extra copying, should it be necessary, on day one either. It'll only be in new APIs that use the new feature.
For borrowing the tail of tuples, I think that we should disallow it unless it's the last item. This may be technically infeasible. But if we don't, it's a weird asymmetry in a lot of these proposals, since in effect you can probably only borrow the tail in some places (one unique advantage of this specific RF C is that I think it would work everywhere).

I like the direction of a trait rather than a struct. However, would it require a special case in a impl coherence rules so that impl<T> SomeTrait for T where T: Tuple is not considered to conflict with impl SomeTrait for SomeUpstreamType? I think it currently would, in case the dependency crate would later add impl Tuple for SomeUpstreamType.
To avoid the need to borrow the tail of a tuple (and the memory layout constraints that implies) we could:

Only provide decomposition into head and tail that move / take ownership of the input tuple rather than borrow it. This requires GATs with lifetime parameters.
Have projections from references to a tuple to a tuple of references, similar to Option::as_ref and Option::as_mut.

API sketch:
pub trait Tuple {
    type AsRef<'a>;
    type AsMut<'a>;
    fn as_ref<'a>(&'a self) -> Self::AsRef<'a>;
    fn as_mut<'a>(&mut 'a self) -> Self::AsRef<'a>;

    type First;
    type Rest;
    fn split_first(self) -> Option<(Self::First, Self::Rest)>;
}

// Compiler-generated for all tuple sizes:

impl Tuple for () {
    type AsRef<'a> = ();
    type AsMut<'a> = ();
    fn as_ref<'a>(&'a self) -> Self::AsRef<'a> { () }
    fn as_mut<'a>(&mut 'a self) -> Self::AsRef<'a> { () }

    type First = !;
    type Rest = !;
    fn split_first(self) -> Option<(Self::First, Self::Rest)> { None }
}
...
impl<A> Tuple for (A,) {
    type AsRef<'a> = (&'a A);
    type AsMut<'a> = (&'a mut A);
    fn as_ref<'a>(&'a self) -> Self::AsRef<'a> { (&self.0) }
    fn as_mut<'a>(&mut 'a self) -> Self::AsRef<'a> { (&mut self.0) }

    type First = A;
    type Rest = ();
    fn split_first(self) -> Option<(Self::First, Self::Rest)> { Some((self.0, ()) }
}

impl<A, B> Tuple for (A, B) {
    type AsRef<'a> = (&'a A, &'a B);
    type AsMut<'a> = (&'a mut A, &'a mut B);
    fn as_ref<'a>(&'a self) -> Self::AsRef<'a> { (&self.0, &self.1) }
    fn as_mut<'a>(&mut 'a self) -> Self::AsRef<'a> { (&mut self.0, &mut self.1) }

    type First = A;
    type Rest = (B,);
    fn split_first(self) -> Option<(Self::First, Self::Rest)> { Some((self.0, (self.1,)) }
}

// etc.

Alternative where () doesn’t implement the trait:
pub trait NonEmptyTuple {
    // …
    fn split_first(self) -> (Self::First, Self::Rest)
}

I think that having 1 trait is better, using an Option is good enough since this trait will be useless as a trait object, split_first will be inlined and the Option will be optimized away.

Could this RFC (whether struct or trait approach) be applicable to function pointers?

fn(A, B, C, D) -> R
unsafe fn(A, B, C, D) -> R
extern fn(A, B, C, D) -> R
unsafe extern fn(A, B, C, D) -> R
extern fn(A, B, C, D, ...) -> R
unsafe extern fn(A, B, C, D, ...) -> R

What about the Fn/FnMut/FnOnce traits/objects?

I like the direction of a trait rather than a struct. However, would it require a special case in a impl coherence rules so that impl<T> SomeTrait for T where T: Tuple is not considered to conflict with impl SomeTrait for SomeUpstreamType? I think it currently would, in case the dependency crate would later add impl Tuple for SomeUpstreamType.

Good point.  Something like this old proposal for "sealed traits" could work – a way to mark a trait as not being implementable outside of the crate it's defined in, which would then allow more relaxed coherence rules.

What about the Fn/FnMut/FnOnce traits/objects?

We could change the Fn* traits to add Tuple bounds, e.g.
trait Fn<Args> where Args: Tuple

This would not be a breaking change, because you can't write Fn<Args> on stable; you have to use the Fn(Arg, Arg) sugar, which guarantees that the generic parameter is a tuple.
However, to be able to recurse on the Args parameter in a generic context would require some way to express disjunction, as I mentioned before.  You need to be able to write separate impls of your trait for non-empty tuples and for (), and then somehow convince the compiler that your trait is necessarily impl'ed by Args given that Args: Tuple.
One potential approach could be based on associated constants.  Something like:
enum TupleKind {
    Empty,
    NonEmpty
}
trait Tuple {
    const KIND: TupleKind;
}
impl<T> Foo for T where T: Tuple<KIND=TupleKind::Empty> { ... }
impl<T> Foo for T where T: Tuple<KIND=TupleKind::NonEmpty> { ... }

The compiler would have to add support for referencing associated constants with Trait<Foo=Bar> syntax, not just associated types, and additionally be able to tell that the impls together cover all possible variants of TupleKind.
Alternately, there have been some proposals for "mutually exclusive traits".
A third approach would be to add type inequality constraints, but I don't think those would be as easy to implement as they seem: they run into the same coherence issues as specialization.

I like the direction of a trait rather than a struct. However, would it require a special case in a impl coherence rules so that impl<T> SomeTrait for T where T: Tuple is not considered to conflict with impl SomeTrait for SomeUpstreamType? I think it currently would, in case the dependency crate would later add impl Tuple for SomeUpstreamType.

Good point. Something like this old proposal for "sealed traits" could work – a way to mark a trait as not being implementable outside of the crate it's defined in, which would then allow more relaxed coherence rules.

Trait specialization is coming around as part of the 2019 roadmap; perhaps it might be the tool at hand that we use to make this work when it comes time to implementation?

Specialization could work for some things, but as it stands today it has limitations.  If you write <Foo as Trait>::Bar, the compiler will usually 'normalize' the projection by replacing it with whatever Bar is defined as in whichever Trait impl it finds for Foo.  But if that impl only defines a default type, the compiler intentionally leaves it un-normalized.  This is meant to preserve forwards compatibility with hypothetical specialized impls being added in the future; unfortunately, it also makes it impossible to do type-level computation with it, which severely limits what you can accomplish.  In other words, if you ask "does a specialized impl apply", the compiler can only answer "yes" and "maybe", not "no".  Perhaps this could be improved in the future, but I'm not exactly sure how.
...But in any case, the post you quoted wasn't about conflicts between nonempty tuples and (), but about conflicts in downstream crates between impls of the same trait for tuples and for unrelated types, because the compiler doesn't want to rule out that you could impl Tuple for UnrelatedType.  Specialization could serve as a workaround there too, but it's annoying to force on downstream crates, and for some use cases you'd need the (proposed but not implemented) "lattice rule".

Nice! I must admit, I implemented a "sequence" crate https://crates.io/crates/seq, but never thought about it as a generalization of "tuples".
As this proposed  idea of "tuple" is very close to the head/tail concept known form functional languages,  would the proposed tuple-concept in rust also permit to extend an N-tuple, prepending another element to it and forming an (N+1)-tuple, formed by head and a tail, where the tail would reference the N-tuple?

Back in the days, prior to C++11, Boost.Tuple was developed using a similar ConsList strategy.
It unlocked a number of usecases, however it also had a number of drawbacks:

Template instantiation recursion limit would pop up relatively frequently, as all algorithms had to be expressed as recursions with accumulator.
Said template instantiation recursion limit was a hint that compile-time were suffering, and they did.
Said recursive algorithms with accumulator were not really straightforward to write, debug or read.

The addition of variadic templates to C++11 was a very welcome change. It did not clean up all the cruft, but it did sped up compilation and lift quite a few limitations.

This modest proposal is interesting, from a hacker/minimalist POV, however I cannot help but think back to my C++ experience and wonder:

Is this proposal not going to suffer from the same drawbacks that Boost.Tuple did?
Is this proposal going to be sufficient, or will it have to be replaced by a better handling of variadic generics?
If this proposal will have to be replaced anyway, is the intermediate step necessary or should we just go with the next step immediately?

One could layer an inductive destructuring mechanism over such a base, but then with the inductive destructuring mechanism, the whole part of the inductive concrete tuple definition made redundant, and can be replaced by methods that inductively destructure to references, mutable references, or moved values.

I don't have any experience with C++11's variadic templates, but @matthieu-m's comment reminded me of D's variadic templates and static foreach.
So what do people think of this quick mock up?
impl<T @ (..: Debug, _: ?Sized + Debug,)> Debug for T {
    fn fmt(&self, f: &mut Formatter) -> Result<(), Error> {
        let mut builder = f.debug_tuple("");
        static for v in self {
            builder.field(v);
        }
        builder.finish()
    }
}

It is possible to bridge the gap between the recursive and iterative approaches without new syntax. For example:
pub trait VariadicConsumer<T> {
    fn take(&mut self, arg: T);
}

pub trait VariadicProducer<C> {
    fn pass(self, to: C);
}

impl<T: Debug> VariadicConsumer<&T> for DebugTuple {
    fn take(&mut self, arg: &T) {
        self.field(arg);
    }
}

impl<T> Debug for T
    where &T: VariadicProducer<DebugTuple>
{
    fn fmt(&self, f: &mut Formatter) -> Result<(), Error> {
        let mut builder = f.debug_tuple("");
        self.pass(builder);
        builder.finish()
    }
}

The compiler could then have optimized type checking and inlining of VariadicProducer implementations, roughly equivalent to:
impl<C> VariadicProducer<C> for () {
    fn pass(self, to: C) { }
}

impl<C, T: Tuple> VariadicProducer<C> for T
    where C: VariadicConsumer<T::Head>, T::Tail: VariadicProducer<C>
{
    fn pass(self, to: C) {
        to.take(self.head());
        self.tail().pass(to);
    }
}

impl<C, T: Tuple> VariadicProducer<C> for &T
    where T::AsRef: VariadicProducer<C>
{
    fn pass(self, to: C) {
        self.as_ref().pass(to)
    }
}

impl<C, T: Tuple> VariadicProducer<C> for &mut T
    where T::AsMut: VariadicProducer<C>
{
    fn pass(self, to: C) {
        self.as_mut().pass(to)
    }
}

This Variadic(Producer|Consumer) API isn't enough on its own to cover more complex cases where different elements of the tuple have different trait bounds. It could serve the common case well, without suffering from the issues of Boost.Tuple. However, I don't think it would add value if the compiler could apply similar optimized type checking and inlining to any usage of the recursive API.

Just as a data point, scala 3 (dotty) has generalised tuples. They have a thin layer of compiler magic so that they behave as if they were an hlist. The nil element is the empty tuple. Then all other tuples can be interacted with as hcons cells. This is a source-level fiction, so it's up to the dotty compiler to map this down to jvm objects with multiple fields instead of the inefficient singly-linked list representation.
Since rust owns the concrete representation, I don't see why something similar couldn't be done. Also, because rust owns the sharing, it should be possible to optimise adding and removing elements from both ends of a tuple so that it grows/shrinks in place for the cases where the grow/shrink ops take ownership of the prior tuple.

Since rust owns the concrete representation, I don't see why something similar couldn't be done

It's not that rust can't, it's that we probably don't want it to.  A cons-able tuple layout is at odds with optimizing for space and alignment.

To add to @ExpHP, tuples and structs are represented in the exact same way in the compiler. So changing the representation of tuples, would also change the representation of structs. Thus every Rust program would be affected, not just those that have Vec<(u8, u16, u8)>.
disclaimer I read this from the first RFC for variadic tuples. The internals of the compiler may have changed to separate the representation, but I don't think they have.

Hello! We received this RFC in today's "backlog bonanza" meeting. We felt that while the idea of handling tuples of arbitrary arity is very appealing, this was overall not a good fit for our current priorities and in particular not for the current roadmap, which is really oriented at finishing off the features we have in flight and not in adding new ones. This feature seems sufficiently complex that it would be a major undertaking and we don't have the bandwidth for that. If/when we do consider it in the future, though, we felt it would make sense to discuss in conjunction with variadic generics, for the two features seem to be quite similar.
@rfcbot fcp close


modify_password does not work with OpenLDAP when a new password is set

Hi!
While trying to use bonsai to change a password on a OpenLDAP server I encountered a weird failure.
From a python point of view I get the following backtrace:
(venv) $ python update_password.py
Traceback (most recent call last):
  File "/home/lab/update_password.py", line 18, in <module>
    res = conn.modify_password(
  File "/home/lab/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 394, in modify_password
    return super().modify_password(user, new_password, old_password, timeout)
  File "/home/lab/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 64, in modify_password
    return self._evaluate(
  File "/home/lab/venv/lib/python3.9/site-packages/bonsai/ldapconnection.py", line 246, in _evaluate
    return self.get_result(msg_id, timeout)
bonsai.errors.LDAPError: password hash failed. (0x0050 [80])

This test program close to no interrest here as many tests were performed to pinpoint the origin of this issue.
On the server side, nothing seems unusual except for these few lines in the (verbose) log:
Nov  1 22:21:44 ldap slapd[8174]: send_ldap_extended: err=80 oid= len=0
Nov  1 22:21:44 ldap slapd[8174]: send_ldap_response: msgid=2 tag=120 err=80
Nov  1 22:21:44 ldap slapd[8174]: conn=1015 op=1 RESULT oid= err=80 text=password hash failed

The server runs on Ubuntu 18.04.6 LTS with OpenLDAP 2.4.45+dfsg-1ubuntu1.10.
It uses and requires SSL, and the password strategy is so that it is stored hashed using sha512crypt.
I can already update passwords when using pam from another connected server on the network.
I can also successfully get a new password when new_password is not provided to modify_password,
in which case the new password is gathered from the server response.
After more digging it seems to come from the following line:
https://github.com/noirello/bonsai/blob/034ec671b60e41f1181a64ea4a7fe3d1dff7967a/src/_bonsai/ldapconnection.c#L744
    ber_printf(ber, "n}");

When replaced by the following, everything now works as expected:
    ber_printf(ber, "}");

There were already some discussions on samba's bugtracker about this:
https://bugzilla.samba.org/show_bug.cgi?id=5886
This attachment caught my interest (fix for smbpasswd to work with OpenLDAP 2.4):
https://bugzilla.samba.org/attachment.cgi?id=5461
Their current implementation even removed the N:
https://github.com/samba-team/samba/blob/master/source3/passdb/pdb_ldap.c#L1762
Here is the same line for pam_ldap:
https://github.com/PADL/pam_ldap/blob/master/pam_ldap.c#L3267
And here is the line in OpenLDAP implementation:
https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/ldappasswd.c#L299
It seems like N does not work on windows as stated in commit 32f66de96c.
With OpenLDAP headers, this seems to be a debug modifier (ignored in production):
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/encode.c#L553
Should this fix be working on windows, I suggest to use the fix mentioned earlier!
I will open a merge request attached to this issue.
Thanks!
Romain

Thank you for reporting this and for the PR as well.
One thing I don't understand that why has this test never failed for me?

Mmmh, I would say my configuration differs from the test one on these points:

I have defined a custom hash algorithm olcPasswordCryptSaltFormat: $6$rounds=10000$%.16s
I have the Samba overlay for OpenLDAP which adds LM and NT passwords
I enabled the module smbk5pwd (from packages) so that Samba passwords are kept in sync
I use LDAPS (but that should'nt be an issue at this point)

Maybe somehow the extra null byte ends up in a string that needs to be hashed by this module?
At this point I don't really know how things are being called on the server side.

Thanks for the config details and for the PR as well. It merged to dev.


Request to Develop Attacker Information Collection Feature for DeauthDetector

Hope to develop more sophisticated detection and attacker information collection capabilities for DeauthDetector, If the hardware system of esp8266 itself is not able to do it, then close this issue, thanks!

I am very glad to try to developer attacker information collection feature
for deauthdetector but I don't have esp8266 development board on which I
can work.
I request you to please provide me those chip set to developer it.
On Mon, 22 Feb, 2021, 6:04 am Droid-MAX<EMAIL_ADDRESS>wrote:

Closed #8 https://github.com/spacehuhn/DeauthDetector/issues/8.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/spacehuhn/DeauthDetector/issues/8#event-4357009356,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASBNCLNZGQW6GAY5NHFCYNDTAGRCHANCNFSM4FHRPK7A
.


Cannot deploy to cloudflare pages

Environment

Operating System: Darwin
Node Version:     v20.14.0
Nuxt Version:     3.12.1
CLI Version:      3.12.0
Nitro Version:    2.9.6
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      css, extends, modules, site, sitemap, ogImage, linkChecker, seoExperiments, seo, cookieControl, sanctum, bugsnag, eslint, image, runtimeConfig, imports, ui, devtools, experimental, colorMode, tailwindcss
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction
https://stackblitz.com/edit/github-yebevt?file=nuxt.config.ts
Describe the bug
Hello, I am deploying an application to Cloudflare Pages, but I am receiving this message. I am using Nuxt Hub, by the way, congratulations on that! Also i've tried directly on cloudflare pages and is the same.
Iv'e noticed this message at end.
18:22:58.106 | ✨ Success! Uploaded 3 files (472 already uploaded) (1.42 sec)
-- | --
18:22:58.106 |
18:22:58.597 | ✨ Upload complete!
18:23:01.311 | Success: Assets published!
18:23:02.431 | Error: Failed to publish your Function. Got error: Uncaught TypeError: Cannot read properties of undefined (reading 'toString')   at chunks/runtime.mjs:1:193088   at chunks/runtime.mjs:1:216534

I've uploaded logs, because are bigs to paste here
cloudflare_pages.log
Additional context
No response
Logs
No response

Would you be able to make your reproduction more minimal, please? 🙏
There are a lot of modules in that nuxt.config file.

I am deploying latest Nuxt and Nitro successful to Cloudflare Pages. Just for some reason Nitro doesnt automatically select preset cloudflare_pages anymore.

@danielroe For sure, i was testing modules one by one and is a problem with nuxt-bugsnag module. I've opened an issue in bugsnag repository.


New version: vim.vim.nightly version 9.0.1897

Pull request has been created with WinGet Releaser v2 :rocket:

@wingetbot run


[WIP] Travis permissions pt 5

@andrewadare changing permissions on /dev/tty* allows tests to run when operating in debug mode, but still no dice here. As such, I'm out of ideas!
Of course, even when the tests did run on CI, they didn't do much. So further to our conversations regarding the utility of CI tests for this package, this PR simply calls list_ports() then exits when running on CI. Local tests are not affected. This will at least allow us to ensure the library is installing and can be successfully called.
Whilst doing this I accidentally pushed a commit to master. If you want to proceed with this PR I'll resolve the conflict, else I'll undo those changes. I'll put protection on the master branch to avoid trouble in the future!
Let me know what you think.

Thanks @samuelpowell for working on this. Given the challenge of testing a library like this in a CI context, I think this is the best we can do. I support merging this PR. No problem that you pushed to master; should be simple to resolve. Feel free to merge it once you're satisfied.
I think once we have this, we can undertake to finally register this package.

Thanks @andrewadare . The rather embarrassing typo in the travis file explains differences in debug mode! But in any case, exploring what the correct permissions enable is a task for another day.


[FR] Add check for precompiled code

Given the recent drama I was wondering if it was sensible to add a check for precompiled code in crates. This would be a nice feature, especially for distro maintainers of rust crates as we can't allow such code in the repos (for obvious reasons).
CC @sdroege @decathorpe

This was added in 0.14.2 https://embarkstudios.github.io/cargo-deny/checks/bans/cfg.html#the-executables-field-optional, but only for crates that can execute code at compile time (proc macros or build scripts).

awesome, thanks.


Pressing Insert key in source editor changes display in REPL

If I press Insert in an editor pane (to toggle insert/overwrite mode), the REPL window changes:

A grey bar appears on the side
The line-change indicator appears whenever I submit code

Before pressing Insert:

After pressing Insert:

Same as C#. REPL window is an editor and editor modes are global, ie. going Insert -> Override changes all editor windows. There is little we can do about this, at least now.

That's lol-worthy. I guess you can close this, it's not really RTVS-related.


run it on a 16-line LiDAR

Have you tried running on a 16 line laser and what was the effect? I tried it with a 16-line LiDAR, but the effect was not good. The extracted plane\line\cluster also have a poor effect.Is it because the point cloud is too sparse？

Thank you for your feedback. Are you testing G3Reg on Nuscenes? or some other datasets. I have thought about it, but I didn't try it. Would you mind uploading some pairs (better with GT in our format)? I can finetune the parameters for you.

I can provide the rosbag files and some data in .pcd format. How would you prefer to receive them? Is BaiduNetdisk convenient for you? The total data amounts to approximately 40GB.
This is an indoor data package. I think there are obvious large planar features at the start of indoor that can be used for global localization. And, as it moves to the middle of the workshop, it enters a degraded environment.
here is the link of BaiduNetdisk:
link：https://pan.baidu.com/s/1EsWC4S3I5nMU4wVs1SrxUA?pwd=sger
code：sger

Can I ask which version of PCL you are using? I use the PCL-1.12. And I modified many instances of boost::shared_ptr to std::shared_ptr in the source code to get it to compile successfully.
I saw a lot of formal parameters of type "boost::shared_ptr" in the source code, but the actual parameters were of type "std::shared_ptr". I couldn't compile it successfully, so I modified them. Did I do the right thing?? or is your compilation environment able to automatically convert between boost::shared_ptr and std::shared_ptr?

I can provide the rosbag files and some data in .pcd format. How would you prefer to receive them? Is BaiduNetdisk convenient for you? The total data amounts to approximately 40GB. This is an indoor data package. I think there are obvious large planar features at the start of indoor that can be used for global localization. And, as it moves to the middle of the workshop, it enters a degraded environment. here is the link of BaiduNetdisk: link：https://pan.baidu.com/s/1EsWC4S3I5nMU4wVs1SrxUA?pwd=sger code：sger

It's very slow of BaiduDisk. Could you please send it by the email attachment? I perfer pcd files. Giving me several pcd pairs is okay. I don't need too much. Thank you.

Can I ask which version of PCL you are using? I use the PCL-1.12. And I modified many instances of boost::shared_ptr to std::shared_ptr in the source code to get it to compile successfully. I saw a lot of formal parameters of type "boost::shared_ptr" in the source code, but the actual parameters were of type "std::shared_ptr". I couldn't compile it successfully, so I modified them. Did I do the right thing?? or is your compilation environment able to automatically convert between boost::shared_ptr and std::shared_ptr?

Did you install libboost-dev on your ubuntu system?

I have added a new file that can display the effects of point cloud segmentation. You can refer to the command
 ./bin/demo_seg configs/apollo_lc_bm/gem_pagor.yaml examples/data/velodyne/source.pcd

to run it.
If you want to try with your own point cloud, you first need to replace the path to the point cloud, and also change the "sensor_dir" in the yaml file to "configs/sensors/velodyne16".
Below is a visual comparison of the segmentation of your point cloud by Velodyne64 and Velodyne16.

However, I have not finely tuned the parameters for Velodyne16, so there is still room for improvement. The main parameters that need adjustment are the plane segmentation and TRAVEL clustering.


Density matrix simulator should be optimized for terminal measurements

similar to other simulators.

Instead of running the density simulation once per repetition, run it once and then sample from the final density matrix multiple times. Works almost exactly the same as in the sparse wavefunction simulator; there is existing code to sample from the density matrix.

I'm happy to look into this, it seems doable in 2 weeks.


Register New Package

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/79405
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" cc15c86ca9b59d7d1f36300be29bfdb9a155d806
git push origin v0.1.0


Add costmanagement (2) resources to v1beta1 version

Description of your changes
Add 2 resources to v1beta1 version

[x] azurerm_resource_group_cost_management_export
[x] azurerm_subscription_cost_management_export

Fixes #132
I have:

[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested
Manually
azurerm_subscription_cost_management_export
This resource requires manual intervention, as subscriptionId is need to be specified and subscription Export created.

Manually and Uptest
azurerm_resource_group_cost_management_export

/test-examples="examples/costmanagement/resourcegroupcostmanagementexport.yaml"


Updated the new flutter app template to use the default Material themes

Description
This updates the default flutter app that is created with flutter create to provide both light and dark themes using the current Material baseline colors schemes for both.
Hopefully this will lead to more apps supporting dark mode out of the box, as well as moving apps toward the latest Material design.

The main difference here is that we are using the new ThemeData.from(colorsScheme) method that allows us to define a theme from just a ColorScheme:
    return MaterialApp(
      title: 'Flutter Demo',
      // This is the theme of your application.
      //
      // Try running your application with "flutter run". You'll see the
      // application has a purple toolbar. Then, without quitting the app,
      // try changing the primary color of the theme to green by modifying
      // the line below to:
      //
      // theme: ThemeData.from(colorScheme: ColorScheme.light(primary: Colors.green)),
      //
      // and then invoke "hot reload" (press "r" in the console where you ran
      // "flutter run", or simply save your changes to "hot reload" in a Flutter
      // IDE). Notice that the counter didn't reset back to zero; the application
      // is not restarted.
      theme: ThemeData.from(colorScheme: ColorScheme.light()),

      // This is the theme that will be used for you application if the
      // system's 'Dark mode' preference is set.
      darkTheme: ThemeData.from(colorScheme: ColorScheme.dark()),
      home: MyHomePage(title: 'Flutter Demo Home Page'),
    );

Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[x] No, this is not a breaking change.

@darrenaustin @Hixie What is the status of this PR?

Hi @darrenaustin, this PR has been idle for some time, so I'm going to close it, but feel free to open it again if you'd like to continue with it. Thanks!


at_template - allow additional files to be gitignored

Is your feature request related to a problem? Please describe.
The current gitignore from at_template/base does not allow you to specify additional files to be gitignored.
Describe the solution you'd like
Pass a var of type list to the internal mason bundle for base, and add the same var to the wrapper models.
Describe alternatives you've considered
N/A
Additional context

Merging this issue in #77


added keyboard key binding to buttons functionality

Fixes #
added the functionality requested in issue #200 kindly try the code and give my feedback
Describe the changes you have made in this pr -
added 2 properties to button module
added a keyup and a keydown events
added an input to field to the properties list in the UX.js file and attached an event to this input field
Screenshots of the changes (If any) -

the error with the check of circleci is because postgres is added twice in the gem file and because i didnt use bundler 2.0.

I think you missed some files. I cannot see modules.js

@satu0king  the only two changes i made to modules.js are in lines 2417 & 2418 if you look closely you'll see them in the changes i made

Don't worry about codeclimate issues in javascript. Resolve the conflicts

Please resolve the conflicts, it might be better to send a new PR instead, to make things easier.


hand pose area to be extended to account for held items

after some talk and test with @Malcolmnixon
we came to the following conclusion for what would be needed to be expanded to allow for handpose areas only affecting
the trigger or grip blend of the animationtree

Open pose
Closed pose
Override trigger [true/false]
Override trigger value [0 .. 1]
Override grip [true/false]
Override grip value [0 .. 1]

now this would allow for lets say
performing actions inside handpose areas while holding a pickable item,
example:
holding a can, movin into pose area -> index finger spreads out (trigger blend), rest of the fingers (grip blend) stays in pose as specified by the currently picked up pickable

I think @Malcolmnixon added that to his PR around multiple grip positions, so check if that now works as advertised.

from what i know as we talked before he started refctoring is that he added the possibility to do this in the future but right now it does not work as only the normal hands that are driven by hands.gd are changing their pose to the specified entry pose.
What needs to be extended is this to work with the physics hands to perform the above
so this should be rebranded to the 3.2.0 milestone

The thought here was to allow more options for enhancing the hand animations and posing.
Allowing an option to control which fingers are driven by the grip / trigger inputs allows for enhanced gestures - consider wanting the trigger to drive the peace-sign.
Secondarily this may allow the creation of more poses without having a combinatorial explosion of animations. An analogy would be the way texture compressors (s3tc, astc, etc) work by picking just two colors and then blending them, we could have two base-poses and then have more choices of blending.
Perhaps the second case is substituting for the fact that creating animations is complex for the average user, and that may be solvable by using or creating a simple posing design tool.

In Godot 4 you should now be able to edit poses and alter them, creating your own custom pose specific for an item.
Would this suffice for this issue combined with the work done on open/close hands on grab points?


[Remote File] The live preview does not open for the unsaved file.

Description
The live preview does not open for the unsaved file.
Steps to Reproduce

Launch brackets 1.13.
Press ctrl+shift+O for win and cmd+shift+O for mac.
Quick open modal bar will open.
Enter a network url that supports http or https. Example: https://www.google.com
The code for the page is displayed in brackets and file is visible in working files in file tree.
Click on live preview button.

Expected behavior: The live preview should open for the unsaved file as well.
Actual behavior: The live preview does not open for the unsaved file.
Versions
Win 10 64 Bit
Mac 10.12
Release 1.13 build 1.13.0-17668

@ayushrathi15 This behaviour is expected. Since, the remote file is not present in the project, live preview won't be displayed for it.
https://github.com/adobe/brackets/wiki/Troubleshooting#files-should-be-in-current-project has reference of this behaviour.
If you save the code as an html file in the project folder, then the live preview will be displayed.

This is As Designed.
Hence closing the issue.


Can we add some options to ClientQueryOptions?

Hi all,
I'm Jinho Bang and Blink contributor. (I'm interested in service worker.)
Can we add some options to ClientQueryOptions?
For example, if there is a FrameType option in ClientQueryOptions, we can simplify the following code.
Before:
// Imagine that we have to do something to client if frameType == 'nested'.
clients.matchAll().then(function(client_list) {
  client_list.forEach(function(client) {
    if (client.frameType == 'nested')
      // do something
  });
});

After:
// If we have FrameType option,
clients.matchAll({ frameType : 'nested' }).then(function(client_list) {
  // do something
});

We will add other options such as id, url and other things.
Also, we can add clients.match() method as well. (I think)
clients.match({ frameType : 'nested' }).then(function(client) {
  // do something to first nested client.
});

I think it's simpler and more convenient.
What do you think?
/cc @jungkees, @jakearchibald, @nhiroki

IMO we should not be pursuing such sugary conveniences at this stage, and leaving them to service worker libraries such as sw-toolbox.

Agreed, we should look to add things like this based on real world usage.

Agreed. Thanks for the suggestion though @romandev.
Closing.


terraformer --resource  error

I am having any issue when running the terrarformer command.    I have search the web hoping to find a solution, but nothing has surfaced.
terraformer import aws --resources=vpc,subnet --regions=us-west-2 --profile=prod
error produced
2020/01/09 19:10:55 unknown flag: --resources
I am running:
go version go1.13.5 linux/amd64
Terraform v0.12.18

provider.aws v2.25.0

I have also tried:
Terraform v0.12.18

provider.aws v2.43.0

The install went as expected I did not see any errors.  I think that I must have something wrong in the configuration?   Can anyone provide any guidance/help?

Its been solved.   I had an issues when building from the source.  I rebuilt and the problem corrected it self.    As such, I am not sure what exactly happened.    Thank you to anyone who might been thinking about my problem.

That’s strange. I’ve been building the project many times and never got this kind of random error.

I created a new ec2 instance to determine what went wrong with my original build.   In doing so, I discovered the rebuild did not fix the problem.  I was pointing to the release version I download earlier.   I now think the problem might simply be my "GO" skills and environment setup.
To build the Terrafomer executable - I follow the directions as specified:
Git clone
GO111MODULE=on go mod vendor
go build -v
created the init.tf -- added AWS provider
ran terraform init
I did not see any errors during the build.
Command an error.
$ ./terraformer import aws --resources=vpc,subnet --regions=us-west-2
2020/01/13 22:09:10 unknown flag: --resources
I also noticed a big difference in the executable size of the built version compared to the relaese version.
Release version is around 86M
Built version is around 31M
I am running:
go version go1.13.5 linux/amd64
Terraform v0.12.18
provider.aws v2.25.0
Any idea what I done wrong?
thanks

For anyone that might reach this issue, this happened to me when I used WSL2. In my case, with WSL1 it runs as expected.


Updated the Sparrow electrs instructions to avoid Sparrow's Tor bugs

What's the latest on this, will existing docs be good with the sparrow fix?

Correct, we should be good again when 1.6.7 comes out.


Illustrator Integration

Why all the focus on pulling info from photoshop, the current trend in web design is toward vector / svg / illustrator.  It would be nice to have tighter Illustrator integration with brackets.  I just downloaded it so forgive me if that's already possible but the website talks a lot about ps and not at all about Illustrator.

Extract is deprecated http://blog.brackets.io/2016/04/14/update-about-extract-for-brackets-preview/
Closing


Switch Windows platform test to use MAX_VERSION

This changes one of our RfN platform tests to check that 19 is working on Windows as expected.

@bot-gradle test PRF

OK, I've already triggered the following builds for you:

PullRequestFeedback build

Yes, I am working on them.

@bot-gradle test PRF

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle help

Currently, the following commands are supported:
@bot-gradle test <BuildTrigger1> <BuildTrigger2> ... <BuildTriggerN>

A trigger is a special build for this PR on TeamCity, common triggers are:

SanityCheck/CompileAll/QuickFeedbackLinux/QuickFeedback/PullRequestFeedback/ReadyForNightly/ReadyForRelease
Shortcuts: SC/CA/QFL/QF/PRF/RFN/RFR
Specific builds:

BD: BuildDistributions/BuildDocs so that you can preview the generated docs/distribution.
PT: PerformanceTest, all performance tests for Ready For Nightly stage.
APT: AllPerformanceTest, all performance tests, including slow performance tests.
AST: AllSmokeTestsPullRequestFeedback
AFT: AllFunctionalTestsPullRequestFeedback
ASB: AllSpecificBuildsPullRequestFeedback
ACC: AllConfigCacheTestsPullRequestFeedback
ACT: AllCrossVersionTestsReadyForNightly
AFTN: AllFunctionalTestsReadyForNightly
ACTR: AllCrossVersionTestsReadyForRelease
AFTR: AllFunctionalTestsReadyForRelease

@bot-gradle test and merge

queues this PR for testing and merges if all tests pass by:

Creating a merge commit from your PR branch HEAD and the target branch
Running a ReadyForNightly build against the merge commit
When it passes, fast-forward the target branch to this merge commit (i.e. merge the PR)

The merge commit is called a pre-tested commit, which means that it fully tests the integration
of your branch HEAD and latest master, instead of only testing your branch HEAD.
@bot-gradle cancel

cancel a running pre-tested commit build or remove it from queue

@bot-gradle clean

clear the conversation history

@bot-gradle help

display this message

To run a command, simply submit a comment.  For detailed instructions see here.

@bot-gradle cancel

@bot-gradle test PRF

OK, I've already triggered the following builds for you:

PullRequestFeedback build

Pre-tested commit build failed.

@bot-gradle test ReadyForNightly

OK, I've already triggered the following builds for you:

ReadyForNightly build

@bot-gradle test ReadyForNightly

OK, I've already triggered the following builds for you:

ReadyForNightly build

@bot-gradle test PRF

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test and merge

OK, I've already triggered a build for you.


Where can I find "Energy expended" from Google Fit app? "Calories Burnt Daily" seems to be off.

Calories burned - Documentation
Google Fit app:
Energy expended on August 31: 2102 Cal
Home Assistant:
Last Energy Burnt Daily on August 31: 1707.79 kcal

Hi @Defozo, there is a slight delay between data showing on your Google Fit app and that data then being available to developers in the cloud to access via their API (which is what this integration uses).
In my experience this can be 30-60 minutes but I've also noticed (at least on my device) that data is not uploaded when on mobile data, only WiFi.
Could you check this again, noting down timings, and seeing if this could apply in your case?

Closing this down now, please re-open with the timings requested above if you still have a problem


usgs logo viz function

function to add a semi-transparent usgs logo to the plot in a position dictated by the arguments to this function. this function will be called by #13.

GIFs don't support semi transparency for pixels (it is all or none).

Rats. Well, light grey, then.

Yes, we can, but if instead we are really explicit about colors (including limiting us to a 256 color palette), we'll make it easier to see what the true color (i.e., GIF export) will look like

looks like @jread-usgs has this under control in https://github.com/USGS-VIZLAB/vizstorm-GIF/pull/47.


Rarity being incorrect

I've noticed some rarity can be incorrect. I'm guessing this has to do with the API you're using so you can forward it to them if need be.

Not sure how we can fix this 'easily'. Since the plugin gathers data from OSRSBox API

Seems it's fixed already, the API calls for all Lizardman Shaman ID's return a rarity of 0,0002 (1/5000). Closing for now :)


Expose get_s3fs_session as a top-level function

Per https://github.com/nsidc/earthaccess/discussions/482, there is a desire to be able to directly invoke get_s3fs_session from the top of earthaccess, like so:
earthaccess.get_s3fs_session(endpoint="https://nisar.asf.earthdatacloud.nasa.gov/s3credentials")

Currently, it is possible to do the following, but accessing __store__ is perhaps not desirable:
earthaccess.__store__.get_s3fs_session(endpoint="https://nisar.asf.earthdatacloud.nasa.gov/s3credentials")

yes, this is a good idea. In the same vein, I also find this method useful and think it would be good expose directly:
>>> earthaccess.__store__.auth.get_s3_credentials(endpoint='https://nisar.asf.earthdatacloud.nasa.gov/s3credentials')
{'accessKeyId': 'XXX',
 'secretAccessKey': 'XXX',
 'sessionToken': 'XXX',
 'expiration': '2024-06-12 20:48:21+00:00'}

and might be a nice addition to the TEA s3 credentials READMEs: https://nisar.asf.earthdatacloud.nasa.gov/s3credentialsREADME
Notably, this does not work:
>>> earthaccess.auth.get_s3_credentials(endpoint='https://nisar.asf.earthdatacloud.nasa.gov/s3credentials')
AttributeError: module 'earthaccess.auth' has no attribute 'get_s3_credentials'

For anyone interested in working on this issue, there is currently an earthaccess.get_s3_credentials() function exposed at the top level (api.py). My understanding is this issue aims specifically to include exposure of the endpoint kwarg there.

For anyone interested in working on this issue, there is currently an earthaccess.get_s3fs_session() function exposed at the top level (api.py). My understanding is this issue aims specifically to include exposure of the endpoint kwarg there.

Yes, sorry if my original description was confusing.

How's this read to y'all?


Mobile devices controller reports all of my simulators as type "watch"

I've traced it down to this part of code in the ios-controller:
const stringType = /\w+[a-z]/g.test(level) && /\w+[a-z]/g.exec(level)[0];
let type = DeviceType.SIMULATOR;
if (stringType) {
  type = stringType === "tv" ? DeviceType.TV : DeviceType.WATCH;
}

Have noted same issue, is to do with how XCode10 writes out strings for ApiLevels
previously in XCode9 (iOS 11 etc) they are written as
watchOS 4.3
tvOS 11.4
iOS 11.4

in newer XCode10 (iOS 12 etc) they are written as
com.apple.CoreSimulator.SimRuntime.tvOS-12-2
com.apple.CoreSimulator.SimRuntime.watchOS-5-2
com.apple.CoreSimulator.SimRuntime.iOS-12-2

and the string matching is just picking out com and therefore not matching anything, defaulting to DeviceType.WATCH
Working on a PR, something like
const stringType = /(watchos|tvos|ios)/g.exec(level.toLowerCase())[0]
let type = enums_1.DeviceType.SIMULATOR;
if (stringType) {
    if (stringType[0] === "tvos") {
        type = enums_1.DeviceType.WATCH;
    } else if (stringType[0] === "watchos") {
        type = enums_1.DeviceType.TV;
    }
}


10116 hotfix bad margin

Fixes bug in #10116 (see comment https://github.com/CartoDB/cartodb/issues/10116#issuecomment-263278517)
Also fixes #10846
Icons now are on place even with long dataset names.

Menu option with proper copy 'Center map on layer'

Same copy applied to tooltip

CR @nobuti

much better :)


Init clevercloud deployment

Your checklist for this pull request
🚨Please review the guidelines for contributing to this repository.

[] Make sure you are requesting to pull a topic/feature/bugfix branch (right side). Don't request your master!
[] Make sure you are making a pull request against the dev (left side). Also you should start your branch off dev.
[] Check the commit's or even all commits' message styles matches our requested structure.
[] Check your code additions will fail neither code linting checks nor unit test.
[] Make sure that you've add licence text on every new file you are adding to repository.

Description
Please describe your pull request.
If possible provide visual elements to illustrate your feature and
Thank you for your contribution ! :tropical_drink:

Fix #256


how to process a video file

great project Vladimir!
Broswer Demo works great on our hardware.
Do you have a suggestion on how to process a video file via a command line?   We would like to sample a video file, checking scores for models each second and outputting to a csv file or something.
Again, nice work!

nodejs does not have built-in video capabilities (in browser, it's handled by browser itself and just exposed via html element), so you'd need a module that can process the video and on-demand output frames as images.
and such library would likely be a wrapper around a native binary player as decoding video in pure javascript inside nodejs would be too slow. most libraries around are just wrappers around ffmpeg as that is considered most flexible video engine.
for example, https://www.npmjs.com/package/fluent-ffmpeg

nodejs does not have built-in video capabilities (in browser, it's handled by browser itself and just exposed via html element), so you'd need a module that can process the video and on-demand output frames as images.
and such library would likely be a wrapper around a native binary player as decoding video in pure javascript inside nodejs would be too slow. most libraries around are just wrappers around ffmpeg as that is considered most flexible video engine.
for example, https://www.npmjs.com/package/fluent-ffmpeg

nodejs does not have built-in video capabilities (in browser, it's handled by browser itself and just exposed via html element), so you'd need a module that can process the video and on-demand output frames as images.
and such library would likely be a wrapper around a native binary player as decoding video in pure javascript inside nodejs would be too slow. most libraries around are just wrappers around ffmpeg as that is considered most flexible video engine.
for example, https://www.npmjs.com/package/fluent-ffmpeg

so your model just work with real-time stream? we ca not test the model with a previously recorded video?
is it also true from the Mediapie? can't we install mediapipe and test it with a video, not live stream.

nodejs does not have built-in video capabilities (in browser, it's handled by browser itself and just exposed via html element), so you'd need a module that can process the video and on-demand output frames as images.
and such library would likely be a wrapper around a native binary player as decoding video in pure javascript inside nodejs would be too slow. most libraries around are just wrappers around ffmpeg as that is considered most flexible video engine.
for example, https://www.npmjs.com/package/fluent-ffmpeg

so your model just work with real-time stream? we ca not test the model with a previously recorded video?
is it also true from the Mediapie? can't we install mediapipe and test it with a video, not live stream.

I did something similar in my own project. A simple answer: run it on electron

I did something similar in my own project. A simple answer: run it on electron

@lghasemzadeh i didn't say it only works with real-time stream, i said it works with any video format (stream or not) supported by underlying platform.
for browsers, they can decode live streams (but not in RTSP format) or video files (MP4, AVI, etc. - again, a lot of formats are supported out of the box, but it depends on codecs pre-installed on OS).
but nodejs does not have built-in video decoder of any kind, so user has to provide it's own.
it's the same with python, it does not have video decoding capabilities of its own, so users use a library such as OpenCV and pass frames to detection library.

@lghasemzadeh i didn't say it only works with real-time stream, i said it works with any video format (stream or not) supported by underlying platform.
for browsers, they can decode live streams (but not in RTSP format) or video files (MP4, AVI, etc. - again, a lot of formats are supported out of the box, but it depends on codecs pre-installed on OS).
but nodejs does not have built-in video decoder of any kind, so user has to provide it's own.
it's the same with python, it does not have video decoding capabilities of its own, so users use a library such as OpenCV and pass frames to detection library.

closing the issue as the original question is answered.

closing the issue as the original question is answered.


Improve document number already exists check performance

1. Why is this change necessary?
The current check if there is already a document with the given document number in DocumentGenerator is to slow for large datasets.
Because the current query has to parse the document number from the config column it isn't efficient enough and creating a new document starts to slow down significantly around ~500K documents.
2. What does this change do, exactly?
It adds a migration to generate the document_number column and an index on that column, it also adjusts the querying process to take advantage of the added column and index.
3. Describe each step to reproduce the issue or behaviour.

Generate many orders with documents.
Create a new document and measure the time taken.

My data:

Time-baseline: 700-800ms (No orders/documents)
Time-before-fix: 3-4s (With orders/documents)
Time-after-fix: 700-800ms (With orders/documents)
~5000 Orders
~100 Documents/Order (~500K Documents)

4. Please link to the relevant issues (if any).
5. Checklist

[x] I have rebased my changes to remove merge conflicts
[x] I have written tests and verified that they fail without my change
[x] I have created a changelog file with all necessary information about my changes
[x] I have written or adjusted the documentation according to my changes
[x] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

🤖 Generated by Copilot at 3f91bac
This pull request adds a new documentNumber field to the DocumentDefinition and DocumentEntity classes, and uses it to improve the performance of the document number already exists check. It also provides a migration to add the field to the database, and updates the changelog, the API fixtures and the tests accordingly.

🤖 Generated by Copilot at 3f91bac

Add a new document number field to the document entity and definition, which is exposed to the API and computed from the config field (link, link, link, link, link)
Optimize the document number already exists check by using the new field instead of the config field for filtering the criteria (link)
Create a migration that adds the document number column and index to the document table, with a generated expression from the config field, and checks for their existence before creating them (link)
Add a changelog entry for the performance improvement of the document number check (link)
Add a test class that covers the migration and asserts the creation and idempotence of the column and index (link)

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

Hey @Benedikt-Brunner,
thanks for your contribution! :tada: :blue_heart: In general, your approach is looking pretty good, but we actually internally already work on the exact same fix at the moment, so I'm closing this PR for now.
Here is the public ticket for reference: https://issues.shopware.com/issues/NEXT-29060

Please mean it :/ I really like this PR

Should be fixed here: https://github.com/shopware/shopware/commit/a48bb7a555bfb94b5f0aac029fa915b140fa38d0
cc @JoshuaBehrens & @Benedikt-Brunner


[Staging & Production] Can't delete GH files if viewing previous version

Reported by @caileyfitz on the 0.25 Trello board
Steps

Go to a project and connect to your GH account
Click on a file that has multiple versions
When viewing the file, click on a previous version (not the most recent)
Now, click the delete button
In the confirmation modal, press OK

Expected
I expect that this will delete all versions of the file
Actual
The file is not deleted and a growlbox message pops up saying that the file cannot be deleted

I think we need some clarity on expected functionality here: Should you be able to delete past versions of a file? If so, should it delete only the version you are deleting? or should it delete all versions prior to that version? or should it delete the entire file, all versions?

All other add-ons will delete a file, even if you are viewing a previous version. The Delete button isn't tied to a specific version like the individual download buttons are. Deleting a file should delete all versions.

Closed


Is there a way sharing a global var through vue and electron?

sorry for my poor english :)
Is there a way sharing a global var through vue and electron? I've tried electron-settings but i realized that it cant trigger vue to update the value on the page.

use ipc to send values and receive them in vue

@propotatomaster I have tried this but it seems that it cant trigger vue to regenerate the page when i edit the value in render progress.

uh that's weird


Improve unaligned buffer error messaging

When someone attempts to access an unaligned buffer, the error message that's printed is a bit terse and unhelpful. Some more explanation about required alignment would be helpful:
unaligned buffer, expected alignment 4 but found alignment 1
help: rkyv requires byte buffers to be aligned to access the data inside.
      Using an AlignedVec or manually aligning your data with #[align(...)]
      may resolve this issue.

Adding a section on alignment requirements to the book would also help alleviate this issue.

Fixed by 26b0669ea9dff3ced1db5bf5c3b2710f3a316990


consolidate compiler/REPL pipeline and tests

make tests use Pipeline so we don't have to jump through tons of hoops just to write a test on Avalanche/Flatten/Sea

groovy :+1:

Cool :banana:

gonna merge this, then write more specific tests for melt/constructor (e.g. no more pack/unpack)


HA unreachable!

Be careful with the latest update, HA become unreachable either with the URL of my reverse proxy or even directly via the IP address!!
Only solution: plug the RPi4 to a display and disable manually the addon (by doing: addons stop "slug name").
To get the "slug name", you need to type "ha addons list".

What is your network configuration? What URL is unreachable? What is your reverse proxy (Tailscale's builtin proxy, or another eg. NGINX proxy)?
There are 2 significant changes in this version, merged from the official add-on:

Removed: --tun=userspace-networking (from now on there is a real tailscale0 interface on the host)
Added: --accept-dns

What is your network configuration? >> A classic one I would say, nothing special.
What URL is unreachable? >> The public one through my FQDN and the local one with the IP 192.168.X.X:8123 (none of them could be pinged)
What is your reverse proxy? >> I host via Docker a NGINX (NGINX Proxy Manager).
As soon as I disabled the addon, my HA came back to life.

Hmmm, quite similar to mine (DuckDNS, NGINX, HA, Tailscale, eth0, NAT).
As I understand, your host lost it network access completely.
Strange. Now I'm just guessing. Seems that the presence of Tailscale's tailscale0 interface screwed your routing. Maybe something else has 100.x.x.x IP in your config. Maybe some routing is added manually. Maybe some Tailscale subnet routing is enabled/configured to another Tailscale client's 192.168.x.x subnet. It seems to me, that all 192.168.x.x traffic of your host was redirected to somewhere else, other than the real router, maybe sent to the add-on's tailscale0 interface, or anywhere. But I'm just guessing.
If you have access to the host (not the SSH add-on, but to the host OS), you can access the logs of the stopped add-on with journalctl CONTAINER_NAME=addon_09716aab_tailscale > /mnt/data/supervisor/share/tailscale.log And you can access the log as a text file at /share/tailscale.log Search for the word "route". Maybe there will be some strange thing going on. My guess is, when tailscaled started it broke your host's routing. But why? How?

I'm just thinking to make this non-userspace-networking mode optional, make the previous userspace-networking the default, and add a config option to turn it off (like taildrop, proxy, funnel, etc. all have this optionality). So anybody in the future have to manually disable userspace-networking to use tailscale0 as a real interface.
And make a PR to the official add-on...

Maybe some routing is added manually. Maybe some Tailscale subnet routing is enabled/configured to another Tailscale client's 192.168.x.x subnet.
The only thing I had, is that Tailscale through HA could act as an exit node (but it wasn't enable on the admin panel of Tailscale)

If you have access to the host (not the SSH add-on, but to the host OS), you can access the logs of the stopped add-on with journalctl CONTAINER_NAME=addon_09716aab_tailscale > /mnt/data/supervisor/share/tailscale.log And you can access the log as a text file at /share/tailscale.log Search for the word "route". Maybe there will be some strange thing going on. My guess is, when tailscaled started it broke your host's routing. But why? How?
I'll try to give you some logs, but as I uninstalled your fork to come back to the "official" addon, I don't know if the logs are still there. But I'll try anyway!

If exit node is not enabled, that shouldn't be a problem.
With journalctl from the OS command line you can access uninstalled add-on's logs.
Be aware with the next version of the official add-on, it will contain the exact same changes. I will make a PR soon, check whether sg. like "Make userspace networking configurable" PR is in the changelog of the next release of the official add-on, if not, do not update until it is.

New v<IP_ADDRESS> version is out, this is by default uses userspace networking again (like all previous versions before), so if you install/update to it from your console, it should not break your networking on the host. You need to add userspace_networking: false to get back the broken v<IP_ADDRESS> functionality. If you can test it, this would be a proof of the "danger" of non-userspace-networking.
If it still doesn't help, I run out of ideas. :( The only other thing that is changed in the broken v<IP_ADDRESS> is adding --accept-dns, but that should not break IP level networking, though you can disable even this with adding accept_dns: false to the configuration.

FYI The PR is https://github.com/hassio-addons/addon-tailscale/pull/199

A question about this because I also had a problem with routing in the past when I started experimenting with userspace.
The interface (type tun) is not managed via the network manager If a subnet router with the local IP addresses is set up, however, the system tries to send the local data via the tailscale interface, which theoretically works but not in connection with the network manager in HA OS.
Have you tested if the configuration works when the subnet router is deactivated via the Tailscale Admin interface?

Hmmm, so when a subnet routing is active with the local IP domain, we should not allow non-userspace-networking? Seems plausible.
Frenck also knows about this "losing network access altogether" problem, that is the reason it is not released in the official add-on, but I have no more information about his plans on the solution.

With /opt/tailscale status --self=false --peers=true --json | jq -rc '.Peer[] | select(has("PrimaryRoutes")) | .PrimaryRoutes[]' | sort -u we can list all the subnet routes in the Tailnet.
We can then force using userspace networking to avoid this routing problem when the allowed external subnets (above) has any overlap with the local advertised subnet routes.
But what happens when the add-on is already using tun (not userspace-networking), and on the Admin interface somebody allows the local IP domain to be routed somewhere else? I don't know the internals of the network manager, and whether Tailscaled will try to modify the host routing and break everything on the fly?

We could create a s6 service that periodically checks if local subnet routes are available in the tailnet and then restarts the service (with/without userspace) but that would also be more of a workaround.
The real question would be if there is the possibility upstream in HA-OS and/or HA-Supervisor to get the tunnel interfaces working within the HA environment.

I've read these https://github.com/tailscale/tailscale/issues/1227 https://github.com/tailscale/tailscale/issues/6231 https://github.com/tailscale/tailscale/issues/5999 https://github.com/tailscale/tailscale/issues/1344
Summary:

This is a 2 year old issue.
Tailscale uses table 52 for route settings and it has higher priority than the main route table.
Reason: if a coffe shop has the same IP as eg. your home network, you will still access your home network subnet from the coffee shop.

Solution:

HA devices won't go to coffee shops, so we should use the solution from https://github.com/tailscale/tailscale/issues/6231#issuecomment-1418124609
ie: ip rule add to <local subnets> priority 5000 table main

We can add/remove these rules when tailscale start/stop, from now on tailscale won't break local routing?
What do you think? It wouldn't take too much for me to implement it, the big question, who will test it and rist to brick it's config? :D

Might be worth a try, I don't have a test instance running right now, I might manage to set up a VM in proxmox this weekend.

I made it, it is out as v<IP_ADDRESS>. Changes: https://github.com/lmagyar/homeassistant-addon-tailscale/commit/0c67af07a1a11b67884c1286da957ce80571cfa3
You have to add userspace_networking: false to the config to activate it.
Itt will add local subnets with higher priority to ip rules than Tailscale, and will remove it on add-on stop.
I tested it setting "Start on boot" and "Watchdog" to false (in case I brick the device, a power cycle can make it available again), then enabled subnet routing on another device with the same <IP_ADDRESS>/24 network, and it survived it. I have restarted the add-on, and still survived it. So I think it works. :)

FYI: And I made a PR toward the official add-on also. https://github.com/hassio-addons/addon-tailscale/pull/201

Has anybody tested this subnet issue? (You have to add userspace_networking: false to the config to "activate" the issue and the workaround.)

Been using your addon for tunnels since you made it available and had no issues with connection. But yea around two weeks ago I started also getting connection issues. Tought it was my router. Since rebooting the router makes the HA instance reachable again.
Will try the flag and see how it goes

With userspace_networking: false

Thank you @MayorBug!
It seems route "manipulation" have some issue with IPv6, I will try to reproduce and fix it.

New version v<IP_ADDRESS> is out, with the bugfix for IPv6. (And with new Tailscale v1.42.0.)
[13:36:43] INFO: Adding route <IP_ADDRESS>/24 to ip rules
[13:36:43] INFO: Adding route fd19:8efe:2a99::/64 to ip rules

Been using with the userspace_networking: false flag now for 4days and it has been stable.

Closing this now, as userspace_networking: false is quite stable, tested (v<IP_ADDRESS>) with site-to-site networking, even with real colliding subnets by misconfiguration (yeah, even when you know what you really don't want to do), and it survived everything.


cli: support multi-line interactive mode

If i run the following sql line by line without ";", then the  history.txt will not contain ";". It is not convient for me to copy the scripts from history.txt to the cli and run them together, as i need to add the ";" at the end of all sql sentence.
> create table x (x int)
> insert into x values (1)
> insert into x values (2)
> insert into x values (33333)
> select * from x

The history file:
create table x (x int)
insert into x values (1)
insert into x values (2)
insert into x values (33333)
select * from x;

Normally, the shell should not execute a SQL until there is a ;. I think we'd better refactor the interactive shell?

Usually history file records user input as is, including incorrect input. So I'm not sure whether adding ; is proper...

Normally, the shell should not execute a SQL until there is a ;

I found https://github.com/dbcli/mycli supports both Multi-line mode and the eager mode allowing no ; (default). I think we should choose one style for now? One-line is simpler but multi-line is more traditional?

Normally, the shell should not execute a SQL until there is a ;. I think we'd better refactor the interactive shell?

Pgwire doesn’t require a semicolon, so pgcli will accept sql without semicolon, but psql requires it.

Then I would prefer keep it as-is in our current cli. A multi-line mode can be configured via cli parameter. 🥰

can anyone elaborate the a little bit? I want to have a try. My current understanding is as follows:
the interactive shell currently doesn't support multi-line sql without the ending semicolon, eg,
select 1
select 2
select 3

which gives the following error:
parse error: sql parser error: Expected end of statement, found: select
and we want to support this kind of input

I think we support it -- did you just past those three lines into the console? If you press enter without semicolon, the current shell would proceed to evaluate the statement.

But in Postgres shell:

If we want to correctly handle all cases... do we need to have a simple lexer on cli? Then it doesn't seem like a good first issue 🤣

But we can keep it simple for now -- we don't need to handle the case like we have ; in string. We can simply detect if the last character of an input line is ;?

I think we support evaluate on enter -- did you just past those three lines into the console? If you press enter without semicolon, the current shell would proceed to evaluate the statement.

But in Postgres shell:

yes, one line without the semicolon is ok, I thought your want to run three line together with the  semicolon....

run three line together with the semicolon....

This should also be supported now! What we need is to run one statement that spans multiple lines 🤪

What prompt should we use for lines other than the first line？

Of course. We can execute sql only when we meet ;, as long as it's the last character.


Add static landscape modal

From filterable-landscape created by dankohn : cncf/filterable-landscape#148
Clicking the static landscape link in the header should launch a modal that covers almost the whole screen and displays https://raw.githubusercontent.com/cncf/landscape/master/landscape/CloudNativeLandscape_latest.png
Click the l key for landscape should bring up and dismiss this modal.

Instead implemented the landscape in browser.


Push notification with image on android received as regular notification without image.

Expected Behaviour
Notification shows up with a big picture
Actual Behaviour
Notification is shown as a regular notification
Reproduce Scenario (including but not limited to)
Send a push notification from the backend and receive it on the phone.
Steps to Reproduce
try to make a request to firebase cloud messaging with style -> picture and picture -> img file in data through php.
Platform and Version (eg. Android 5.0 or iOS 9.2.1)
Android 7.1.0
(Android) What device vendor (e.g. Samsung, HTC, Sony...)
Any
Cordova CLI version and cordova platform version
cordova --version                                    # e.g. 6.0.0
cordova platform version android                     # e.g. 4.1.1

cordova version 7.1.0
cordova-android version 6.3.0
Plugin version
cordova plugin version | grep phonegap-plugin-push   # e.g. 1.5.3

phonegap-plugin-push 2.1.2
Sample Push Data Payload
'to' => '/topics/sometopic',
'notification' => array(
    'title' => 'sometitle',
    'body' => 'sometext',
    'click_action' => "FCM_PLUGIN_ACTIVITY", ****
    'sound' => 'default',
    'icon' => 'ic_stat_message',
    'color' => '#c41e63'
),
'priority' => 'high',
'data' => array(
    "text" => 'sometext', ****
    "summaryText" => 'dummy',
    "headsUp"=> true, ****
    "picture" => 'http://someurl/someimg.jpg",  ***
    "color"=> "#c41e63",
    "largeIcon" => "ic_large_app", ****
    "style" => 'picture',
    "smallIcon" => "ic_stat_berichten",
    "title" => 'some title',
    "vibrate" => true,
    "sound" => true
)

*** Absolutely sure this is correct.
**** this comes from the previous fcm plugin that we used and for older builds to still work we need to keep this for backwards compatibility....
Sample Code that illustrates the problem
$check = $formModel->getElementData('berichten___stuur_notificatie');
if ($check[0] == '1') {
$messagetitle = $formModel->getElementData('berichten___Auteur');
$messagetitle = $messagetitle[0] . ' meldt:';
$body = $formModel->getElementData('berichten___Bericht');
$image = $formModel->getElementData('berichten___image');
$url = 'https://fcm.googleapis.com/fcm/send';
$fields = array(
'to' => '/topics/berichten',
'notification'=> array('title'=>$messagetitle,'body'=>$body,'click_action' => "FCM_PLUGIN_ACTIVITY",'sound'=>'default', 'icon' => 'ic_stat_berichten', 'color' => '#c41e63'),
'priority'=> "high",
'data' => array("text" => $body, "summaryText" => 'dummy', "headsUp"=> true, "picture" => 'https://someurl.com' . $image, "color"=> "#c41e63", "largeIcon" => "ic_large_app", "style" => 'picture', "smallIcon" => "ic_stat_berichten", "title" => $messagetitle, "vibrate" => true, "sound" => true)
);
define('GOOGLE_API_KEY', 'THIS_IS_MINE!!!');
$headers = array(
'Authorization:key=' . GOOGLE_API_KEY,
'Content-Type: application/json'
);

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($fields));
$result=curl_exec($ch);
curl_close($ch);
}

Logs taken while reproducing problem
none

If this is the case for android, does this also count for iOS? How does a request look like that sends to both iOS and android users simultaneously while keeping the big picture format on android?
I'm rather confused as to how my payloads should look like for cross platform compatibility (android and iOS)


great performance improvement with a small change :-)

ISPN-1456 Improve transactions performance by defining a non-system hashCode
https://issues.jboss.org/browse/ISPN-1456

thanks for this sanne!

How great is great, have you benched this? Even a microbench? :)
curious to see the effect.
Sent from my mobile phone
On 14 Oct 2011, at 19:54, Sanne Grinovero
<EMAIL_ADDRESS>wrote:

ISPN-1456 Improve transactions performance by defining a non-system hashCode
https://issues.jboss.org/browse/ISPN-1456
You can merge this Pull Request by running:
git pull https://github.com/Sanne/infinispan ISPN-1456
Or you can view, comment on it, or merge it online at:
https://github.com/infinispan/infinispan/pull/573
-- Commit Summary --

ISPN-1456 Improve transactions performance by defining a non-system hashCode

-- File Changes --
M core/src/main/java/org/infinispan/transaction/xa/TransactionXaAdapter.java (17)
-- Patch Links --
https://github.com/infinispan/infinispan/pull/573.patch
https://github.com/infinispan/infinispan/pull/573.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/infinispan/infinispan/pull/573

With an OGM microbenchmark it increased TX/second 5 times ! but it's a really synthetic one not very real-world representative

BTW this is the test: https://github.com/Sanne/hibernate-ogm/commit/ba04ce88854a06bb2074cba6a06a891999033ee8
so you can check ;-)
Another good thing, even though not as impressive is the ThreadLocals gone when migrating to 5.1 (we're still on 5.0), that added another 2% to the same test.


Take club name as a url param

Detect club name from a url param, and if included replace the club dropdown with a hidden field automatically filled out with the club name.

Sam brought this up in a call, so is probably relevant.

Or if you really want to get specific, you could target a specifc range of GeoIPs.

Closing this because club choice is remembered by packrat from meeting to meeting


Clarify BQ instructions in user_score.py

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[ ] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[ ] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[ ] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[ ] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

R @aaltay

LGTM. Thank you.

(Maybe also update this: https://github.com/apache/beam/blob/master/examples/java8/src/main/java/org/apache/beam/examples/complete/game/UserScore.java#L68)


[Feature] Specify meta along with file name

When we are naming the request, we specify file name. However, in the saved bru file there is a meta.name which, when changed manually, reflects on the UI request name.
It would be more user friendly to allow setting it via GUI:
Something like this:

Bruno should offer automatically <Verb>-<Name> or equivalent to set as a file name as you type it (and file name should be editable by the user). So if you have two /list request, one GET one PUT, you will have get-list.bru and put-list.bru which are both named the same (list) as we already have verb visible in the GUI next to the name.

Closing this issue as this effort is being tracked here
There is also a PR that's mostly in a good shape - https://github.com/usebruno/bruno/pull/3094
Looking forward to have this feature in Bruno by end of Dec 2024


set multipart upload file limit to 50mb

to support bigger files for material upload

Pull Request Test Coverage Report for Build 2773

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 91.645%

Totals

Change from base Build 2772:
0.0%

Covered Lines:
1042

Relevant Lines:
1137

💛  - Coveralls


[Week 2 HW]

Name: Ghazwa
Email<EMAIL_ADDRESS>Linkedin Profile: https://www.linkedin.com/in/ghazwa-q
Attach the homework step I screenshots below:

Attach the homework step II screenshots below:

![Screenshot (48)](https://user-images.githubusercontent.com/53545055/127750790-d779d8df-9dc5-4013-802e-1349442c43f9.png)

Hey Ghazwa, great job! Congrats! Here is your badge! https://api.badgr.io/public/assertions/K1ElsZoQT6Wk46lYMt8mQQ


feat(docs): added points to FEMA table

The PR adds two points to the FEMA table.

Yep there's a duplicate. Will address when resolving the merge conflict


A Random RuntimeError : Tensor of 0 Elements

Hi, thans for your sharing!
I applied the Monodepth2 training framework you recommended to train on my own dataset. The training can process normally and reasonable depth maps can also be obtained. However, a weird tensor shape mismatch error happened at random -- It does not occur at a specific time such as the first iteration or the end of a epoch, it just appear at any time. It makes me hard to train for multiple epochs. Do you have any clues?
The error is as follows:
Traceback (most recent call last):
File "/mnt/Project/DeFeatNet_storz/train.py", line 18, in
trainer.train()
File "/mnt/Project/DeFeatNet_storz/trainer.py", line 202, in train
self.run_epoch()
File "/mnt/Project/DeFeatNet_storz/trainer.py", line 218, in run_epoch
losses = self.process_batch(inputs)
File "/mnt/Project/DeFeatNet_storz/trainer.py", line 275, in process_batch
losses = self.deFeatLoss(target_disps, target_features, support_features, poses,
File "/root/miniconda3/envs/myconda/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
return forward_call(*input, **kwargs)
File "/mnt/Project/DeFeatNet_storz/losses/defeat_loss.py", line 64, in forward
l_feat = [self.hca_loss(torch.cat((pred_feats, sf), dim=2), corr)
File "/mnt/Project/DeFeatNet_storz/losses/defeat_loss.py", line 64, in
l_feat = [self.hca_loss(torch.cat((pred_feats, sf), dim=2), corr)
File "/root/miniconda3/envs/myconda/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
return forward_call(*input, **kwargs)
File "/mnt/Project/DeFeatNet_storz/losses/hierarchical_context_aggregation.py", line 78, in forward
return sum(loss(feat, labels) for feat, loss in zip(feature_chunks, self._losses))
File "/mnt/Project/DeFeatNet_storz/losses/hierarchical_context_aggregation.py", line 78, in
return sum(loss(feat, labels) for feat, loss in zip(feature_chunks, self._losses))
File "/root/miniconda3/envs/myconda/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
return forward_call(*input, **kwargs)
File "/mnt/Project/DeFeatNet_storz/losses/pixelwise_contrastive.py", line 59, in forward
loss = self._positive_loss(source, target, source_kpts, target_kpts)[0]
File "/mnt/Project/DeFeatNet_storz/losses/pixelwise_contrastive.py", line 69, in _positive_loss
dist = self._calc_distance(source, target, source_kpts, target_kpts)
File "/mnt/Project/DeFeatNet_storz/losses/pixelwise_contrastive.py", line 64, in _calc_distance
source_descriptors = ops.extract_kpt_vectors(source, source_kpts).permute([0, 2, 1])
File "/mnt/Project/DeFeatNet_storz/utils/ops.py", line 75, in extract_kpt_vectors
return tensor[b_num, :, tmp_idx[:, 1], tmp_idx[:, 0]].reshape([batch_size, num_kpts, -1])
RuntimeError: cannot reshape tensor of 0 elements into shape [8, 0, -1] because the unspecified dimension size -1 can be any value and is ambiguous

Hi,
Thanks for the interest!
It seems like it is not finding any correspondences between the images? (since num_kpts is 0).
Looking at [get_correspondences](https://github.com/jspenmar/DeFeat-Net/blob/master/losses/defeat_loss.py#:~:text=def-,get_correspondences,-(pix_coords%2C) this might happen if all coordinates are out of bounds or if all pixels in the image are removed by automasking.
Maybe it is worth visualizing the depth map at the state where it fails, or adding a check to ignore the contrastive loss if no correspondences are found.
Kind regards,
Jaime


mfg_tool examples

If you change the examples to use the environment variable you will be able to copy and use them....
./mfg_tool.py -cn "My bulb" -v 0xFFF2 -p 0x8001 --pai     -k $ESP_MATTER_PATH/connectedhomeip/connectedhomeip/credentials/test/attestation/Chip-Test-PAI-FFF2-8001-Key.pem     -c $ESP_MATTER_PATH/connectedhomeip/connectedhomeip/credentials/test/attestation/Chip-Test-PAI-FFF2-8001-Cert.pem     -cd $ESP_MATTER_PATH/connectedhomeip/connectedhomeip/credentials/test/certification-declaration/Chip-Test-CD-FFF2-8001.der     --passcode 20202021 --discriminator 3840  --enable-rotating-device-id --rd-id-uid d2f351f57bb9387445a5f92a601d1c14

instead of
./mfg_tool.py -cn "My bulb" -v 0xFFF2 -p 0x8001 --pai \
    -k path/to/esp-matter/connectedhomeip/connectedhomeip/credentials/test/attestation/Chip-Test-PAI-FFF2-8001-Key.pem \
    -c path/to/esp-matter/connectedhomeip/connectedhomeip/credentials/test/attestation/Chip-Test-PAI-FFF2-8001-Cert.pem \
    -cd path/to/esp-matter/connectedhomeip/connectedhomeip/credentials/test/certification-declaration/Chip-Test-CD-FFF2-8001.der \
    --passcode 20202021 --discriminator 3840  --enable-rotating-device-id --rd-id-uid d2f351f57bb9387445a5f92a601d1c14

I just discovered mfg_tool and see now that I can use it to set things like Product and Vendor name. I think mfg_tool should be combined into the examples as part of the cmake process. First come up with a set of workable defaults and explicitly set those in the cmake file. Then as I need to make changes I can edit the cmake file to implement them.
For certificates it can initially use the sample ones. Or can you generate new ones?
Don't esp chip have hardware serial numbers? Option to use that?
            # If serial number is not passed, then generate one
            if (args.serial_num is None):
                chip_factory_update('serial-num', binascii.b2a_hex(os.urandom(SERIAL_NUMBER_LEN)).decode('utf-8'))
Don't save this tool until the end of the process, include it from the begining.

@jonsmirl did you figure out where and how to include the generated <uuid>-partition.bin?

@edWin-m The factory partition binary is to be flashed at the factory partition address in the partition table.
Closing this issue as the examples are added: https://docs.espressif.com/projects/esp-matter/en/latest/esp32/production.html#the-mfg-tool-example

@dhrishi Got it. Thanks for the update.


devspace: 6.2.4 -> 6.2.5

Description of changes
Update devspace to the latest version

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@ofborg build devspace

I have:

built devsocket
ensured that a basic subset of commands works (./devsocket version, sync, add plugin, etc)