Representation of structs

Discussion topic about how structs are represented in Rust. Some things to work out:

Do we ever say anything about how a #[repr(rust)] struct is laid out
(and/or treated by the ABI)?
- e.g., what about different structs with same definition
- across executions of the same program?
For example, rkruppe writes that we might "want to guarantee (some subset of) newtype  unpacking and relegate #[repr(transparent)] to being the way to guarantee to other crates that a type with private fields is and will remain a newtype?"
When is interop with #[rust(C)] guaranteed and what can we say there?

I for one would like someone to talk a bit about what #[repr(C)] really means anyway. It seems to play a number of roles for us, at once defining a kind of fixed layout strategy but maybe also having other effects?
Is it worth maybe trying to tease those out into distinct repr flags (any lang changes would require an RFC, of course).
There may also be lesser variants that are useful: for example, I think it would be useful to be able to say that "the first field appears at offset 0" but say nothing about the positions or layouts of other fields within a struct.
It'd be good -- while we're thinking about this stuff -- to think about the kinds of things we might want to say but currently cannot.

The C11 spec provides some fairly detailed guidance on structure layout, which we could apply to repr(C) structs.

The C17 standard is here: http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf
The struct layout is specified in <IP_ADDRESS> Structure and union specifiers (starting at paragraph 3). Ignoring bitfields and other things that do not apply to Rust, things that might be relevant are:

A structure or union shall not contain a member with incomplete or function type (hence, a structure shall not contain an instance of itself, but may contain a pointer to an instance of itself), except that the last member of a structure with more than one named member may have incomplete array type;  such a structure (and any union containing, possibly recursively, a member that is such a structure) shall not be a member of a structure or an element of an array.

As discussed in 6.2.5, a structure is a type consisting of a sequence of members, whose storage is allocated in an ordered sequence.

Within a structure object, the non-bit-field members and the units in which bit-fields reside have
addresses that increase in the order in which they are declared. A pointer to a structure object,
suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in
which it resides), and vice versa. There may be unnamed padding within a structure object, but not
at its beginning.

There may be unnamed padding at the end of a structure or union.

As a special case, the last element of a structure with more than one named member may have an
incomplete array type; this is called a flexible array member. In most situations, the flexible array
member is ignored. In particular, the size of the structure is as if the flexible array member were
omitted except that it may have more trailing padding than the omission would imply. However,
when a . (or-> ) operator has a left operand that is (a pointer to) a structure with a flexible array
member and the right operand names that member, it behaves as if that member were replaced with the longest array (with the same element type) that would not make the structure larger than the object being accessed; the offset of the array shall remain that of the flexible array member, even if this would differ from that of the replacement array. If this array would have no elements, it behaves as if it had one element but the behavior is undefined if any attempt is made to access that element or to generate a pointer one past it.

Let's say the compiler keeps the freedom to choose arbitrary layouts at compile time, would punning be valid after checking that the layout just happens to be identical (via some offset_of construct)?
E.g. as an optimization to just cast between repr(C) and repr(rust) where things match and otherwise shoveling data from one type the other field by field?

On Fri, Aug 31, 2018 at 12:14:02PM +0000, gnzlbg wrote:

Ignoring bitfields and other things that do not apply to Rust,

...yet. :)

I'm going to stake out a tentative position:

I think we may well want the freedom to reorder distinct #[repr(Rust)] structs independently, for example based on PGO information.

The only real thing this seems to rule out is people using transmute to gain "unauthorized" access to private fields of data structures, right?
That is definitely a real thing, but also a pretty sketchy one.

I think that the following repr options might be useful:

something to force the first field to be at offset 0, but not constrain the rest

useful for guaranteeing "prefix" properties

something to force fields to be laid out in order but not the full #[repr(C)]

though maybe not: what else does #[repr(C)] even do?

My quick two cents on easy questions before I tackle the big issue of what to do about repr(Rust):
@the8472

Let's say the compiler keeps the freedom to choose arbitrary layouts at compile time, would punning be valid after checking that the layout just happens to be identical (via some offset_of construct)?

Yes, this should definitely be valid if done properly. The checks can get quite involved though, if we truly guarantee nothing about repr(Rust) layout, one would have to check at minimum:

alignment of the whole struct (since the compiler would be allowed to raise the alignment requirements of the repr(Rust) struct)
offsets of all fields, as you say
size of the whole struct (even if the offsets of all fields are identical, tail padding would be a possibility)

@nikomatsakis

#[repr(in_order)], whihc would force fields to be laid out in order, but not otherwise require full #[repr(C)] compatibility

though maybe not: what else does #[repr(C)] even do?

repr(C) also prescribes the amount and locations of padding, but I don't think this makes repr(in_order) useful: we can't lower the alignment requirements of the fields, and raising it is basically useless. It can theoretically facilitate the use of instructions with higher alignment requirements (e.g., SIMD) or prevent false sharing, but both of those are very tricky and niche even when done by a programmer, and automatically detecting when these opportunities are present and justifying them against the increased padding (and the cache misses, memory bandwidth, peak rss, etc. implied by it) seems infeasible to me.

I personally feel that we shouldn't add repr(inorder), or any other "some but not all of what repr(Rust) is free to do", until we have a specific, concrete use case for it.
I also hope we don't need repr(prefix) to ensure that initial fields stay in place.
Personally, I would greatly prefer that we handle structure ordering issues by helping developers reorder the actual structure order in the source, rather than deciding to reorder it at compile time. If you write a struct with a u8, u32, and u8, in that order, and it isn't repr(C), why don't we emit a warning rather than just reordering? (If you use repr(C) then you might need that exact layout for compatibility.)

I think that the following repr options might be useful:

I think we already talked about this on IRC, but for the record, I do find these ideas for new reprs interesting, but think we should try to avoid introducing new reprs and features in the unsafe code guidelines if possible. There is so much to do already, that if we try to also specify features that Rust does not have yet, we might end up achieving nothing.

Otherwise, I would prefer that I have the freedom to order my fields in a way that maximizes readability of my source, and without regard for "bitpacking" or other things.

Preserving order by default does make even less sense when generic fields are present.

I absolutely agree that repr(Rust) should not make guarantees about ordering, because doing that is saying "here's some thing that the compiler has a lot of ability to do really well, and we're going to go force the programmer to do it." @the8472's example of generics are particularly important: there's no way for the author of a generic struct to always pick the best layout.

But if you do, it'd be surprising to have the compiler reorder for other reasons, such as expected locality optimizations or profiling. I'd much rather have that information used to guide the developer into making such changes.

It's not surprising to me, as a developer who rarely in practice has to concern myself with low-level bit manipulation, that no guarantees are made other than those explicitly promised. If I am writing code that cares about common prefixes or field order, I'm already off the beaten path. And I'm in unsafe code, which means that I have to be watching myself carefully. I know that there are many pitfalls and caveats, and that I can't just make assumptions.

If you write a struct with a u8, u32, and u8, in that order, and it isn't repr(C), why don't we emit a warning rather than just reordering?

Because the vast majority of users do not want to ever have to think about this stuff. They want the compiler to just do the optimization. There will be questions in #rust-beginners to the effect of "why doesn't the compiler just do it itself?" and "because some unsafe code people prefer it this way" is very far from a satisfactory answer. It will become a serious turn-off for new users, particularly when they add a new field to an existing struct and get ceremoniously informed that they have done so in the wrong place. It will hold up code reviews as people have to go "Sorry, the build failed because we have deny(warnings) and you put your fields in the wrong order."
If users care about field order in source code, they want it to be in some logical order. Maybe it's alphabetical, maybe it's grouped by purpose. Whatever it is, it definitely not "the order that leads to the least packing".

@nikomatsakis wrote:

I think we may well want the freedom to reorder distinct #[repr(Rust)] structs independently, for example based on PGO information.

The only real thing this seems to rule out is people using transmute to gain "unauthorized" access to private fields of data structures, right?
That is definitely a real thing, but also a pretty sketchy one.

There are some cases where one can  legitimately know and exploit that two distinct repr(Rust) structs have identical contents, without breaking privacy/abstraction barriers and without being otherwise "sketchy". Most commonly, there are "plain old data" types with all fields public and a Copy impl (for example, Vec3 style types in computer graphics libraries, of which there's a ton of different but structually identical ones, and not all of them are repr(C)).
Another example might be writing a compatibility shim between two different crates (or major versions of the same crate) solving a common problem with different APIs. If the author of this shim is also the author of the other crates involved, they can know that some relevant data structure is defined the same in both crates and will remain so in future releases, even if it's not public.
Given the knowledge that two types are layout compatible, what can we use it for? For one, we can receive a large collection containing items of one type, and pass it to other code expecting a collection of the other type without copying. We can also implement AsRef and AsMut traits to faciliate interoperability. And of course, if we know the exact layout and not just that two types have the same unknown layout, we can apply all the usual unsafe tricks that rely on knowing the layout, without having to add repr(C) to a type that one does not fully control.
I'm sure there's more examples, but I hope this establishes type punning of other crates' types is not limited to sketchy rule-breaking.
To top it off, here's a concrete example of something I might want to do: Suppose I load a 3D model from disk using the obj-rs crate. For the geometry, this gives me a vector of Vertex -- a repr(Rust) struct containing the per-vertex position and normal. Both fields are public and themselves have defined layout, so if only I could be sure that the position and normal are not swapped, I would know the memory layout of the entire geometry data. I could then pass this data to a renderer that knows nothing about obj-rs  (assuming the format the renderer does expect happens to be identical to what obj-rs gives me), without having to allocate a new Vec and copy the data (or write very subtle unsafe code to opportunistically detect that the layout is as I would expect, as discussed earlier in this thread).

@rkruppe

I'm sure there's more examples, but I hope this establishes type punning of other crates' types is not limited to sketchy rule-breaking.

Fair enough!
I think an example of where PGO might be useful that would break some of these invariants is adding padding to reduce false sharing for things that cross threads.
But perhaps this ought to be handled by informing the user where to add annotations, instead, as @joshtriplett suggested. I find that appealing, particularly since it means that one could compile again (without profile data) and still see the same optimizations.
So this is a concrete thing we could decide here:

Can we enumerate what inputs the compiler might use to decide on the layout of a struct (even if we don't want to define the function)?

In particular, are we willing to say that the layout of a struct is a function of the types of its fields?
Or do we want the freedom to examine how the struct is used?
Does anybody even do PGO of the kind I am talking about? (I have no real idea)

@gnzlbg

There is so much to do already, that if we try to also specify features that Rust does not have yet, we might end up achieving nothing.

I don't thikn we can "specify features that Rust doesn't have yet", but I definitely think we should take note of gaps that exist and file them for future follow-up.

@joshtriplett

I would hope that users could have multiple structs with a common prefix and read that common prefix without needing a special directive to do so.

I think I feel quite differently here. Even when I was a "young C hacker", I always found myself writing comments when I was writing a struct where field ordering was important -- it seems like a subtle thing that is worth documenting! (And I second @alercah's arguments as well.)
I think this is the position I currently favor:

We should not guarantee #[repr(Rust)] layout
But I would  be amendable to guaranteeing that it is a deterministic function of the types of the fields
And it seems like any sort of PGO or other optimization tool would be better off suggesting annotations that users can use

This makes the optimization repeatable but also serves as a kind of documentation for the future

But I'm curious to hear from people who have experience using PGO-like optimizations in the wild. I'd also be curious to hear what @eddyb thinks on the particular point of whether layout should be deterministic.

@rkruppe
But if you wanted to rely on such things then the order of fields would suddenly become part of the API contract of crates, i.e. someone just reordering their fields for code formatting reasons would suddenly become an API break if punnability were guaranteed for repr(Rust) types.
At a minimum you'd still need some compile-time verification that they are layout-compatible.

But I would be amendable to guaranteeing that it is a deterministic function of the types of the fields

This seems like a bare minimum, yes.
I'd also love to provide enough information that people can know when their structs get reordered, and at the very least some way to explicitly enable a lint to get the compiler to say when it reorders so that the developer can incorporate that.

And it seems like any sort of PGO or other optimization tool would be better off suggesting annotations that users can use

This makes the optimization repeatable but also serves as a kind of documentation for the future

This is precisely what I meant when I said that the compiler should tell you rather than just doing it.

PGO:
Related to false sharing, there are other classes of optimizations that the compiler could make by rearranging fields. For instance, suppose we have a struct containing 3 halfwords, one which is written to much more frequently then the others (note that Vec is an example in terms of the profile, though it's the wrong size). In such a case, if the architecture punishes undersized memory access, the compiler may well decide that it is best to put the data field in the same word as the halfword of padding, allowing it to do full-word write at all times, happily clobbering the padding.
Even without resorting to strange architectural properties, it is probably faster to load two subword variables in a single load and then mask them out. So the compiler may want to move fields frequently accessed together into offsets where it can minimize the total number of loads and stores.
The possibility that this is architecture-dependent makes me think that any manual input to this process may be better off in the form of annotations on fields, rather than asking for specific layouts, as the optimal layout may be architecture-dependent.
It's possible that our technology today is not really at the point where we can take advantage of this. But we're also in a world where machine-learning-optimized compiles may be a thing in the near future, so I'm inclined to say that we should not close the door to these sorts of improvements.
Punning:
It seems to me that we can separate punning into three cases: a) where the user owns both types b) where the user owns only one type and c) where the user owns neither type.
Case a) doesn't worry me too much. Especially if, as I suggested in the tuples thread, we allow the user to explicitly specify that the layout of a struct matches the tuple with the same fields, then it's easy enough for the user to so annotate both of the types involved (and there may be benefit to letting them do so in a way other than repr(C), since repr(C) may add padding that repr(Rust) does not).
As for b) and c), I realized something just today: if we say that layout is deterministic, then field order becomes part of a type's API. If we provide a guarantee that you can take some repr(Rust) type that someone else wrote, write your own type with the same fields in the same order, and pun between them, then this requires them to never decide that they like the fields better in another order. RFC 1105 is silent as to this, but it seems to me that almost every Rust user would be surprised that reordering fields of a non-tuple-like struct would constitute a breaking change and, scarily, a potentially memory-safety-violating one. I think that this is a guarantee that crate authors should have to opt into giving by specifying a repr attribute.
This implies to me that scenario c) is something we can never guarantee in general, unless we add some additional information than field type to the process (e.g. lay out all fields of the same size in lexicographic order by name). Although we could in theory do so for tuple-like structs, I think that most of the things people are interested in punning have nominal fields anyway.
This made me wonder: why are we asking users to do type punning themselves, anyway? There's two reasons: either they really care about performance, or they just don't want to write out the fields. We can solve the latter through better language features (or even just better optimizations: if the compiler was capable of recognizing when a move/copy was being done fieldwise between two identically-laid out types, it could just optimize to a single wide move/copy and this would work for data that was owned, although not for punning a reference or pointer to unowned data), and those features would benefit all conversions between similar types. For the former, we could either flat-out say that we do not support this, or we could offer safe APIs that allow for punning. For instance, we could have one
For b), we're in a boat where we can't safely make any such guarantee today, but we could in theory add a way to say "my type is laid out the same as this other one", which would be robust against changes to the remote type's layout. Furthermore, any language features or optimizations like the above would apply here.

Apropos of none of the above things: I think we can probably safely guarantee that a DST appears last in memory.

But I would be amendable to guaranteeing that it is a deterministic function of the types of the fields

This seems like a bare minimum, yes.

Considering that PGO is frequently mentioned and struct-layout-randomization could conceivably also be used as some form of testing that does not seem all that self-evident.

@nikomatsakis

Does anybody even do PGO of the kind I am talking about? (I have no real idea)

In https://github.com/rust-rfcs/unsafe-code-guidelines/issues/12#issuecomment-420160985 @ChrisJefferson linked these two papers:

https://ieeexplore.ieee.org/abstract/document/7726757/
https://pdfs.semanticscholar.org/567e/a8bf671735f120faa615ea6313faaaf07084.pdf

Neither is directly applicable, though. The first is about Java where allocations tend to have different shapes than in Rust (and reports mixed results, indicating to me that this should be opt-in), the latter does much more aggressive transformations that we can't allow in Rust except under the as-if rule.

@the8472

But if you wanted to rely on such things then the order of fields would suddenly become part of the API contract of crates, i.e. someone just reordering their fields for code formatting reasons would suddenly become an API break if punnability were guaranteed for repr(Rust) types.

Good point, though this still leaves tuple structs where order is already significant.

At a minimum you'd still need some compile-time verification that they are layout-compatible.

One should have that in any case so that a semver break (uncool but happens) does not turn into a memory safety issue (very bad).

@joshtriplett

I'd also love to provide enough information that people can know when their structs get reordered, and at the very least some way to explicitly enable a lint to get the compiler to say when it reorders so that the developer can incorporate that.

As has been pointed out before, for generic types the optimal order may be different depending on type parameters, making it impossible to even write down the optimal order in the source code. I'll add that the optimal order can also vary by target platform, e.g. due to variances in the size/align of pointers and usize varying and the alinment requirements of large primitives like u64 and u128.
Additionally, for the metric "minimize overall structure size" or "minimize padding while aligning this field to K", it is quite feasible to find optimal solutions quickly, reliably and automatically. It's silly to force programmers to think about and put into their source code an optimization that the compiler can handle 100%
In contrast, for metrics such as "reduce false sharing", "reduce cache misses", etc. an "optimal" solution is very hard to find for many reasons (e.g. it depends on runtime memory layout and uarch details, and even ignoring those the idealized mathematical optimization problem is computationally hard). Add in that a PGO build is more expensive than a normal optimized build and it's quite obvious to me why a programmer might want to invest time once to learn about layout changes that seem profitable, investigate them, and then put them in writing if they seem good.

Just wanted to say, with regards the papers I mentioned in earlier, I agree these papers don't directly apply to Rust, but they show that people do do research into layout in various ways -- it's not surprising there isn't (yet) research into layout in Rust, the language isn't old enough yet! Anything we fix today will be, in practice, fixed forever (at least experience with past languages suggest this will be the case), so I'd very much prefer we not fix anything, just because people think varying it won't be useful for optimisation. At the moment we have #[repr(C)] for people who want a well-defined ABI (although different for each OS of course, and maybe not the ABI they want).
On the other hand, I know academics who haven't bothered doing research into layout of C and C++, because as the languages define the layout, any system which automatically changed layouts for all structs in a program would have a good chance of breaking things, and trying to detect which structs/classes can have their layout changed is a non-trivial activity.
I personally don't want to investigate which layout changes might be profitable, in the same way i'm not interested in which functions are worth inling. I'd prefer a PGO to just "go forth" and do it's best attempt at speeding up my program.

Good point, though this still leaves tuple structs where order is already significant.

Tuple struct ordering is already significant though, because the fields are accessed by index. So reordering a tuple struct is very clearly a breaking change today and will break people's builds (though, admittedly, it's not a guarantee, so it could lead to memory safety violations).

Tuple struct ordering is already significant though, because the fields are accessed by index. So reordering a tuple struct is very clearly a breaking change today and will break people's builds

A tuple index can refer to the elements in the order declared by the user. A compiler can re-order the fields as long as the indices are mapped accordingly, which isn't any different from mapping struct field names to fields.

Sure, but that doesn't matter across crate versions.

EDIT: Re-reading, I think this was exactly @rkruppe's point and I was just confusing myself...

Yes, that was exactly my point, but since two people have replied restating this at me, I clearly must have worded it very badly 🤔

I'm not clear why changing the order in memory of these things would effect the behaviour of tupper structs. As long as rust maps the first element of the struct to (in this case) name, it doesn't matter how the valuee are padded, or their order?

I opened https://github.com/rust-rfcs/unsafe-code-guidelines/pull/31 which contains my attempt to summarize our tentative consensus here. Please give feedback! (In particular, let me know if there is anything you think is incorrect.)

Are there any guarantees about how changing a type parameter affect the memory layout of a struct when it is  only ever used in a PhantomData<fn()->TypeParam> field ?
Example:
use std::marker::PhantomData;

struct Value<T,C>{
    value_0:T,
    value_1:usize,
    value_2:T,
    _marker:PhantomData<fn()->C>,
}

I am currently relying on the layout of Value not changing when its C type parameter does.

@rodrimati1992 Good point, can we mandate that the layout of PhantomData<T> is the same as () in all type contexts?

Wouldn't those types be compiled separately due to monomorphization and thus be subject to independent optimization choices by the compiler.

@the8472 that's the question, should different zero-size types affect representation? Josephine is unsafe if different PhantomData have different memory layouts.

The reasons for wanting to reserve the right to lay out structurally-identical but nominally-different types differently (different types may be used differently incentivizing different layouts, "if you need layout compatibility you can add an attribute") apply here unaltered.
I for one do think we should guarantee PhantomData to be irrelevant to layout, but I am also in favor of guaranteeing a lot more than there was consensus for in this thread.

I think if a special-case were provided for zero-sized types in generics this would result in spooky action at a distance where sometimes you would be guaranteed that a generic type with different parameters are layout-identical until someone changes one of the types to be non-zero-sized and suddenly your layouts are not compatible anymore.
Instead you could say something like
#[repr(as(Value<T, ())>)]
struct Value<T,C>{
    value_0:T,
    value_1:usize,
    value_2:T,
    _marker:PhantomData<fn()->C>,
}

Which puts the guarantees or compile time checks at the level where you need them.

This se

I think if a special-case were provided for zero-sized types in generics this would result in spooky action at a distance where sometimes you would be guaranteed that a generic type with different parameters are layout-identical until someone changes one of the types to be non-zero-sized and suddenly your layouts are not compatible anymore.
Instead you could say something like
#[repr(as(Value<T, ()>))]
struct Value<T,C>{
    value_0:T,
    value_1:usize,
    value_2:T,
    _marker:PhantomData<fn()->C>,
}

Which puts the guarantees or compile time checks at the level where you need them.

This type parameter passes through multiple layers,and requiring every user of type_level_values to annotate their own types with #[repr(as(TypeName<T, ()>))] is a lot to ask.
I would prefer a trait-based solution,in which I can require that two types have compatible memory layout,
rulling out cases where such thing could accidentally happen.This would require no annotations by the user in the common case
I forgot to mention that I generate a type alias to pass a PhantomData-like type as the C type parameter,
guaranteeing that C cannot be anything but zero-sized..

Can we say something like we guarantee that the layout for a struct is only dependent on certain properties of its fields? Off the top of my head those are size, alignment and non-zero-ness, but there may be others. This would avoid having to propose an RFC with a language extension.

That is an option in principle but the current position is that different types with the same properties should allow maximal layout freedom for various kinds of optimization, randomization and similar compiletime decisions. So pretty much any guarantee at all for repr(Rust) types would have to be opt-in.
See the summary in #31

Ok,if we go with the annotation based approach,how about something like this:
#[no_effect_on_layout(C)]
struct Value<T,C>{
    value_0:T,
    value_1:usize,
    value_2:T,
    _marker:PhantomData<fn()->C>,
}

This attribute would guarantee that the type parameter C would not change the layout of the type regardless of what it is,requiring it to be stored in a zero-sized-type.
This attribute could also be detected by derive macros that depend on the type parameter,not changing the layout of the type,and would be usable with any #[repr(..)].

The intended effect would be the same. You would just be telling the compiler that layout should behave as if C were set to a fixed value and thus all instances of Value<T, C> collapse to Value<T>, but again, only for layout purposes.
This would basically be a special case of the as() constraint where as points to an anonymous generic type with one less generic parameter that contains all the same fields except _marker: ().

The effect would be that the attribute would be easier to parse by macros.
An alternative if one uses the repr(..) syntax is to extend syn to parse #[repr(as(Value<T, ()>))] so that macro authors don't have to.

Ah, I have not put much thought into that specific syntax. It could also be expressed in different ways, e.g. T = () to say that a single generic argument behaves as if it were fixed instead of specifying the layout of the whole struct. The details have to be worked out once additional repr annotations are introduced.

So, after all this talk about layout guarantees for structs... could we do a little practical exercise and see if https://github.com/rust-lang/rust/pull/54922 if within bounds of the guarantees, or exceeding them? This does some manual layout computation that is supposed to recompute the layout of a repr(Rust) struct with an unsized tail.

Quickly chiming in with a +1 for restricting repr(rust) to only reordering and still mandating natural/greedy c-style padding. This would make (align=1,size=0) types not affect layout, newtypes not affect layout, alignment predictable, and the size of heterogeneous types predictable. At the same time it would still allow us to do the only really relevant optimization of ordering the fields optimally. The fact that a theoretical field fuzzer wouldn't be allowed to be as powerful as it could be is not especially concerning to me.
(also cc me)

@asajeffrey

Can we say something like we guarantee that the layout for a struct is only dependent on certain properties of its fields? Off the top of my head those are size, alignment and non-zero-ness,

I don't know. For example, consider the repr(Rust) struct F { x: f32, y: f32, z: f32, w: f32 }, under the assumption that f32 has an alignment of 4 in the platform being targeted - the maximum alignment of a field of F is then 4. Would it be ok for the compiler to increase the alignment of F to say, 16, to, for example, be able to generate aligned SIMD loads and stores in that platform ?
We have been talking about guaranteeing the layout of homogenous tuples / structs, but I also imagine that this could happen somewhere else, e.g., struct G { _: u64, f: F, _: u64 } where f gets re-ordered at the front and the alignment increased to 16 to facilitate SIMD operations.

We've called final-comment-period on #31.

Actually, I see some of the latest comments here -- these are great. Perhaps we can redirect them to  #35, which is a subissue on this topic? I'll copy over some of those now.


docs(README.md): update requirements.txt

:tada: This PR is included in version 1.26.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add support for istioctl -ojsonpath

Describe the feature request
This is helpful when we only need partial of the listener/cluster config from the config dump.
istioctl pc cluster -ojsonpath='items[?(@.name=="outbound||httpbin.svc.cluster.local")]

As a work-around I've used jq.  For example:
istioctl pc cluster details-v1-875c6d75d-ghpf4 -ojson | jq '.[] | select(.name=="zipkin")'

Do you think it would be worthwhile to bring in k8s.io/client-go/util/jsonpath ?  I am not sure I want to write the docs/examples for using it....

Related https://github.com/istio/istio/issues/19927

jq works for me personally, the downside is that people need to be aware of
that, install etc. I guess we don't have to write json path if we support
that. At most link to somewhere else?
On Sun, Mar 22, 2020 at 9:42 AM John Howard<EMAIL_ADDRESS>wrote:

Related #19927 https://github.com/istio/istio/issues/19927
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/19485#issuecomment-602237157, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMVXB6QYYBBMAFW6CZWT3LRIY5YBANCNFSM4JYSR43Q
.


sweet: 4.0 -> 5.0

Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[X] Tested, as applicable:

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

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

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

[X] Fits CONTRIBUTING.md.

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

Quick question, why do we backport this? Does this solve a regression in 24.11?

Quick question, why do we backport this? Does this solve a regression in 24.11?

Regression in 24.11? Which regression

Quick question, why do we backport this? Does this solve a regression in 24.11?

i don't think it solves regression, but in release log there is no mention of breaking changes


Sample store: Elements disappearing during canvas interaction

See e.g.
https://screenshot.click/05-09-s8rsq-17biw.mp4
https://screenshot.click/05-08-8gc49-a3cc6.mp4

I don't remember this being a problem in the hydrogen-november project, so I think that's a good starting point to figure out what's the difference between the two projects

https://github.com/concrete-utopia/hydrogen-editions-24/commit/cf4aed2b937c39f6c28fa9fafc295d3aa4dde6cf

Re-opening this as we mitigated the symptom but did not fix the underlying issue.


⚠ Bofrost.es has degraded performance

In 5645894, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1519 ms

Resolved: Bofrost.es performance has improved in 10808ad after 9 minutes.


Problems still showing up even when problem.visibility is toggled

Testing #199247

/duplicate https://github.com/microsoft/vscode/issues/199300
this is intended!


How to subscribe Group address in BLE Mesh In esp32 without mobile app  (IDFGH-8180)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
Hi all,
I am tiring to create a BLE mesh with esp32 which can send and receive msg to all nodes.
What i done:
I can send a msg to all nodes with nrfApp after i group the nodes
What i cant
I cant send a msg to all nodes without App from client (When Vendor client automatically bind the key with nodes). Because i cant group the nodes.
Suggest me the way to subscribe group address to all nodes or any other way to send and receive msg or binding key programmatically.

Hi @JegadeeshXaglabs
Sorry for the late reply. If you want to send message to all nodes, you don't need to subscribe any group address, you only need to  set the DST of the message to 0xFFFF.
If you want to subscribe group address, you can use the function of esp_ble_mesh_model_subscribe_group_addr(). And config client send config model app bind message to config server to bind the appkey to the model.
Hope it can help you.

Thanks for the help @JiaLWang .it worked

@JiaLWang @JegadeeshXaglabs
Can you guys explain to me how this command works and potentially point out the issue I am having
I have an ESP provisioning an nRF58232 and I am able to get temperature requests no issue. Now I want to subscribe the nRF to a group address of   0xC000, Nordic default company is 0x058.
AT-BMNS_TEST is just the ESP_LOG name
To test I have tried all the available models
I (17102) BMNS_COMMON: ********************** Composition Data Start **********************
I (17112) BMNS_COMMON: * CID 0x0059, PID 0x0000, VID 0x0000, CRPL 0x000a, Features 0x0007 *
I (17122) BMNS_COMMON: * Loc 0x0001, NumS 0x03, NumV 0x00 *
I (17132) BMNS_COMMON: * SIG Model ID 0x0000 *
I (17132) BMNS_COMMON: * SIG Model ID 0x1100 *
I (17142) BMNS_COMMON: * SIG Model ID 0x1101 *
I (17142) BMNS_COMMON: *********************** Composition Data End ***********************
I (17162) BMNS_PROV: ESP_BLE_MESH_PROVISIONER_STORE_NODE_COMP_DATA_COMP_EVT, err_code 0
W (17382) BMNS_CONFIG: Provision and config successfully VENDOR
W (24802) BLE_MESH: Receive configuration status message timeout
I (32212) AT-BMNS_TEST: argument count 1
I (32212) AT-BMNS_TEST: primary address 1
I (32212) AT-BMNS_TEST: element_address 1
I (32222) AT-BMNS_TEST: sig_model_count 3
I (32222) AT-BMNS_TEST: vnd_model_count 1
I (32232) AT-BMNS_TEST: [0] sig_models->model_id 0x0000
I (32232) AT-BMNS_TEST: [1] sig_models->model_id 0x0001
I (32242) AT-BMNS_TEST: [2] sig_models->model_id 0x1102
E (32242) BLE_MESH: Subscribe, model not found, cid 0x0059, mod_id 0x0000
E (32252) BLE_MESH: Subscribe, model not found, cid 0x0059, mod_id 0x0001
E (32262) BLE_MESH: Subscribe, model not found, cid 0x0059, mod_id 0x1102
E (32272) BLE_MESH: Subscribe, model not found, cid 0x0059, mod_id 0x0059
E (32272) BLE_MESH: Subscribe, model not found, cid 0x0059, mod_id 0x0006


[Feature Request] Support returning "count" in RESTful API handler

Getting the total count during pagination is a very common requirement. Since JSON:API allows custom meta, we can probably use it to contain that information in the response. Also, there should be an option to opt-in for this feature to avoid a default performance hit.

hi @ymc9 I'm trying to build and test the project, but when I exec the pnpm install and pnpm run build I have some packages with error like this:

what i'm missing? thanks!

hi @ymc9 can you please give access to make a PR? thanks :)

Fixed by #529


Don't override the JVM timezone in a Hibernate integration test

HSQLDB correctly retrieves a timestamp from the DB in the JVM timezone, Jadira converts it to DateTime and then Jackson serializes it to JSON in UTC.
So all assertions in UTC will pass regardless of the JVM timezone.

LGTM.


BIP70 URI scanning

BIP70 URI support
Currently Badger Mobile does not support BIP URI's.
When they are scanned, the app resets itself.

Add support for...

[x] Clicking on BIP70 URI's
[x] Scanning BIP70 URI's
[x] Pasting BIP70 URI's

Example URI
bitcoincash:?r={payment URL here}

Need to extend this ticket for pay.bitcoin.com integration.

Live in internal builds for testing


don't fail on other tests if test po fails

previously if this test failed, it would leave the current directory
in a inconstant state (pointing to a temporary directory that is
deleted).
This caused the following error on many tests in the testsuite:
cwd = os.getcwd()
OSError: [Errno 2] No such file or directory
After this fix the testsuite still fails, but only on the actual tests that still have problems.

LGTM


Update README.md

One step in the quick setup is missing.

@agamemnus Thanks for sending the PR. I think the wording should be something like-

Change the directory- cd react-boilerplate.

That would suffice :)

Idk. It just doesn't feel complete that way. I reworded it slightly.

@agamemnus Okay. Just mention the complete command (cd react-boilerplate) instead of eg. cd. Let's merge this in then!

I was just thinking someone might have a system that didn't have cd. That
might be an unfounded worry. Ok, I'll rework ot in a few hours to do it
like that. (I'm supposed to be asleep)
On May 29, 2017 1:01 AM, "Mihir Karandikar"<EMAIL_ADDRESS>wrote:

@agamemnus https://github.com/agamemnus Okay. Just mention the complete
command (cd react-boilerplate) instead of eg. cd. Let's merge this in
then!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/react-boilerplate/react-boilerplate/pull/1785#issuecomment-304572829,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADFJWDNtTvDv0XeiTo053lVMXFqZBT8sks5r-lEUgaJpZM4No2yh
.

@agamemnus Well it works on most of the platforms so let's not worry too much :smile:

Done.

@agamemnus Awesome. Thank you for your contribution :sparkles:

@react-boilerplate/core I inadvertently merged this without checking the base branch :disappointed_relieved: :cry:
But thank god, it only changes the README.md. Just wanted to give you a heads-up.


Remove ScheduleComponent Class

What is the expected enhancement?
ScheduleComponent should be removed and we should just replace with a common Value type with much fewer common attributes.

Closing as a duplicate of #5076


Create a flutter web app

Create a flutter web app which acts as a console to view and use every widget of ModularUI
Needs to be discussed.

I would recommend widgetbook, it’s really nice for ordering and building out ui elements. You can preview different themes, adjust dynamic the widgets parameters and a lot more. I could set it up if you want. https://www.widgetbook.io/

Perfect 💯. I am assigning this to you

Hey we are creating a new repo for wrapping and hosting all of those widgets under WidgetBook.
Thankyou @oxelf


ARROW-13151: [C++][Parquet] Propagate schema changes from selection all the way up the stack

Previously, structs would only work for a single level, and other nested types did not do this at all.  This PR propagates types through lists, large_lists, fixed_sized_lists and multiple nesting of structs.  Maps had some special handling:

If only a partial key is selected it gets converted to list
If only a partial value is selected it maintains the map type.
The old behavior of changing to list is maintained when the entire key or value are removed (but test coverage was added for this)

The example given in the JIRA now works:
>>> data = {"root": [[\{"addr": {"this": 3, "that": 3}}]]}
 >>> table = pa.Table.from_pydict(data)
 >>> pq.write_table(table, "/tmp/table.parquet")
 >>> file = pq.ParquetFile("/tmp/table.parquet")
 >>> array = file.read(["root.list.item.addr.that"])
 >>> array
 pyarrow.Table
 root: list<item: struct<addr: struct<that: int64>>>
 child 0, item: struct<addr: struct<that: int64>>
 child 0, addr: struct<that: int64>
 child 0, that: int64
----
root: [[ – is_valid: all not null
 – child 0 type: struct<that: int64>
 – is_valid: all not null
 – child 0 type: int64
 [
 3
 ]]]

Also CC @zeroshade I know we haven't gotten there yet, but this might have crept into your port.


README: Instructions for starting the S3 mock server

Please include instructions for starting the S3 mock server, in terms of:

Command line instructions (for quick bash runs)
Java calls (for pure Java integration tests)

A PR for the current README explaining this would be very welcome :)

Use a readily built docker containe with instructions^^: https://hub.docker.com/r/scireum/s3-ninja/tags/


Uses tab key to choose next candidate without showing candidate panel.

This feature helps to save time in some cases. For example, when a user
wants to type "…", he or she has to input _ and then use space key
to show the candidate window and then select the second candidae. Using
the tab key feature can let the user just input _ and tab.

A demo video.
https://user-images.githubusercontent.com/53011/170793126-10913a3f-dbd7-4790-a5f5-f0a8ac98df07.mp4


Random item on join

Describe the bug
Every time i join the server i get an cobblestone wall with the config settings from the graves module.
I dont know what to do with it, i dont see any problem with my config...
To Reproduce
Join the server
Expected behavior
Nothing getting in my inventory
Screenshots
https://i.imgur.com/5bLqO1F.png

Already fixed without a version bump, just redownload 1.8.3-beta


Uanble to get the SQL MI running

Unable to get the SQL managed instance pod running
kubectl get pods --namespace arc
NAME                 READY   STATUS    RESTARTS   AGE
bootstrapper-fj5xq   1/1     Running   0          118m
control-9nxn5        2/2     Running   0          118m
controldb-0          2/2     Running   0          116m
controlwd-wshnj      1/1     Running   0          115m
logsdb-0             1/1     Running   0          115m
logsui-ntwzg         1/1     Running   0          115m
metricsdb-0          1/1     Running   0          115m
metricsdc-g2xsc      1/1     Running   0          36m
metricsdc-gj28h      1/1     Running   2          115m
metricsdc-pkt4z      1/1     Running   1          39m
metricsdc-s594c      1/1     Running   0          115m
metricsdc-zxmmr      1/1     Running   0          115m
metricsui-gx574      1/1     Running   0          115m
mgmtproxy-br7sz      2/2     Running   0          115m
sql1-0               2/3     Running   0          3m7s
The ready state of the container is false and this is what i get when i do a describe on the pod
Conditions:
Type              Status
Initialized       True
Ready             False
ContainersReady   False
PodScheduled      True
Volumes:
data-gzpv8dfinayqx0114evicl60:
Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName:  data-gzpv8dfinayqx0114evicl60-sql1-0
ReadOnly:   false
logs-gzpv8dfinayqx0114evicl60:
Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName:  logs-gzpv8dfinayqx0114evicl60-sql1-0
ReadOnly:   false
var-run:
Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:     Memory
SizeLimit:
cluster-config-volume:
Type:      ConfigMap (a volume populated by a ConfigMap)
Name:      cluster-configmap
Optional:  false
controller-internal-secret:
Type:        Secret (a volume populated by a Secret)
SecretName:  controller-internal-secret
Optional:    false
metricsdb-wo-secret:
Type:        Secret (a volume populated by a Secret)
SecretName:  metricsdb-wo-secret
Optional:    false
agent-secret:
Type:        Secret (a volume populated by a Secret)
SecretName:  sql1-agent-secret
Optional:    false
monitoring-login-secret:
Type:        Secret (a volume populated by a Secret)
SecretName:  sql1-monitoring-login-secret
Optional:    false
container-agent-login-secret:
Type:        Secret (a volume populated by a Secret)
SecretName:  sql1-container-agent-login-secret
Optional:    false
useradmin-login-secret:
Type:        Secret (a volume populated by a Secret)
SecretName:  sql1-login-secret
Optional:    false
sa-login-secret:
Type:        Secret (a volume populated by a Secret)
SecretName:  sql1-sa-login-secret
Optional:    false
system-login-secret:
Type:        Secret (a volume populated by a Secret)
SecretName:  sql1-system-login-secret
Optional:    false
default-token-v9gvw:
Type:        Secret (a volume populated by a Secret)
SecretName:  default-token-v9gvw
Optional:    false
QoS Class:       Burstable
Node-Selectors:  kubernetes.io/os=linux
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type     Reason                  Age                   From
Message

           -------

Warning  FailedScheduling                     default-scheduler
0/5 nodes are available: 1 Insufficient cpu, 4 pod has unbound immediate
PersistentVolumeClaims.
Normal   Scheduled                            default-scheduler
Successfully assigned arc/sql1-0 to aks-worloadpool-28951543-vmss000001
Warning  FailedScheduling                     default-scheduler
0/5 nodes are available: 1 Insufficient cpu, 4 pod has unbound immediate
PersistentVolumeClaims.
Normal   SuccessfulAttachVolume  4m36s                 attachdetach-controller
AttachVolume.Attach succeeded for volume "pvc-f60da5a0-c7b7-42d5-9525-edfd10d9958e"
Normal   SuccessfulAttachVolume  4m6s                  attachdetach-controller
AttachVolume.Attach succeeded for volume "pvc-2044365d-c5ff-4026-9802-2ceb0fae1ce9"
Warning  FailedMount             3m40s                 kubelet, aks-worloadpool-28951543-vmss000001  Unable to attach or mount volumes: unmounted volumes=[data-gzpv8dfinayqx0114evicl60 logs-gzpv8dfinayqx0114evicl60], unattached volumes=[monitoring-login-secret var-run useradmin-login-secret sa-login-secret data-gzpv8dfinayqx0114evicl60 controller-internal-secret metricsdb-wo-secret logs-gzpv8dfinayqx0114evicl60 agent-secret cluster-config-volume system-login-secret container-agent-login-secret default-token-v9gvw]: timed out waiting for the condition
Normal   Pulling                 3m24s                 kubelet, aks-worloadpool-28951543-vmss000001  Pulling image "mcr.microsoft.com/arcdata/arc-monitor-fluentbit:public-preview-jan-2021"
Normal   Pulled                  3m24s                 kubelet, aks-worloadpool-28951543-vmss000001  Successfully pulled image "mcr.microsoft.com/arcdata/arc-monitor-fluentbit:public-preview-jan-2021"
Normal   Pulled                  3m23s                 kubelet, aks-worloadpool-28951543-vmss000001  Successfully pulled image "mcr.microsoft.com/arcdata/arc-sqlmi:public-preview-jan-2021"
Normal   Created                 3m23s                 kubelet, aks-worloadpool-28951543-vmss000001  Created container fluentbit
Normal   Pulling                 3m23s                 kubelet, aks-worloadpool-28951543-vmss000001  Pulling image "mcr.microsoft.com/arcdata/arc-sqlmi:public-preview-jan-2021"
Normal   Started                 3m23s                 kubelet, aks-worloadpool-28951543-vmss000001  Started container fluentbit
Normal   Created                 3m22s                 kubelet, aks-worloadpool-28951543-vmss000001  Created container arc-sqlmi
Normal   Started                 3m22s                 kubelet, aks-worloadpool-28951543-vmss000001  Started container arc-sqlmi
Normal   Pulling                 3m22s                 kubelet, aks-worloadpool-28951543-vmss000001  Pulling image "mcr.microsoft.com/arcdata/arc-monitor-collectd:public-preview-jan-2021"
Normal   Pulled                  3m22s                 kubelet, aks-worloadpool-28951543-vmss000001  Successfully pulled image "mcr.microsoft.com/arcdata/arc-monitor-collectd:public-preview-jan-2021"
Normal   Created                 3m21s                 kubelet, aks-worloadpool-28951543-vmss000001  Created container collectd
Normal   Started                 3m21s                 kubelet, aks-worloadpool-28951543-vmss000001  Started container collectd
Warning  Unhealthy               81s (x12 over 3m11s)  kubelet, aks-worloadpool-28951543-vmss000001  Readiness probe failed: cat: /var/run/container.ready: No such file or directory
azdata arc sql mi list
ExternalEndpoint     Name    Replicas    State

<IP_ADDRESS>,1433  sql1    0/1         Creating

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9ae4f1fb-5b3f-ade7-e1f6-e4f5c5779d34
Version Independent ID: 55679aae-1665-0ab5-64a2-d70cb1df73e0
Content: Create an Azure SQL managed instance on Azure Arc - Azure Arc
Content Source: articles/azure-arc/data/create-sql-managed-instance.md
Service: azure-arc
Sub-service: azure-arc-data
GitHub Login: @vin-yu
Microsoft Alias: vinsonyu

Thank you for your feedback! Since this channel is for driving improvements towards MS Docs, could you provide the URL of the specific documentation that your feedback is applicable to? That way, we are able to make sure your feedback is addressed by the right team.
The best place for specific answers about implementations are going to be the Microsoft Q&A and Stack Overflow forums. We actively look through posts in the forums, and will do our best to get you going in the right direction!

This is the URL https://docs.microsoft.com/en-us/azure/azure-arc/data/create-sql-managed-instance

Hi @girishgouda, looks like your Kubernetes cluster does not have enough resources available to run the SQL MI workload.
0/5 nodes are available: 1 Insufficient cpu

You can use --cores-request 1 to deploy with minimum number of cores else you'll need more CPU resources on your Kubernetes cluster

Thanks a lot @vin-yu for helping on this thread.
@girishgouda  Please review the information shared by @vin-yu and let us know if you have any further queries.
Please note that this  channel (the Azure Docs repository) is only for driving improvements related to the Azure documentation. At this point it appears that there's no further edits or updates needed to the documentation. We will go ahead and close this issue for now, however if you have any further queries/feedback regarding the documentation please tag us in your reply and will be happy to reopen the thread and continue the conversation. Thank you


Add pseudo translation Strings to gitignore

Codecov Report

Merging #135 into master will increase coverage by 1.62%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #135      +/-   ##
============================================
+ Coverage     73.08%   74.71%   +1.62%
+ Complexity     1644      999     -645
============================================
  Files           129       69      -60
  Lines          5674     3951    -1723
  Branches        874      440     -434
============================================
- Hits           4147     2952    -1195
+ Misses          859      749     -110
+ Partials        668      250     -418

Impacted Files
Coverage Δ
Complexity Δ

...e/msdkuiapp/routing/RoutingInstructionsFragment.kt

...java/com/here/msdkuiapp/common/PermissionsUtils.kt

.../com/here/msdkuiapp/routing/OptionPanelFragment.kt

...ere/msdkuiapp/routing/RouteManeuverListFragment.kt

.../here/msdkuiapp/routing/SubOptionPanelPresenter.kt

...m/here/msdkuiapp/routing/SubOptionPanelFragment.kt

...msdkuiapp/guidance/GuidanceNextManeuverFragment.kt

...com/here/msdkuiapp/routing/OptionPanelPresenter.kt

...m/here/msdkuiapp/position/AppPositioningManager.kt

...ain/java/com/here/msdkuiapp/about/AboutActivity.kt

... and 51 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2d66c67...6dd81f9. Read the comment docs.


Fix typo in color

This is just a simple typo I noticed that's causing color not to translate on this section

thank you


[bug] asNavFor in combination with Responsive

Hello,
I use your plugin a lot and i'm always happy with the result.
But this time its working against me...
I've got two sliders and one of them uses the arrows for navigating both.
Also there is a responsive breakpoint at 1024 but the hole script broke down when i added that.
When I delete the "asNavFor" the slider is fixed and responsive works.
When I delete "responsive" the slider is fixed and the asNavFor works.
But I can't get them to work together.
Here is the script:
jsFiddle: http://jsfiddle.net/tatof/kxw0x3hm/
websites: http://www.tatof.nl/test2/   (bottom slider)
EDIT: i found out that when the slick loads in 1920px and resizes to small screen it works. but when i press f5 and reload the page in small screen its brokan again.
EDIT2: I found out that i cant make both sliders responsive, but its posible to make the bottom one responsive.

here's an update to the fiddle with the raw master-branch slick, makes it easier to debug.
http://jsfiddle.net/kxw0x3hm/3/
I'm having al oko, but it seems pretty nuts, I think there's atleast 4 open issues about this! :confounded:

@tatof could you quickly test: http://jsfiddle.net/kxw0x3hm/4/ ... I have linked in the raw file from my branch, if you're happy it fixes your issue, I'll merge and close :smiling_imp:

Found a tiny bug; It was forcing a refresh when the carousel initialised inside a breakpoint. That refresh would try to getSlick() on the asNavFor target... but that target was not even initialised yet. So it crashed. - Resolved.

Yes this works! :) used the 1.5.2 script and its fixed:
http://www.tatof.nl/test2/
Thank you! you made my day.


add required attribution for explores using CartoDB darkmatter tiles

Currently, executing many of the examples in "11-interactive-web-mapping notebook with required attribution" yields
this error: "ValueError: Custom tiles must have an attribution."
This diff resolves the error by adding the required "attr" param to the explore calls.

@arjunbanker I'm not seeing this error with GeoPandas 0.13.x or 0.14.x. Can you provide a complete list of your package versions (such as with conda list) and the complete error traceback? Thanks.

ah interesting. sure, adding the stack trace & package versions via pip
list.
folium wasn't an environment dependency so i manually pip installed it (so
it's likely latest @ 0.14) and wondering if that may be the underlying
conflict?
from cell:
explore nodes and edges together in a single map
nodes, edges = ox.graph_to_gdfs(G)
m = edges.explore(color="skyblue", tiles="cartodbdarkmatter")
nodes.explore(m=m, color="pink", marker_kwds={"radius": 6})
execution stack:
ValueError Traceback (most recent call last)
/Users/arjunbanker/Development/learn/osmnx-examples/notebooks/11-interactive-web-mapping.ipynb
Cell 8 line 3 1 # explore nodes and edges together in a single map 2 nodes,
edges = ox.graph_to_gdfs(G) ----> 3 m = edges.explore(color="skyblue", tiles
="cartodbdarkmatter") 4 nodes.explore(m=m, color="pink", marker_kwds={"
radius": 6}) File
~/.pyenv/versions/3.7/envs/myenv/lib/python3.11/site-packages/geopandas/geodataframe.py:2101,
in GeoDataFrame.explore(self, *args, **kwargs) 2099 @doc(_explore) 2100 def
explore(self, *args, **kwargs): -> 2101 return _explore(self, *args, **kwargs)
File
~/.pyenv/versions/3.7/envs/myenv/lib/python3.11/site-packages/geopandas/explore.py:371,
in _explore(df, column, cmap, color, m, tiles, attr, tooltip, popup,
highlight, categorical, legend, scheme, k, vmin, vmax, width, height,
categories, classification_kwds, control_scale, marker_type, marker_kwds,
style_kwds, highlight_kwds, missing_kwds, tooltip_kwds, popup_kwds,
legend_kwds, map_kwds, **kwargs) 368 map_kwds["max_zoom"] = tiles.get("
max_zoom", 18) 369 tiles = tiles.build_url(scale_factor="{r}") --> 371 m =
folium.Map( 372 location=location, 373 control_scale=control_scale, 374
tiles=tiles, 375 attr=attr, 376 width=width, 377 height=height, 378 **map_kwds,
379 )
...
(...) 147 **kwargs 148 ) ValueError: Custom tiles must have an attribution.
pip list:
Package            Version

affine             2.4.0
appnope            0.1.3
asttokens          2.4.0
attrs              23.1.0
backcall           0.2.0
branca             0.6.0
certifi            2023.7.22
charset-normalizer 3.2.0
click              8.1.6
click-plugins      1.1.1
cligj              0.7.2
comm               0.1.4
contourpy          1.1.0
cycler             0.11.0
debugpy            1.8.0
decorator          5.1.1
executing          1.2.0
Fiona              1.9.4.post1
folium             0.14.0
fonttools          4.42.0
GDAL               3.7.2
geographiclib      2.0
geopandas          0.13.2
geopy              2.3.0
idna               3.4
igraph             0.10.8
ipykernel          6.25.2
ipython            8.15.0
jedi               0.19.0
Jinja2             3.1.2
joblib             1.3.2
jupyter_client     8.3.1
jupyter_core       5.3.1
kiwisolver         1.4.4
mapclassify        2.6.0
MarkupSafe         2.1.3
matplotlib         3.7.2
matplotlib-inline  0.1.6
nest-asyncio       1.5.7
networkx           3.1
numpy              1.25.2
osmnx              1.6.0
overpy             0.6
packaging          23.1
pandas             2.0.3
parso              0.8.3
pexpect            4.8.0
pickleshare        0.7.5
Pillow             10.0.0
pip                23.2.1
platformdirs       3.10.0
prompt-toolkit     3.0.39
psutil             5.9.5
ptyprocess         0.7.0
pure-eval          0.2.2
Pygments           2.16.1
pyparsing          3.0.9
pyproj             3.6.0
python-dateutil    2.8.2
pytz               2023.3
pyzmq              25.1.1
rasterio           1.3.8
requests           2.31.0
scikit-learn       1.3.0
scipy              1.11.1
setuptools         65.6.3
shapely            2.0.1
six                1.16.0
snuggs             1.4.7
stack-data         0.6.2
texttable          1.6.7
threadpoolctl      3.2.0
tornado            6.3.3
traitlets          5.10.0
tzdata             2023.3
urllib3            2.0.4
wcwidth            0.2.6
On Sun, Sep 17, 2023 at 11:35 AM Geoff Boeing @.***>
wrote:

@arjunbanker https://github.com/arjunbanker I'm not seeing this error
with GeoPandas 0.13.x or 0.14.x. Can you provide a complete list of your
package versions (such as with conda list) and the complete error
traceback? Thanks.
—
Reply to this email directly, view it on GitHub
https://github.com/gboeing/osmnx-examples/pull/73#issuecomment-1722538199,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAEVCJTGX3EEF5FDFDYLQ3X247I5ANCNFSM6AAAAAA42RJ6XY
.
You are receiving this because you were mentioned.Message ID:
@.***>

I'm still unable to reproduce this error with OSMnx 1.6.0, GeoPandas 0.13.2 or 0.14.0, and Folium 0.14.0. If this is a conflict with a recent version of one of the dependencies, I cannot see where it comes from. Can you try another environment to see if you can reproduce it elsewhere? For example, try Binder.

appreciate the link to Binder! the issue doesn't seem to reproduce there, so it was likely some local dependency issue on my end. closing this out


Refactor permission checking

This creates a new ActionsBasedPermissions to manage permissions on a view.
The old version couldn't distinguish between a POST to create a transaction
and a POST to take a transaction.
The new version checks for individual permissions so that they can be
assigned and managed better.

@SteveMarshall @ibrechin review/merge?

Should we have some tests for ActionsBasedPermissions?

@marcofucci Also: first line of commit should be “Refactor […]”, not “Refactored” :wink:

@SteveMarshall I'll be more careful next time ;-)

@SteveMarshall I think everything is now covered, can you merge it if happy?

:boom:


How to provision C.H.I.P board ?

Hi,
I successfully built images but cannot find any instruction about how to flash them to C.H.I.P.
Can you help me figuring it out ?
Thanks

There are a set of tools chip come with and the build system provides. They are used to flash the board.


Create plugin to publish VSCEs

The repository https://github.com/octorelease/vsce has been created. It is still a WIP but any bugs/enhancements can be tracked there 🙂


Release Google.Cloud.Domains.V1 version 2.2.0

Changes in this release:
No API surface changes; just dependency updates.

Created release for Google.Cloud.Domains.V1-2.2.0


Update README.md

I forgot to add https://github.com/netdata/netdata to web section, please add it if you have a minute

when @mash1t approved, we can merge :)


Users can occlude each other

There is no collision detection between users, so users can occupy the same grid tile.
However, there is a problem with strict "one user per time" in that it can turn doors into bottlenecks, you have to wait for people to clear a door way before anyone else can get through. If that user blocking the doorway is inattentive or lagged out, then it could be a long time before anyone can get through.
I think it would probably be better if everyone could still occupy the same tile, but their avatar got offset be a few pixels, so you could see that there is a stack of people. Perhaps the avatars could even be shrunk a little. Differently shaped avatars with transparent backgrounds would also help.

Fixed with commit cf473342ffa97a78c7c2ad089cad3a5b01c0ab0c


buildah task params test for extra build args

Closes #442
So it was not a bug. Nevertheless, with the added test we can now show how to provide multiple extra args and confirm it works 👍
I will add a FAQ entry about this too 👀
Tasks:

[x] Updated design documents in docs/design directory or not applicable
[x] Updated user-facing documentation in docs directory or not applicable
[x] Ran tests (e.g. make test) or not applicable
[x] Updated changelog or not applicable

I'd love to have an example in the task param description (https://github.com/opendevstack/ods-pipeline/blob/master/deploy/central/tasks-chart/templates/task-ods-package-image.yaml#L68).
E.g. like this:

Extra parameters passed for the build command when building images (e.g. '--build-arg=firstArg=one --build-arg=secondArg=two').

That should be closer to where people need it opposed to the FAQ ... thoughts?

maybe we can reference this as an example in an FAQ entry talking about YAML hehe

Just wanted to mention two tests which are somewhat related:

https://github.com/opendevstack/ods-pipeline/blob/d5a361306eddf30e85a0f67c5519d2570e4685dd/cmd/build-push-image/main_test.go#L10
https://github.com/opendevstack/ods-pipeline/blob/c37d7296a51edeea9b54e6abfbc5858db371cbbd/test/tasks/ods-package-image_test.go#L18

So I am wondering whether we need both task tests. I am leaning towards yes, but I am not sure.

@henrjk I also think we need both. The added test ensures it works end-to-end, your tests are more low-level

@henrjk @michaelsauter I checked first on having a unit test as pointed out by @henrjk but that required more changes in the code base so I preferred to not do for now and just focus on the minimal test provided here


-P now has two meanings

-P means both "just upgrade this package" and "forbid .post versions" - this changed the meaning of -P from before.

 I wonder why didn't click catch it...
Anyway I want to go with the "just upgrade this package" meaning, since that's what pip-compile uses.
What do you think about changing --forbid-post short option to lowercase -p?

Lower case p would be fine with me
On Tue, Jul 30, 2019 at 6:22 PM Peter Demin<EMAIL_ADDRESS>wrote:

Ah, what a shame. I wonder why didn't click catch it...
Anyway I want to go with the "just upgrade this package" meaning, since
that's what pip-compile uses.
What do you think about changing --forbid-post short option to lowercase
-p?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/peterdemin/pip-compile-multi/issues/147?email_source=notifications&email_token=AABYA7W26PE7CA7A2QJUSPDQCC5JVA5CNFSM4IH7KJE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3FPQTI#issuecomment-516618317,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABYA7RJNWCXKE2H34NHG5LQCC5JVANCNFSM4IH7KJEQ
.

Fixed in 1.5.0


fzf: 0.47.0 -> 0.48.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/junegunn/fzf/releases.
meta.description for fzf is: A command-line fuzzy finder written in Go
meta.homepage for fzf is: https://github.com/junegunn/fzf
meta.changelog for fzf is: https://github.com/junegunn/fzf/blob/0.48.0/CHANGELOG.md
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.48.0 with grep in /nix/store/qazhdjwfpi6y6j0zqawnhsca0mvgfkz8-fzf-0.48.0
found 0.48.0 in filename of file in /nix/store/qazhdjwfpi6y6j0zqawnhsca0mvgfkz8-fzf-0.48.0

Rebuild report (if merged into master) (click to expand)

42 total rebuild path(s)

42 package rebuild(s)

First fifty rebuilds by attrpath
adl
ani-cli
arsenal
catcli
clerk
felix-fm
fishPlugins.fzf-fish
fontpreview
fzf
fzf-git-sh
fzf-zsh
kakounePlugins.fzf-kak
kns
license-cli
lunarvim
mov-cli
navi
python311Packages.pyfzf
python312Packages.pyfzf
ripgrep-all
spacevim
sway-launcher-desktop
sysz
tmuxPlugins.extrakto
tmuxPlugins.fuzzback
tmuxPlugins.session-wizard
tmuxPlugins.t-smart-tmux-session-manager
tmuxPlugins.tmux-fzf
unipicker
vimPlugins.fzf-hoogle-vim
vimPlugins.fzf-lua
vimPlugins.fzf-vim
vimPlugins.fzfWrapper
vimPlugins.telescope-zoxide
vimPlugins.vim-fzf-coauthorship
vimPlugins.vim-zettel
vimPlugins.zoxide-vim
xmloscopy
yazi
ytfzf
zoxide
zsh-forgit

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/qazhdjwfpi6y6j0zqawnhsca0mvgfkz8-fzf-0.48.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A fzf https://github.com/r-ryantm/nixpkgs/archive/e68272d5ed965712ebb836709f3be72e8f069c77.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/e68272d5ed965712ebb836709f3be72e8f069c77#fzf

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/qazhdjwfpi6y6j0zqawnhsca0mvgfkz8-fzf-0.48.0
ls -la /nix/store/qazhdjwfpi6y6j0zqawnhsca0mvgfkz8-fzf-0.48.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

50 packages built:

adl
ani-cli
arsenal
arsenal.dist
catcli
catcli.dist
clerk
felix-fm
fishPlugins.fzf-fish
fontpreview
fzf
fzf-git-sh
fzf-zsh
fzf.man
kakounePlugins.fzf-kak
kns
license-cli
lunarvim
mov-cli
mov-cli.dist
navi
ocamlPackages.fzf
ocamlPackages.magic-trace
python311Packages.pyfzf
python311Packages.pyfzf.dist
python312Packages.pyfzf
python312Packages.pyfzf.dist
ripgrep-all
spacevim
sway-launcher-desktop
sysz
tmuxPlugins.extrakto
tmuxPlugins.fuzzback
tmuxPlugins.session-wizard
tmuxPlugins.t-smart-tmux-session-manager
tmuxPlugins.tmux-fzf
unipicker
vimPlugins.fzf-hoogle-vim
vimPlugins.fzf-lua
vimPlugins.fzf-vim
vimPlugins.fzfWrapper
vimPlugins.telescope-zoxide
vimPlugins.vim-fzf-coauthorship
vimPlugins.vim-zettel
vimPlugins.zoxide-vim
xmloscopy
yazi
ytfzf
zoxide
zsh-forgit

Maintainer pings
cc @Br1ght0ne @Ma27 @zowoq for testing.

Builds in general and works but will break shell-completion for all platform (see changelog)
Result of nixpkgs-review pr 295978 run on x86_64-linux 1

48 packages built:

adl
ani-cli
arsenal
arsenal.dist
catcli
catcli.dist
clerk
felix-fm
fishPlugins.fzf-fish
fontpreview
fzf
fzf-git-sh
fzf-zsh
fzf.man
kakounePlugins.fzf-kak
kns
license-cli
lunarvim
mov-cli
mov-cli.dist
navi
python311Packages.pyfzf
python311Packages.pyfzf.dist
python312Packages.pyfzf
python312Packages.pyfzf.dist
ripgrep-all
spacevim
sway-launcher-desktop
sysz
tmuxPlugins.extrakto
tmuxPlugins.fuzzback
tmuxPlugins.session-wizard
tmuxPlugins.t-smart-tmux-session-manager
tmuxPlugins.tmux-fzf
unipicker
vimPlugins.fzf-hoogle-vim
vimPlugins.fzf-lua
vimPlugins.fzf-vim
vimPlugins.fzfWrapper
vimPlugins.telescope-zoxide
vimPlugins.vim-fzf-coauthorship
vimPlugins.vim-zettel
vimPlugins.zoxide-vim
xmloscopy
yazi
ytfzf
zoxide
zsh-forgit

Not fully certain but it appears to be common to move the loading to the module as it requires eval in the users-config now?

Result of nixpkgs-review pr 295978 run on aarch64-darwin 1

1 package marked as broken and skipped:

fontpreview

40 packages built:

ani-cli
arsenal
arsenal.dist
catcli
catcli.dist
felix-fm
fzf
fzf-git-sh
fzf-zsh
fzf.man
license-cli
lunarvim
mov-cli
mov-cli.dist
navi
python311Packages.pyfzf
python311Packages.pyfzf.dist
python312Packages.pyfzf
python312Packages.pyfzf.dist
ripgrep-all
spacevim
sysz
tmuxPlugins.extrakto
tmuxPlugins.fuzzback
tmuxPlugins.session-wizard
tmuxPlugins.tmux-fzf
unipicker
vimPlugins.fzf-hoogle-vim
vimPlugins.fzf-lua
vimPlugins.fzf-vim
vimPlugins.fzfWrapper
vimPlugins.telescope-zoxide
vimPlugins.vim-fzf-coauthorship
vimPlugins.vim-zettel
vimPlugins.zoxide-vim
xmloscopy
yazi
ytfzf
zoxide
zsh-forgit

ℹ In the meantime fzf 0.48.1 has been released. Is there a way for @r-ryantm to pick this up automatically in this PR or will another PR be created?

Not sure about that but I would assume it creates another one. I can create a new one containing 0.48.1 and the fix for the module removing shell-completion install from the derivation itself if you agree that's the way to go-ahead?

@SebTM can you provide more context about and pointers to the removal of the shell completion module? Maybe other PRs that have done so or a README in this repository documenting best practices? That would be helpful for me.

@SebTM can you provide more context about and pointers to the removal of the shell completion module? Maybe other PRs that have done so or a README in this repository documenting best practices? That would be helpful for me.

https://github.com/junegunn/fzf/releases/tag/0.48.0
After seeing that change I checked nixpkgs how other packages using eval to load do that (piping the val to a file to keep behavior or do it by module)
https://github.com/NixOS/nixpkgs/blob/03cce5618f73780156c6cf2b98619d5efd558cee/nixos/modules/programs/zsh/zsh.nix#L68
https://github.com/NixOS/nixpkgs/blob/03cce5618f73780156c6cf2b98619d5efd558cee/nixos/modules/programs/thefuck.nix#L10
https://github.com/NixOS/nixpkgs/blob/03cce5618f73780156c6cf2b98619d5efd558cee/nixos/modules/programs/direnv.nix#L72
so I assumed that could be the preferred way

fzf
https://github.com/nix-community/home-manager/blob/master/modules/programs/fzf.nix#L20
I would say the changes need to be done to both modules

ℹ In the meantime fzf 0.48.1 has been released. Is there a way for @r-ryantm to pick this up automatically in this PR or will another PR be created?

Looks like it will neither update this PR nor create a new one while this is open: https://r.ryantm.com/log/fzf/2024-03-18.log

@SebTM would you be interested in creating a new PR that supersedes this one and includes the various changes that were talked about here?

@SebTM would you be interested in creating a new PR that supersedes this one and includes the various changes that were talked about here?

I can if nobody want's / does it until the weekend before I might not get to it...

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/fzf/versions.
meta.description for fzf is: A command-line fuzzy finder written in Go
meta.homepage for fzf is: https://github.com/junegunn/fzf
meta.changelog for fzf is: https://github.com/junegunn/fzf/blob/0.48.1/CHANGELOG.md
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.48.1 with grep in /nix/store/45p2n2dml8v1xvd6wmyjnzwhr8b4gg9r-fzf-0.48.1
found 0.48.1 in filename of file in /nix/store/45p2n2dml8v1xvd6wmyjnzwhr8b4gg9r-fzf-0.48.1

Rebuild report (if merged into master) (click to expand)

42 total rebuild path(s)

42 package rebuild(s)

First fifty rebuilds by attrpath
adl
ani-cli
arsenal
catcli
clerk
felix-fm
fishPlugins.fzf-fish
fontpreview
fzf
fzf-git-sh
fzf-zsh
kakounePlugins.fzf-kak
kns
license-cli
lunarvim
mov-cli
navi
python311Packages.pyfzf
python312Packages.pyfzf
ripgrep-all
spacevim
sway-launcher-desktop
sysz
tmuxPlugins.extrakto
tmuxPlugins.fuzzback
tmuxPlugins.session-wizard
tmuxPlugins.t-smart-tmux-session-manager
tmuxPlugins.tmux-fzf
unipicker
vimPlugins.fzf-hoogle-vim
vimPlugins.fzf-lua
vimPlugins.fzf-vim
vimPlugins.fzfWrapper
vimPlugins.telescope-zoxide
vimPlugins.vim-fzf-coauthorship
vimPlugins.vim-zettel
vimPlugins.zoxide-vim
xmloscopy
yazi
ytfzf
zoxide
zsh-forgit

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/45p2n2dml8v1xvd6wmyjnzwhr8b4gg9r-fzf-0.48.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A fzf https://github.com/r-ryantm/nixpkgs/archive/2d8947d45957fb80a637427911dfdbf7d0eeb5d7.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/2d8947d45957fb80a637427911dfdbf7d0eeb5d7#fzf

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/45p2n2dml8v1xvd6wmyjnzwhr8b4gg9r-fzf-0.48.1
ls -la /nix/store/45p2n2dml8v1xvd6wmyjnzwhr8b4gg9r-fzf-0.48.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

50 packages built:

adl
ani-cli
arsenal
arsenal.dist
catcli
catcli.dist
clerk
felix-fm
fishPlugins.fzf-fish
fontpreview
fzf
fzf-git-sh
fzf-zsh
fzf.man
kakounePlugins.fzf-kak
kns
license-cli
lunarvim
mov-cli
mov-cli.dist
navi
ocamlPackages.fzf
ocamlPackages.magic-trace
python311Packages.pyfzf
python311Packages.pyfzf.dist
python312Packages.pyfzf
python312Packages.pyfzf.dist
ripgrep-all
spacevim
sway-launcher-desktop
sysz
tmuxPlugins.extrakto
tmuxPlugins.fuzzback
tmuxPlugins.session-wizard
tmuxPlugins.t-smart-tmux-session-manager
tmuxPlugins.tmux-fzf
unipicker
vimPlugins.fzf-hoogle-vim
vimPlugins.fzf-lua
vimPlugins.fzf-vim
vimPlugins.fzfWrapper
vimPlugins.telescope-zoxide
vimPlugins.vim-fzf-coauthorship
vimPlugins.vim-zettel
vimPlugins.zoxide-vim
xmloscopy
yazi
ytfzf
zoxide
zsh-forgit

Maintainer pings
cc @Br1ght0ne @Ma27 @zowoq for testing.

Superseeded by https://github.com/NixOS/nixpkgs/pull/298692


Fix iOS unable to publish 1080p

Rewrite profile level for iOS also
Fixes
https://github.com/livekit/client-sdk-swift/issues/144

@cnderrauber good point... I'm not sure how to investigate this

@cnderrauber
Maybe it works since iOS8
https://developer.apple.com/documentation/videotoolbox/kvtprofilelevel_h264_baseline_5_0


fix(python): Few fts patches

filtering with fts mutated the schema, which caused schema mistmatch problems with hybrid search as it combines fts and vector search tables.
fts with filter failed with with_row_id. This was because row_id was calculated before filtering which caused size mismatch on attaching it after.
The fix for 1 meant that now row_id is attached before filtering but passing a filter to to_lance on a dataset that already contains _rowid raises a panic from lance. So temporarily, in case where fts is used with a filter AND with_row_id, we just force user to using the duckdb pathway.

CI system running OO space, local tests passing


⚠ Bofrost.es has degraded performance

In e53f6b7, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1632 ms

Resolved: Bofrost.es performance has improved in 3ce78bf after 28 minutes.


Integrity check

Check mod files for integrity after download and as part of the update check.
Also provide modpack authors with a tool to automatically create a file with all the checksums.

Implemented in 3.0


APCs should have batteries

Ideally they would charge as the APC is powered and then when the APC is no longer powered the UI starts running off of it.

i was under the impression APCs already had a power storage component, unless you mean giving them replaceable batteries

pretty sure they're replaceable in ss13; benefit in our case is it gives more sources of batteries to scavenge (e.g. for borgs or whatever tools).

sounds like a good idea, a bit concerned that greytide cutting wires will turn into greytide disabling APCs via battery tampering which can affect entire areas vs one localized section where the wire's cut but may not even be an issue depending on implementation

In SS13, APCs have batteries that charge up when power is connected and draw when supply is out, giving you some lee-way when sabotage happens. More upgraded batteries could hold power for a few minutes without interruption.
But wasn't NOT having batteries the point? I remember PJB saying something along the lines of "This was agreed upon that the energy system was to be more reactive like irl (i.e supply falls, everywhere falls) instead of like ss13"?
I'm all up for going towards ss13's implementation tho


Rebuild for RHSA-2021:3058

Fixes: https://github.com/open-cluster-management/backlog/issues/15260
Signed-off-by: Stephen Kitt<EMAIL_ADDRESS>

/lgtm

/cherry-pick release-2.3

/approve
/lgtm

/approve


Quorum control fails

Bug Report
What happened:
site.yml playbook failed when controlling the quorum
TASK [ceph-mon : waiting for the monitor(s) to form the quorum...] **********************************************************************************************************
Friday 19 April 2019  14:12:19 +0000 (0:00:00.175)       0:01:04.571 **********
fatal: [zenko-ceph-mimic-0001]: FAILED! =>
msg: |-
The conditional check '(ceph_health_raw.stdout != "") and (ceph_health_raw.stdout | default('{}') | from_json)['state'] in ['leader', 'peon']
' failed. The error was: No JSON object could be decoded
What you expected to happen:
as Ceph-mon are running and listening on port 6789, it whoud pass but
ceph -s also fails
ceph -s
server name not found: [v2:<IP_ADDRESS>:3300 (Name or service not known)
unable to parse addrs in '[v2:<IP_ADDRESS>:3300,v1:<IP_ADDRESS>:6789],[v2:<IP_ADDRESS>:3300,v1:<IP_ADDRESS>:6789],[v2:<IP_ADDRESS>:3300,v1:<IP_ADDRESS>:6789]'
2019-04-19 14:12:46.726 7f1aca492700 -1 monclient: get_monmap_and_config cannot identify monitors to contact
[errno 22] error connecting to the cluster

seems to wait for a service listening on port 3300

How to reproduce it (minimal and precise):
installation from scratch.
ceph lab : 3 servers with mon, mgr and 3 osds each, and an external rgw
Share your group_vars files, inventory
inventory:
[mons]
zenko-ceph-mimic-0001
zenko-ceph-mimic-0002
zenko-ceph-mimic-0003
[mgrs]
zenko-ceph-mimic-0001
zenko-ceph-mimic-0002
zenko-ceph-mimic-0003
[osds]
zenko-ceph-mimic-0001 devices="['/dev/xvdb','/dev/xvdc','/dev/xvdd']"
zenko-ceph-mimic-0002 devices="['/dev/xvdb','/dev/xvdc','/dev/xvdd']"
zenko-ceph-mimic-0003 devices="['/dev/xvdb','/dev/xvdc','/dev/xvdd']"
[rgws]
zenko-ceph-mimic-rgw
group_vars:
grep -v "^#" all.yml | sed '/^$/d'
dummy:
fetch_directory: ~/ceph-ansible-keys
cluster: ceph
ceph_origin: repository
ceph_repository: community
ceph_repository_type: cdn
ceph_stable_release: mimic
cephx: true
monitor_interface: eth0
public_network: <IP_ADDRESS>/24
cluster_network: <IP_ADDRESS>/24
osd_objectstore: bluestore
radosgw_civetweb_port: 80
radosgw_interface: eth0
ceph_conf_overrides:
global:
mon_allow_pool_delete: true
mon_health_preluminous_compat: true
mon_health_preluminous_compat_warning: false
osd_pool_default_size: 3
osd_scrub_begin_hour: 20
osd_scrub_end_hour: 6
client.rgw.zenko-mimic-rgw:
host: zenko-mimic-rgw
rgw realm: myrealm
rgw zonegroup: myzonegroup
rgw zone: myzone
grep -v "^#" osds.yml| sed '/^$/d'
dummy:
copy_admin_key: true
osd_scenario: collocated
grep -v "^#" mgrs.yml| sed '/^$/d'
dummy:
copy_admin_key: true
grep -v "^#" rgws.yml| sed '/^$/d'
dummy:
copy_admin_key: true
Environment:

OS (e.g. from /etc/os-release):
NAME="Ubuntu"
VERSION="18.04.2 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.2 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
Kernel (e.g. uname -a):
Linux zenko-ceph-admin 4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Docker version if applicable (e.g. docker version):
No docker
Ansible version (e.g. ansible-playbook --version):
ansible 2.7.5
config file = /etc/ansible/ansible.cfg
configured module search path = [u'/home/cloud/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /usr/local/lib/python2.7/dist-packages/ansible
executable location = /usr/local/bin/ansible
python version = 2.7.15rc1 (default, Nov 12 2018, 14:31:15) [GCC 7.3.0]
ceph-ansible version (e.g. git head or tag or stable branch):
stable brach
Ceph version (e.g. ceph -v):
ceph version 13.2.5 (cbff874f9007f1869bfd3821b7e33b2a6ffd4988) mimic (stable)

Do I miss something in the configuration ?

You should use the stable-3.2 branch for mimic and not stable-4.0 (nautilus)

Hi
works fine with right branch
thx

I wonder why we cannot use stable-4.0 for Mimic?  I thought that your code should work with supported ceph versions.   Should I assume that there is no backward compatibility between releases?  If so, it has to be documented and no options to enable releases older than supported should be allowed.

I wonder why we cannot use stable-4.0 for Mimic?

Because Nautilus introduced a lot a changes and Mimic was already supported on the stable-3.x branch

Should I assume that there is no backward compatibility between releases? If so, it has to be documented and no options to enable releases older than supported should be allowed

http://docs.ceph.com/ceph-ansible/master/#releases

Thank you for your reply.   Unfortunately, some good changes like possible podman support or fixes from the master will possibly not backported to stable-3.2.  I assume that versions are related to RHEL storage cluster versions and whence there is no reason to backport new features.  Nautilus is relatively young so we would like to push Mimic in production for now.     Especially because of the massive changes such as v2 messaging etc .


plugins: add AssemblyAI STT plugin

I've tested this contribution both against the built-in tests, as well as within our Assort Health voice assistant app. Every so often it struggles with picking up short utterances, but that may have more to do with its integration specifically with our app. tests/test_stt test results:

We're upstreaming so that others can use our AssemblyAI plugin, however we can't commit right now to maintaining it.
Two notes: The below test failures are unrelated, and this just implements streaming

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

Thanks @oconnoob for the comments, I should be able to get to them mid week

Hey, this pull request was automatically closed when we deleted the dev branch.
Can you reopen this PR against the main branch. We're looking forward to merge this PR