RFC: Generic integers

:framed_picture: Rendered
:memo: Summary
Adds the builtin types uint<N> and int<N>, allowing integers with an arbitrary size in bits. For now, restricts N ≤ 128.
:sparkling_heart: Thanks
To everyone who helped on the internals thread to review this RFC, particularly @Centril, @rkruppe, @scottmcm, @comex, and @ibkevg.

I like the idea, and I would really love to have efficient and ergonomic strongly-typed bitfields. However, this proposal feels too magical for my taste; there is to much stuff built in to the compiler. I would rather expose a single simple primitive that allows implementing arbitrarily sized ints efficiently.
Just a half-baked idea: We only build a Bit type into the language, which is guaranteed to be 1 bit large (though it must be padded in a struct unless you use repr(packed)). All of the other integer types are defined as follows:
#[repr(packed)]
struct int<const Width: usize> {
  bits: [Bit; Width],
}

#[repr(packed)]
struct uint<const Width: usize> {
  bits: [Bit; Width],
}

with the appropriate operations implemented via efficient bit-twiddling methods or compiler intrinsics for performance.

(independently from the remark above)
This RFC spends quite some time explaining the memory layout of int<N>
and uint<N> types. Is user code allowed to rely on this memory layout,
or is it not?
Intuitively it'd be better if the layout was not actually defined, to
allow for further optimizations, but the current text makes me believe
it is defined. The one case where layout would be mandatory would be for
a not-yet-written #[repr(bitpacked)] RFC, in my opinion.
Oh, and

At the time of writing, no known programming language offers this
level of integer generalisation, and if this RFC were to be accepted,
Rust would be the first.

Programming languages with dependent types (F*, etc.) do offer this, and
actually much more. :)

Programming languages with dependent types (F*, etc.) do offer this, and actually much more. :)

Well, you can represent a Fin : Nat -> Type type constructor in dependent typing pretty easily, but those are quite inefficient...

Programming languages with dependent types (F*, etc.) do offer this, and actually much more. :)

Well, you can represent a Fin : Nat -> Type type constructor in dependent typing pretty easily, but those are quite inefficient...

Low* (a part of F* that deals with machine types) can represent those
and still compile to C, with for instance the type
x:int_32{x >= -128l /\ x < 128l}

This type will be compiled (to C) as an int32_t type, after F* will
have proven that the value can indeed not be out of the [-128, 128[
bounds.
More details can be found about machine integers in F* on
the F* wiki

I didn't see any discussion within the RFC about not using uN directly. It seems like that could make quite a bit of sense -- at least for an initial implementation.
It seems like it should at least be mentioned in the alternatives section...

We only build a Bit type into the language, which is guaranteed to be 1 bit large (though it must be padded in a struct unless you use repr(packed)).

@mark-i-m's suggestion strikes me as deeply complementary to @clarcharr's proposal. The leading motivation of this RFC is supporting bitfields, but using a number (albeit one guaranteed to be the right number of bits) to represent a bitfield is often a logical type-mismatch. To use the example from the RFC:
#[repr(bitfields)]
struct MipsInstruction {
    opcode: u6,
    rs: u5,
    rt: u5,
    rd: u5,
    shift: u5,
    function: u6,
}

How often does it really make sense to add or subtract from an opcode? By representing it as an unsigned six-bit integer, we signal that arithmetic on an opcode is a well-defined operation.
With @mark-i-m's suggestion, we can have a more well-typed version of this struct:
#[repr(packed)]
struct MipsInstruction {
    opcode: [Bit; 6],
    rs: u5,
    rt: u5,
    rd: u5,
    shift: u5,
    function: [Bit; 6],
}

It never makes sense to represent opcode or function as numbers, so we don't. Conversely, shift is very clearly numeric.
(Disclaimer: I'm not a MIPS expert; I'm just going off the wikibook. I can't tell whether r{s,t,d} ought to be [Bit; 5] or u5.)

As for the second half of @mark-i-m's suggestion: I can't tell whether it's merely an implementation detail or if it has semantic differences from @clarcharr's proposal. Regardless, it would be a good candidate for discussion in the Alternatives section.

Arrays aren't (and can't be changed to be) repr(bitpacked), so [Bit; N] would actually occupy N bytes. While one could instead provide a dedicated Bitvector<N> type, that would have a lot of overlap with uint<N> (which have many applications not covered by Bitvector<N>). I also don't really see the typing benefit @jswrenn suggests: if you care about that, you'd want to use more fine-grained newtypes to distinguish (in this MIPS instruction encoding example) the opcode from the function field or the shift amount from the register numbers. Once you have these newtypes, uint<5> vs Bitvector<5> becomes largely irrelevant as it's an implementation detail. (In fact, one could implement Bitvector<N> as a newtype around uint<N>.)

Finally getting around to a few comments:

Is user code allowed to rely on this memory layout, or is it not? Intuitively it'd be better if the layout was not actually defined, to allow for further optimizations, but the current text makes me believe it is defined. The one case where layout would be mandatory would be for a not-yet-written #[repr(bitpacked)] RFC, in my opinion.

I feel that defining memory layout is important because there doesn't seem to be a compelling argument otherwise. Rust very much avoids "undefined"ness whenever possible. People will want to know how these types operate in a #[repr(C)] struct or in an array; would [uint<48>; 2] take up six bytes or eight? Establishing this is crucial for stabilisation imho.

Programming languages with dependent types (F*, etc.) do offer this, and actually much more. :)

I'll take a look later and add these to the prior art section.

I didn't see any discussion within the RFC about not using uN directly. It seems like that could make quite a bit of sense -- at least for an initial implementation.
It seems like it should at least be mentioned in the alternatives section...

I'll add it to alternatives, although the main reason against this would be that it doesn't allow generic impls even though it is generic. Unless uN were just an alias for uint<N>, which seems unnecessary to me.

In terms of offering Bit instead of uint-- I'll definitely add this to the alternatives section. Essentially, offering some kind of bits<N> type would be similar to uint<N>, although completely orthogonal to uint<N> and presumably only allowing bit operations, not arithmetic. I still believe that uint<N> is better overall, but thoroughness is important.

Regarding Bit, I had intended it as a way to not add uint<N> and int<N> as language features. Rather, they could be implemented in a crate as wrappers around [Bit; N]. My motivation is just that adding uint<N> seems like a lot of magic, and I would like to reduce magic.

While Bit by itself is less magic than bits<N>, there's a lot of magic for making arrays compact for just one particular type. How does Bit apply in most type contexts? Is (Bit, Bit) compact? Etc.

My thinking was that Bit had a size of one bit and alignment of 1 bytes. So you need to use repr(packed) to get rid of padding, as with other types.
However, now that you mention it, IIUC, the size and alignment of types is tracked in bytes in the compiler. So some work would need to be put into making the compiler track bits, but i suspect similar work would need to be put into the current RFC proposal anyway to make bitfields work.
Also one other minor thing that I didn't see mentioned in the RFC: does size_of::<uint<N>>() just round up to the nearest byte? or the nearest byte when rounded up to a power of two?

@rkruppe Sorry, I just saw your comment

Arrays aren't (and can't be changed to be) repr(bitpacked), so [Bit; N] would actually occupy N bytes.

I was curious why. Does this break some other stability guarantee we have?

@mark-i-m the sizes of uint<N> are the same as the larger power of two size. So, uint<48> has the same size as u64.

Hmm... so using repr(packed) actually changes the size of the type?

@mark-i-m In this case, no. repr(packed) allows alignment to break, but in this case, uint<48> would have an alignment and size of 8. In this case, we'd need a different form of repr(packed) which allows both size and alignment to break, shoving things down to individual bits. That's mostly what repr(bitfields) is in the RFC; originally, I recommended bitpacked as a name but I changed it and I don't remember why.

Even though for all currently existing types that would remain so when arrays start become bitpacked, it would mean we'd have to add new bounds to those things, which would break generic code that doesn't have those bounds.

Couldn't we signal that individual Bits are unaddressable with an Addressable auto trait that isn't implemented for Bit? E.g.:
auto trait Addressable {}

// Individual bits are unaddressable.
impl !Addressable for Bit {}

@jswrenn There was a big discussion of doing this for DynSized with extern types, and the verdict was to not there. I feel like an Addressable bound would have similar problems.

@jswrenn Auto traits are not assumed to be implemented by default (e.g. fn foo<T>() does not imply T: Send). So beyond just an auto trait, you'd need a new opt-out default bound like Sized, and as @clarcharr mentioned those have been rejected for other purposes in the past.

Adds the builtin types uint<N> and int<N>

Those names are a bit unexpected. They look like primitives (since they are in lowercase), but IMO they are closer to a generic type.
Maybe, something like std::num::integer::Signed and std::num::integer::Unsigned could work.

It would be great to have something like this in Rust! I've created a crate using macros to simulate this in order to implement the uavcan protocol in Rust, but having native support would make everything way more smooth.

If I remember correctly, not many promises are made when using repr(Rust). And due to all interior mutable containers being !Sync it seems like the default representation can be changed between a sparse representation to a packed requiring "read-modify-write" to write without breaking anything or affect anything except time/mem performance. If I'm right in this it seems like the N.next_power_of_two() repr can be changed at a later point, and thus acceptable as a starting point even if further optimization is made later.
On the other hand, when repr(C) is used people rely on the representation. At the same time, I can't find any information on what happens if repr(C) is used alone (without repr(bitpacked) in the RFC. I guess there are (at least) three possible options: pack, align or refuse to compile allowing this to be decided later. What is the repr(C) behavior suggested by the RFC?
Is the repr(bitfield) supposed to be used for tweaking memory usage as well as for defining the layout (with rerp(C, bitfield)) for use with FFI? Unless the memory behavior aspect is important, wouldn't it be better to just wait to define the usage together with repr(C) until we know what behavior we want when using this with FFI instead of introducing a new repr?

If I remember correctly, not many promises are made when using repr(Rust). And due to all interior mutable containers being !Sync it seems like the default representation can be changed between a sparse representation to a packed requiring "read-modify-write" to write without breaking anything or affect anything except time/mem performance.

Even for non-Sync data, you can take &muts to disjoint elements/fields and send them to different threads ((&mut T): Send if T: Send), so if "writes" are actually read-modify-write operations that touch surrounding memory, you get races that way (see also https://github.com/nikomatsakis/rust-memory-model/issues/43). And that's just one issue -- &T not being pointer-sized would be pretty bad, and making integers non-Send or non-Sync would be a pretty severe restriction as well.

On the other hand, when repr(C) is used people rely on the representation. At the same time, I can't find any information on what happens if repr(C) is used alone (without repr(bitpacked) in the RFC. I guess there are (at least) three possible options: pack, align or refuse to compile allowing this to be decided later. What is the repr(C) behavior suggested by the RFC?

Today repr(C) structs can contain any types and doesn't affect the internal layout of individual fields. It just determines the field's starting offset and the padding between them from the fields' size and alignment. Of course, a repr(C) type containing fields with unspecifieid layout isn't suitable for C interop but it's useful for ensuring that the offsets of those fields and the amount of padding between them is deterministic.
So the layout of repr(C) structs containing int<N>/uint<N> follows from the layout of those types on their own, it wouldn't be consistent to treat them different when placed in repr(C) structs (not to mention all the issues with being able to take references to struct fields).

In general I sort of like the "big ideas" behind this RFC, but I am inclined to postpone this right now. This seems like a big source of compiler complexity -- I predict a bunch of bugs and weird LLVM edge cases -- and before we embark on that I'd like to have a very strong motivation. I also think we probably need to work out the const generics story (i.e., so you can write impls over these things, and we don't wind up with the same "huge dump of impls" that we get with [T;N]).
The other thing is that, when we do visit this, I would like to have a very clear picture of our motivations. The main two motivations I have seen are:

C interop (for things with bitfields)
Unpacking packet headers or whatever (the Erlang use case)

I've not read in super detail, but I don't think that this RFC fulfills either of those?

So,is the approach I take in the comment above not viable for constraining N to less than 128?
https://github.com/rust-lang/rfcs/pull/2581#discussion_r230043717

@nikomatsakis I understand this as being the foundation for C compatible bitfields. But even without this there'd be a huge benefit for embedded: As you might be aware microcontrollers expose a lot of functionality via memory-mapped registers and those are nicely grouped together into a number of data bus width sized bitfields. Luckily we have tools (e.g. svd2rust) which compile vendor provided register definitions into a huge blob of a module which slice and dice them into nice thousands of proxies (one struct and impl per accessible field) making sure that the right bits are accessed.
I will spare you the large block of code required just to read or write a single bit inside such a register but needless to say that the sheer amounts of code required to make the whole system work is:

nearly unreadable
impossible to maintain by human
extremely slow to compile
generates huge docs (don't you dare click the src button!)
doesn't allow to address fields spanning multiple bits safely

The possibility of properly defining a register as a bitfield would be a game changer in my eyes, even if (at the beginning) we cannot rely on proper packing and simply coerce the whole thing into a e.g. u32 and vice versa.

@rfcbot fcp postpone
While I think I'm actually in favour in general of something in this space, I don't think now is the right time to consider it.  I propose that we postpone considering this until we have enough const generics in nightly to have a concrete comparison between this and a pure library solution.  That ought to also give a more confident answer to a variety of questions here, like how things generic over N need to be constrained to avoid monomorphization-time errors.

I think I would prefer to get const generics first and see if we can build these in a library, and if we can't, see which language extensions we would need to do so before considering adding them to the language (in particular given that there is no RFC for where clauses yet).
One of the motivating examples for const generics are bounded integers (e.g. Bounded<i8, 1, 10>, a 8-bit wide integer that only can take values between 1 and 10). I'd like for these types to be able to specify their niches "somehow", and if that were possible then we might be able to put these int<N>/uint<N> in a module in the std library instead of making them part of the language (as primitive types).

I think I would prefer to get const generics first and see if we can build these in a library, and if we can't, see which language extensions we would need to do so before considering adding them to the language (in particular given that there is no RFC for where clauses yet).
One of the motivating examples for const generics are bounded integers (e.g. Bounded<i8, 1, 10>, a 8-bit wide integer that only can take values between 1 and 10). I'd like for these types to be able to specify their niches "somehow", and if that were possible then we might be able to put these int<N>/uint<N> in a module in the std library instead of making them part of the language (as primitive types).

As far as I remember struct Bounded<I,const START:I,const END:I> won't be valid until const generics can mention type parameters,which this RFC gets around by using const BITS:usize instead.
Quoting from the RFC:
Because consts must have the structural match property,
and this property cannot be enforced for a type variable,
it is not possible to introduce a const parameter which is ascribed to a type variable
(Foo<T, const N: T> is not valid).

If you wanted to implement Bounded before const generics can mention generic parameters,you would have to have at least 2 different versions,
IBounded<I,const START:i128,const END:i128> and
UBounded<I,const START:u128,const END:u128>.
As far as specifying niches,could we not just have a trait with an associated constant specifying which bit-patterns are invalid for the type:

/// Repr is the underlying representation of the type.
enum ValidBitPatterns<Repr>{
    AllAreValid,
    Range( ::core::ops::RangeInclusive<Repr> ),
    Value( Repr ),
    Not(&'static InvalidBitPattern<Repr>),
}

trait Niche{
    type Repr:BitPattern;
    const VALID:ValidBitPatterns<Self::Repr>;
}

Now that I finally have the time to work on this, I'm going to try and integrate all of the suggestions into the RFC text before the end of the day. No idea how much I'll get done, but we'll see.
I personally wasn't expecting this RFC to get accepted any time soon, and postponing it now makes a lot of sense even to me as the RFC author. Although I did want to post this for the visibility and design so that someone else can take this work and discussion and make another RFC once const generics are stable and the desires of the community are clear. Additionally, a lot of the things here I think should be planned to integrate into the language shortly after const generics are available, even though not all of them are the best decision.

To clarify, I don't intend to close this until the FCP runs through. So, I'll try to constantly revise the RFC until it reaches that point. :)

Thinking about the notch optimizations in this, note that the notches are ranges not bits.  So Integer<3, 200> can totally have the notch optimizations.  As such, I think I'd rather have that version as the primitive, with type uint<N> = Integer<0, (1<<N)-1>; just a simple alias, not the main feature.

@scottmcm The problem is that if we want to use these for bitfields, we would then need to guarantee that the niche optimizations will always be applied to use the smallest number of bits.

This feature, if desired, should be designed to be as orthogonal as possible to a similar but distinct feature: built-in ranged integers (as in Ada language). (And if I must choose what of the two features to implement in Rust, I think ranged integers are more useful).

@scottmcm

I don't think it ever should

Really? Why do you say that?

it could look for Integer<L,H> just as well.

This is true, but IMHO it seems less obvious from a UX perspective how to pack a Integer<L, H> than a int<15>, especially if L != 0.
Also, I'm really skeptical of stabilizing/guaranteeing optimizations, like niche-filling because then those effectively become part of the language and have stability guarantees, which seems very sketchy.

Really? Why do you say that?

Because I can soundly ptr::write_unaligned over fields of repr(packed) structs today.  That means that it can't pack things smaller than their size, or such code would overwrite other fields.  Thus if int<N> were to be sub-byte packed by repr(packed), it would have to be !Sized or something so it can't be passed to existing code, and that doesn't sound like a nice world state.  I'd much rather make a new "you can't get pointers to fields" repr than make that part of the uint<N> types.

You can use a pair of unsigned integers to specify a wraparound range, you don't need a signed version separately.

As far as specifying niches,could we not just have a trait with an associated constant specifying which bit-patterns are invalid for the type:

IMO that causes all sorts of issues. Whether the trait is implemented must now be evaluated by several different things, including unsafety checking and type layout.
And you don't get a constructor like NonNull:: new for free.

You can use a pair of unsigned integers to specify a wraparound range, you don't need a signed version separately.

As far as specifying niches,could we not just have a trait with an associated constant specifying which bit-patterns are invalid for the type:

IMO that causes all sorts of issues. Whether the trait is implemented must now be evaluated by several different things, including unsafety checking and type layout.
And you don't get a constructor like NonNull:: new for free.

I am not expecting to get NonNull::new for free though.
To clarify what I would expect if a trait like this were accepted,here is an newtype for u32 that disallows the maximum value in its constructor.

fn main(){

    assert_eq!(
        ::std::mem::size_of::<Option<NonMaxU32>>(),
        4
    );

    assert_eq!(
        ::std::mem::size_of::<NonMaxU32>(),
        4
    );

    assert_eq!(NoMaxU32::new(0) , Some(0))
    assert_eq!(NoMaxU32::new(1) , Some(1))
    assert_eq!(NoMaxU32::new(2) , Some(2))

    let max=!0u32;

    assert_eq!(NoMaxU32::new(max-2) , Some(max-2))
    assert_eq!(NoMaxU32::new(max-1) , Some(max-1))
    assert_eq!(NoMaxU32::new(max) , None)
}

#[repr(transparent)]
struct NoMaxU32{
    repr:u32,
}

impl NoMaxU32{
    pub fn new(repr:u32)->Option<Self>{
        if repr == !0u32 {
            None
        }else{
            Some(Self{ repr })
        }
    }
}

unsafe impl Niche for NoMaxU32{
    type Repr=u32;
    const VALID:ValidBitPatterns<u32>=
        ValidBitPatterns::Range(0..=((!0u32)-1) ) ;
}

Yes, I think that is harder to implement and more prone to subtle soundness issues. Note that your main function needs an unsafe block to create Self.

Finally managed to get around to updating this. Let me know if there's anything I missed, or if you have any additional things to clarify. :)

See also:
https://andrewkelley.me/post/a-better-way-to-implement-bit-fields.html

While I agree with postponing this until const generics land, I do think it makes sense to have enough compiler support to aid in using these in repr(C) structs, so I don't think these should just be a library without language support.
(Also, as a procedural note, if we postpone this, we need to add a note to the lang team agenda to revisit it at a defined later time.)

As noted in the RFC text, there is the option of using these types just to get better interfaces while still leaving bit fields out of the language and letting macros generate the code to insert or extract those bits into/from uN fields. Library-defined types that enforce the bit size limit without compiler support would work just as well for that purpose, and would avoid many of the language and compiler complications of native bit fields.

Yep! The goal of this is just the generic integer types, and how exactly bitfields are done is entirely separate. I personally feel like the benefits of having the generic integer types in the compiler make it worth it, but the point of the RFC is to determine that.

Prior art
ZIG has arbitrary-width integers built-in:

In addition to the integer types above, arbitrary bit-width integers can be referenced by using an identifier of i or u followed by digits. For example, the identifier i7 refers to a signed 7-bit integer. The maximum allowed bit-width of an integer type is 65535.

https://ziglang.org/documentation/master/#Primitive-Types

Looks like this RFC was postponed until const generics, and it looks like min_const_generics landing in 1.50 via https://github.com/rust-lang/rust/pull/79135 should be enough to re-evaluate?

should be enough to re-open and re-evaluate?

@trevyn From my postpone comment,

until we have enough const generics in nightly to have a concrete comparison between this and a pure library solution

so just stabilization isn't enough, to me, to return to this.
Instead, does this exist as a crate yet?  If not, is there something blocking it?  Is that something that's already on the const generics roadmap?  If it does exist, how well does it work?  What are the problems with it?  Is there a sufficiently-essential part of it that could be proposed as a new libs RFC?  Is there a language feature that would make it better but could also be used in other places?

While it would be really important to have any solution to arbitrary sized, I don't think abusing const generics for this purpose is the best possible solution.
With other languages (already supporting bitworks) scrambling on hacks to implement custom types for arbitrary sized integers (because they can't really extend the primitive types) I do feel that Rust could do one better and add uX and iX as primitives to the language.

Instead, does this exist as a crate yet? If not, is there something blocking it? Is that something that's already on the const generics roadmap? If it does exist, how well does it work? What are the problems with it? Is there a sufficiently-essential part of it that could be proposed as a new libs RFC? Is there a language feature that would make it better but could also be used in other places?

Here's a initial start for a crate: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=89887f72711b3e472c2f0b89770b9120
Feel free to use it under the same license as rustc (Apache 2 + MIT iirc).

Instead, does this exist as a crate yet? If not, is there something blocking it? Is that something that's already on the const generics roadmap? If it does exist, how well does it work? What are the problems with it? Is there a sufficiently-essential part of it that could be proposed as a new libs RFC? Is there a language feature that would make it better but could also be used in other places?

I do think that it would be lovely to have a crate solve these problems before any discussion is required for this, but I also want to point out that there have already been a few (big) reasons pointed out for why a library solution might not be sufficient. One big point is that there has already been expressed a desire for 256-bit and 512-bit integers in the compiler, and this seems like a very good candidate for that. I feel like the outcome of this decision would play into that as well.
And, again, one other key point I brought up here was that this would substantially reduce macro boilerplate for implementing traits on integers. That problem does not go away if we can't guarantee that the existing integer types are merely instances of a generic integer type; if anything, it only amplifies it, because you have to implement methods for both the existing integer types and the newer, more generic integer type.

Check out jhpratt/deranged for a speculative implementation within the compiler's current limits. It's in no way based on this RFC, but just throwing it out there.

Ranged integers are super interesting and desired but also a bit separate from the RFC given that the number of bits isn't considerable with const generics, only the range. That plus the inability to convert between ranges (e.g. From<Ranged<OLD_MIN, OLD_MAX>> for Ranged<NEW_MIN, NEW_MAX>> where NEW_MIN <= OLD_MIN && NEW_MAX >= OLD_MAX) leaves a lot to be desired.

"Generic integers" have come up as a possible desirable for use in a core::simd library, especially because it allows for easily representing arbitrary-length bitmasks, including ones of only 4 elements or of irregular, non-2^N values, even values larger than 128. Wanting a u4, u48, or u256 is surprisingly plausible in this context.

Here's a initial start for a crate: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=89887f72711b3e472c2f0b89770b9120
Feel free to use it under the same license as rustc (Apache 2 + MIT iirc).

This now compiles with stable. A crate capable of compiling on stable as PoC could help move this RFC forward.

Here's a initial start for a crate: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=89887f72711b3e472c2f0b89770b9120
Feel free to use it under the same license as rustc (Apache 2 + MIT iirc).

This now compiles with stable. A crate capable of compiling on stable as PoC could help move this RFC forward.

I have implemented a PoC crate based on this code here: https://github.com/npars/arbintrary and published here: https://crates.io/crates/arbintrary. PR's welcome! Hopefully we can get this RFC moving again.

I am very much in support of adding generic integers, I'm currently writing a Rust-based Hardware Description Language, and I had to write my own generic integer types: https://salsa.debian.org/Kazan-team/rust-hdl/-/blob/a4dda2a764a55bc342785e4488695ff516c1f04a/src/values/integer.rs

@programmerjake You might want to check out https://github.com/jhpratt/deranged. It's similar to this but provides for range bound integers with common trait impls.

@programmerjake You might want to check out https://github.com/jhpratt/deranged. It's similar to this but provides for range bound integers with common trait impls.

Neat! I'd still have to use my own implementation for rust-hdl since I need support for >128-bit integers, so I have it based on BigInt.

Honestly not a bad idea to add support for that behind a flag ¯\_(ツ)_/¯

C is getting generic integers:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2709.pdf
clang patch where I found my info: https://reviews.llvm.org/rG6bb042e70024

I might try and update this RFC with some prior art for zig, C, and LLVM at some point, maybe this weekend. Not sure if it'd be worth resubmitting though, since I have no idea where this'd be in terms of priorities.
We could probably get away with a very minimal MVP without any additions to the current const generics on stable, although it wouldn't add all the stuff we want. In particular, I guess that the biggest concern is the ability to implement From<uint<N>> for uint<M> where N < M, since we have no idea how those kinds of where clauses will ultimately be implemented. An MVP would not allow such impls, only the enumerated ones we currently have implemented (e.g. u16 > u32).

This RFC was postponed on const generics (although I don't see that as blocking this as I prefer the u48 form over uint<48>).  Now that a minimal level of that has hit stable, how does this get reopened?
Prior art: I believe that Ada (general purpose language) and VHDL and SystsemC (hardware description languages) also allow arbitrary integer sizes.

The main reason for offering a generic form uint<N> is explicitly for generics -- if you're forced to use macros to implement for multiple sizes, then it leaves out a large amount of use cases that allow simplifying integer trait implementations.
That said, there's nothing stopping us from offering uN as an alias for uint<N> if there's desire for it, and there's also nothing stopping people from type-aliasing uint<N> for specific N if we don't.
At this point, I would really love to restart this RFC with the things we've learned since, but I simply have too much going on with work + other stuff at the moment. As I said, if anyone else wanted to take over the role of doing that, I'd be happy to help however I can.

Is there somewhere that the "things learned" are documented?
In addition, I don't like coupling "Generic Integers" to "Bitfields" at all.  "Bitfields" have a lot of edge cases while a Rust struct that is "packed" is still useful even if you don't necessarily know exactly how it is packed.  (ie RGBA--10/10/10/2 can be packed into 4 bytes even if you don't know the exact order while "unpacked" would cost you at least 7 bytes--almost double the size and corresponding problems with cache lines).
While I do want bitfields, I suspect that having generic integers in the language would help people implementing bitfields to explore the space more effectively before converging.

I agree that generic integer lengths should not be seen "as-if bitfields", as the rules for C bitfields are subtle and highly implementation dependent. However, Rust users will likely use them as an implementation convenience for Rust types that work "like a bitfield" if introduced, so we should consider their semantics in that regard.
Of course, people already use u8, u16, etc. for that same reason, so that's nothing new or shocking.

I mean, there's precedent from Zig for using generic integer types for bitfields, as their packed struct would be equivalent to the #[repr(bitpacked)] I suggested. And we could potentially make it so that #[repr(bitpacked)] allows reordering fields just like #[repr(packed)] does, and then you have to do #[repr(C, bitpacked)] in order to ensure order.

Sure.
As far as the length-oriented where bound:
It should probably exist in the form of a trait or const fn bound. This would allow changing it after the fact without breaking compatibility. core::simd implements a similar thing as a somewhat ugly hack with a trait implementation on a struct, one we have at least some intention to move to a const fn before we stabilize anything.
And I actually think it should be confined to a bound equivalent to uint<N> where N <= 64 at first, because of these issues:

https://github.com/rust-lang/rust/issues/78473
https://github.com/rust-lang/rust/issues/63018
https://github.com/rust-lang/rust/issues/54341

However, eventually that should rise at least to 128 for the obvious reasons. It would also be nice to be able to go up to 256. This would help simplify implementations of "mask vectors" for AVX512 and eventually SVE2 and RISCV-V, etc.

I think that the long-term goal should be to make N virtually unbounded; I say virtually because obviously you're limited by memory and codegen size, and at some point you really should just be using bigints. But yeah, if someone wants to make a 4096-bit integer for RSA keys or something like that, I say they should be allowed. The codegen might kinda suck for integers that big, but I wouldn't say we should stop them.

C23 and C++ are getting generic integer types _BitInt(N) where N is the number of bits:
https://reviews.llvm.org/rG6c75ab5f66b4

iirc llvm already has proper support, at least for and, or, xor, shifts, comparison, add, sub, and multiply. division needs runtime library helpers (I don't remember if just the existing 128-bit helpers are sufficient).

LLVM RFC is up for adding library functions (div/rem) for >128-bit integers:
https://discourse.llvm.org/t/rfc-add-support-for-division-of-large-bitint-builtins-selectiondag-globalisel-clang/60329?u=programmerjake
maybe that would be enough to allow @rust-lang/project-portable-simd to use generic integers for bitmasks once rustc gains support.

I would like to note that C23 has standardized "N2709 - Adding a Fundamental Type for N-bit Integers"
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2709.pdf
At this point, Rust will actually be lagging C without support for generic integers.

I think it definitely weighs in strongly on the utility of the type, but we also actually trail behind C and C++ in many other things as well. Adding one more won't hurt.
One thing that came up in idle conversation when discussing the extension to the C Standard with a friend is that we don't necessarily have a good story for what operations with these types look like... C has the advantage (yes, it is an advantage here!) of accepting certain kinds of numeric promotion, which means that having what are effectively 4096 different integer types is not a problem because they interoperate with each other for simple operations. Are we sure we want that to be the same for Rust?
However, that's actually not something that requires deciding with the implementation, it's just an unresolved question that came up.

As evident by the fact that this was postponed instead of closed, there is a pretty strong desire to add these to Rust at some point; it just wasn't on the road map at the time this RFC was done since const generics weren't even close to being done yet, and there's still the unanswered question of numerically constraining where clauses with const generics (i.e., how do we want to implement From<u<N>> for u<M> where N < M).
If people have answers to these questions and the time to write an RFC, I would say go for it. But otherwise, there's not the biggest benefit to posting here since this is still a closed RFC.
I wonder, maybe it would be worth opening up a discussion somewhere in the const generics WG?

After trying to work with several bitfield crates, I stumbled upon this one: https://github.com/danlehmann/bitfield
I then tried to make it more ergonomic, which went ok for a while until it led me to trying:
#[bitfield(u4)]
struct TestChild {
    field1: u2,
    field2: u2,
}
#[bitfield(u8)]
struct TestParent {
    field1: TestChild,
    field2: u4,
}

Of course, this does not work, as proc macros can't "access" types, so TestParent can't access TestChild and therefore doesn't know how big it is and therefore can't generate any getters/setters. I'm not sure if any crate can (or should) breach that barrier?
My current idea is to add a const field SIZE to every bitfield and then generate offsets at runtime. Another idea is to give up on ideals and add an attribute to every struct field specifying it's size.
There are a ton more things to think about and similar issues when implementing bitenums (and bitflags).
To me it feels like we're reimplementing stuff the compiler does, only that the compiler likes to work with bytes and we reimplement things for working with bits, e.g. offset_of and size_of in the case above.
What would a first helpful step be? Maybe allowing the compiler to recognize bit-sized types?

Adding the notion of a "bit-sized" type (as opposed to a bit type that happens to occupy an entire u8) is much more troublesome than you might think, because one thing that Rust code can usually count on is that for each T in (T, T), the types can have pointers taken to them and interacted with separately. If you want to bitpack four u2 into one u8, that goes out the window.

Adding the notion of a "bit-sized" type (as opposed to a bit type that happens to occupy an entire u8) is much more troublesome than you might think, because one thing that Rust code can usually count on is that for each T in (T, T), the types can have pointers taken to them and interacted with separately. If you want to bitpack four u2 into one u8, that goes out the window.

imho bit-sized types would always be padded out to an integer number of bytes, except for inside bit-packed structs/enums, which are like repr(packed) in that you can't make references to their fields, you can only read or set them.

Has enough time passed to revisit this yet? :P


Add Mailfence

Hello,
I am quite new to Github, i finally found how to add the image asset but now how do i add it to the actual code itself? Thanks a lot if you take the time to reply

@resto1231 that asset needs to be added to the repo itself, thanks!

Hello,
So i added the image asset on my branch since i cannot upload the asset directly to the master branch. Is this the way to do it? Thankss

Yep, on the branch is the right place! But now I'm seeing 2 images uploaded, instead of one :)

I deleted the second picture it should be ok now, thanks!!


Be aware of License Terms 😉

Hello, thanks for opening the source code for the benefit of the community.
I'm very happy to see many patterns we've developed with much love and effort for KISS-ICP. It definitely makes your implementation stand against the usual ones we see in LiDAR odometry.
Although I would recommend being a bit more conservative when it comes to copying code from other projects, even when you don't pay for it, there are licensing terms:
https://github.com/PRBonn/kiss-icp/blob/11c7d97d156a7ff72fefdacc3105db4a99805e0e/LICENSE#L13-L14
Just to name a few
https://github.com/kevin2431/Traj-LO/blob/f04d15a7625bbc1167d76ddc8ef2bdcdda7d884c/include/trajlo/core/map_manager.h#L42-L59
Looks WAY too similar too
https://github.com/PRBonn/kiss-icp/blob/11c7d97d156a7ff72fefdacc3105db4a99805e0e/cpp/kiss_icp/core/VoxelHashMap.hpp#L36-L51

I don't mind at ALL that you reuse some code. Just be mindful of not claiming it as yours, as you claim in your license.

Thanks for reminding me this and apologize for the improper claiming in this part. The map manager of this project is inspired by your work kiss-icp. I will make it more clearer in the next commit and let you know.
Really sorry for this 😔

No problem at all, just be sure you at least mention it, like you did with the adaptive threshold


Editor performance issues in large codebases

Using https://github.com/astahmer/openapi-zod-client and example schema https://api.merge.dev/api/accounting/v1/schema, we generated a zodios file that is about 5k lines long. At this length it seems that the autocomplete works only after a very significant lag, making it really difficult to use zodios. Does this happen to anyone else? Are there ways we can make the performance better?

Hello,
I'll migrate this into Q&A because we are wrapping thé limites of typescript there.
So here are some thoughs:

if you can, remove all the endpoints and schema you don't need on your code
Split it into different files and different client zodios instance / like put a client for each resources (if you have isolated modules ts perf will go up)


businessDiff only returning absolute value

At the moment businessDiff only returns the absolute value rather than a relative value. This is an issue because if I am trying to use this in an if clause I am getting incorrect values.
if (startDate.businessDiff(moment()) <=3)  returns false if today is July 30 and the date I am comparing it too is June 15 because the value businessDiff gives is a positive number not a negative one.

@thorakmedichi Hi, are you still interested in this feature?

Just got caught out by this.
businessDiff should mirror the functionality of moment's diff which is to return a negative number:

If the moment is earlier than the moment you are passing to moment.fn.diff, the return value will be negative.

You can try my fix for this by changing your moment-business-days dep in your package.json to look like this:
"moment-business-days": "lyleunderwood/moment-business-days#negative-diff",

and then running npm i or yarn again.

+1 to This. @kalmecak can you implement the fix to mirror what moment does?

Shall we bump the minor version or jump to next major?

@lyleunderwood If i use your repo my npm install in production server hangs like 200 seconds in loadIdealTree:loadAllDepsIntoIdealTree: sill install loa
Do you know what could that be?

@tommyalvarez Not really, but this issue looks relevant.
I'm gonna update my PR to try and get this into a version.

@tommyalvarez that belongs to a different issue, anyway I'll change the repo url from ssh to https

@thorakmedichi Hi, are you still interested in this feature?
because I found its useful as well, f.e. Luxon has this on .diff and .diffNow

I found a work around and the project I was working is now shipped. So at this time I am fine.

I love running into an issue and then finding is was reported  2 years earlier, with a PR from half a year earlier that fixes the issue all open and ignored by the person who maintained the package.
Has anyone forked this project? there was a release after this PR was submitted and the package so indicates the package owner is only interested in changing/fixing things that effect him directly.

While I'm not the package owner, I always contributed to this package because forking the project on such a niche functionality gives no upside to anybody. That being said it it true that this feature was ready for merging, I'll bump it to @kalmecak


Cannot read property 'getState' of null

Hey, thanks a lot for the library! I am using version 4.1.0.
I have some code which is not working.
Possibly of interest is that this code is in a lazy loaded module.
I have the following select statement:
@select(selectors.settings.getPageSize) pageSize$: Observable<number>;
This works: (i.e. the page size is printed to the console)
constructor(
    private route: ActivatedRoute,
    private clientsActions: ClientWorkOrdersActions
  ) {
    this.pageSize$.forEach(pagesize => console.log({pagesize}));
  }

But when I try to inject an instance of NgRedux it no longer works (No errors but nothing printed to console):
constructor(
    private route: ActivatedRoute,
    private store: NgRedux<any>,
    private clientsActions: ClientWorkOrdersActions
  ) {
    this.pageSize$.forEach(pagesize => console.log({pagesize}));
  }

Running the following code gives the error shown in the attachment:
constructor(
    private route: ActivatedRoute,
    private store: NgRedux<any>,
    private clientsActions: ClientWorkOrdersActions
  ) {
    console.log(selectors.settings.getPageSize(this.store.getState()));
  }

See the attachment for more error details.
Thanks

This may be a silly question but are you calling ngRedux.configureStore or ngRedux.provideStore anywhere?

I am calling ngRedux.configureStore. Not sure if I am calling provideStore... I don't have access to the code right now sorry.
Something I should ave mentioned is that this code works in a normally imported module but not in a lazy loaded module (but @select works fine in the lazy loaded module).
console.log(selectors.settings.getPageSize(this.store.getState()));

OK, so I have figured this out....
I have the following structure:

AppModule
-- Imports StoreModule
-- Lazy-loads ClientsModule
---- Imports StoreModule

StoreModule has provides: [..., NgRedux] -> This was the issue!
From the angular docs [https://angular.io/docs/ts/latest/guide/ngmodule.html#!#shared-module]:

Do not specify app-wide singleton providers in a shared module. A lazy loaded module that imports that shared module will make its own copy of the service.

@nzjoel1234 Could you please explain how you solved this problem.

NgRedux is an app-wide singleton provider.
I was spcifying NgRedux in a shared module which was referenced by a lazy loaded module.
The angular docs specify (as I linked to in my last comment) that you should not do this (and why).
I moved the referenced to the NgRedux provider up to my root module (and removed any other referenced) and it fixed the problem.

thanks for the quick reply, so you simply removed the
 -- Lazy-loads ClientsModule
- ---- Imports StoreModule

No, I removed provides: [..., NgRedux] from all modules other than my root module

ok, interesting, I never had the provides: [..., NgRedux]
but I got it to work like this.

Create a ReduxModule (or StoreModule)

@NgModule({
  imports: [
    CommonModule,
    NgReduxModule,
    NgReduxRouterModule,
  ],
  declarations: [],
  providers: [],
})

export class ReduxModule {
  constructor(
    ngRedux: NgRedux<any>,
    devTools: DevToolsExtension,
    ngReduxRouter: NgReduxRouter
  ) {
    const rootReducer = combineReducers({
        router: routerReducer,
        context: contextReducer,
    });

    ngRedux.configureStore(
      rootReducer,
      {},
      [],
      devTools.isEnabled() ? [ devTools.enhancer() ] : []);

    ngReduxRouter.initialize();
  }
}

import that in the AppModule

@NgModule({
  declarations: [
    AppComponent,
    HomeComponent
  ],
  imports: [
    RouterModule.forRoot(routes),
    BrowserModule,
    FormsModule,
    HttpModule,
    ReduxModule, // <-- import from step 1
  ],
  providers: [],
  bootstrap: [AppComponent]
})

export class AppModule {
}

Do not import ReduxModule or NgReduxModule from any lazy children

I initially did not even have the ReduxModule all of that was inside the AppModule. Thank you for sharing


Footer component design update

Disregard content in the attached visuals but look to the structure and placement of content. Still maintains a column structure.
Default:

Minimal:

This is a duplicate issue. Will move the missing minimal design piece to the existing ticket (https://github.com/carbon-design-system/ibm-dotcom-library/issues/860)


Add questions template

Create a data model of how a question should be structured.

@ArcadyRob Assign me and also for #24.
I've prepared something based on opentdb API, grabbed some questions from their API, and added json-server for developing.
Let me know if I can open PR.


Self referencing table auto includes parent and child properties

Describe what is not working as expected.
I have a self referencing table, with a one-to-many relationship, define in Fluent API.  It includes a virtual property for the parent, and a virtual ObservableCollection<> for the children.  There are other one-to-many relationships, with virtual properties, that point to other tables.  When I use EntityFramework to query the table, it automatically includes both the self-referencing, parent and children properties, even though I do not specify .Include().  The secondary related tables, I do not specify .Include, and they are not returned.  One row has more than 8,000 child rows, and it is causing my WepAPI calls to fail.
Steps to reproduce
Include a complete code listing (or project/solution) that we can run to reproduce the issue.
Partial code listings, or multiple fragments of code, will slow down our response or cause us to push the issue back to you to provide code to reproduce the issue.
public class Supplier
{
        public virtual Supplier ParentCompany { get; set; }
        public virtual ObservableCollection<Supplier> ChildCompanies { get; set; }
        public virtual SupplierMember MemberSupplier { get; set; }
        public virtual ObservableCollection<SupplierAlias> Aliases { get; set; }
        public virtual ObservableCollection<SupplierContact> Contacts{ get; set; }
}

var result = await _context.Supplier.Include(e => e.MemberSupplier).OrderBy(e => e.CompanyName).ToListAsync();

result includes MemberSupplier, which is expected.  It does not include Aliases or Contacts, because I did not specify them.  However, it does include ParentCompany and ChildCompanies.  I expect these properties to not be included.
Further technical details
EF Core version: 2.0.1
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows 7
IDE: Visual Studio 2017 15.5.7

@dpedrelli What you describe seems to be working as designed. That is, when performing a normal tracking query, all relationships between entities in the query are "fixed up"--i.e. the navigation properties are set/populated with entities based on the FK values in the loaded entities. This happens regardless of whether or not Include is used explicitly on those relationships. This is a service provided by the context when entities are tracked, so to avoid this behavior a no-tracking query can be used. With a no-tracking query, only the relationship explicitly included will have navigation properties set/populated. However, note that both sides of the relationship will be fixed up regardless of which side is used to specify the relationship in the Include call.
If this doesn't answer your question, then can you please post a runnable project/solution or complete code listing that demonstrates the behavior you are seeing so we are able to investigate more?


some question about “merged_elevation_map”

Hi, is it necessary to enable the elevation_mapping module for the construction of erged_elevation_map in global_manager, I noticed that elevation_mapping transmits a submap to global_manager as well, is it possible to just Is it possible to transmit only the front-end LIO submap to build erged_elevation_map to generate the global costmap?

@Joosoo1  It's not necessary to enable the elevation_mapping module to build a costmap. With some simplification, you can also generate a global costmap using the 3D point cloud merged from submaps provided by LIO. Specifically, you need to write a plugin in costmap dir for this. Note that the elevation mapping package provides a more accurate analysis of the terrain.


Add Particl to atomic swap compatible list

Particl was added by Decred in https://github.com/decred/atomicswap on Oct. 24.
Reference: https://github.com/decred/atomicswap/commit/2bdb0d870c6c82fc0b92f69aef3b00b074fbaacb

I am new comer here, i want sign up but seen FACEBOOK can make me easy to login.
Is have app in play store or direct download from website.


Website Materials Notebook does not exist

The website at https://econ-ark.org/materials/solvingmicrodsops points to an interactive notebook that does not exist in this repository, namely Code/Python/SolvingMicroDSOPs-Python.ipynb.
Reported in Scientific Python Discord https://discord.com/channels/786703927705862175/1057710158639267990/1060587813281747034

@llorracc It seems like in the private repo the notebook has been moved and renamed and it hasn't propagated to the public version

@llorracc after your fix, I tried to open it and it returned this error
ERROR: Ignored the following versions that require a different python version: 0.8.0.dev1 Requires-Python >=2.7, !=3.*; 0.8.0.dev2 Requires-Python >=2.7, !=3.*; 0.8.0.dev3 Requires-Python >=2.7, !=3.*; 0.8.0.dev4 Requires-Python >=2.7, !=3.*; 0.8.0.dev5 Requires-Python >=2.7, !=3.*; 0.8.0.dev6 Requires-Python >=2.7, !=3.*; 0.8.0.dev7 Requires-Python >=2.7, !=3.*; 0.9.0 Requires-Python >=2.7, !=3.*; 0.9.0.dev1 Requires-Python >=2.7, !=3.*; 0.9.0.dev2 Requires-Python >=2.7, !=3.*; 3.6.0 Requires-Python >=3.8; 3.6.0rc1 Requires-Python >=3.8; 3.6.0rc2 Requires-Python >=3.8; 3.6.1 Requires-Python >=3.8; 3.6.2 Requires-Python >=3.8
ERROR: Could not find a version that satisfies the requirement matplotlib-base==3.3.4 (from versions: none)
ERROR: No matching distribution found for matplotlib-base==3.3.4
Removing intermediate container 80ec26f8130c
The command '/bin/sh -c ${KERNEL_PYTHON_PREFIX}/bin/pip install --no-cache-dir -r "binder/requirements.txt"' returned a non-zero code: 1

OK, can you see if you can figure out the problem?  Presumably some change to the requirements.txt file ...

made some changes on my fork, this link is almost working but now I think there are some errors in the code https://mybinder.org/v2/gh/alanlujan91/SolvingMicroDSOPs/enviro?labpath=SolvingMicroDSOPs.ipynb

I'm getting the same "cannot find SolvingMicroDSOPs.ipynb" error as before
when I click on the link.
On Fri, Jan 6, 2023 at 1:41 PM alanlujan91 @.***> wrote:

made some changes on my fork, this link is almost working but now I think
there are some errors in the code
https://mybinder.org/v2/gh/alanlujan91/SolvingMicroDSOPs/enviro?labpath=SolvingMicroDSOPs.ipynb
—
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/SolvingMicroDSOPs/issues/8#issuecomment-1374047152,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKCK74TFS643HEIDSORJNTWRBYMVANCNFSM6AAAAAATSLJHEI
.
You are receiving this because you were mentioned.Message ID:
@.***>

--

Chris Carroll

Fixed it so now the link works. However, running the notebook in this environment still creates an error further down in the notebook, so still need to figure out what's going on.
It also still takes way too long to set up this environment, maybe @camriddell can provide suggestions.

@alanlujan91 can you make a PR to the SolvingMicroDSOPs-Latest repo so I can run my script to create the public version and test it?

@alanlujan91 the binder link was actually quite fast for me, but that's likely because when you accessed it you had to sit through a build of the container (then when I accessed it, binder was able to pull that previously built image).
There are a few ways you can speed up binder links

If your source repos are pushed to very often for code changes but not for environment changes it may be worth creating separate environment repos.
Not enough activity on the links, binder will throw away docker images that aren't used often meaning more build processes when you do want to access them.

There are shortcuts we can take, but let's save that for an online meeting.

As per the notebook issue, there is an issue with the GothicMC class where its varsigma_Tminus1 and varsigma_t methods sometimes return a numpy scalar and sometimes return a numpy array with 1 element. A quick fix of squeezing via np.squeeze the returned result down into a scalar enabled me to run the notebook to completion.
class GothicMC(Gothic):  ## inheriting from Gothic class
    ## inheritance from Gothic and adds additional functions/methods for portfolio choice
    ...

    def varsigma_Tminus1(self,
                         a):
        ...
        return np.squeeze(varsigma_opt)

    def varsigma_t(self,
                   a,
                   c_prime):
        ...
        return np.squeeze(varsigma_opt)

Awesome! Thanks for helping out with this @camriddell. I think there might also be redundancy with having a binder folder and also requirements.txt and environment.yml files in root directory. For the PR that @llorracc just requested I will just keep the environment.yml file.

@camriddell,@alanlujan91
Well, really my recommendation is that we queue this up for the systematic review of how we handle requirements.  Since @alanlujan91 could not figure out how to require texlive-full I'm concerned that the .yml approach may be less general than the files-in-binder-directory version.


Flatten sidebar

PR with 2 changes

Make the first page of the sidebar the same level as its children.

before
after

Make the sidebar collapsed by default.

I think this is OK for now but wanted to check that we can still have the full expanded sidebar?  Is that just a matter of changing the glob?

I think this is OK for now but wanted to check that we can still have the full expanded sidebar?  Is that just a matter of changing the glob?

If you don't configure the glob in the mosaic config file then it will default to the full sidebar of the whole site
It won't be visually expanded by default though (meaning the sub menus are not visible until you expand them) but I think that makes sense because you can't really read a sidebar with 100 items, makes sense to just expand the sections you're interested in.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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 62.903%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1255

Relevant Lines:
1741

💛  - Coveralls

Yeh i agree with the new structure and it not being expanded by default. Also a thought, do we want the parent dir e.g "Mosaic" or "Developer Home" to be in the sidebar ?
Surely the user knows their int he website and can use the logo in the app header to navigate back to the home page


Preferring yaml over json

Our config hub uses yaml files, but lit_config.json (and soon prompt_style.json) are json files. We might want to have a single file format for consistency.
This would require changing #1019 to dump to yaml instead, and have scripts read and save .yaml
We also need to think of the crawlers using lit-gpt as training data for their LLMs, where yaml is much preferred due to tokenization artifacts :zany_face:

Arghh, I just recently merged the prompt PR and I forgot that we previously agreed to make it yaml, and I made it json anyway. Not sure what happened. I'll change it.


Expand form width button

Description

This adds a new option in Settings.json to enable a full width toggle button. This works by defining css variables for the page's max-width and padding. These css-variables are overridden by conditionally adding a class to the Presentation component that overrides these variables for all of its children. Previously, the page max width and the modal padding was hardcoded many different places, but now this is all refactored to use the css variables instead.
I also took this oppurtunity to refactor and get rid of material-ui makeStyles (and replace with css modules) in most of the places that I updated, and also refactored/updated many of the old components used in the Presentation such as the NavBar (back, close, language-selector). I also removed a lot of mui Grid, and using css modules to style the flex layout instead.
Finally I changed some layout surrounding the summary component, to make the Edit button positioning work better, as it looked pretty bad in the expanded view.
https://user-images.githubusercontent.com/47412359/223988190-3a602210-7821-4711-bf13-ce50516f9199.mov
Related Issue(s)

closes #95

Verification/QA

Manual functionality testing

[x] I have tested these changes manually
[ ] Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
[ ] No testing done/necessary

Automated tests

[ ] Unit test(s) have been added/updated
[ ] Cypress E2E test(s) have been added/updated
[x] No automatic tests are needed here (no functional changes/additions)
[ ] I want someone to help me make some tests

UU/WCAG (follow these guidelines until we have our own)

[x] I have tested with a screen reader/keyboard navigation/automated wcag validator
[ ] No testing done/necessary (no DOM/visual changes)
[ ] I want someone to help me perform accessibility testing

User documentation @ altinn-studio-docs

[ ] Has been added/updated

[ ] No functionality has been changed/added, so no documentation is needed
[x] I will do that later/have created an issue

Changes/additions to component properties

[x] Changes are reflected in both src/layout/layout.d.ts and layout.schema.v1.json, and these are all backwards-compatible
[ ] No changes made

Support in Altinn Studio

[?] Issue(s) created for support in Studio

[?] This change/feature does not require any changes to Altinn Studio

Sprint board

[x] The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
[ ] I don't have permissions to do that, please help me out

Labels

[x] I have added a kind/* label to this PR for proper release notes grouping
[ ] I don't have permissions to add labels, please help me out

I'll let David, king of code reviews, take the lead on this review! 👑
While I assume it hasn't been in the requirements, I would assume there comes a new requirement after this for the layout to be expanded by default. Would that be a reasonable expansion to the properties?
Also, I haven't tested this yet, but does the button disappear when the viewport is mobile? At that point it can't expand, so it would make sense for the button to be hidden. And, of course test that in the mobile.ts cypress test.. 😉

I'll let David, king of code reviews, take the lead on this review! 👑
While I assume it hasn't been in the requirements, I would assume there comes a new requirement after this for the layout to be expanded by default. Would that be a reasonable expansion to the properties?
Also, I haven't tested this yet, but does the button disappear when the viewport is mobile? At that point it can't expand, so it would make sense for the button to be hidden. And, of course test that in the mobile.ts cypress test.. 😉

Making the button disappear for small widths is a good idea especially if it is not already expanded.
I have talked about default expansion with Lasse and Marianne, and that could indeed become a requirement. But as most of this PR is just refactoring to make it possible, we thought it was ok to leave that for a future issue. It should be relatively easy to add more controls for the expanded-state in uiconfig.


RDKBDEV-2749: Fix for VLAN Interface Incorrectly Updated to vlan101 in PPPoE Configuration

Reason for change:
The VLAN interface name was not being fetched from Device.PPP.Interface.1.LowerLayers.
Test Procedure:
Ensure the PPPoE connection is established.
Risks: None.

Internal ticket for tracking https://ccp.sys.comcast.net/browse/RDKCOM-5063


Add metricbeat chart

The first commit is a copy paste of the filebeat chart. If you want to see all of the changes after the s/filebeat/metricbeat you can look at: https://github.com/elastic/helm-charts/pull/127/files/f8aa4bfaa972ac72abb017acb484ffbf457295d2..8bc136528dfb40ed3fd563edf9322708e6873447
Couple of notes:

I don't really like the add/remove charts/ dance in .helmignore however I had to add it because helm lint --strict will fail because of linting problems with kube-state-metrics child chart. And leaving it in .helmignore will mean that helm can't find the child chart :(
I made the decision for the metricbeat that uses kube-state-metrics to re-use the configmaps, secrets and extra envs from the daemonset. I did this because these secrets are always being used for the output to Elasticsearch. I couldn't imagine a situation where you would want to add a secret to one of them, but not the other. This simplifies the chart and removes a lot of duplication. The real reason we run a seperate deployment is so that we don't have each daemonset pod sending exactly the same information from the Kubernetes API. Since we theoretically could move the kube-state-metrics logic into the daemonset config (with the downside that you would have duplicated data and extra queries to the Kubernetes API) I can't see this causing any issues.
I added in a couple of tests to make sure that the correct data really appears in Elasticsearch. This was to be sure that the daemonset metricbeat data and the deployment were making it in properly.

Just realised the CI changes won't work in this PR since they are only deployed from master. I just deployed the changes from this branch to devops-ci.
jenkins test this please

jenkins test this please


Put all Icons in one folder

currently, icons are spread throughout all folders. in css you can use .. before a directory to go back one folder. For example, if I wanted to get a file called "lock.svg" then I would use ../icons/lock.svg

pull request made for this


Update supported-management-agents.md

Update to note SP 2019 is supported.

@tseward : Thanks for your contribution! The author, @billmath, has been notified to review your proposed change.


Fixed incorrect path to download bootstrap-alert.js

The "Download" button for the alerts section of the javascript docs pointed to the old naming of the boostrap-alert.js file. This corrects the path.

Resolved in the template and rebuilt the docs. Thanks!


feat: do not add a the Name tag for docker+machine >= 0.16.2

Description
This PR checks the version of the docker machine and adds the Name tag if it is not done by the driver itself. It also removes the second Name tag from the amazonec2-tags in the config.toml. In consequence it is no longer possible to change the Name of the Runners as the Name tag is now added by the docker-machine driver (for versions >= 0.16.2).
docker_machine_version >= 0.16.2 automatically adds the Name tag to the EC2 instances. Adding another Name tag here causes the EC2 creation process to fail.
To be able to configure the name, var.overrides["name_docker_machine_runners"] is added as prefix to the name of the docker machine which is used as name for the EC2 instance by the driver.
The main logic was taken from https://github.com/hashicorp/terraform/issues/22688#issuecomment-1196805096
Closes #521
Migrations required
No.
Verification

[x] Verify the version logic manually with a local.tf only. Returns true if version >= 0.16.2
[x] Check the config.toml for versions >= 0.16.2 with overrides["name_docker_machine_runners"]. No Name tag present.
[x] Check the config.toml for versions >= 0.16.2 without overrides["name_docker_machine_runners"]. No Name tag present.
[x] Check the config.toml for versions < 0.16.2 with overrides["name_docker_machine_runners"]. No Name tag equals the name set in the override.
[x] Check the config.toml for versions < 0.16.2 without overrides["name_docker_machine_runners"]. Name tag shows var.environment + "-docker-machine"
[x] Replace the current module with this version and check if tags are changed (using version < 0.16.2). There shouldn't be any change in the resource tags.

Also see #522 for long-wan-ep's test.

Still discussing the MachineName option in #521

Using the var.overrides["name_docker_machine_runners"] as prefix for the EC2 name.

Tested out the prefix for the machine name, it looks good to me. One thing to note is that gitlab-runners will add runner-<SHORT_TOKEN> as a prefix to the machine name so the name of the instance will end up being `runner-<SHORT_TOKEN>-<NAME_OVERRIDE>-<MACHINE_IDENTIFIER>, but I think it's ok.


Random failing tests in waitForAngular (IE11)

We see a lot of random failing tests with Internet Explorer 11. The error message (see also here) always points to a timeout in Protractor.waitForAngular():
[iexplore #3] Failures:
[iexplore #3]
[iexplore #3]   1) PaperHub homepage Test page title
[iexplore #3]    Message:
[iexplore #3]      ScriptTimeoutError: Timeout expired waiting for async script (WARNING: The server did not provide any stacktrace information)
[iexplore #3] Command duration or timeout: 4.09 seconds
[iexplore #3] Build info: version: '2.40.0', revision: 'fbe29a9', time: '2014-02-19 20:54:28'
[iexplore #3] System info: host: 'WIN-8LIIH1BGM1D', ip: '<IP_ADDRESS>', os.name: 'Windows Server 2008 R2', os.arch: 'x86', os.version: '6.1', java.version: '1.7.0_60'
[iexplore #3] Session ID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXc5e9d7c9
[iexplore #3] Driver info: org.openqa.selenium.ie.InternetExplorerDriver
[iexplore #3] Capabilities [{platform=WINDOWS, javascriptEnabled=true, elementScrollBehavior=0, ignoreZoomSetting=false, enablePersistentHover=true, ie.ensureCleanSession=false, browserName=internet explorer, enableElementCacheCleanup=true, unexpectedAlertBehaviour=dismiss, version=11, ie.usePerProcessProxy=false, cssSelectorsEnabled=true, ignoreProtectedModeSettings=false, requireWindowFocus=false, handlesAlerts=true, initialBrowserUrl=about:blank, ie.forceCreateProcessApi=false, nativeEvents=true, browserAttachTimeout=0, ie.browserCommandLineSwitches=, takesScreenshot=true}]
[iexplore #3]    Stacktrace:
[iexplore #3]      ScriptTimeoutError: Timeout expired waiting for async script (WARNING: The server did not provide any stacktrace information)
[iexplore #3] Command duration or timeout: 4.09 seconds
[iexplore #3] Build info: version: '2.40.0', revision: 'fbe29a9', time: '2014-02-19 20:54:28'
[iexplore #3] System info: host: 'WIN-8LIIH1BGM1D', ip: '<IP_ADDRESS>', os.name: 'Windows Server 2008 R2', os.arch: 'x86', os.version: '6.1', java.version: '1.7.0_60'
[iexplore #3] Session ID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXc5e9d7c9
[iexplore #3] Driver info: org.openqa.selenium.ie.InternetExplorerDriver
[iexplore #3] Capabilities [{platform=WINDOWS, javascriptEnabled=true, elementScrollBehavior=0, ignoreZoomSetting=false, enablePersistentHover=true, ie.ensureCleanSession=false, browserName=internet explorer, enableElementCacheCleanup=true, unexpectedAlertBehaviour=dismiss, version=11, ie.usePerProcessProxy=false, cssSelectorsEnabled=true, ignoreProtectedModeSettings=false, requireWindowFocus=false, handlesAlerts=true, initialBrowserUrl=about:blank, ie.forceCreateProcessApi=false, nativeEvents=true, browserAttachTimeout=0, ie.browserCommandLineSwitches=, takesScreenshot=true}]
[iexplore #3] ==== async task ====
[iexplore #3] Protractor.waitForAngular()
[iexplore #3]     at [object Object].<anonymous> (/home/travis/build/paperhub/paperhub-frontend/test/spec.js:5:20)
[iexplore #3] ==== async task ====
[iexplore #3] Asynchronous test function: it()
[iexplore #3] Error
[iexplore #3]     at [object Object].<anonymous> (/home/travis/build/paperhub/paperhub-frontend/test/spec.js:2:3)
[iexplore #3]     at Object.<anonymous> (/home/travis/build/paperhub/paperhub-frontend/test/spec.js:1:63)
[iexplore #3]
[iexplore #3] Finished in 8.197 seconds
[iexplore #3] 1 test, 1 assertion, 1 failure

Do you have any hints? Possibly this is related to #1476.

4 seconds seems like a pretty slow timeout for the async script. Have you changed any timeout settings anywhere? Maybe the default for IE is getting set incorrectly in some way.

There's only one timeout setting in the config and it is set to 60 seconds. Do you see any other suspicious code in the config that could be related? :)

No, your config looks good to me. We'll investigate!

Thx!

I'm having the same problem, is there a way to debug this by ourselves or to send more information about it?

Me too have the same problem. A for loop that works flawlessly in Chrome / Firefox fails with the same message as in OP.
I've tried increasing allScriptsTimeout: xyz, to no avail. The test just times out after the set time.
Let me know if I can help by providing the test.

:+1:

Sorry for the delay, I've had a man cold for a couple of days...
Here's my test below. It's supposed to create _number of systems, but what happens is in IE the test times out after first iteration (so only one system is created). In Chrome and Firefox the test works fine.
Let me know if you need any more info.

this.createSystems = function (number) { //create i number of systems
	//TODO: FAILS IN IE AFTER ONE ITERATION......

	var testSystemName = "System #";
	var testSystemDescription = "SystemDescription #";

	browser.get(toolKitUrl);

	function create(x) {
		toolKitPage.systemDropDown.click();
		toolKitPage.systemDropDown_CreateSystem.click();

		toolkitSystemCreatePage.systemName.clear();
		toolkitSystemCreatePage.systemDescription.clear();

		var field = toolkitSystemCreatePage.Description;
		var value = "{}";

		field.clear();
		_completeInput(field,value );

		function _completeInput(field, value) {
			return field.getAttribute('value').then(function(v) {
				if (v.length < value.length) {
					field.clear()
					return field.sendKeys(value).then(function() {
						return _completeInput(field, value);
					});
				};
			});
		};

		toolkitSystemCreatePage.systemName.sendKeys(testSystemName + x);
		toolkitSystemCreatePage.systemDescription.sendKeys(testSystemDescription + x);
		toolkitSystemCreatePage.createButton.click();
	}

	var funcs = [];

	for (var i = 0; i < number; i++) {
		funcs[i] = create.bind(this, i);
	}

	for (var j = 0; j < number; j++) {
		funcs[j]();
	}

};

I have plenty of flakiness examples (tests that randomly fail) in IE11 but works perfectly in Chrome. I don't think people is using IE11 in production e2e tests, as it is impossible.

I confirm that the timeout time seems being set randomly:
Failed: Error while running testForAngular: Timeout expired waiting for async script (WARNING: The server did not provide any stacktrace information)
    Command duration or timeout: 330 milliseconds

i've not set any timeout manually, and this number is that low for a timeout and everytime changing.
@juliemr maybe the setting used by testForAngular is using a call to a function that is instable during the browser startup?

Any updates on this issue? I'm running Protractor 3.3.0 and WebDriver 10.0.1 against IE 11 and I'm getting the same result after changing the getPageTimeout property. Thanks!

After investigation, I cannot get this to reproduce.
Here's my test:
spec
https://github.com/angular/protractor-cookbook/blob/master/protractor-typescript/spec.ts
config
import {Config} from 'protractor';

export let config: Config = {
  seleniumAddress: 'http://<IP_ADDRESS>:4444/wd/hub',
  capabilities: {
    browserName: 'internet explorer'
  },
  specs: ['spec.js']
}

@cnishina if using the 64-bit driver is discouraged, couldn't webdriver-manager use the 32-bit version by default?


Alleviate "truncated tar archive" issue

Cabal would sometimes fail to download the Hackage package index with an error: "truncated tar archive".
To alleviate this, on an error, we remove the Hackage package index (presuming it is corrupted) and try again.

Issue Number
ADP-1796

Attempted fixes failed - requires further investigation.


Ensure create_session starts a transaction if used as a context manager

We’d need to make sure that the default behavior when create_session is used as a context manager is:

establish connection
Start transaction
commit or rollback at exit

Right now I’m not sure we do 2.

~/code/5esheets main *3 ❯ SQLALCHEMY_ECHO=true make db-dev-fixtures | grep BEGIN
INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
2023-06-28 10:23:17,338 INFO sqlalchemy.engine.Engine BEGIN (implicit)
2023-06-28 10:23:17,762 INFO sqlalchemy.engine.Engine BEGIN (implicit)

looks good


Update sensor.py

To avoid WARNING in HASS:
WARNING (MainThread) [homeassistant.helpers.entity] Entity None (<class 'custom_components.aladin_online.sensor.SensorEntity'>) is implicitly using device name by not setting its name. Instead, the name should be set to None, please report it to the custom integration author.

What version of integration and HA do you use?

Latest release of Aladin - 2.4.0
And same the latest HA - 2023.9.2 (same behavior in 2023.9.1, no older logs available)
In general there seems to be bigger change in weather component:
https://www.home-assistant.io/blog/2023/09/06/release-20239/#weather-forecast-service

It’s just strange because I use both latest versions too and don’t have nothing in logs.

Weird then.
I modified the sensor.py at HASS and after restart the error disappeared from logs.
I googled the same issue in several other integrations and this was the fix there as well.

Can you try remove the integration and install it again?

Well.
Removed the service, removed intergration in HACS. Restart HA, jsut of sure. Add Aladin in HACS, create service again.
Immediately after adding the serveice the WARNING appeared in the log.
HA restart and WARNING in log again during startup.

I'm still not able to reproduce it. And I also this the fix does not make sense: https://developers.home-assistant.io/docs/core/entity/#entity-naming

I am more and more confused.
For me it is perefectly reproducible :(
Restart of HASS, tailing the log and grepping for aladin:
2023-09-20 22:02:00.776 INFO (MainThread) [homeassistant.setup] Setting up aladin_online
2023-09-20 22:02:00.776 INFO (MainThread) [homeassistant.setup] Setup of domain aladin_online took 0.0 seconds
2023-09-20 22:02:13.564 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.aladin_online
2023-09-20 22:02:13.565 INFO (MainThread) [homeassistant.components.weather] Setting up weather.aladin_online
2023-09-20 22:02:13.571 WARNING (MainThread) [homeassistant.helpers.entity] Entity None (<class 'custom_components.aladin_online.sensor.SensorEntity'>) is implicitly using device name by not setting its name. Instead, the name should be set to None, please report it to the custom integration author.
2023-09-20 22:02:13.578 WARNING (MainThread) [homeassistant.helpers.entity] Entity None (<class 'custom_components.aladin_online.sensor.SensorEntity'>) is implicitly using device name by not setting its name. Instead, the name should be set to None, please report it to the custom integration author.

Then modify sensor.py and clean up all files in homeassistant/custom_components/aladin_online/__pycache__.
Restart of HASS, tailing the log and grepping for aladin and only this:
2023-09-20 22:07:29.749 INFO (MainThread) [homeassistant.setup] Setting up aladin_online
2023-09-20 22:07:29.749 INFO (MainThread) [homeassistant.setup] Setup of domain aladin_online took 0.0 seconds
2023-09-20 22:07:40.844 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.aladin_online
2023-09-20 22:07:40.865 INFO (MainThread) [homeassistant.components.weather] Setting up weather.aladin_online


Update doctests for Julia 1.6

Note that I've also updated the branch settings for main so that CI / Julia 1 - ubuntu-latest - x64 (pull_request) job must now pass. This is consistent with our other open source packages.

I don't need to update the Project.toml right?
https://github.com/invenia/FeatureTransforms.jl/blob/main/Project.toml#L17

I don't need to update the Project.toml right?
https://github.com/invenia/FeatureTransforms.jl/blob/main/Project.toml#L17

Don't think so, since doctest is just ignored rather than failing for 1.5


⚠ Bofrost.de has degraded performance

In 80b72d0, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1050 ms

Resolved: Bofrost.de performance has improved in 5c49136.


Cannot save lists on sd-card

Great job with the app ! Really like the ability to export the lists.
However, I'm an unable to export the lists to my sdcard. Only the internal memory and the app private storage work.
I just get a toast message saying "failed to save ...1list"

Hi ! thanks for noticing, I thought it worked but indeed it doednt on most devices. I'm working on it !

Hi ! I have implemented sd card support. It's available on version 1.2. :)


Dashboard: Safari typeahead options overlap

Bug Description
In safari type ahead options are overlapping and the background color for hover is off center.

Expected Behaviour
It should look more like this:

Steps to Reproduce
In Safari: Use the search typeahead in the header of the dashboard

Plugin Version: 1.0.0-beta.1
Operating System: Mac - Catalina 10.15.5
Browser: Safari

Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance Criteria

typeahead options shouldn't overlap and space should be respected, like in chrome and firefox

Implementation Brief

add proper fallbacks in typeahead options so that works as expected

added to s33 after start

What was the final resolution here? to account for long titles with "...", or line break?
Checked PR3347 and seeing this:

But the "Expected Behaviour" above indicates line breaks

This is my fault for not clarifying or updating this. The resulting typeahead options should all be 1 line with an ellipsis now.

Perfect - Thanks, @BrittanyIRL !

Verified in QA


When I was trying to upload, it's showing error.

Fatal error: Uncaught mysqli_sql_exception: Unknown column '70434f546d98048d624bc35c074cb5d8' in 'where clause' in C:\xampp\htdocs\php\libs\database.php:38 Stack trace: #0 C:\xampp\htdocs\php\libs\database.php(38): mysqli->query('SELECT user_id...') #1 C:\xampp\htdocs\php\libs\database.php(51): Db->query('SELECT user_id...') #2 C:\xampp\htdocs\php\upload.php(120): Db->select('SELECT `user_id...') #3 C:\xampp\htdocs\php\upload.php(40): valid_user('70434f546d98048...', '1', Object(Db)) #4 C:\xampp\htdocs\en\upload\upload.php(218): upload() #5 {main} thrown in C:\xampp\htdocs\php\libs\database.php on line 38

Have you installed the database?

Has your issue been resolved?


Strip version from fixture files

This causes them to match what is produced in Bazel HEAD, while allowing us to test Bazel 6 and 7.

Going a different route, since it's hard to get the paths to match up correctly in the fixtures: https://github.com/MobileNativeFoundation/rules_xcodeproj/pull/2901.


Consider a different tagline

Thank you for starting this repo. I absolutely love the name "test-drive".
Consider changing the tagline. Currently you write "The non-fancy testing framework". But "non-fancy" could be interpreted as a negative. I suggest using a tagline "A simple testing framework". The word "simple" has the same meaning with what you intended, I think, but is a positive word.
It may seem like an irrelevant detail, but I think this matters a lot. It's the first thing that people will read coming to the repo and it sets the tone for the rest of their experience.

This part is just boilerplate I put together in a hurry. I changed to simple now, but I will probably revisit the overall presentation of the project later again.


GithubRepoProvider cannot access private repositories in Github

I tried following the documentation on enabling private Github repository access but am unable to make it work. I am using the latest (to date) 0.2.0-fbbc302 helm chart for binderhub. My current secret.yaml looks like this:
config:
  GithubRepoProvider:
    access_token: <access-token-from-github>

But when I try to build a private repository I get the following:
Could not resolve ref for gh:<username>/<repository>/master. Double check your URL.

Just to verify, I tried out the GitLabRepoProvider for gitlab with the following setting:
config:
  GitLabRepoProvider:
    private_token: <gitlab-token>

This pretty much works fine. Anything I am missing?
P.S. i also tried creating a Github App with a client_id and client_secret with the secret.yaml that looks like below but that also does not work.
config:
  GithubRepoProvider:
    client_id: <id>
    client_secret: <secret>

The code that ends up getting called uses https://github.com/jupyterhub/binderhub/blob/master/binderhub/repoproviders.py#L475-L477 to add auth information to the API call. Off the top of my head I don't think that'll work. I was expecting to see it adding a Authorization header to the request. All things related to making a BinderHub private (auth and private repos) counts to the less used parts of the code base so it is possible they've experienced code rot. I'd start looking at how a authenticated request should look from the GH docs, try and make that request with your auth credentials with something like curl and if all that works change the GitHub repo provider to do that as well. PRs would be welcome to help get the code working or improve the docs so that people from the future don't have to go on the same expedition of trial-and-error.

Thanks for giving me a head start on this @betatim ! I'd be more than happy to help fix this part of the codebase if I can. Other than the docs in the CONTRIBUTING.md  any helpful guidelines I should be aware of?

CONTRIBUTING.md should get you started. Thanks for helping out!

Did a pull request with the changes. Thanks also @betatim !

@kaseyhackspace my bad for the late reply, but private github repo access has been working for me (using the binder helm chart 0.2.0-f746e50 and using access_token in my secrets.yaml) .....curious what version of repo2docker you're using? I initially ran into issues too but was fixed after https://github.com/jupyter/repo2docker/issues/736

Changing to 0.2.0-f746e50 fixed this bug for me, but note for anyone that might have the same issue: running "helm upgrade" didn't work, I had to delete and re-install the helm chart from scratch.


fixed the trans start/end issue

the StoredData check didnt account for all the states in transitions, so added another of the more obvious ones. keep in mind there may still be outliers that aren't caught.

closing for branch shenanigans


Pre-sort tracks data by ID and time

Description
Currently, inputted tracks vertices must be sorted according to track ID, then time (i.e., in ascending order columns 0 then 1 of the input array). If the data is not sorted, an error is returned. This PR resolves this by pre-sorting the data.
Type of change

[x] Bug-fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

References
This change was discussed by @jni in https://github.com/napari/napari/issues/1662#issuecomment-703180933 and https://github.com/napari/napari/pull/1361#discussion_r497459001.
How has this been tested?

[x] Added test for unsorted data
[x] Track layer tests pass

Final checklist:

[x] My PR is the minimum possible work for the desired functionality
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works

Ah! @AbigailMcGovern I forgot — with this PR, the properties and track data can fall out of sync now! The properties also need to be sorted! Could you open a follow-up PR to fix that?? 😬

Totally forgot about properties! 🤦♀ Sure thing @jni. I'll do that now.

I forgot too! 🤦🤦


Add the emote preferences tab from chatterino1 and all the options from there

Add the emote preferences tab from chatterino1 and all the options from there :)

Only thing missing seems to be the Ignored Emotes settings, which another issue covers


[Fix] Add new error type E_PARSE(number:4)

Resolve the problem of not sending syntax errors to rollbar.
Please check if everything is ok.
Thanks

Merged, thanks!


Contrib: git hooks to comment/close issues in kanboard

I've made a simple PHP script that uses regexps to detect issue ids mentioned in a comment. The script then contacts Kanboard using JSON-RPC and either validates that issues exist and belong to the specified project, or adds comment to the issues, and optionally moves them to the specified column.
There are also two git hooks:

commit-msg detects and validates issue ids in the commit message. If validation fails, the commit is aborted. Optionally, if no issue ids are mentioned, commit is also aborted.
post-commit runs after commit is made, and: adds comments, optionally moves issues to the specified column (e.g. Done).

Wherever I mentioned issues I mean Kanboard tasks.
I hope these hooks can be useful, maybe you can add them in contrib folder, or do you think I should create a separate repository myself and put them there?
https://dl.dropboxusercontent.com/u/49471027/kanboard-hooks.7z
Example of what the RegExps can detect: all of the issues mentioned here in there:
Sample log message to test the regex strings.

Testing mentions of issues inside a text: Mention single issue #55. Mention issues #77, #78 and #79. Mention more issues #123, #124 and #125 and some more separate ones: Issue #45, issue #46 and issue #47.

Related issues: #10, #11 and #13.

All of the following will be moved to Done:
Implements issue #101
Fixes bug #202
Fixed #123
Closes #99.
Closed #333, #334 and #335.
Closed: #10, #20.

I've somewhat improved the hooks since then.
When amending a commit, the script attempts to amend the Kanboard task comments.
I've uploaded the hooks to a new repo on github.
https://github.com/gene-pavlovsky/kanboard-git-hooks

I added your project to the list of related projects: https://github.com/fguillot/kanboard/blob/master/doc/faq.markdown#where-can-i-find-a-list-of-related-projects
Thanks!

Thanks!


update flutter_rust_bridge to >1.77.0 <=1.77.1

To be usable with ldk-node-flutter in the same project, I upgraded the flutter_rust_bridge package and build bdk-flutter again.

Thanks @kumulynja will review the impact and merge. Thanks for the PR 👍

Closing this as it is out of synch and not required anymore


Gradient norm clipping.

Pull Request Checklist

[x] Changes are complete (if posting work-in-progress code, prefix your pull request title with '[WIP]'
until you can check this box.
[x] Unit tests pass (pytest)
[x] Updated major/minor version in sockeye/__init__.py. Major version bump if this is a backwards incompatible change.
[x] Updated CHANGELOG.md

It might also make sense to add norm clipping to one of the system tests.

Addressed comments, added to one of the system tests and rebased.

Thanks for iterating, I will merge this despite the CNN system test fail (which seems to be occuring independent of this PR).


Add py.typed file

Description
Add py.typed file and add it the package_data to setup.py
https://peps.python.org/pep-0561/#packaging-type-information
Motivation
Seems to be helpful for typecheckers
Are you planning to do it yourself in a pull request?
No.

Cruising for good-first-issue issues and here I am.


OssChat cannot work due to we change repo name from summer-of-wechaty to summer

done

Fixed by https://github.com/kaiyuanshe/osschat/commit/e7d1753594a2058fd986a6f3fe1e2a1f90b21ce2


Why can't I find historical information

Js-waku  'queryHistory' could not find the message sent before
"js-waku": "^0.18.0",
const waku = await Waku.create({bootstrap: {default: true}});
waku.waitForRemotePeer().then(()=>{
...................
})
//  waku.store.queryHistory(ChatContentTopic, {
pageSize: 1,
pageDirection: 'forward',
timeFilter: {
startTime,
endTime
},
callback
})
//      No messages present in HistoryRPC response  ？？？？？     There should be information
//      waku.relay.addObserver(callback, ChatContentTopic)         This function and the send function are normal
//      And like it        https://js-waku.wakuconnect.dev/examples/web-chat/
//     The message sent, refreshed, disappeared

Maybe there are no message in the history at the given time, where there messages when you loaded https://js-waku.wakuconnect.dev/examples/web-chat?
We are also aware of issues with store: https://github.com/status-im/nim-waku/issues/841
It is fixed in nim-waku 0.8 but I don't believe it is deployed yet.
What content topic did you use?
Finally, please use markdown to write issue so it can be easier to read:
https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github

@xyy0725 I guess it was working before? This might related to the new nim-waku release: https://github.com/status-im/nim-waku/issues/882

I think we found the culprit:

nim-waku: https://github.com/status-im/nim-waku/pull/878 this is now deployed on the test fleet. a new release needs to happen and be deployed on prod fleet
js-waku: #606

Will release today but you would need to use the test fleet.


suddenly no connection to chargers

My integration is not reporting new data. It says car is not connected, while it is actually charging. Also does not report power and everything else. Tried to remove it and re-add with serial number, but nothing changed.
I can see that it's charging via go-e app, which connects via local network.
Perhaps a coincidence, but I was messing with my network, changed 192.168.0.xx to 192.168.1.xx.
There are no entries in HA log. Not sure how else I can debug this.

Update: actually, the integration is simply not working. I can "add" a charger with any random serial number and the result is the same - no data reported.
I can ping the chargers just fine, so not sure where the problem is.

Figured it out. It's bit embarrassing. I forgot to change mqtt IP in charger's settings.


General Issue: add badges

Background Information
Add pharmaverse badge and any other badges (covr, etc.)

https://pharmaverse.org/contribute/badges/

Definition of Done
Badges are shown on readme and pkgdown

Closed by #8


Error: elementHandle.click: Element is not attached to the DOM

Getting following error:-
    Error: elementHandle.click: Element is not attached to the DOM
    =========================== logs ===========================
    attempting click action
      waiting for element to be visible, enabled and stable
    ============================================================

        at /REDACTED/node_modules/@ngx-playwright/harness/element.js:230:14
        at PlaywrightElement.#perform (/REDACTED/node_modules/@ngx-playwright/harness/element.js:167:16)
        at SelectHarness.selectByText (/REDACTED/projects/app/e2e/harness/select.ts:48:9)

The way to reproduce is to use MatSelectHarness and do the following (in my case I am extending MatSelectHarness) which is going through the options and clicking on one of them.
    const options: MatOptionHarness[] = await this.getOptions(null, true);
    for (const opt of options) {
      const optText = await opt.getText();
      if (optText.trim() === text) {
        const h = await opt.host();
        //await h.focus();

        await opt.click(); /// <----  -- --  -- -- -- Throws above error
        break;
      }
    }

also I am using respectShadowBoundaries
createEnvironment(page).withOptions({ respectShadowBoundaries: true })

Not an issue.
It turned out that the opt.click() is occurring when the cdk select panel overlay was no longer open.


[Issue]: dkms compilation issues on Debian testing: objtool (dma_resv->seq is missing)

When compiling rocm with the stock kernel (6.8.12) from Debian testing the following error appears
DKMS make.log for amdgpu-6.7.0-1781449.22.04 for kernel 6.8.12-amd64 (amd64)
/tmp/amd.A0EtTvUI/Makefile:52: *** dma_resv->seq is missing. exit....  Stop.

However I believe this error message is misleading. The amdgpu-dkms ./configure logs show that basically all checks fail due to:
objtool: SRCARCH variable not defined  thus the autoconf check AC_AMDGPU_DMA_RESV_FENCES fails because of the build error from objtool and not because of the check. This check sets HAVE_DMA_RESV_SEQ_BUG, which is why the dkms builds on recent Debian fails with dma_resv->seq is missing.
Newer kernel build tools on Debian (linux-kbuild-6.*) ship multiple objtools:
/usr/lib/linux-kbuild-6.8.12/tools/objtool/objtool
/usr/lib/linux-kbuild-6.8.12/tools/objtool/objtool.real-powerpc
/usr/lib/linux-kbuild-6.8.12/tools/objtool/objtool.real-x86

where objtool expects an environment variable SRCARCH to be set to x86, otherwise it fails.
I guess somewhere in the autoconf/configure scripts this SRCARCH needs to be properly set to build on recent Debian.
As a workaround you can rename objtool.real-x86 to objtool unless you want to cross-compile.
OS: Debian Testing
ROCM: 6.1.1 & 6.1.2

@ppanchad-amd Can you add this information to the JIRA that got made for https://github.com/ROCm/ROCm/issues/3036 ?

@nairboon @kentrussell I created JIRA ticket for issue #3036 but it was rejected by KCL team since packaged driver is not supported on Debian.  Please re-open the ticket if issue still occurs when Debian is officially supported. Thanks!

@nairboon @kentrussell I created JIRA ticket for issue #3036 but it was rejected by KCL team since packaged driver is not supported on Debian. Please re-open the ticket if issue still occurs when Debian is officially supported. Thanks!

I know Debian is not officially supported, however this issue is kind of preventing to support it at least unofficially. Maybe you can tag it as wishlist or something instead of just closing. Unless you never plan to ever support Debian?