Niches

Add support for niches in a stabilizable way.
Define them as narrowly as possible, using only support that already exists in
the compiler.
Provide an extensive section on future possibilities, covering many of the
additional ideas generated over the years.
Rendered

The RFC should mention pattern based refinement types (sort of like enum variant types but much more usable) as an alternative way of giving a type niches:
struct Foo(u32 is 0..100);
struct Bar(i32 is 0..);
struct Baz(i32 is ..0);
enum MyEnum {
    A,
    B,
    C,
}
struct Blah(MyEnum is MyEnum::A | MyEnum::B);

What types can the non-ZST field have? What is “the appropriate unsigned equivalent to use” for negative signed integers? I assume it’s the as conversion with the unsigned integer type of the same width, but the RFC doesn’t say. What syntax is accepted in parameters of #[niche(…)]? If it’s only (ranges) of integer literals, how are those values mapped to non-integer types? (If any are allowed)

What types can the non-ZST field have?

While we may need to narrow it, right now there isn't a specific restriction.

What is “the appropriate unsigned equivalent to use” for negative signed integers? I assume it’s the as conversion with the unsigned integer type of the same width, but the RFC doesn’t say.

The two's-complement representation; added some text to that effect.

What syntax is accepted in parameters of #[niche(…)]?

Unsigned integers. Added text to that effect.

If it’s only (ranges) of integer literals, how are those values mapped to non-integer types? (If any are allowed)

They correspond to the in-memory bit-pattern representation. For instance, a float value maps via the bits of the float representation.

The RFC should mention pattern based refinement types (sort of like enum variant types but much more usable) as an alternative way of giving a type niches:
struct Foo(u32 is 0..100); // Foo has niches for all values >= 100
struct Bar(i32 is 0..); // Bar has niches for all values < 0
struct Baz(i32 is ..0); // Baz has niches for all values >= 0
enum MyEnum {
    A,
    B,
    C,
}
struct Blah(MyEnum is MyEnum::A | MyEnum::B); // Blah has a niche for the value of `MyEnum::C`

Added as an alternative. Let me know if that covers what you would like to see covered.

I think I've addressed all comments up to this point.

#[niche(range = 4..)]
struct S {
    field: u16,
}

// `size_of::<S>()` may return less than 2

While the layout of repr(Rust) is of course unspecified, I don't think explicitly proposing this here is a good idea. Giving S only a size of 1 will trivially break as soon as anyone takes a &mut u16 to the field and writes any value to it, as that write will write 2 bytes. So S will always have to be at least as big as its fields (unless the compiler can prove that no reference is ever taken to the field, which doesn't seem too useful).

So, while I'm generally ok with strengthening ABI guarantees, I think this RFC proposes something a bit too strong. From a general perspective, I think this specifies the precise currently-unspecified behaviour of rustc a bit too much. The current spec seems to rely heavily on a specific internal representation in the compiler, which certainly does not match what I have implemented in lccc or in xlang ir for the same.

I echo what was said above regarding non-scalar fields. This should only apply to types directly containing a scalar field or potentially something that is repr(transparent) over a scalar field and is not (recursively) an UnsafeCell. I'd also prefer to exclude pointers entirely for now. (This impacts how it can be implemented, in xlang valid range of integers is encoded directly into the integer type, and not into struct field attributes, this communicates how specifically you can use the type - which is a property of the type in a strong type system).
I think that it should be limited to non-wrapping valid ranges for a similar reason - this one is more flexible though, but I currently assume I can just do max+1 to get the next niche when doing niche optimization.
I'd also, as a stylistic choice (not relevant to an implementation concern, though), want it to be more like #[valid_range(1..)] rather than #[niche(value=0)]. This is more inline with certainly what lccc does, and while I have limited experience with the rustc source code, the attributes currently used seem to indicate that it uses valid_range as well (but at some point determines the niche?).

To clarify, would this allow Result<PositiveI32, NegativeI32> to be the same size/align as a single i32 ?

To clarify, would this allow Result<PositiveI32, NegativeI32> to be the same size/align as a single i32?

I suspect this would be allowed, but not guaranteed.

Cross posting Zulip thread

To clarify, would this allow Result<PositiveI32, NegativeI32> to be the same size/align as a single i32 ?

That's not even supported in the simpler cases: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3902ea14ab2ce29d1a9809913a40d160 and it's unclear if we can do reasonable codegen for it in arbitrary cases.

It's very strange that this RFC proposes so specify invalid bit values, rather than invalid values of the type.
struct Foo {
    x: u8,
    y: u16,
}
// Can a wrapper around `Foo` specify niches? How could that possibly work,
// when the representation is undefined?
#[niche = ???]
struct NicheFoo(Foo);

#[repr(C)]
struct Bar {
    x: u8,
    y: u16,
}
// Now the repr is specified, but there is padding. What does it mean to
// specify a niche with a specific value of padding? It doesn't sound like
// something which should be legal.
#[niche = ???]
struct NicheBar(Bar);

// Can I specify as a niche one specific NaN bit pattern? Does it make sense?
// It feels wrong to specify as invalid bit patterns which can't reasonably
// ruled out during normal operations. You can't even compare against NaN.
// That would mean we must do a conversion to bits and a check against specific
// bit pattern on literally any f32 arithmetic operation.
#[niche = ???]
struct NicheFloat(f32);

And there are also the already mentioned issues with endianness, or pointer width. It would mean that the easy and natural way to use this feature (just specify a specific niche) is broken and non-portable, and the only truly correct way is to carefully #[cfg_attr(..)] its value on all possible architectural details. Similarly, the already mentioned issue with bool, which has its own niches.
I think the only reasonable use case is specifying niches on fixed-width (so no usize) unsized integers. All other primitive types have complications which make this feature at the very least confusing, compound types likely cannot be reasonably supported with the proposed approach. Signed integers could be supported in principle, but this RFC doesn't provide a way to specify negative niches, which makes it mostly useless for dealing with signed integers. It's better to entirely drop their support, to avoid confusion and to avoid stabilizing too much in case the design should be later changed.
For the last point, it would be nice if this RFC also provided an overview for the plans to support further possibilities. Sure, we may avoid stabilizing them at this point, but there must at least be reasonable confidence that we're not painting ourselves into a corner, and those cases really can be supported.

A few notes:

Is there a reason why range and value are separate? For example, why couldn't you just use a range like value..=value for the single-value case? Speaking of which... this RFC doesn't mention inclusive ranges, but I'd imagine they'd be accepted by the attribute.
I don't like the implicit two's complement representation for signed numbers. I think that, if we were to restrict this to only primitive integers as the actual values inside the struct, we could simply require that the range be represented using values for that integer.
Going with the above, this would make it possible to specify niches for types larger than usize, like u128.
I would add onto specification for niches that it may allow for optimisations beyond just type layout. For example, if I have a type #[niche = 101..] struct Percent(u8), the compiler may be able to assume that the value is always less than 100 for optimization purposes. I guess that this is all summed up in "undefined behaviour" but it's worth mentioning since I'd imagine a pretty big use case for niches is also to be able to create index types for arrays that will always elide the bounds checks.
How do niches affect pattern-matching exhaustiveness? I would assume that the above struct would only need to match values 0..=100, but this should be explicitly mentioned.
I assume that these niche-structs can be constructed at constant time, but this isn't actually mentioned, from what I can see.

re (2): The reference already states that signed integers are two's compliment.

re (2): The reference already states that signed integers are two's compliment.

Yes, I know that signed integers are two's compliment, but it gets more complicated when you have different sizes. Which of the following is more correct?
#[niche(value = 0xFF)]
struct One(i8);

#[cfg(target_pointer_width = "16")]
#[niche(value = 0xFFFF)]
struct Two(i8);

#[cfg(target_pointer_width = "32")]
#[niche(value = 0xFFFFFFFF)]
struct Two(i8);

#[cfg(target_pointer_width = "64")]
#[niche(value = 0xFFFFFFFFFFFFFFFF)]
struct Two(i8);

I would expect niches to come out as a consequence of a "pattern types" feature, that would also support enum variant types, ranged integers, etc. E.g., a NonZeroUsize is ~a #[repr(transparent)] struct NonZeroUsize(usize matching 1.. ).

That is a huge amount of work though, and this is forwards compatible with that, so I don't think there's any need to focus on pattern types now

Which of the following is more correct?

Fair point. Always giving the niche as an unsigned is probably bad. It should be a value or value range of the wrapped integer type.
Also, it should probably be required to wrap an integer type, at least initially. call it min_niche if you like.

I'd like to see a bit of discussion of future-proofing. I'm not inherently opposed to the idea of stabilizing just the niche behaviour currently supported by the compiler, but if future language features are going to be more complicated, how might they interact with this feature?
Why do all writes to niched values need to be unsafe? If the value is a compile-time constant, it is safe because the compiler can ensure it's a niche.

It should also be possible to write safely if the compiler adds instrumentation to panic when an invalid value is assigned. Maybe this shouldn't be the default behaviour, but there should be some way to ask the compiler to check your work rather than risking an off-by-one error in your own implementation of new().

I feel like the prior art section needs discussion of other languages' features for controlling type representations. Ada's representation clauses, C/C++'s bit-fields, etc.

What is the behavior of declaring value = 0x800000000 on a usize field?

Why do all writes to niched values need to be unsafe? If the value is a compile-time constant, it is safe because the compiler can ensure it's a niche.
That's talking about the case where the compiler needs to prove the value being inserted is not the niche.

I agree with adding the packed restriction: that the u64 inside a Not42 cannot have references taken to it.

@ChrisDenton wrote:

To clarify, would this allow Result<PositiveI32, NegativeI32> to be the same size/align as a single i32 ?

@thomcc wrote:

I suspect this would be allowed, but not guaranteed.

Exactly. This would fall in the general category of types with multi-value niches, for which Rust doesn't make any guarantees about representation.
I hope that we can support this, and eventually provide some guarantees about it, but this RFC doesn't attempt to specify that.

@chorman0773 wrote:

So, while I'm generally ok with strengthening ABI guarantees, I think this RFC proposes something a bit too strong. From a general perspective, I think this specifies the precise currently-unspecified behaviour of rustc a bit too much.

Attempting to leave large holes in specified behavior has never been a design goal, nor do I believe it should be.

The current spec seems to rely heavily on a specific internal representation in the compiler

The current limitations of the spec are based on the current limitations in the internal representation. This is part of the goal of this RFC: specifying no more than the compiler currently already supports (and has to support for existing stable behavior to be possible). However, nothing in the spec depends on the internal representation. And I expect that internal representation will need to change in the future to accommodate many of the items in the "future possibilities" section.

1. I echo what was said above regarding non-scalar fields.

I've changed the RFC now to only allow a handful of simple types, to address various issues the original RFC had not. (Not least of which, endianness of the unsigned integer representation.)

I'd also prefer to exclude pointers entirely for now.

The list of simple types I added includes raw pointers, precisely so that people can define structures containing pointers where they know the pointer will not take on certain invalid values. I've excluded references for now, though, primarily because they won't be very useful without generic parameters for lifetimes.

2. I think that it should be limited to non-wrapping valid ranges for a similar reason - this one is more flexible though, but I currently assume I can just do `max+1` to get the next niche when doing niche optimization.

This would prevent specifying an invalid value that isn't adjacent to the top or bottom of the integer range. I know of at least one type people want to declare that wants exactly that: people would like to define a signed type that excludes the minimum negative value, which has the advantage of providing symmetry (e.g. negation cannot fail). i32::MIN as u32 == 0x80000000, so this requires "wrapping" to represent.

3. I'd also, as a stylistic choice (not relevant to an implementation concern, though), want it to be more like `#[valid_range(1..)]` rather than `#[niche(value=0)]`.

I covered this possibility in the alternatives section. I expect, in practice, that most niche declarations will find it easier (or at least equally easy) to declare the invalid values than the valid ones.

(Note: I'm currently using "hide comment" as "resolved" to make sure I've addressed all the comments, but will unhide all comments once addressed.)

@clarfonthey wrote:

Yes, I know that signed integers are two's compliment, but it gets more complicated when you have different sizes. Which of the following is more correct?
#[niche(value = 0xFF)]
struct One(i8);

#[cfg(target_pointer_width = "16")]
#[niche(value = 0xFFFF)]
struct Two(i8);
#[cfg(target_pointer_width = "32")]
#[niche(value = 0xFFFFFFFF)]
struct Two(i8);
#[cfg(target_pointer_width = "64")]
#[niche(value = 0xFFFFFFFFFFFFFFFF)]
struct Two(i8);

Side note, even disregarding the actual size of usize, I think it's easier to read -10 than 0xF5.

Did you intend for this to have an isize field rather than an i8 field? For an i8, the first definition seems clearly correct.
Also, you can use cfg_attr(..., niche(...)), so that you don't have to repeat the struct definition.

A few notes:

Is there a reason why range and value are separate? For example, why couldn't you just use a range like value..=value for the single-value case?

Convenience: it's easier to write 0 than 0..=0, and it doesn't make the syntax any more complex. I expect that we will want to add other keys in the future, such as for mask-based niches.

Speaking of which... this RFC doesn't mention inclusive ranges, but I'd imagine they'd be accepted by the attribute.

I've now added an explicit mention of allowing both inclusive and exclusive ranges.

I don't like the implicit two's complement representation for signed numbers. I think that, if we were to restrict this to only primitive integers as the actual values inside the struct, we could simply require that the range be represented using values for that integer.

Going with the above, this would make it possible to specify niches for types larger than usize, like u128.

Rust does mandate two's-complement. And the internal representation does support niches on 128-bit values; I've verified that it's already possible to declare a niche on a struct containing a u128 using values outside the range of a u64: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=052535f23ce1f068b39b0011cfc97a3a
However, I agree with your underlying point: if we can support negative numbers, I think we should. The question then becomes, with the restriction to simple types, can we?
@oli-obk, what do you think? Is this something we could currently support, or would it require substantial changes to the machinery to handle negative numbers?

I would add onto specification for niches that it may allow for optimisations beyond just type layout. For example, if I have a type #[niche = 101..] struct Percent(u8), the compiler may be able to assume that the value is always less than 100 for optimization purposes. I guess that this is all summed up in "undefined behaviour" but it's worth mentioning since I'd imagine a pretty big use case for niches is also to be able to create index types for arrays that will always elide the bounds checks.

I don't want to make guarantees yet, but I've added documentation to that effect.

How do niches affect pattern-matching exhaustiveness? I would assume that the above struct would only need to match values 0..=100, but this should be explicitly mentioned.

Good point! The compiler doesn't really have the ability to do this, and by the nature of pattern-matching exhaustiveness, it has to be guaranteed if supported at all. I've added an explicit note that this doesn't affect pattern-matching.

I assume that these niche-structs can be constructed in constants, but this isn't actually mentioned, from what I can see.

I've added language explicitly allowing this.

Quick question (sorry if it's been answered upstream), but what would the behavior of this API's intersection with derives be!
#[derive(Default)]
#[niche(value = 0)]
struct NonZeroU32(u32);

Since the Default implementation for u32 returns the niched value, would there be a way to detect when this is happening and raise a compiler error within the Default macro? In addition, this may lead to new soundness checks being necessary for proc macros in the ecosystem.

@Jules-Bertholet wrote:

I would expect niches to come out as a consequence of a "pattern types" feature, that would also support enum variant types, ranged integers, etc. E.g., a NonZeroUsize is ~a #[repr(transparent)] struct NonZeroUsize(usize matching 1.. ). If the pattern-matching code has to have a concept of "valid bit patterns" anyway, it would be a shame to re-do all that conceptual and implementation work.

Echoing @JakobDegen's reply:

That is a huge amount of work though, and this is forwards compatible with that, so I don't think there's any need to focus on pattern types now

I also have a note in the alternatives section about using patterns for this, and I've just expanded that note to observe that niche would be forward-compatible with that.

@notgull wrote:

Quick question (sorry if it's been answered upstream), but what would the behavior of this API's intersection with derives be?
#[derive(Default)]
#[niche(value = 0)]
struct NonZeroU32(u32);

Since the Default implementation for u32 returns the niched value, would there be a way to detect when this is happening and raise a compiler error within the Default macro? In addition, this may lead to new soundness checks being necessary for proc macros in the ecosystem.

That's a good catch! I've added a note that the compiler should check this at compile time and produce an error if the default value falls within the niche.

@alercah wrote:

I'd like to see a bit of discussion of future-proofing. I'm not inherently opposed to the idea of stabilizing just the niche behaviour currently supported by the compiler, but if future language features are going to be more complicated, how might they interact with this feature?

I've tried to show some degree of future-proofing, such as by mentioning how other features may extend this. I do think there's a balance between future-proofing and designing those future features. However, I'd welcome suggestions for where further language would help.

* Why do all writes to niched values need to be unsafe? If the value is a compile-time constant, it is safe because the compiler can ensure it's a niche.

I have an entry in the future possibilities section about the compiler handling assignments of compile-time constants safely, by detecting valid/invalid values at compile-time.

  * It should also be possible to write safely if the compiler adds instrumentation to panic when an invalid value is assigned. Maybe this shouldn't be the default behaviour, but there should be some way to ask the compiler to check your work rather than risking an off-by-one error in your own implementation of `new()`.

I'm currently proposing that such support be handled by derive(TryFrom), with which you could either handle the error or call unwrap/expect. I can imagine other ways to handle it as well, but in any case I think those should be future work.

* I feel like the prior art section needs discussion of other languages' features for controlling type representations. Ada's [representation clauses](https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/representation_clauses_and_pragmas.html), C/C++'s bit-fields, etc.

Done. Further suggestions for precedent welcome.

@riking wrote:

I agree with adding the packed restriction: that the u64 inside a Not42 cannot have references taken to it.

I covered this above in a response to scottmcm. I do think there's key value in supporting such references, and unlike packed this can't result in unaligned references or other similar problems. It can only occur in unsafe code, and that code has to ensure that the resulting reference isn't misused. Similar obligations exist in many other ways in unsafe code.

@Mark-Simulacrum wrote:

Would we expect the Default macro to compile? The normally generated Rust code isn't going to have an unsafe block, which I think would mean that constructing would fail. I have no objections to a nicer diagnostic, of course.
The only macros that might become unsound is those that already wrap struct construction in an unsafe block, but I would guess that is very rare - most macros probably generate safe code for the most part. It's probably worth considering some kind of crater audit to see if we can identify such cases ahead of stabilizing, though. It might be a good fit for an unresolved question.

It seems relatively easy to support derive(Default) specifically, since it just needs to know if the type accepts zero-initialization. We have that support today, in the existing check for mem::zeroed().
We could, alternatively, reject derive(Default) until we have specific support for safe assignment of compile-time constant expressions. I've added that as an alternative. Personally, I think it's worth handling derive(Default), but I'm not particularly attached to that.

@clarfonthey wrote:

Yes, I know that signed integers are two's compliment, but it gets more complicated when you have different sizes. Which of the following is more correct?
#[niche(value = 0xFF)]
struct One(i8);

#[cfg(target_pointer_width = "16")]
#[niche(value = 0xFFFF)]
struct Two(i8);
#[cfg(target_pointer_width = "32")]
#[niche(value = 0xFFFFFFFF)]
struct Two(i8);
#[cfg(target_pointer_width = "64")]
#[niche(value = 0xFFFFFFFFFFFFFFFF)]
struct Two(i8);

Side note, even disregarding the actual size of usize, I think it's easier to read -10 than 0xF5.

Did you intend for this to have an isize field rather than an i8 field? For an i8, the first definition seems clearly correct.
For an isize, I would expect to need something like the second definition. I hope that we can eventually make that easier by supporting constant expressions like isize::MIN or usize::MAX.
Also, you can use cfg_attr(..., niche(...)), so that you don't have to repeat the struct definition. I expect people to end up wanting that for other kinds of target-specific niches.

I was not. My assumption here was that the value/range for the attribute was always usize, but based upon what you've said, I'd assume it'd always be u128?
The main point here is that two's complement isn't 100% clear when the size of the value isn't also clear. Since we're talking about values, not bit patterns, using two's complement doesn't make sense, IMHO. Yes, these values will all be the same if they're as-casted back to u8, but again, it feels like a lot of steps to avoid just allowing negative numbers.

As an alternative to a brand new attribute, is there a reason this cannot or should not be a part of the repr attribute?

The main reason for avoiding pointers and floats, afaik, is because doing so would require actually adding new features to the compiler, whereas the ability to do this in the compiler with the given proposal already exists and is just not exposed to users.
I definitely feel like they'll come as future proposals, but since they require more work, that's why it's not done atm.

@clarfonthey  I'm not sure what you meant. This RFC explicitly allows niches on pointers and floats.

The field type must be a built-in integer or floating-point type, a char, or a raw pointer.

It seems like there is not enough current functionality to meaningfully use those niches, though.

@afetisov I completely misread your message. Fair.

The main reason for avoiding pointers and floats, afaik, is because doing so would require actually adding new features to the compiler, whereas the ability to do this in the compiler with the given proposal already exists and is just not exposed to users.

I think this is a consequence of confusing the compiler concept of niches with the language concept of restricted-range values. This RFC, IMO, is about user-defined version of the latter, and that is a new feature either way. However, we already have a type whose restricted range is "aligned non-null pointer" -- it's our reference types. So it would not be strange to let users define similar types. The fact that only null is actually used as a niche for enum layout optimizations is an implementation detail and can be changed any time without an RFC; this RFC anyway does not guarantee layout optimizations.
So I think we could totally have some syntax that lets users declare non-NaN floats, even if the compiler will for now only be able to use a subset of the invalid values as a niche. The compiler would pick the biggest continuous range of invalid values as niche, and can be improved in the future to support non-continuous niches.

I think allowing users to define non-NaN floats would likely be a footgun while our floating point semantics are still a mess, and would make several of our existing bugs around them much worse than they currently are...

@jhpratt "niche" is a real english word that means "space for a thing", like an alcove in a wall, or a place in an ecosystem for a species. It is used within rust because it was already a real word.

@Lokathor I'm a native English speaker :slightly_smiling_face: I've just never heard it in a programming context, so I suspect others may be thrown off by its usage.

Regarding the 'niche' terminology, also see this subthread -- I argue that the concept of a "valid range/set of values" is a lot more common in programming and we should design the interface around that.

Just dropping a suggestion for the "Future possibilities" section of this RFC: Liquid Types :) (a.k.a. "Logically Qualified Data Types")
Instead of just providing a range of (in)valid values, it would be great if in the future we could also add match guards that can express more than just continuous ranges, similar to the match guards that exist for Rust pattern matching today (although for liquid subtyping, the guards should not be allowed to have any side-effects!). This has the advantage that it would become easier to reason about types and their optimizations, leading to less runtime checks if the compiler has support for this (i.e. better optimized binaries), as well as the simplification of formally verified programs (this could be useful for static analysis tools like Prusti and Cruseot - or even for an interpreter like miri, too). The above linked paper about liquid types claims a significant reduction in manual proof obligation thanks to liquid types (read: this could translate to Rust as having less unsafe in your code), and it was pretty successful for Ada as well, from what I heard (they call it predicated subtypes).

@joshtriplett This RFC feels like it was at least somewhat inspired by our discussion on LWN. I said there that I felt like the very simplest thing, just specifying a single niche, was very valuable. You obviously have a lot more experience of this process than I do, but I urge that this RFC tries to be uncontroversial even if that means it gets less done than a richer RFC might have.

Small datapoint: I perfectly know about niches, and was more or less expecting what's in the RFC, and even then when I read
#[niche(range = 2..)]
struct Bit(u8);

for a while I thought "but why is that value starting at 2 and called Bit ?" - despite the obviousness of this example.
So I know I'm bikeshedding but find the syntax unintuitive. I'd really prefer something like
#[niche(exclude = 2..)]
struct Bit(u8);

or something as explicit.

Apologies if this is bikeshedding, but  value = (value that this type CANNOT be) and range = (range that this type CANNOT be) is a bit confusing to me. When I see this:
#[niche(value = 42)]
struct MeaninglessNumber(u64);

#[niche(range = 2..)]
struct Bit(u8);

I internally read it as "MeaninglessNumber's value can only equal 42" and "the range of Bit is anything above 2".
My suggestion is to swap = for !=:
#[niche(value != 42)]
struct MeaninglessNumber(u64);

#[niche(range != 2..)]
struct Bit(u8);

I think it makes it a bit more understandable, to me it translates as "MeaninglessNumber has a niche: the value cannot be equal to 42" or "Bit has a niche: it is not in the range 2..". My intuition says most people will be thinking of niches not as "places to fit another type's information" but more as "the acceptable values for this type", since the former is more of a compiler optimization, e.g. you rarely have to think about it, whereas the latter affects how you use and interact with the type in practice. Thoughts?

That would require even more new syntax for attributes.
On Mon, 7 Nov 2022 at 11:44, Larson @.***> wrote:

Apologies if this is bikeshedding, but value = (value that this type
CANNOT be) and range = (range that this type CANNOT be) is a bit
confusing to me. When I see this:
#[niche(value = 42)]struct MeaninglessNumber(u64);
#[niche(range = 2..)]struct Bit(u8);
I internally read it as "MeaninglessNumber's value can only equal 42" and
"the range of Bit is anything above 2".
My suggestion is to swap = for !=:
#[niche(value != 42)]struct MeaninglessNumber(u64);
#[niche(range != 2..)]struct Bit(u8);
I think it makes it a bit more understandable, to me it translates as
"MeaninglessNumber has a niche: the value cannot be equal to 42" or "Bit
has a niche: it is not in the range 2..". My intuition says most people
will be thinking of niches not as "places to fit another type's
information" but more as "the acceptable values for this type", since
the former is more of a compiler optimization, e.g. you rarely have to
think about it, whereas the latter affects how you use and interact with
the type in practice. Thoughts?
—
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/3334#issuecomment-1305887782, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABGLD2ZC4K5GU3XM4U75UJ3WHEWXPANCNFSM6AAAAAARMIWN5E
.
You are receiving this because you were mentioned.Message ID:
@.***>

Why not just "exclude" and autodetect if it's a range ?

Is there a rationale for sidestepping the type system here? I feel like knowing which values a type can and cannot hold is the type system's domain, so duplicating that responsibility elsewhere in the compiler doesn't seem like the best idea. It also feels like the requirement to use these types in unsafe blocks is a consequence of keeping the type system in the dark, rather than being because niches are inherently unsafe.
To phrase it differently, the type system makes it impossible (in safe rust) to construct an enum with an invalid variant, why not extend that functionality for this purpose, where the type system can enforce it? As it stands, this seems like it'd require an entirely new mechanism, one where all construction is impossible in safe rust.
Compare niches as they are in this RFC to something like the following, just a simple extension of the enum system to use non-ident variants, some syntax for making many variants at once, and some new derives for fallible and infallible conversion. (I'm not suggesting this exact system, just using it as an example.)
#[derive(TryFrom, Into)]
enum Bit as u8 {
    0,
    1
}
#[derive(TryFrom, Into)]
enum MeaninglessNumber as u64 {
    0..42, 43..
}
fn main() -> {
	let a: MeaninglessNumber = 250.into(); // Ok
	let b: MeaninglessNumber = 42.into(); // Error
	match a {
		0..42 => println!("smol"),
		43.. => println!("lorge")
	}
}

Because this is handled by the type system, these values would be checked at compile time, making it impossible (in safe code) to use an invalid variant, and, more importantly, possible to use at all. If you want zero-cost(?) unchecked conversions, std::mem::transmute can do it, but being unsafe is a choice, with a system like this you'd have the option to deal with these types in purely safe rust, and doing so might even help catch some bugs at compile time.
So, why not implement this as an extension to the type system?

A much simpler API (which probably already exists in the ecosystem, although without niche support) is to use const generics:
struct RangedU32<const MIN: u32, const MAX: u32>(u32);

enum char {
    Low(RangedU32<0, 0xD7FF>),
    High(0xE000, 10FFFF),
}

A much simpler API (which probably already exists in the ecosystem, although without niche support) is to use const generics:

I attempted this in https://github.com/rust-lang/rust/pull/103724, but it is a performance regression due to the extra field now existing for NonNull<T> which is inside Box and Vec and thus used a lot. LLVM requires extra work to avoid this extra field, and I haven't found a nonhacky way to avoid that yet.

I really like the ideas raised of using enums for this, as they encode the concept of a set of valid values. It feels very natural to define niches in terms of enums with valid ranges, and I feel makes the type system very coherent: even builtin types, like u32 or char, fit into this mental model. All types can be imagined as either structs or enums, where structs combine types, and enums encode valid values. Bool is just enum bool { true, false }, and ints are just enum uX { value = 0..=X::MAX }.
(Pointers are kind of like struct Ptr<T> { addr: usize, provenance: CompilerMagic }, meaning this doesn't get rid of all type magic, but I think it still feels much better)

Is there a rationale for sidestepping the type system here? I feel like knowing which values a type can and cannot hold is the type system's domain, so duplicating that responsibility elsewhere in the compiler doesn't seem like the best idea. It also feels like the requirement to use these types in unsafe blocks is a consequence of keeping the type system in the dark, rather than being because niches are inherently unsafe.
To phrase it differently, the type system makes it impossible (in safe rust) to construct an enum with an invalid variant, why not extend that functionality for this purpose, where the type system can enforce it? As it stands, this seems like it'd require an entirely new mechanism, one where all construction is impossible in safe rust.
Compare niches as they are in this RFC to something like the following, just a simple extension of the enum system to use non-ident variants, some syntax for making many variants at once, and some new derives for fallible and infallible conversion. (I'm not suggesting this exact system, just using it as an example.)
#[derive(TryFrom, Into)]
enum Bit as u8 {
    0,
    1
}
#[derive(TryFrom, Into)]
enum MeaninglessNumber as u64 {
    0..42, 43..
}
fn main() -> {
	let a: MeaninglessNumber = 250.into(); // Ok
	let b: MeaninglessNumber = 42.into(); // Error
	match a {
		0..42 => println!("smol"),
		43.. => println!("lorge")
	}
}

Because this is handled by the type system, these values would be checked at compile time, making it impossible (in safe code) to use an invalid variant, and, more importantly, possible to use at all. If you want zero-cost(?) unchecked conversions, std::mem::transmute can do it, but being unsafe is a choice, with a system like this you'd have the option to deal with these types in purely safe rust, and doing so might even help catch some bugs at compile time.
So, why not implement this as an extension to the type system?

That is only appliable to literals, it is more complex for compile-time constants to be verified.
For the former, maybe we can have something like C++'s operater literal so that we can write sth like 12_NonZeruU8.
And for the later, I would like Rust to support exception on const evaluation so that we can have NonZeroU8::new(12).unwrap().

And for the later, I would like Rust to support exception on const evaluation so that we can have NonZeroU8::new(12).unwrap().

That is already supported. const Option::unwrap is available on nightly, and matching + panic works on stable.

Does matching work? I guess for Option which is copy.
On Tue, Dec 6, 2022 at 14:28 Bruno Kolenbrander @.***>
wrote:

And for the later, I would like Rust to support exception on const
evaluation so that we can have NonZeroU8::new(12).unwrap().
That is already supported. const Option::unwrap is available on nightly,
and matching + panic works on stable.
—
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/3334#issuecomment-1339888231, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABGLD25DWYBYXMH4SKVRMXTWL6HVTANCNFSM6AAAAAARMIWN5E
.
You are receiving this because you were mentioned.Message ID:
@.***>

Here's something I stumbled upon relating to niches. On x86_64, we have two different kinds of pml2/pml3s, that change depending on the 7th bit. Both variants are the same size, but they have different behavior with regard to flags and bit locations. A simple implementation could look like:
#[repr(transparent)]
pub struct Pml2Entry4KiB {
    data: u64,
}
impl Pml2Entry4KiB {
    // 4KiB code
}

#[repr(transparent)]
pub struct Pml2Entry2MiB {
    data: u64,
}
impl Pml2Entry2MiB {
    // 2MiB code
}

pub enum Pml2Entry {
    Large(Pml2Entry2MiB),
    Small(Pml2Entry4KiB),
}

but obviously, this will not work. It would be nice if one could somehow specify which bit should be the discriminator, that way this could benefit from some abstraction. Currently, I just have to have a single struct with matches for the bit on every function.
This is certainly a very niche niche (ha get it), but I'd love to see it implemented.

@oli-obk successfully convinced me that an approach using const generics, https://github.com/rust-lang/rust/pull/103724 , is better than the attribute approach. And he proved that it's feasible to implement. I'm closing this in favor of https://github.com/rust-lang/rust/pull/103724 .


Migrate data to pyproject.toml

This PR removes setup.py and setup.cfg in favor using a fully PEP 517-compliant build. The linter configs have also moved to pyproject.toml where possible. flake8 does not (and has no plans to) support pyproject.toml, and since it's the only relevant tool doing that I migrated its configuration to a flake8-specific file.

If we feel particularly strongly about unifying all config files we could migrate to using flakeheaven, which adds pyproject.toml support to flake8, but I don't think it's worthwhile. flake8 is super widely used and I have confidence that the community will find a way to maintain it. I have less confidence in flakeheaven.


MSID: 88051 Version: 1 DOI: 2<IP_ADDRESS>2832

"msas": "Developmental Biology, Neuroscience"
"msid": "88051"
"preprintDoi": "10.1101/2<IP_ADDRESS>2832"
"Reviewed Preprint posted": "2023-07-24"
"Sent for peer review": "2023-04-19"
"Posted to bioRxiv": "2023-04-23" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>2832v6/")
[PLACE PDF URL HERE WHEN AVAILABLE] See step 7
Step 1. Inform bioRxiv
Who can help: @QueenKraken, @nlisgo, @scottaubrey

[x] Manuscript is in data hub index (https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v1/by-publisher/elife/get-by-manuscript-id?manuscript_id=88051)

Step 2. Create preview of manuscript
Who can help: @fred-atherden, @nlisgo, @scottaubrey

[ ] Manuscript is available for preview (https://prod--epp.elifesciences.org/preview/88051/v1)

[ ] Trigger import for staging: https://prod--epp.elifesciences.org/import
[ ] Sync data folder with s3://prod-elife-epp-data/data
[ ] Trigger import for staging: https://staging--epp.elifesciences.org/import
[ ] Sync data folder with s3://staging-elife-epp-data/data
[ ] Pull request created to enhanced-preprint-data
[ ] Post link to pull request below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-manuscript
Step 3: Awaiting public reviews and QC
Who can help: Production team

[ ] QC passed or QC not needed

Who can help: Editorial team

[x] Public reviews available on sciety (https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>2832)
[x] Manuscript and editor details at the top of this issue (Supplied by Editorial team)
[ ] Reviews returned by EPP - https://prod--epp.elifesciences.org/api/reviewed-preprints/88051/v1/reviews

Example
"msas": "Genetics and Genomics", "Neuroscience"
"msid": "84628"
"version": "1"
"preprintDoi": "10.1101/2<IP_ADDRESS>4241"
"articleType": "Reviewed Preprint"
"status": "Published from the original preprint after peer review and assessment by eLife."

"Reviewed Preprint posted": "2023-01-02"
"Sent for peer review": "2022-10-28"
"Posted to bioRxiv": "2022-11-21" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>4241v1")

Editors:
Reviewing Editor
Michael B Eisen
University of California, Berkeley, United States
Senior Editor
Michael B Eisen
University of California, Berkeley, United States

Step 4: Modify manuscripts.json (no PDF)

[ ] Reviewed preprint is published to EPP (https://elifesciences.org/reviewed-preprints/88051)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[ ] Request that a doi be registered

[ ] Post link to #enhanced-preprint comment below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]

Instructions to modify manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/publish-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/334/files
Once the pull request is merged in it should be available a few minutes later.

Request that a doi
Post the following in #enhanced-preprint:
@Fred can you register a doi for https://elifesciences.org/reviewed-preprints/88051

Step 5: Awaiting search reindex

[ ] Reviewed preprint is avaliable on journal homepage (https://elifesciences.org)

The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.

Additional info
If needed, the jenkins pipeline to reindex search can be triggered sooner.
https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 6: Published! Request PDF generation

[ ] Post the link to the PDF url at the top of the issue

[ ] Post link to #enhanced-preprint comment below

#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]
Post the following to the #enhanced-preprint on slack:
@Ryan Dix-Peek please can you generate a PDF for https://elifesciences.org/reviewed-preprints/88051

Step 7: Introduce PDF to data folder and git repo

[ ] PDF is avaliable at https://github.com/elifesciences/enhanced-preprints-data/raw/master/data/88051/v1/88051-v1.pdf

Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-pdf
Step 8: Add PDF url to manuscripts.json

[ ] Reviewed preprint PDF is available for download (https://prod--epp.elifesciences.org/reviewed-preprints/88051)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[PLACE LINK TO PULL REQUEST HERE]

Instructions to add PDF url to manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/add-pdf-url-to-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/397/files
Once the pull request is merged in it should be available a few minutes later.

Step 9: Done!

[ ] Kettle is on!

We have version 5 loaded instead of version 6.

Correct version being imported in https://github.com/elifesciences/enhanced-preprints-data/pull/142

Authors have a problem with the response - hold until this is resolved

@fred-atherden "Posted to bioRxiv": "2023-04-23 in this ticket is incorrect, v6 was posted 3rd April 2023. Should this be updated?

@fred-atherden "Posted to bioRxiv": "2023-04-23 in this ticket is incorrect, v6 was posted 3rd April 2023. Should this be updated?

Good spot Naushin! Yes, please update

Supplementary figures listed but not present (provided as supplementary file in biorxiv)


ApplicationSet controller v0.2.0 Release Checklist

Release Checklist
First, follow the instructions on the release process RTD docs page.
Once complete, this is a set of checks to perform once you have a commit, tags, release, docs, and container image.
Once you have completed a release, the following should be true:

[x] A release-(numbered version) branch exists in argoproj-labs/applicationset

example: 'release-0.1.0'
[x] The release branch name should NOT contain the letter v (e.g. BAD: release-v0.1.0, not like this!)
[x] Confirm that, within the GitHub web UI, the branch says This branch is 1 commit ahead of master. , with that one commit being the release commit described below.

A release commit exists as the most recent commit of the release-(version) branch:

[x]  A commit with the message of Release (version)

Example: Release v0.1.0
The version string SHOULD contain the letter v, as above.

The commit should contain changes to:

[x] manifests/install.yaml
[x] manifests/install-with-argo-cd.yaml
[x] manifests/base/kustomization.yaml
[x] .github/workflows/ci-build.yaml
[x] docs/Geting-Started.md
[x] hack/verify-argo-cd-versions.sh
[x] manifests/namespace-install-with-argo-cd/kustomization.yaml

[x] A v(version) tag exists in the argoproj-labs/applicationset repo

Example: v0.1.0
[x] Ensure it matches the release commit above

[x] A stable tag exists, and points to the same release commit as above.

[x] Ensure that a GitHub v(version) GitHub Release exists, pointing to the v(version) tag.

Tag must have v prefix, eg v0.1.0

[x] Ensure that container image exists on quay.io with name 'argoproj/argocd-applicationset'

[x] Appears here: https://quay.io/repository/argoproj/argocd-applicationset
[x] With tag v(version), eg v0.1.0

[x] Tag must have v prefix, eg v0.1.0

[x] Verify that the tag update time references today's date
[x] Security scan should be green.

On the release-(version) branch:

[x] Ensure the VERSION string matches the expected version

[x] The VERSION string should NOT begin with a v, (eg BAD: v0.1.0)

[x] Ensure that kustomize.yaml under manifests/namespace-install-with-argo-cd/kustomization.yaml points to the desired Argo CD version.
[x] #348
[x] Ensure that install.yaml and install-with-argo-cd.yaml under manifests/ points to the desired Argo CD version.

Master branch checklist

Ensure that a PR is opened on the master branch that:

[x] Increments the VERSION file (eg 0.1.0 to 0.2.0)
[x] Verify VERSION file does not contain the letter v as a prefix to the versio number

Doc checklist

[x] Ensure that https://readthedocs.org/projects/argocd-applicationset/versions/ points to the correct commit (commit that is at the HEAD of the release branch), for the stable and v(version) versions.
[x] Ensure that https://argocd-applicationset.readthedocs.io/ points to the new version, and contains the correct content

Note: this may require a manually triggered build at rtd.io. See release process for details.

[x] Ensure that the Getting Start page at rtd.io includes references to kubectl apply which points to the correct applicationset controller version

On Stable
On the version-specific page: https://argocd-applicationset.readthedocs.io/en/(version)/Getting-Started/

Example: https://argocd-applicationset.readthedocs.io/en/v0.1.0/Getting-Started/

Changelog and release notes
In the GitHub Releases tag:

[x] Ensure that the v(version string) release contains the features/change log for the particular version. This should be roughly the same content as goes into the CHANGELOG.md file.

On the release-(version) branch:

[x] Ensure that CHANGELOG.md includes the new version information

On the master branch:

[x] Ensure that CHANGELOG.md includes the new version information

Live image testing

[x] Apply install.yaml on a cluster, and confirm that it installs the correct image version

[x] Confirm that all the pods start as expected.
[x] Confirm that the pod logs contain no errors
[x] Run ApplicationSet E2E tests against ApplicationSet controller installed via this method
[x] Confirm that the pod logs contain no errors after runnings the tests

[x] Apply install-with-argo-cd.yaml on a cluster, and confirm that it installs the correct image version

[x] Confirm that all the pods start as expected.
[x] Confirm that the pod logs contain no errors
[x] Run ApplicationSet E2E tests against ApplicationSet controller installed via this method
[x] Confirm that the pod logs contain no errors after runnings the tests

Communications

[x] Publish blog post (if applicable)
[x] Post to Slack

Released! :tada: :tada: :tada:


Growing the Project Library on the Website

Viewing the site on the website, not all the projects in this repository are displayed.
This could be hindering to beneficiaries of the project that don't have access to the repository.
Adding all projects, or as many as possible, to reflect on the website will do justice to this.

Go ahead


Rename extension objects

Hi Waldo,
It's a big help to rename project files in a consistent manner, but I am missing the same functionality for tableextension and pageextension files.
Could you please update the rename function to include these object types?
Kind regards,
Brian Christensen

Hi  Brian,
What doesn't work?  It should rename table- and pageextensions as well.  There are even settings to set the pattern: CRS.ExtensionObjectNamePattern

@BrianThorChristensen ,
no problem at all - glad it works ;-)


[Regex] add replace_by function

Pull Request Test Coverage Report for Build 624264342

11 of 11 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.0001%) to 99.961%

Totals

Change from base Build 613768139:
0.0001%

Covered Lines:
2531

Relevant Lines:
2532

💛  - Coveralls


Traceroute service type broken

Hi,
MCA relies on the "service type" concept to organise the test meshes and currently there are service types defined such as pinger, traceroute, latency, bandwidth. This requires a certain mapping to take place to understand which nodes can participate in which type of tests, which I guess has been usually done by extracting this information from SLS. Below is a screenshot of hostgroup config showing service type field.

I'm not sure if this is configuration issue of our MCA instance or a potential bug, but it looks like that recently this mapping has broken as most of the hosts that are synced from global SLS lookup no longer declare to be able to run traceroute, thus effectively we don't have a way to configure traceroute testing for them (as they don't show up in the list of hosts for traceroute service type). It could be also that something has changed in SLS.
Below are screenshots of two examples, perfsonar01-iep-grid.saske.sk host which comes from our custom local SLS - showing traceroute under services

and atlas*.bu.edu which uses global SLS and doesn't show traceroute under supported services.

@marian-babik
It's been a while since I troubleshoot-ed MCA, so my memory is a bit rusty.. but I will do my best.
So I can confirm that, there is no traceroute service listed for perfsonar-cms2.itns.purdue.edu https://meshconfig.grid.iu.edu/#!/hosts/58f74b23f5139f0021ac2a04 which causes meshconfig publisher to not list this host in the generated /us-cms meshconfig. I've roughly looked and it looks like none of the hosts that information comes from SLS are listed in meshconfig, is that what you are seeing also?
For perfsonar-cms2.itns.purdue.edu, the host page shows that the information comes from this SLS instance So, I queried all services listed under this host and I see following services
    "service-type": [      "bwctl"    ],
    "service-type": [      "mp-bwctl"    ],
    "service-type": [      "mp-owamp"    ],
    "service-type": [      "ma"    ],
    "service-type": [      "pscheduler"    ],

which isn't the exact match as listed under MCA's service endpoint, so I might be missing something, but I wonder if SLS used to show service-type: ["traceroute"] in the past, but not anymore?
@apertome Do you know of any changes (within the last few month) on how registration service registers traceroute service? I am not even sure if there ever was such a thing as "traceroute service(server)".. so maybe we can just add "traceroute" service on all hosts?

I think putting a "traceroute" service on all hosts could work.  We want to be able to initiate traceroutes on any hosts running bwctl or pscheduler so maybe add it to any host with either of those services?   This bug is actually high-priority in that we are no longer getting traceroute measurements for hosts coming in via SLS.

@ShawnMcKee The changes to the traceroute registration in the LS happened around a year ago, so I don't understand why this would just now manifest itself. Are you sure nothing has changed in your instance?
This is definitely something I intend to fix before the 4.1 beta release, but I don't see doing a new release between now and then -- the entire deployment model is changing, so it wouldn't make sense to figure out how to do a new release to publish this one fix.
However, I will review the code and see if I can see an obvious/easy fix. If so, I may be able to provide a patch.

Additional context from Andy:

I don’t remember when we last registered a separate traceroute service. I
think it must pre-date 3.5.1 because I can’t find an example of the
lsregistrationdaemon.conf file that contains it. We should not be
registering a “traceroute” service because there is no such thing. If a
host record exists, you should be allowed to setup a traceroute test in the
GUI. Same for ping. I know at one time we did have records for those, but
they were dropped because they did not give useful information.
Generally speaking I don’t really like the GUI limiting the user to being
able to setup certain types of tests because its not in the LS. The LS
should be used as a guideline to help you set things up, but making it a
strict requirement kills usability IMO. This is especially true in this
case because a traceroute service is non-sensical, but I believe holds true
for other types of tests where an admin may know more than the LS.
You might want to double-check the GUI isn't looking for BWCTL in order to
setup throughput tests because that is not accurate either since a
pScheduler host without BWCTL works just as well.

@apertome I think it could have been happening for a while and we didn't notice.  Most hosts are inserted from the OIM/GOCDB and they don't show the problem.   Many hosts took a while to upgrade (we still have some 3.x hosts!).     It would be good if there was a simple patch you add to allow us to include those hosts in traceroute tests.   Otherwise we are missing any topology context for the measurements we are making with those hosts.

We just found out that global SLS record likely has priority over OIM/GOCDB record in MCA, so all hosts registered in global SLS will be missing traceroute tests (traceroute test won't be added into auto-mesh json since the node doesn't support traceroute service). So the impact is larger then we initially thought, it could impact all/most of the OSG hosts and probably some GOCDB hosts as well.

I still have not had a chance to look at this, and can't get to it this week. Furthermore, I'll be out of the country the next two weeks for the perfSONAR developer meeting and other travels, so I would not expect any movement on this in the next couple weeks.
The way the MCA was designed, it considers the LS as the ultimate source of truth, which doesn't always play out well in practice (like in this situation).
We are planning on reducing reliance on the LS in general in the future; this is a great example of why we want to do that.
I'm still hoping to be able to come up with a simple patch for this issue, but not sure when I will be able to look at it.

@apertome I believe it should be very simple to have traceroute service added to all LS ingested sites. Since you are busy, I will take a look and send a PR.

That's very kind, @soichih , I'm not saying I think that will be complicated, but part of the issue is that I have not entirely figured out/tested the build/release/upgrade process for this yet. As well as figuring out how to merge just this change, without the many others that have been made. If you create a PR I can look at that when I have time, and would also hopefully work as a patch for Shawn/Marian in the short term ... if you want to do that, feel free. If not, I will look at it when I have the time. Either way, thanks for your help!

Thanks @soichih !
Marian and I can put any PR you produce in place (temporarily) in meshconfig.grid.iu.edu just to fix the current issue.   Longer term we can work with @apertome to get the official version deployed when it is ready.   Thanks for your help!
Shawn

@apertome I've submitted a PR. Please take a look.
@ShawnMcKee
If Michael is going to create a new docker container, then you can just docker pull it on meshconfig.grid.iu.edu, or you can manually apply the patch - since it really involves a single line change

We are planning on reducing reliance on the LS in general in the future;

Does this mean LS would be deprecated eventually? MCA was designed with assumption that information on LS would improve as time goes by. How can users reliably find hosts that they can initiate tests to? Maybe a list from the directory?
By the way, on the directory page, I see "Traceroute Daemons". What are they? I also found "traceroute" service listed in LS
http://ps-west.es.net:8090/lookup/records?service-host=lookup/host/a8080e52-aa25-4542-914a-bea206d5c244
http://ps-west.es.net:8090/lookup/records?service-host=lookup/host/79e65307-83e5-474a-8115-dd6312312443
http://ps-east.es.net:8090/lookup/records?service-host=lookup/host/d8e0d463-d7e6-466b-a780-8285802cbde6

Thanks Soichi,
No, I won't be doing an immediate release; I'd recommend if Shawn wants to patch his instance that he do it manually.
Re: traceroute daemons, I don't know. Maybe Andy knows? @arlake228

No, the LS is not going away, but there are quite a few deployments that don't use the LS at all, and right now, it's difficult to schedule tests to hosts that are NOT in the LS.
This specific issue is actually a good example of the kinds of LS dependencies that we want to avoid.
I reviewed your PR, but it is more complicated than you indicated, and conflicts with some changes I've made; I'll need to test and merge it carefully.


Ports are still forwarded when process is killed

Testing #180696
I'm not clear on what unforwarding a port means so this maybe expected, but we do detect that the process is no longer running but it still appears in the list:

@karrtikr can you please provide the steps you used to get here? If hybrid port forwarding is properly set (setting "remote.autoForwardPortsSource": "hybrid" + reload) then yes, the port should be unforwarded and no longer appear in the list.

import socket

# Define the host and port to listen on
host = 'localhost'
port = 3000

# Create a socket object
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# Bind the socket to the host and port
s.bind((host, port))

# Listen for incoming connections
s.listen(5)
print(f"[*] Listening on https://{host}:{port}")

# Accept incoming connections
while True:
    conn, addr = s.accept()
    print(f"[*] Connection from {addr[0]}:{addr[1]}")

    # Send a message to the connected client
    message = f"https://localhost:{port}"
    conn.sendall(message.encode())

    print(f"[*] Sent: {message}")

    # Close the connection
    conn.close()

Run the above Python script in integrated terminal when using Remote-SSH, it should start appearing in the list along with process ID under "Running process" column. Kill process using kill <pid> in a separate terminal.

If hybrid port forwarding is properly set (setting "remote.autoForwardPortsSource": "hybrid" + reload)

Confirming I made sure this was done as well.

Thank you for the steps!

When verifying, please test that the port is unforwarded with both "remote.autoForwardPortsSource": "process" and "remote.autoForwardPortsSource": "hybrid" are used.

The port is not unforwarded when "remote.autoForwardPortsSource": "hybrid" is used. It is however unforwarded when "remote.autoForwardPortsSource": "process" is used. I'm testing with the vscode-remote-try-node repo and the default launch config.

The fix works for me though, with the original Python script I provided.

The port is not unforwarded when "remote.autoForwardPortsSource": "hybrid" is used. It is however unforwarded when "remote.autoForwardPortsSource": "process" is used. I'm testing with the vscode-remote-try-node repo and the default launch config.

I'm not able to reproduce this. It's possible for what you describe to occur if the process is terminated before we have a chance notice that it's running. If you see this again can you please set the log level to debug, repro, and share logs from Remote Extension Host and Window?
Closing again for testing.

I am unable to reproduce the issue with vscode-remote-try-node on Codespaces or Dev Containers, though it did take a bit longer for the port to close on Codespaces. Marking as verified.


Create uchicago.txt

https://cs.uchicago.edu/

@Celiajm I am sorry, the domain uchicago.edu is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Pack at https://education.github.com/discount_requests/application. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


fix region offset handling

The specification states that the region offset given in the region info should
be used as the "offset" when mmap()ing the region from the client side. However,
the library instead implemented a fixed offset scheme  similar to that of vfio -
and no clients actually set up the file like that.
Instead, let servers define their own offsets, and pass them through to clients
as is. It's up to the server to decide how its backing file or files is
organized.
Signed-off-by: John Levon<EMAIL_ADDRESS>

Fixes #478


Bump quic-go from v0.33.0 to v0.37.4

What does this PR do?

You are not targeting the right branch, could you rebase your branch onto v2.10 branch?

Is it a problem for you if I close your PR in favor of my PR #10078?
It is just easier for me.

Sure, go ahead, i had similar prepared first: https://github.com/traefik/traefik/compare/master...stefanb:traefik:go-1.21
...but decided to break it down into two smaller PRs after reading your contribution guidelines :)

Thank you anyway :heart:


Add prometheus metrics

This PR is for issue #378 and adds the beginning scaffolding to export metrics for Prometheus.  Ultimately we will fully migrate over to Prometheus instead of using the current Statsd metrics, but in the meantime we will need to support both.
The baseplate spec specifies that an active_requests metrics must be (ref: spec) emitted so this PR adds that as the first custom metric.
The /metrics endpoint has been added to the golang baseplate code via the baseplate-cookiecutter repo in this PR.
The next work that will be done in a different PR is to add the scaffolding that allows applications to generate custom metrics for their own purposes.

Closing this to add active_request to the per transport server middleware instead.


Implementation dark mode UI support

Contact Details
<EMAIL_ADDRESS>What happened?

Relevant log output
No response
Code of Conduct

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

@maityamit assign this to me.


07/06/2018 00:57 : Create Pull Request for branch master -> prTesting1_2018070600

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestRef1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


fix: Correct comment about default TypeName

The default TypeName was changed to '_doc' in #298
What issue does this PR address?
Correcting a documentation error.
Does this PR introduce a breaking change?
No. It does not affect the running code.
Please check if the PR fulfills these requirements

[X] The commit follows our guidelines
[X] Unit Tests for the changes have been added (for bug fixes / features)

Other information:
None

Thanks!

No problem :)


Extract_Uris_From_Tsv -> Search by Column causes too many KeyErrors

There needs to be a way of gathering DRS uris without sorting by collumn, requesting metadata from martha and then removing duplicate uris from the list to avoid this common KeyError and make the tool easier to use for the end user.

This has been addressed in previous commits, duplicate URI error is evident in https://github.com/anvilproject/drs_downloader/blob/main/drs_downloader/cli.py#L344, there is also a flag for specifying individual URIS in the cli


Loosen dependecy on rest-client

We're using the apiary client to automatically publish documentation in our Rails app as part of each CI build in stating and production environments. We're using the library code directly as part of a rake task and not using the clie.
Some dependency in our app happens to use a version of rest-client that is < 1.8. Is there a specific feature in 1.8+ that is required or did this just happen to be the version of rest-client available when authoring the first time?

There have been numerous security vulnerabilities in versions of rest-client below 1.8 which is why we've required 1.8 or newer.
If you notice the pull request check for "Hakiri" is now red due to security warnings. Perhaps it would be a good idea to upgrade the other library to be compatible with newer versions of rest-client, especially if you are using this in a production service. There is various security advisories against these older versions of rest-client. You should be able to use isitvulnerable to pin-point the exact vulnerabilities against the version you are using.

We'll update our deps! Thanks.


[EVENT REQUEST] codeunit 4810 IntrastatReportManagement – OnGetIntrastatBaseCountryCodeOnElseCase | OnGetOriginalCurrencyOnElseCase

Describe the request
We necessarily need a possibility handle item ledger entries having a different "Document Type" within the Intrastat Core extension. Therefore we would need two IntegrationEvents in the codeunit 4810 IntrastatReportManagement, to receive the Intrastat Base Country Code as well as the Original Currency for Item Ledger Entries differently:
procedure GetIntrastatBaseCountryCode(ItemLedgEntry: Record "Item Ledger Entry") CountryCode: Code[10]
    procedure GetIntrastatBaseCountryCode(ItemLedgEntry: Record "Item Ledger Entry") CountryCode: Code[10]
    var
        [...]
    begin
        [...]
        case ItemLedgEntry."Document Type" of
            [...]
            ItemLedgEntry."Document Type"::"Purchase Return Shipment":
                if ReturnShptHeader.Get(ItemLedgEntry."Document No.") then
                    case IntrastatReportSetup."Shipments Based On" of
                        IntrastatReportSetup."Shipments Based On"::"Ship-to Country":
                            CountryCode := ReturnShptHeader."Buy-from Country/Region Code";
                        IntrastatReportSetup."Shipments Based On"::"Sell-to Country":
                            CountryCode := ReturnShptHeader."Buy-from Country/Region Code";
                        IntrastatReportSetup."Shipments Based On"::"Bill-to Country":
                            CountryCode := ReturnShptHeader."Pay-to Country/Region Code";
                    end;
            //> New
            else
                OnGetIntrastatBaseCountryCodeOnElseCase(ItemLedgEntry, CountryCode );
            //< New
        end;
    end;

    //> New
    [IntegrationEvent(false, false)]
    local procedure OnGetIntrastatBaseCountryCodeOnElseCase(ItemLedgEntry: Record "Item Ledger Entry"; var CountryCode: Code[10])
    begin
    end;
    //< New

procedure GetOriginalCurrency(ItemLedgerEntry: Record "Item Ledger Entry") CurrencyCode: Code[10]
    procedure GetOriginalCurrency(ItemLedgerEntry: Record "Item Ledger Entry") CurrencyCode: Code[10]
    var
        [...]
    begin
        case ItemLedgerEntry."Document Type" of
            [...]
            ItemLedgerEntry."Document Type"::"Service Credit Memo":
                if ServiceCrMemoHeader.Get(ItemLedgerEntry."Document No.") then
                    CurrencyCode := ServiceCrMemoHeader."Currency Code";
            else
                //> New
                //CurrencyCode := '';
                OnGetOriginalCurrencyOnElseCase(ItemLedgEntry, CurrencyCode);
            //< New
        end;
    end;

    //> New
    [IntegrationEvent(false, false)]
    local procedure OnGetOriginalCurrencyOnElseCase(ItemLedgEntry: Record "Item Ledger Entry"; var CurrencyCode: Code[10])
    begin
    end;
    //< New

Additional context
we are having own datastructures, which are also creating item ledger entries, which have to be considered by the intrastat reporting. Therefore we have to handle item ledger entries with a different "Document Type".
Internal work item: AB#501789

Availability update: We will publish a fix for this issue in the next update for release 24.
Build ID to track: 22505.


Is it possible to change the measurement unit from mm to centimeters?

Prerequisites

[x] Are you running the latest version?
[x] Are you reporting to the correct repository?
[x] Did you perform a cursory search?

For more information, see the CONTRIBUTING guide.
Description
[Description of the bug or feature]
Steps to Reproduce

Is it possible to change the measurement unit from mm to centimeters maybe with a new parameter?
Expected behavior: [What you expected to happen]
I expect to have the possibility to select the unit meassure

Actual behavior: [What actually happened]
The unit measure is taken from a string 'mm' or 'px' in the lenght.js tool

@JesusParra, not currently. I'd be open to adding this as a configuration option, if done in a smart way, in our vNext branch. If you want to discuss implementation details, we can discuss?

It's ok, if I have some dubts or if I can to solve it I'll let you know

This wasn't a formal request to add this behavior and I think the heart of the question was answered. If someone would like to see this as an enhancement, please feel free to create a new issue.


Fixing for locale es-do #3629

The es and es-do locales had the same issue with date parsing of format D-MMM-YYYY . Both locales had code to test for /-MMM-/, so i added the fix for es, to es-do as well. Also added the appropriate test

So this is the same as https://github.com/moment/moment/pull/3894 but for es-do? Can you merge them in one PR please?

Will do!

Woops, I merged #3894  a bit too fast. Never mind, I'll merge this one too @kkopanidis

Merged in c87087876e9fb5ffa357b55aad3d5ac1377ea828


Update Clauses page

Note all that's missing (if any)

Missing clauses:
ORDER BY
SKIP
LIMIT
DETACH DELETE
Multi-tenancy Cypher queries -> https://memgraph.com/docs/configuration/multi-tenancy#cypher-queries-for-multi-tenancy + USE DATABASE
Configuration, transaction, listing and other commands
Indexing queries (CREATE/SHOW/DROP)
USING INDEX
ANALYZE GRAPH
Constraints queries
Admin/auth queries
Replication queries
(probably something else is missing)
If we want to have a page that has all Cypher clauses listed, then all of them should be there. Otherwise, they are scattered around docs. They should be categorized and all listed.

I removed this from Best practices for querying because I think it can be done on the docs side and that our help is not required here (@kgolubic).

Not sure if all has to be documented under clauses, check https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf


Add nodeIdLabel config and optimisations

With this PR, we add a node label the value of which uniquely identifies each node. This is necessary to have a common notion of what identifies a node. We also add optimisations for node selectors that include this label. These optimisations will be important for future scheduler work that require efficiently targeting a specific node for scheduling a pod.

Codecov Report
Base: 47.57% // Head: 47.55% // Decreases project coverage by -0.03% :warning:

Coverage data is based on head (38993e4) compared to base (db473c0).
Patch coverage: 44.70% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2057      +/-   ##
==========================================
- Coverage   47.57%   47.55%   -0.03%
==========================================
  Files         212      212
  Lines       28828    28887      +59
==========================================
+ Hits        13715    13736      +21
- Misses      14123    14156      +33
- Partials      990      995       +5

Flag
Coverage Δ

airflow-operator
89.13% <ø> (ø)

armada-server
46.50% <44.70%> (-0.03%)
:arrow_down:

python-client
93.83% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

internal/armada/server/lease.go
10.77% <0.00%> (-0.16%)
:arrow_down:

internal/scheduler/nodedb.go
63.39% <42.22%> (-3.61%)
:arrow_down:

internal/scheduler/api.go
69.40% <64.70%> (-2.03%)
:arrow_down:

internal/scheduler/legacyscheduler.go
70.32% <70.00%> (-0.01%)
:arrow_down:

internal/scheduler/scheduling_algo.go
69.56% <100.00%> (+0.13%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


parsing error - unexpected '?'

Avec la release 1.1.4, pour parser un fichier de la release 2.2.0 de https://forge.puppetlabs.com/puppetlabs/apt, j'ai l'erreur :
ERROR: (allnodes) ./modules/apt/manifests/init.pp:80:51:
unexpected '?'
expecting '}' or Statement at # ./modules/it/manifests/baseconfig/aptcfg.pp:3:13
Cela fait référence au code suivant :
$sources_list_content = $_purge['sources.list'] ? {
true    => "# Repos managed by puppet.\n",
default => undef,
}

Would you mind testing with the latest master  (the parser has been changed to use megaparsec) ? You can easily do this using stack.

Well actually, we have a complicated build setup, and at the moment our tools can only build the latest release from https://github.com/bartavelle/language-puppet/releases
I will try to build the latest master on another system, and let you know if I succeed.

In case it helps I have a docker that bundles the tool at the latest master (it also inclues  a check_lint command):
docker pull pierrer/puppetresources:v1.1.4-k

OK, I was confused by the way our build systems works, the resulting package is versioned 1.1.4 but it is actually compiled from the master branch.
This is up to date to the latest commit 3e916fcd3db6e81bd83eb2e6b9b2173ef91c306e
so the bug is present in current code.

The problem is that selectors only work with variables currently. I will add support for lookups.

It turns out it should be more general : https://docs.puppetlabs.com/puppet/latest/reference/lang_conditional.html#control-expressions-1
But I will only fix this for lookups for now.

See 7bb0a8d52b5a19bb7daa8d0474c5f479077b2489

Fixed confirmed for the case I encountered. You can close the bug if you want, or keep it open to track the more general case.


Correctly handle or reject duplicate feature index IDs in 'predict' utility

When parsing a feature index file, the 'predict' utility does not detect duplicate IDs. Failing to detect duplicate IDs allows an invalid feature index file to be loaded, which can eventually lead to issues such as segmentation faults (see issue https://github.com/amznlabs/amazon-dsstne/issues/62 for an example).
Although this is related to issue https://github.com/amznlabs/amazon-dsstne/issues/64 which seeks to resolve the issue at the time that the data is generated, fixing the issue here may prevent it from coming up in different ways.

I've started working on this issue in my personal fork of DSSTNE, and realised that this change applies to both the 'generateNetCDF' and 'predict' utilities. I've updated the title and description for this issue accordingly.

Closing this issue now that the change has been merged.


If you reload the updates page in settings while updating a plugin, it won't show as updating when you come back to it.

Prerequisites

[X] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
If you start updating a plugin (or plugins), then close the settings tab and re-open it or reload it, the plugin(s) won't show as updating and if you restart the update(s) the counter in the bottom right will say a bigger number than the amount of updates (ex. 2/1 updates)
Steps to Reproduce

Start updating some plugins
Close the settings page (or even just the updates section of the page)
Come back to the updates page in the settings

Expected behavior: Plugin(s) are not showing as updating
Actual behavior: They are still updating in the background
Reproduces how often: 100% on my machine (Windows 10 (latest) and the latest stable Atom (1.27.1))
Versions
Atom    : 1.27.1
Electron: 1.7.15
Chrome  : 58.0.3029.110
Node    : 7.9.0
Windows 10 (1803 build 17134.81)
Additional Information
This has happened on every version of Atom I've ever used. And while I'm not sure, I believe that if you manually start the update for all your plugins from the settings page, "Update All" is still clickable which could be another bug. (I don't have any plugin updates to test that bug right now though). I don't report bugs often so sorry if I formatted this wrong or something.

Thanks for taking the time to contribute!
We noticed that this is a duplicate of atom/settings-view#901. You may want to subscribe there for updates.
Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


Interval Type Missing

Precheck
Been searching online, able to specify :interval for the type in the migration, and it seems an Ecto.Interval type used to exist, but it no longer seems to exist.
Environment

Elixir version:  1.3.0
Database and version:  PostgreSQL 9.4
Ecto version:  2.0.1
Database adapter and version:  Phoenix_ecto 3.0.0,  postgrex 0.11.2
Operating system:  Win10 and Ubuntu 16.04

Current behavior
# Migration:
  create table(:testing) do
    add :renewal_period, :interval
  end

# Schema
  schema "testing" do
    field :renewal_period, xxx
  end

In place of xxx have tried Ecto.DateTime (does not work since Postgres Interval required %{"months", "days", "seconds"}), Postgrex.Interval (error, unknown Ecto type), Ecto.Interval (error, does not exist), :interval (error, unknown Ecto type), and others all to no avail.
Expected behavior
Assuming Ecto.Interval existed like it used to according to google then this should work:
# Schema
  schema "testing" do
    field :renewal_period, Ecto.Interval
  end

@OvermindDL1 you can define your own interval type. Look at Ecto docs about defining your own types. There are no plans for supporting Ecto.Interval directly in Ecto for now.

Already have for now, just curious as to if I were missing something since Intervals seem that they used to be implemented but are not now and not found the reason for removal yet.  :-)

@OvermindDL1 have you posted your interval custom ecto type online anywhere?

have you posted your interval custom ecto type online anywhere?

@axelson Nope, but I could, it is a simple single-file implementation with no docs or anything (mostly from the original Ecto version but with more additions).  I just stripped it out of my main project and put it into its own little library at:  https://hex.pm/packages/ecto_interval
Just use the type of EctoInterval.  PR's welcome as it is entirely untested since pulled out (but simple enough that there should not be any issues anyway).

Thanks! I'll check it out!


[FIX] return a Redux thunk for the INIT action

Before, Redux was throwing an error saying that a plain object was not being returned from the init() function which was breaking hyperterm.

I was creating the same PR with the same solution.
Another solution is to put directly in the index file :
rpc.emit('init');

but I think it's a good thing to dispatch a redux 'INIT' action (for plugins especially)

Sorry about the delay - do you mind rebasing @TooTallNate?

I like this solution better than what I just merged

Ok, rebased


[tracking] Remove cyclic dependencies

cargo cyclist currently shows these internal dependency cycles in our  Cargo.lock, which prevents us from publishing on crates.io. These need to be fixed:

[x] sp-api (2.0.0): Cycle through sp-api(2.0.0) -> sp-api-proc-macro(2.0.0) -> sp-api(2.0.0)
[x] sc-application-crypto (2.0.0): Cycle through sc-application-crypto(2.0.0) -> substrate-test-runtime-client(2.0.0) -> substrate-test-runtime(2.0.0) -> pallet-babe(2.0.0) -> pallet-session(2.0.0) -> sc-application-crypto(2.0.0)
[x] sc-block-builder (2.0.0): Cycle through sc-block-builder(2.0.0) -> sp-api(2.0.0) -> sp-runtime(2.0.0) -> sc-application-crypto(2.0.0) -> substrate-test-runtime-client(2.0.0) -> sc-block-builder(2.0.0)
[x] sp-api (2.0.0): Cycle through sp-api(2.0.0) -> sp-runtime(2.0.0) -> sc-application-crypto(2.0.0) -> substrate-test-runtime-client(2.0.0) -> sc-client(2.0.0) -> sc-client-db(2.0.0) -> sp-blockchain(2.0.0) -> sp-block-builder(2.0.0) -> sp-api(2.0.0)
[x] sp-runtime (2.0.0): Cycle through sp-runtime(2.0.0) -> sc-application-crypto(2.0.0) -> sp-runtime(2.0.0)
[x] substrate-test-runtime-client (2.0.0): Cycle through substrate-test-runtime-client(2.0.0) -> sc-client(2.0.0) -> sc-client-db(2.0.0) -> sp-blockchain(2.0.0) -> sp-consensus(2.0.0) -> substrate-test-runtime-client(2.0.0)
[ ] frame-support (2.0.0): Cycle through frame-support(2.0.0) -> frame-system(2.0.0) -> frame-support(2.0.0)
[ ] node-executor (2.0.0): Cycle through node-executor(2.0.0) -> node-testing(2.0.0) -> node-executor(2.0.0)
[ ] pallet-balances (2.0.0): Cycle through pallet-balances(2.0.0) -> pallet-transaction-payment(2.0.0) -> pallet-balances(2.0.0)
[ ] sc-client (2.0.0): Cycle through sc-client(2.0.0) -> sc-executor(2.0.0) -> sc-offchain(2.0.0) -> sc-network(2.0.0) -> sc-client(2.0.0)
[ ] sc-client-api (2.0.0): Cycle through sc-client-api(2.0.0) -> sc-client-db(2.0.0) -> sc-client(2.0.0) -> sc-client-api(2.0.0)
[ ] sc-client-db (2.0.0): Cycle through sc-client-db(2.0.0) -> sc-client(2.0.0) -> sc-executor(2.0.0) -> sc-offchain(2.0.0) -> sc-client-db(2.0.0)
[ ] sc-executor (2.0.0): Cycle through sc-executor(2.0.0) -> sc-offchain(2.0.0) -> sc-network(2.0.0) -> substrate-test-client(2.0.0) -> sc-executor(2.0.0)
[ ] sp-core (2.0.0): Cycle through sp-core(2.0.0) -> sp-runtime-interface(2.0.0) -> sp-runtime-interface-test-wasm(2.0.0) -> sp-core(2.0.0)
[ ] sp-runtime-interface (2.0.0): Cycle through sp-runtime-interface(2.0.0) -> sp-runtime-interface-proc-macro(2.0.0) -> sp-runtime-interface(2.0.0)
[ ] sp-trie (2.0.0): Cycle through sp-trie(2.0.0) -> sp-core(2.0.0) -> sp-runtime-interface(2.0.0) -> sp-runtime-interface-test-wasm(2.0.0) -> sp-io(2.0.0) -> sp-state-machine(2.0.0) -> sp-trie(2.0.0)
[ ] substrate-test-runtime (2.0.0): Cycle through substrate-test-runtime(2.0.0) -> pallet-babe(2.0.0) -> substrate-test-runtime(2.0.0)

I just run cargo-cyclist several times to see how my changes are affecting the dependency list and I've noticed that this tools output is not deterministic. i.e. It 5 subsequent runs on master branch can reported 18, 16, 16, 15 and 16 cyclic dependencies

Yeah, I noticed that, too. I think it is because a) it builds an hashmap of
the keys and deps, which it reads from - so that order is non-deterministic
and then b) it stops at the first circle it finds per dependency. Which
also means it currently doesn't detect multiple cycles... but if run in a
different order, it might ...
On Tue, 10 Dec 2019, 17:38 Marek Kotewicz<EMAIL_ADDRESS>wrote:

I just run cargo-cyclist several times to see how my changes are
affecting the dependency list and I've noticed that this tools output is
not deterministic. i.e. It 5 subsequent runs on master branch can reported
18, 16, 16, 15 and 16 cyclic dependencies
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/paritytech/substrate/issues/4338?email_source=notifications&email_token=AAAJ4MCBYGRJ2KKWLCZAI7LQX7AZXA5CNFSM4JYR2FQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGP4UHA#issuecomment-564120092,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAJ4MBNWM44T5OHESK63MDQX7AZXANCNFSM4JYR2FQQ
.

--
Wichtige Mitteilung
Diese Mitteilung wurde von Parity Technologies
Deutschland GmbH kommuniziert, eine im Handelsregister des Amtsgerichtes
Charlottenburg unter HRB 190583 B registrierte Gesellschaft mit
beschränkter Haftung (GmbH). Die Geschäftsführerin der GmbH ist Frau Dr.
Jutta Steiner. Der registrierte Geschäftssitz ist Glogauer Straße 6 in
10999 Berlin, Deutschland.
Diese Mitteilung enthält Informationen welche
vertraulich sind und welche eventuell die Vertraulichkeit der
Rechtsberatung ("Anwaltsgeheimnis") berühren. Sie ist ausschließlich für
den/die vorgesehenen Empfänger bestimmt. Wenn Sie nicht der/die
beabsichtigte(n) Empfänger sind, benachrichtigen Sie bitte<EMAIL_ADDRESS><EMAIL_ADDRESS>und löschen Sie diese Nachricht sofort.
Unsere
Datenschutzrichtlinie, einschließlich die Art und den Umfang von
personenbezogenen Daten, die wir erfassen, wie wir diese Daten erfassen und
verarbeiten, an wen wir sie in Bezug auf die von uns angebotenen Dienste
weitergeben dürfen, sowie bestimmte Rechte und Optionen, die Sie in dieser
Hinsicht haben, finden Sie unter: https://www.parity.io/privacy/
https://www.parity.io/privacy/
--
This communication and any attachments are confidential.

@bkchr any idea, how to tackles these ones?

[ ] sp-core (2.0.0): Cycle through sp-core(2.0.0) -> sp-runtime-interface(2.0.0) -> sp-runtime-interface-test-wasm(2.0.0) -> sp-core(2.0.0)
[ ] sp-trie (2.0.0): Cycle through sp-trie(2.0.0) -> sp-core(2.0.0) -> sp-runtime-interface(2.0.0) -> sp-runtime-interface-test-wasm(2.0.0) -> sp-io(2.0.0) -> sp-state-machine(2.0.0) -> sp-trie(2.0.0)

The first one could be done by splitting the stuff that is used in sp-runtime-interface-test-wasm into a sub-crate of core. However, as sp-runtime-interface-test-wasm will never be published on crates.io and it is only a dev-dependency, why do we not just remove the dev-dependencies before we run cargo publish?

I am against running cargo publish against local changes. In particular, I am not a fan of removing dev-dependencies as a hack, just to be able to publish, because it almost always means you publish something that then the one pulling from crates.io can't run the tests with ... this clearly is wrong, as running the tests is kinda the first thing you should be (able to) doing if the local version of your lib doesn't behave as expected.

Who pulls stuff from crates.io to run tests with? I'm not even sure how to do this with cargo?
As always we are speaking here about a Cargo bug that should be fixed upstream and even the official "hack" for now is to prune all dev-dependencies: https://github.com/rust-lang/cargo/issues/4242#issuecomment-413250159
I'm totally against releasing stuff like sp-runtime-interface-test-wasm that will never be used by anyone, it will just clutter crates.io.

Fair enough. From the regular lib world, I am used for that being a thing, but apparently this is a non-expectation within the rust-ecosystem (sadly, though). I am still not happy with publishing on a dirty checkout, but if this is part of the automatic release, procedure, well ... whatever...
Unfortunately, right now, the Cargo.lock also clumps them together, so finding only cycles that aren't in dev-dependencies (yes, we have those, too) is a bit tricky. Will investigate.

Why not rewrite your cargo cylic to use the actual Cargo.toml files? Use cargo metadata to get all the files and build the dependency graph while ignoring dev-dependencies.

That's one option... I am investigating.

cargo metadata doesn't distinguish between dependencies and dev-dependencies... would have to read the Cargo.toml-files myself and build all the aliases and trees :( ...

Yeah, that is what I meant :D But cargo metadata gives you all Cargo.toml files. If a dependency contains a package = "bla" you take this or you take the name given for the dependency. So, it should not be that hard to parse all of this.

https://github.com/bkchr/proc-macro-crate/blob/721d5a9dbdedbfbb6d160a3e4a482226d8edb178/src/lib.rs#L125 probably not perfect, but a starting point

hoping that the current version of cycle doesn't hide them from us, the only remaining non-dev-dependency-cycle appears to be:

[ ] sp-core (2.0.0): Cycle through sp-core(2.0.0) -> sp-runtime-interface(2.0.0) -> sp-core(2.0.0)

any takers? It looks like it might not be that easy to resolve...

This must be some dev-dependency, otherwise we could not compile this, because cargo would complain about cyclic dependencies. Everything we fixed in this issue here, were only stuff that was cyclic because of some dev-dependencies. Otherwise it would not have compiled before.
And it is strictly required that sp-core includes runtime-interface to use the derive macros.

ah, you are right, it is a sp-core is a dev-dependency in runtime_interface.

If you would have moved the tests folder to the test crate of runtime interface, you would have removed this as well.


Fixes verbose print statements

Addresses #66 by fixing the highlighted errors, listed here again:
1.The verbose boolean is never specified, thus always defaults to the default of false.
2.The getWorkInfo() method specifies a str 'param' when it should reference the param variable

When you have a moment, could you review @nathanmlim?

LGTM. Merging.


If there is a scratch between words and words, how do you get rid of the scratches?

If there is a scratch between words and words, how do you get remove of the scratches? ====> OCR

No, this algorithm cannot remove such lines. You can try to use any other line detection algorithm. Not sure is there any suitable algorithm for such a task in PRLIB


support for optional attributes

This is not explicit in the documentation: does quickavro support doc and aliases attributes at record and field-level ?

If it is supported by AvroC, it should be supported, since the record and fields are handed off to the AvroC API.  Have you tried it and found something not to be working with those record and field-level attributes?

Closing due to lack of response.  Please reopen if you want to continue working through this issue!


Update requirements.txt

Added bs4 and aiohttp 🍾

o avoid errors caused by missing modules,  I included bs4 and aiohttp in requirements.txt.


chore(main): release 1.0.2

:robot: I have created a release beep boop
1.0.2 (2023-09-12)
Bug Fixes

test release (39a3e14)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/mdshack/inertiajs-table/releases/tag/v1.0.2 :sunflower:


python310Packages.appthreat-vulnerability-db: 3.0.2 -> 4.0.0

Changelog: https://github.com/AppThreat/vulnerability-db/releases/tag/v4.0.0
Description of changes

Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 202994 run on x86_64-linux 1

3 packages built:

appthreat-depscan
python310Packages.appthreat-vulnerability-db
python39Packages.appthreat-vulnerability-db


video has gray border around it in Android 6.

Hi,
It's a great library :). I recently used it to scale my video. It works perfectly in Android5. However, in android 6, my video always has a gray border.
Here's my code:

<com.yqritc.scalablevideoview.ScalableVideoView
android:id="@+id/video_view"
android:layout_width="200dp"
android:layout_height="100dp"
android:layout_centerInParent="true"
app:scalableType="centerCrop"
/>

Since my parent background is white, the gray border of the video looks ugly right now. Could you please help me with that ? Thanks. :)

@shumin0809
I checked sample project by Android 6.
but I could not see gray border.
do u see gray border when you run my sample project?


Is there any plan in releasing the full training data

Hello,
I want to ask do you have any plan in releasing the full training data?

Hi @changhaonan ,
Thanks a lot for your interest in our work!
We are currently working hard to release the complete version of the SceneFun3D dataset with detailed documentation. Stay tuned!
Best,
Alex