Nearest Neighbour algorithms

Nearest neighbour algorithms are an item in the roadmap. They're helpful in clustering algorithms, particularly DBSCAN. There are a number of existing implementations of advanced nearest neighbour algorithms in the Rust ecosystem, but they are not compatible with ndarray so they'd need to be modified to be included in Linfa.
Existing algorithms I found:

Linear search: The simplest and least efficient method. O(N) time. Already exists in our DBSCAN implementation.
K-D tree: O(logN) data structure. The kdtree crate looks pretty solid.
BSP tree: O(logN) data structure. This binary_space_partition crate is pretty basic so I'm not sure how useful it is to us. BSP tree is also the nearest neighbour implementation use by SmartCore.
Ball tree: O(logN) as well. This ball_tree crate implements the algorithm.
R* tree: O(logN) algorithm. The rstar crate is the most well-maintained of the nearest neighbour implementations with existing benchmarks.

We should pick at least one of the O(logN) algorithms to integrate into Linfa, along with linear search due to its simplicity. I'm not sure how many of these algorithms we really need since I don't know the detailed tradeoffs between them.

I used the rstar crate in an initial implementation of approximate dbscan algorithm and it was nice to use. The only thing is that it wasn't possible to use it with an arbitrary number of features, so I had to use const generics. Maybe now that const generics are in stable rust it could be easier easier to use it inside linfa, it would certainly be interesting to try 👍🏻

For it to be compatible with the rest of Linfa we'd have to make rstar work with ndarray, which uses runtime values as dimensions, so I don't think const generics helps there.

this is a good analysis of the state of space partition algorithms atm :+1: do you think that approximate nearest neighbor would also fit into that? I have used the hnsw crate for sparse kernel approximation here https://github.com/rust-ml/linfa/blob/master/algorithms/linfa-kernel/src/sparse.rs#L24 and it worked well

IMO approximate nearest neighbour is a different problem from nearest neighbour, so it'd have its own dedicated section/module. We could also aggregate/integrate approximate nearest neighbour algorithms into Linfa, but I'm not familiar with the state of approximate neighbours in the ecosystem so I decided to stick to normal nearest neighbours.

yeah approximate nearest neighbor should be added behind a feature flag for linfa-nn. This could pull in an additional dependency and add a hyper-parameter to set the recall/speed tradeoff. First we should stick to the space partition you've listed.

One concern is that 'rstar' (and likely many other listed crates as well) only accepts inputs with dimensionality known at compile time. This is incompatible with ndarray, so integrating the algorithm into Linfa would involve putting a reworked version of the code into our repo instead of relying on the crate directly.

only rstar has this constraint, the others are allowing a dynamically sized arrays, but they are not looking as complete by far. Another popular approach are vintage point trees. There is vpsearch but it only implements a nearest neighbor query and no k/eps queries. (also 1 and 2)

Are we interested in parametrizing these algorithms by different distance functions or do we only care about Euclidean/square Euclidean distance?

you could add a simple enum with only a single variant for euclidean distances. If people are interested for other, they could just extend that in the future

Should the distance function be parametrized at compile-time (via a type parameter) or run-time (via an enum)? Run-time parametrization might add a function-call overhead so it may not be ideal. Also, do we want to abstract over all nearest neighbour functions with a trait?

I added some comments in #120 one way how you could solve the type vs enum parametrization is by having both. You could add a distance trait:
trait CustomDistance<F: Float> {
    fn distance<'a>(a: ArrayView1<'a, F>, b: ArrayView2<'a, F>) -> F;
}

and accept that in your type definitions. An enum would define common distance functions and also implements the CustomDistance trait:
enum CommonDistances<F> {
    OneNorm,
    TwoNorm,
    PNorm(F),
    InfNorm,
    //...
}

impl<F: Float> CustomDistance<F> for CommonDistances<F> {
    //...
}

The default parameter would then return CommonDistances::TwoNorm. I doubt that you are running into performance issues when querying for points with a branching distance function. But in doubt you could measure the performance gain compared to a custom distance object.

Thanks to #120, linfa-nn has been created and merged. The following are possible future enhancements.
Algorithms implemented:

[ ] Linear scan
[ ] K-D tree, wrapping over kdtree
[ ] Ball Tree.
- [ ] Optimize ball tree performance to be on par with K-D tree
[ ] BSP Tree. The binary_space_partition crate doesn't implement the queries we need, so we definitely can't depend on it directly.
[ ] R* Tree. The rstar crate is incompatible with ndarray, so we'll have to modify and integrate it into our code.
[ ] Approximate nearest neighbour algorithms. The current traits in linfa-nn should work fine regardless of how precise the implementation is.

Miscellaneous:

[ ] Add benchmarks for points with higher dimensional data? (might give us some extra insights, shouldn't be a complex code change).

Other crates:

[ ] Integrate linfa-nn into DBSCAN. Don't think we can do it for Approximate DBSCAN.
[ ] Parametrize algorithms by the distance function (should work for every algorithm that calls sq_l2_dist(), such as KMeans).

At this moment the linfa-nn doesn't implement any trait from the main Linfa crate. We considered using Fit to abstract over the from_batch() trait method, but from_batch() requires that the input dataset shares the same lifetime as the output index, which is not a restriction expressed by Fit. See this comment for more details.

Approximated dbscan would benefit from using a nn algorithm instead of the recursive search it uses now (https://github.com/rust-ml/linfa/blob/master/algorithms/linfa-clustering/src/appx_dbscan/cells_grid/cell.rs at line 180). I had a (very quick) look at the current nn implementation and it should be doable, similarly to how I did it here at line 103 (sorry for the comments in Italian). I had planned to do it in the near future but I'm quite busy rn, so if somebody else wants to do it go ahead 👍🏻
I admit I did not look too in depth at the nn code, but it seems to me like the kd-tree implementation could be used

I wanted to comment on this to discuss interoperability with rust-cv, but also to show what we have done so far on this task.
For abstractions on nn algorithms, we are currently using this crate: https://docs.rs/space/0.17.0/space/. The abstractions here are designed assuming you have a pre-parameterized nearest neighbor search data structure. There are traits for metrics, knn search, knn point sets, knn maps (where points are keys that correspond to values), and inserting things into knn maps.
While I haven't promoted it very publicly yet, I have created an alternative to HNSW here: https://github.com/rust-cv/hgg. hgg is on crates.io and implements the traits from the space crate. hgg has performed better for me than HNSW on the datasets I have worked with. I have primarily benchmarked it with binary features, which are probably not something linfa works with much, but I would love it if some people in the Rust ML community would perform some benchmarks. I will attach some benchmark results as a CSV file to this message:
recall_insert_knn_64.csv
recall_refactor_hgg_lite.csv
These benchmarks were ran on AKAZE feature descriptors (486 bits each) padded with zeros to 512 bits. The features were extracted from the KITTI dataset as explained on the README. All benchmarks were performed with one thread on an Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz 3.31 GHz. Based on what I have seen, I recommend this crate over the HNSW crate.
I would also like to see if we can standardize our method of creating a metric space. The space crate explicitly uses unsigned integer values, chosen by the Metric implementation: https://docs.rs/space/0.17.0/space/trait.Metric.html. The reason for this is:

Floats themselves can actually violate the triangle inequality if a returned distance is NaN
Some spaces, like hamming space, have small integer distances (like 8 or 16 bits), and for performance reasons it is actually important that the smallest integer type is used
All IEEE floats can be converted into unsigned integers by simply using .to_bits(), and their order is perfectly preserved, so long as they are all positive floating point numbers (even positive infinity is permitted, but NaN is not). Also, all ordered positive distances can be mapped to the range of unsigned integers, provided you choose a sufficiently large unsigned integer.
The comparison operation for unsigned integers doesn't have edge cases that can come up later, and the burden of eliminating NaNs is pushed to the user, rather than the ANN search process

I could see the need for an additional trait for spaces that are more specific than metric spaces, but for metric spaces I think that representing distances with the unsigned integers is reasonable considering the above.
Would linfa be interested in using the space crate for the abstraction over metric spaces and knn? Any thoughts? I just kind of threw the things I was thinking about out here to see what everyone had to say.

linfa uses floats over ints in its algorithms because integer division error can cause correctness issues, in additional to floats being the industry standard in other ML libraries. linfa-nn uses floats to interoperate with the rest of linfa. Regarding NaN issues, we use noisy_float in linfa-nn to catch all instances of NaN in debug builds (this is too expensive to do for release builds). Also we need the algorithms to work for negative floats, which can't just be converted to unsigned ints. Thus I would still like to keep the current version of the NN algorithms on floats, but we could generalize the algorithms across both ints and floats.
Ideally I'd like to reexport traits from space instead of rolling out our own for NN, but there's a few things missing from space that we need in linfa. The biggest blocker is the lack of range queries, which we use to speed up DBSCAN. There's also no trait for constructing a kNN index from a batch of points, though that's something we can roll ourselves. Additionally linfa-nn algorithms works entirely with ArrayViews, which are reference types, so using them with space traits may cause some weird lifetime errors (not too sure about this one).

linfa uses floats over ints in its algorithms because integer division error can cause correctness issues, in additional to floats being the industry standard in other ML libraries. linfa-nn uses floats to interoperate with the rest of linfa. Regarding NaN issues, we use noisy_float in linfa-nn to catch all instances of NaN in debug builds (this is too expensive to do for release builds). Also we need the algorithms to work for negative floats, which can't just be converted to unsigned ints. Thus I would still like to keep the current version of the NN algorithms on floats, but we could generalize the algorithms across both ints and floats.

Yes, on this front, it sounds like you have some algorithms that don't generalize to discrete spaces, but you might have some that do. It might make sense then for me to see if we can create a more specific abstraction for these floating point metrics. For discrete spaces, I am doing NN search with algorithms that perform no division. The algorithms only perform comparisons, and the only requirement is that the triangle inequality is fulfilled. For algorithms where you are subdividing space in ways that assume it can be partitioned infinitely, we might want to just create a separate and more-specific trait for those spaces. I will probably need to dig into what is in linfa today to see your requirements more exactly.

The biggest blocker is the lack of range queries, which we use to speed up DBSCAN.

We can make this happen with additional traits. Again, we might also need abstractions for general "metric spaces", but we can do some digging to figure that out.

There's also no trait for constructing a kNN index from a batch of points, though that's something we can roll ourselves.

In this case I would suggest allowing the user to provide a closure that returns a new instance of the Knn datastructure so you can insert the points into it. If you just mean use of FromIterator for using .collect() like a HashMap, that could just be implemented on the data structure if implements Default and supports that. Either way, I think this can be implemented downstream, and I don't think a shared trait is needed here, but let me know if you think this is specifically needed.

Additionally linfa-nn algorithms works entirely with ArrayViews, which are reference types, so using them with space traits may cause some weird lifetime errors (not too sure about this one).

I think this one is a bit complicated. It isn't possible to store Array2 as points and get ArrayView2 out when you query the nearest points, you would get &Array2 in this case, where the reference depends on the datastructure lifetime. You also can use ArrayView2 as points, but then the lifetime of the data structure will be tied to your ndarray arrays (as it would be in any case), and you would get back &ArrayView2 when performing searches. In either case, to convert to the type you want, you would need to consume the iterator and convert the outputs into ArrayView, putting them into another location (like a Vec). Part of this has to do with the fact that the Generic Associated Type feature puts hard limitations on what I can do with lifetimes in the trait. If this feature is merged soon, then we can resolve that issue, but it might take longer than is currently anticipated by the authors. It seems they currently believe they can get it done before the end of this year. Once that is merged, it will be possible for us to specify iterators that depend on the lifetime of &self when they are borrowed, and we would also be able to specify what type we get back when we perform searches on a particular type using a trait that describes the borrowing (or copying) of that type. We will be further empowered once the existential types feature is complete. For now though, there are several limitations to the implementation due to a lack of type-system features. For instance, it has to return a Vec of references to points because the lifetime to &self has to show up somewhere in the return type, and we don't have access to GATs yet. Basically, I get around these issues by performing more allocation than we should, but I only do it because it has to be done to create an abstraction. Once GATs are merged, these issues go away.
I can perform some preliminary work to see if we can create a cohesive set of traits that will work for all of the spatial queries that linfa needs to do in its clustering searches. You mentioned clustering algorithms, so I will look there (particularly at DBSCAN) and at the existing nearest neighbor search algorithms, but is there anywhere else in linfa that nearest neighbor is being used that I should also take a look at? I would like to make sure that I am able to cover all the bases we can. If there is something we can't write a trait/abstraction for today, then we could just choose a concrete nearest neighbor algorithm for that specific instance, but hopefully we can work out abstractions for everything.

For discrete spaces the you can simply convert your float data into equivalent integer data and feed it into the existing traits/algorithms (this requires the traits to be generalized across floats and ints). The algorithms and interface shouldn't change between discrete and continuous spaces, so I don't think we need new traits. Precision issues with ints actually go beyond just division and partitioning, since errors also happen with square rooting. This means many distances metrics, such as Euclidean distance, don't work with ints/discrete spaces. From my understanding the difference between discrete and non-discrete spaces lies in whether the underlying data are integers, so we could get clever with our bounds and disallow the use of non-float types for continuous-space algorithms and distance metrics.
The reason why I wanted batch construction is because some kNN data structures, such as the tree-based ones in linfa, perform much better when constructed with all the points at once instead of inserting the points one-by-one. This is useful in DBSCAN, where all the points are known beforehand. We can abstract this by having a trait called something like KnnBatch with a constructor method that takes a batch of points. By default it inserts the points one-by-one, but the relevant data structures can implement their own batch constructors.
Regarding lifetimes, our current algorithms don't store Array2s at all. They treat each row in the data as a single point, and stores references to those points (ArrayView1s) in a tree structure. The lifetimes of the stored points are tied to the input data, but the lifetime of query points aren't tied to that of the stored points. In fact, the lifetimes of the two points don't need to be related when calculating distance. I'm not sure if this type of decoupling is possible in space without GATs.
Currently the only place in linfa using kNN algorithms is DBSCAN. We do use our abstract distance metric trait in both DBSCAN and KMeans, and are planning to integrate it into some other algorithms.

For discrete spaces the you can simply convert your float data into equivalent integer data and feed it into the existing traits/algorithms (this requires the traits to be generalized across floats and ints). The algorithms and interface shouldn't change between discrete and continuous spaces, so I don't think we need new traits. Precision issues with ints actually go beyond just division and partitioning, since errors also happen with square rooting. This means many distances metrics, such as Euclidean distance, don't work with ints/discrete spaces. From my understanding the difference between discrete and non-discrete spaces lies in whether the underlying data are integers, so we could get clever with our bounds and disallow the use of non-float types for continuous-space algorithms and distance metrics.

What I would like to point out here is that there are very specific metric spaces you are working with in this case. For instance, you might have some kNN data structures that are specialized in working with euclidean space specifically. In that case, we should probably have a EuclideanMetric trait that does use a float as the unit of distance. However, for kNN data structures that abstract over any metric space (like HNSW), the only thing they rely upon is the triangle inequality, so they cant make assumptions about the underlying space that would allow them to perform a division or square root operation, which is why the integer is a better unit of distance in that case. If there are more specific requirements that kNN data structures might have, we would want to create more specific traits for each one of those scenarios and then provide blanket implementations of those traits for more general kNN data structures (like HNSW) that use the general trait Metric.

The reason why I wanted batch construction is because some kNN data structures, such as the tree-based ones in linfa, perform much better when constructed with all the points at once instead of inserting the points one-by-one. This is useful in DBSCAN, where all the points are known beforehand. We can abstract this by having a trait called something like KnnBatch with a constructor method that takes a batch of points. By default it inserts the points one-by-one, but the relevant data structures can implement their own batch constructors.

I think it would be valuble to use an abstraction here, but I think that the existing Rust traits Extend and FromIterator would allow you to abstract over adding these points. If it makes more sense to add a specific trait to space, we can do that, but I think that these should suffice.

Regarding lifetimes, our current algorithms don't store Array2s at all. They treat each row in the data as a single point, and stores references to those points (ArrayView1s) in a tree structure. The lifetimes of the stored points are tied to the input data, but the lifetime of query points aren't tied to that of the stored points. In fact, the lifetimes of the two points don't need to be related when calculating distance. I'm not sure if this type of decoupling is possible in space without GATs.

The traits in space do not currently support this paradigm, but it makes sense and is important. We might need to have separate types for the returned borrowed points and the inserted points, but, as you mention, I don't think we can do that without GATs, which is unfortunate. I don't think I have a solution off the top of my head to this problem, so I will spend some more time later thinking about how we might deal with this scenario. We might just need to wait for GATs to stabilize.

Currently the only place in linfa using kNN algorithms is DBSCAN. We do use our abstract distance metric trait in both DBSCAN and KMeans, and are planning to integrate it into some other algorithms.

Perfect. I will take a look at those then. Thanks!

I think it would be valuble to use an abstraction here, but I think that the existing Rust traits Extend and FromIterator would allow
you to abstract over adding these points. If it makes more sense to add a specific trait to space, we can do that, but I think that
these should suffice.

Actually, I am going to go back on this. I can add an insert_multiple method to the existing KnnInsert trait that has a default implementation that simply calls insert on every item. I don't see why we shouldn't have that.

What I would like to point out here is that there are very specific metric spaces you are working with in this case. For instance, you might have some kNN data structures that are specialized in working with euclidean space specifically. In that case, we should probably have a EuclideanMetric trait that does use a float as the unit of distance. However, for kNN data structures that abstract over any metric space (like HNSW), the only thing they rely upon is the triangle inequality, so they cant make assumptions about the underlying space that would allow them to perform a division or square root operation, which is why the integer is a better unit of distance in that case. If there are more specific requirements that kNN data structures might have, we would want to create more specific traits for each one of those scenarios and then provide blanket implementations of those traits for more general kNN data structures (like HNSW) that use the general trait Metric.

I think if a specific algorithm/metric only works with specific number types, we can express that restriction on the type level rather than the trait level. For example, if HNSW only works with unsigned ints, then the type bounds should be Hnsw<I: Unsigned>, which would prevent HNSW to be used with floats. For something like Euclidean distance, the type bounds would be Euclidean<F: Float>. If an algorithm does not have either restriction, then we can relax the bounds and allow both ints and floats. Once we restrain the types we can use the same set of traits, since we have already eliminated "invalid" parametrizations such as HNSW with floats.

I think it would be valuble to use an abstraction here, but I think that the existing Rust traits Extend and FromIterator would allow you to abstract over adding these points. If it makes more sense to add a specific trait to space, we can do that, but I think that these should suffice.

The reason I want to use a separate abstraction is because for some data structures, the algorithm for constructing from a batch of data is different than inserting data one-by-one. For those cases we can't just compose FromIterator with insert.

The traits in space do not currently support this paradigm, but it makes sense and is important. We might need to have separate types for the returned borrowed points and the inserted points, but, as you mention, I don't think we can do that without GATs, which is unfortunate. I don't think I have a solution off the top of my head to this problem, so I will spend some more time later thinking about how we might deal with this scenario. We might just need to wait for GATs to stabilize.

Actually if we look at the Add trait it treats LHS and RHS as separate generic types, but RHS defaults to the type of LHS. Maybe we can do something like that for the Metric traits?

I just took another look at Metric and it looks like only the output of the distance function is converted to int; the input can still be floats. The only operations we do with distance values in Linfa are comparisions and basic arithmetic (eg subtractions), and I'm not sure how well ints work in that case.
Also, if the distance function actually produces a NaN, Metric would still convert that NaN into an int, which causes an error in the algorithm. I don't see how converting distances to ints shifts the burden of eliminating NaNs onto the user, since NaN related bugs will still pop up when we run the algorithm. I'd argue that NaN bugs are the burden of users regardless of how we represent distances, since our algorithms assume that the data has no NaN. Integer distances don't help with maintaining triangle equality because they, like float distances, break down when a NaN is produced.

I don't see how converting distances to ints shifts the burden of eliminating NaNs onto the user, since NaN related bugs will still pop up when we run the algorithm. I'd argue that NaN bugs are the burden of users regardless of how we represent distances, since our algorithms assume that the data has no NaN.

The user should panic if they see a distance which is NaN, since that would make the output of the data structure invalid. If the user knows their data has no NaN in it, then they can skip this step, for instance if they perform validation later. As you said, using float or int in this scenario doesn't provide us with any benefit.

The only operations we do with distance values in Linfa are comparisions and basic arithmetic (eg subtractions), and I'm not sure how well ints work in that case.

So long as the index supports arbitrary metric spaces (not just L2, for instance, but even hamming distance or Jaccard distance (1.0 - Jaccard similarity)) then all distances of all precisions can be mapped to the integers given a sufficiently sized integer. For algorithms which don't operate over all metric spaces, more specific units of distance can be used, like f64. Unfortunately, we cannot sort f64 directly either, as f64 do not implement the Ord trait in Rust, as they are not fully ordered. However, since the integers are ordered, they can be used without any extra considerations that the data structure has to make when sorting. hgg takes advantage of this fact, and sorts distances in many places.
Nearest neighbor algorithms which can use BOTH f64 and u64 should simply use u64, as the unsigned integer case provides equivalent ordering and is thus an abstraction over the concept. So, for instance, hgg uses the unsigned integer type.
However, for nearest neighbor algorithms which only work on a subset of those metric spaces which only use f64, or if they rely on a property of f64, we can make a separate Metric trait, for instance, L2Metric, which requires the distance type to be f64. If your algorithm requires f64, then it is likely not abstracting over all metric spaces (which satisfy the triangle inequality), and so we should create a more specific trait so that users know to implement that specific trait if they have a more specific metric.
For instance: If you have a data structure that depends on a distance metric that relies on L2 distances for the underlying space, then it takes a metric that satisfies L2Metric. However, we will also add blanket impls for impl<T> Metric for T where T: L2Metric. The reason we do this is so that the more specific metric ALSO supports data structures which support more general metrics. The implementation could look like:
trait FloatToPositiveIntegerOrdering {
    type Int: Unsigned + Ord + Copy;

    fn to_positive_integer_ordering(self) -> Self::Int;
}

impl<P, T, F> Metric<P> for T where T: L2Metric<P, Unit=F> where F: FloatToPositiveIntegerOrdering {
    type Unit = F::Int;

    fn distance(&self, a: &P, b: &P) -> Self::Unit {
        L2Metric::distance(self, a, b).to_positive_integer_ordering()
    }
}

Now so long as everybody correctly implements the correct MetricL2, MetricL1, etc traits, everyone should be happy. Nobody has to do any extra work, and all of the floats get automatically converted. Every data structure which performs faster with integers can utilize them. Every data structure that needs floats gets them as well.

Ordering floats isn't actually an issue because there are zero-cost abstractions that implement Ord for floats that we currently use (eg noisy-float). Like with integers, those abstractions only break down when encountering a NaN, so ints are floats are equally valid when it comes to ordering/sorting. Are there any other reasons to use float-to-int conversions? You mentioned that some algorithms perform faster, can you elaborate?

Ordering floats isn't actually an issue because there are zero-cost abstractions that implement Ord for floats that we currently use (eg noisy-float).

If one data-structure uses noisy-float, another uses float-ord, and another uses https://doc.rust-lang.org/std/primitive.f64.html#method.total_cmp, then we now have inconsistent concepts of ordering with floats. So every data structure will interpret their order differently. We would expect every spatial datastructure to return the nearest neighbors in the same order, and for them to use the same ordering. Floats have no defined ordering, so we have to determine that ordering at a specific point. I will discuss further down how we can allow floating metrics while also allowing the metric to determine its own ordering, which should deal with this problem.

Like with integers, those abstractions only break down when encountering a NaN, so ints are floats are equally valid when it comes to ordering/sorting.

I agree with this. We need to eliminate NaNs from floats, and I suggest that we do this as soon as possible. Rather than checking this repeatedly and wrapping floats in the downstream implementation to specially treat the ordering of NaNs, this responsibility is moved to the implementer of the trait, who must ensure that there are no NaNs.
I would also note that this does not mean that floats are inherently better than integers, it only means that when it comes to NaN that int and float are equally valid in terms of enforcing the triangle inequality assuming that the user is responsible for filtering out NaNs either way.

Are there any other reasons to use float-to-int conversions?

This allows the downstream crate to assume a full ordering Ord, which I would expect for a metric, and it makes their implementation simpler. Any data structure which abstracts over all metric spaces will have simpler code with unsigned integers than with floats. I can guarantee this since in an arbitrary metric space, the only thing you can rely on is the triangle inequality, therefore the only operations you can use on floats can also be done on integers. Some operations cannot be done on raw floats because they lack the Ord trait (like matching on a.cmp(&b) or sort_unstable()). By making this conversion, it will make all downstream implementations simpler, since they can rely on the Ord trait to work properly.
An alternative to this would be that we could remove the Unsigned bound on the Metric trait, and instead bound it with Ord + Copy + Zero. In the HGG crate, I regularly rely on the fact that points that occupy the same space have a metric distance of zero: https://github.com/rust-cv/hgg/blob/main/src/lib.rs#L1384. If we bound the distance type with Ord + Copy + Zero, then the person implementing the distance can choose the ordering of the float themselves, and we can still abstract over the integers without needing to convert them to floats. So perhaps this is the solution that will work best for us. This way we can utilize NoisyFloat still. Note that NoisyFloat does implement the Zero trait, which means it will satisfy the trait bound Ord + Copy + Zero.

You mentioned that some algorithms perform faster, can you elaborate?

If the above idea of allowing any distance type that implements Ord + Copy + Zero is sufficient, I think we don't need to get into this specific topic. However, if you would like to see benchmarks showing the difference in performance between float and integer distance units, I can set my recall benchmark for HGG here to test both float and int cases (with integers being converted to floats), then we can compare the two on equal footing on a real-world dataset that exercises fast distance calculation and data-locality (and thus will stress the comparison operation).
Let me know if the type Unit: Ord + Copy + Zero (with Zero coming from here) solution will work for you. I know that it doesn't support f64 directly, but it will allow you to set the unit to a wrapper that ensures total ordering and produces the unit of distance for two things which are equal to each other. If this is good, I think I can make this change for you pretty quickly.

@YuhanLiin I added a commit adding my proposal above which would also permit NoisyFloat. Here is what it looks like (documentation also updated): https://github.com/rust-cv/space/blob/b4ec64489b78d24e00ce36b7ec22dd9c901e8189/src/lib.rs#L50

Ord + Copy + Zero looks perfect. In the implementations we should make sure that NaN checks only happen in debug mode, not release mode, for perf reasons.

Ord + Copy + Zero looks perfect. In the implementations we should make sure that NaN checks only happen in debug mode, not release mode, for perf reasons.

Yep, that seems reasonable to me. Here is my update to the docs and the trait bound: https://github.com/rust-cv/space/blob/d47ba8f56ffb85f16f8b24e9312d26113d9449ce/src/lib.rs#L17
Let me know if this looks good, and if so I can update everything. We should also add traits for specific metric spaces as well that you are relying on (such as L2).

Wait why do we still need separate traits for L2 meter space? Are there algorithms that only work for L2 spaces? The algorithms in Linfa only care if metrics satisfy triangle inequality.

Wait why do we still need separate traits for L2 meter space? Are there algorithms that only work for L2 spaces? The algorithms in Linfa only care if metrics satisfy triangle inequality.

You had mentioned dividing the metric before, so I assumed that you were working with a specifc norm. I am not sure that division of the distance metric works in all spaces. Was that only a hypothetical, or is there a situation where you are dividing in Linfa? If so, I would like to see an example, because I am not sure it would work for hamming space, for instance. We might need to figure out exactly what it is that is required by the data structure.

The division was for finding the midpoints between two points, which doesn't actually have anything to do with distance metrics. I mentioned division before because I thought you wanted to convert all the floats into ints. We also have a subtraction of distance values. Specifically, we do distance-from-center-of-circle - radius = distance-to-edge. Are operations like these supported by only a subset of spaces/metrics?

The division was for finding the median in a set of points, which doesn't actually have anything to do with distance metrics. I mentioned division before because I thought you wanted to convert all the floats into ints. We also have a subtraction of distance values. Specifically, we do distance-from-center-of-circle - radius = distance-to-edge. Are operations like these supported by only a subset of spaces/metrics?

Subtraction by a radius is perfectly valid, so long as you consider the less than vs less than or equal to cases.
Computing the median by dividing seems like it might cause some problems. Typically, the way I compute the median roughly is that I collect all of the items into a Vec, then I sort the vector, and then I choose the item at length / 2. I understand that this is not the true median if you have two points in the middle of the vector, but in arbitrary metric spaces, the average of two distances is somewhat arbitrary. Is this the reason why the division is required? We might be able to create a trait bound that could help find the average of two distances.

I am going to expand the trait bounds on the distance type to require the types to support addition and subtraction for that use case you mentioned with radius (I assume ball tree?). Just let me know whether you need division as well and what for, and then we can figure out what additional trait bounds might be needed.

I just checked the ball tree code (which I wrote a while ago) and you're right that the median operation doesn't use division. I mixed it up with another implementation which uses midpoints instead of median. However, there's an operation that averages several points to find the center of a sphere. This requires division for the points, and it may be a good idea to restrict the algorithm to floats to prevent rounding errors. The distances only need to support add/subtract. I'm not sure if any arithmetic type bounds need to be expressed in space, since they can just be placed in the ball tree type signature. On another note, the library we use for KD trees only accepts floats, probably because it most likely also uses division.

However, there's an operation that averages several points to find the center of a sphere.

Based on what I am reading on the Wikpedia page, I think that this would be a specific implementation of the Ball Tree that relies on having f32 vectors as points in L2 space, and the central point could even be chosen by other processes (such as the point closest to the geometric median). You might be able to relax this floating point requirement so that integers can also be used by setting the radius of the ball based on the median and the center of the ball using an existing point in the data set using a process other than the mean.
I would also add that if the ball center is chosen by the centroid, then that assumes that the underlying metric space uses an L2 distance metric. See here for more details: https://en.wikipedia.org/wiki/Centroid#Of_a_finite_set_of_points. The centroid minimizes the sum of squared euclidean distances specifically, and so this would not be relevant for other metric spaces.
If you would like to generalize the ball tree to arbitrary dimensions, one option could be to find the point which minimizes the sum of the distances to all other points, which would be closest to the geometric median. The only problem with this algorithm is that summing a large number of distances could overflow an unsigned integer, so if you would be interested in that, we will need to come up with an additional trait bound that allows two iterators over distances to be compared for their sum to work around the overflow problem. For floats, we would probably want to do this too anyways, since we should probably use a Kahan sum. Additionally, you could choose the center of the ball randomly. Either way, I just want to point out that taking the average to compute the centroid is specific to L2. It would not work on, for instance, strings using levenshtein distance. However, you could create a ball tree over strings using levenshtein distance if the center point is chosen using a different method such as minimizing the sum of distances.
Basically, if we need an additional trait to handle one of these extra situations, we can do that.

On another note, the library we use for KD trees only accepts floats, probably because it most likely also uses division.

Yes, this seems reasonable. KD trees over L2 spaces should probably be specific to floats, whereas KD trees over finite spaces should probably be implemented separately (such as point clouds using integer morton encoded coordinates).
KD trees also cannot abstract over all metric spaces, of course, and for them we could use an L2Metric trait (see previous comment for rough definition) to be used by the Knn trait implementation.

How would we calculate the geometric median for non-L2 spaces? Do we use an approximation? In that case how slow would it be? We should probably have different ways to calculate geometric medians/centroids, one for L2 spaces and one for other spaces. It seems possible to generalize ball trees across all types of spaces, so I'm willing to do that within Linfa once the necessary machinery is complete. Also, is it possible to have a non-L2 space with floats? In that case we won't be able to restrict KD trees to L2 spaces by bounding its numerical type to Float, so we'd need different metric traits for different spaces.
BTW, generally speaking, do data structures that support KNN operations also support range queries?

Another neat HNSW implementation https://github.com/InstantDomain/instant-distance

instant-distance only supports f32, so I don't think it fits into our trait.


[TEVA 2126] add code for rerunning of cookie ab test

https://dfedigital.atlassian.net/browse/TEVA-2126

Review app deployed to https://teaching-vacancies-review-pr-3257.london.cloudapps.digital

All looks good now. Thanks @alexbowen

How do we force a particular variant to show, again?

So we're definitely using different text for the gds variant as compared to the other variants? Wondering if we should use the gds text across all variants, to make the test fairer - unless we actively want to test the effect of varying the text.

Looking good - thanks @alexbowen !

So we're definitely using different text for the gds variant as compared to the other variants? Wondering if we should use the gds text across all variants, to make the test fairer - unless we actively want to test the effect of varying the text.

yes i

So we're definitely using different text for the gds variant as compared to the other variants? Wondering if we should use the gds text across all variants, to make the test fairer - unless we actively want to test the effect of varying the text.

thats a question for product/content people really, they wont see it on PR


Warnings at build time [x] referenced in [y] didn't resolve at build time, it will remain unchanged to be resolved at runtime

Environment

Operating System: Linux
Node Version:     v18.18.0
Nuxt Version:     3.11.1
CLI Version:      3.11.0
Nitro Version:    2.9.4
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      devtools, css
Runtime Modules:  -
Build Modules:    -

Reproduction
https://stackblitz.com/edit/github-mrq86l-s2dqph
Describe the bug
After upgrading to 3.11, the build log is filled with messages like:

[x] referenced in [y] didn't resolve at build time, it will remain unchanged to be resolved at runtime

This is introduced when using images from the public folder in styles.
There is two examples in my reproduction, one in main.css and one in the style tag of app.vue.
Running npm run build or npm run generate will produce the warnings when building the client and the server.
Additional context
No response
Logs
No response

Changing to url('~/public/favicon.ico') does the trick.
And shouldn't it be this way to refer to local assets/public file?

Changing to url('~/public/favicon.ico') does the trick.

No it doesn't really do the trick. Because this results in the static file being copied as an asset.
Which means that:

it doesn't benefit from proper browser caching afterwards, because of the hashing
gets needlessly preloaded as if it was a critical part of the application

We're having this issue with our font faces, ie this:
@font-face {
  font-display: swap;
  font-family: "Poppins";
  font-style: normal;
  font-weight: 100;
  src:
    url("/fonts/poppins/poppins-v19-100.woff2") format("woff2"),
    url("/fonts/poppins/poppins-v19-100.woff") format("woff");
}

@font-face {
  font-display: swap;
  font-family: "Poppins";
  font-style: normal;
  font-weight: 300;
  src:
    url("/fonts/poppins/poppins-v19-300.woff2") format("woff2"),
    url("/fonts/poppins/poppins-v19-300.woff") format("woff");
}

[...]

This will then end up inside the manifest and all other places where we then have to specifically remove it from.

I'm also seeing those warnings on all my Nuxt projects where I'm referencing files in my styles.
3.11.0's release notes did mention a "reimplementation of Vite's public asset handling" with #26163

[...] this PR takes full control over public assets and bypasses the vite pipeline entirely for them.

With vite.publicDir.$resolve(val) now only returning false.

I am also getting this warning at build time with:
.landing-grid {
  background: url(/topo_landing_bg.svg);
}

in 3.11.0/1 leads to

/topo_landing_bg.svg referenced in ... didn't resolve at build time, it will remain unchanged to be resolved at runtime

Same issue here, I'm using Nuxt version 3.11.2. The issue persists for the npm run build and npm run generate.

Same issue. Since I have a lot of public files, too many warnings are generated during build.

Same for me with version 3.11.1

Same issue version 3.11.1

Same. 3.11.2

thanks for all the hard work, is there a plan to merge a fix for this in nuxt 3?


Nextest doesn't work in workspace where Cargo.toml of workspace is not hierarchically higher than crates

Output

File structures
Repo
  .cargo/workspace/Cargo.toml
  Crate/
     src/
     Cargo.toml

MinimalRepro repository
What I think the issue is
I believe that nextest assumes that the workspace Cargo.toml will always be in a parent folder of the crates the workspace contains.

Thank you! I've never seen this before to be honest. Do you have a reference in the Cargo documentation for it?

Hi @sunshowers , I'm sorry but I didn't understand what reference do you want me to provide?

Thanks. I had another look at your repro, and to be honest I didn't know that you could use .. in workspace members! It definitely seems rare, I've never seen a Rust project in the wild do this.
This would have to be addressed in the underlying guppy library (also maintained by myself), https://github.com/guppy-rs/guppy. I don't plan to fix this but a patch would be welcome.

I don't plan to work on this, but a patch would be welcome.

I checked the error message, if do not restrict manifest path must within workspace path, nextest can run tests at MinimalRepo. If you are sure this restriction can be bypass optionally, I can try provide patch to Guppy and Nextest.

Patch is ready now, for guppy repository, please review
0001-Help-fix-manifest-might-exist-out-of-workspace-root-.patch

In guppy PR #331 now

Just tagged cargo-nextest 0.9.86-b.1 with a fix -- binaries will be out in around 20 minutes. Please test it out with:
cargo nextest self update --version 0.9.86-b.1


adding navbar on main pageFeat:

Describe the feature
we can add navbar on the first page which contain logo of examtime search toggle and different button.
Add ScreenShots

here at the top we do so on the top
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSoC'24 contributor
[X] I want to work on this issue

please assign me this

@hereisSwapnil, can you assign it to me if the work has not been finished?

I want to resolve the issue, kindly assign me the task


#1203 Routine upgrades

Description
This is a routine upgrade of dependencies, including lambdas.  I opened 2 new tickets for dependencies not upgraded here.  Please refer to the issue's comments for links.
I changed ~= to >= in a number of places after noting that the former does not necessarily pull in minor version upgrades.  For all non-patch upgrades, I inspected the relevant changelog.
#1203
Type of change

[x] New feature (non-breaking change which adds functionality) --> upgrades only

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Deployed, including lambdas
[x] Daily stats continue to work as expected

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] New and existing unit tests pass locally with my changes

I verified that nightly stats still works.  Big Query has data for 4/19.


HmIP-RGBW: Light will not turn on when using transition-parameter

I agree to the following

[X] I have read the documentation right now
[X] I have read the FAQs right now
[X] I am aware of the latest release notes
[X] The Backend (CCU/Homegear/...) is working as expected and connected devices are controllable by its own UI.
[X] I am running the latest version of the custom_component (and Home Assistant)

The problem
Hello everyone,
when using the transition-parameter while turning on the HmIP-RGBW, e.g. when activating a scene, the light will not turn on. (Without the transition parameter it will).
I also tried to use the 'light.turn_on'-service in the developer tools with the same result. Here is the YAML when calling the service:
service: light.turn_on
target:
  entity_id: light.wohnzimmer_licht_schrankwand
data:
  transition: 5

What version of HomematicIP (local) has the issue?
1.52.0
What was the last working version of HomematicIP (local)?
No response
What type of installation are you running?
Home Assistant OS
What type of installation are you running for your homematic backend?
RaspberryMatic Standalone
Which version of your homematic backend are you running?
<IP_ADDRESS>31130
What hardware are you running for your system?
Pi4
Which config details do you use

[X] Username and password
[ ] TLS
[ ] callback data (see)

Which interfaces do you use?

[X] Homematic IP
[X] Homematic (Bidcos-RF)
[X] Groups (Heating-Group)
[ ] BidCos-Wired (HM-Wired)

Diagnostics information
No response
Anything in the logs that might be useful for us? The log (full log) is the best source to support trouble shooting!
From Home Assistant Core Log:
2024-01-03 16:37:27.988 WARNING (MainThread) [hahomematic.client] PUT_PARAMSET failed: ClientException [XMLRPC Fault from backend: -1 Generic error (MISSING_NON_OPTIONAL_PARAMETER)] 0033E0C99248BE:1, VALUES, {'COLOR_TEMPERATURE': 4504, 'RAMP_TIME_UNIT': <TimeUnit.SECONDS: 0>, 'RAMP_TIME_VALUE': 5, 'LEVEL': 1.0}

Additional information
No response

A transition to ... which brightness value?

In the example I mentioned, I didn't specifically add a brightness value when calling the service. The service will then use the default brightness of 100%. The log-message I added shows that the brightness value was passed forward correctly { ..., 'LEVEL': 1.0}.
I now also tried to add a brightness value to the service-call with the same result: Works without the transition parameter, but not when using it.

The service will then use the default brightness of 100%.

Thanks, good to know.

Please try this service call, and replace the device_address and  the channel (1-4) with the correct one.
service: homematicip_local.put_paramset
data:
  device_address: "6789"
  channel: 1
  paramset_key: VALUES
  paramset:
    RAMP_TIME_UNIT: 0
    RAMP_TIME_VALUE: 5
    LEVEL: 1

That will give me a similar error:
PUT_PARAMSET failed: ClientException [XMLRPC Fault from backend: -1 Generic error (MISSING_NON_OPTIONAL_PARAMETER)] 0033E0C99248BE:1, VALUES, {'RAMP_TIME_UNIT': 0, 'RAMP_TIME_VALUE': 5, 'LEVEL': 1}

The question is now: What is the MISSING_NON_OPTIONAL_PARAMETER ?
I don't know!
Please create a program in the CCU and check what is needed for a transition.

Please try:
service: homematicip_local.put_paramset
data:
  device_address: "0033E0C99248BE"
  channel: 1
  paramset_key: VALUES
  paramset:
    RAMP_TIME_UNIT: 0
    RAMP_TIME_VALUE: 5
    LEVEL: 1
    HUE: 9
    SATURATION: 80

Also try:
service: homematicip_local.put_paramset
data:
  device_address: "0033E0C99248BE"
  channel: 1
  paramset_key: VALUES
  paramset:
    RAMP_TIME_UNIT: 0
    RAMP_TIME_VALUE: 5
    LEVEL: 1
    HUE: 9
    SATURATION: 0.8

They both didn't work. When creating a program in the CCU it seems to be using the COMBINED_PARAMETER parameter.
The following service call works:
service: homematicip_local.set_device_value
data:
device_address: "0033E0C99248BE"
channel: 1
parameter: COMBINED_PARAMETER
value: L=80,OT=111600,RT=1,TC=6000,RTTOV=0,RTTOU=0
value_type: string
I'm only not yet sure, what all the single parameters mean: L = LEVEL, RT= RAMP_TIME, TC=COLOR_TEMPERATURE, RTTOU=RAMP_TIME_TO_OFF_UNIT, RTTOV=RAMP_TIME_TO_OFF_VALUE, ...?
OT= no idea.

Founfd on https://homematic-forum.de/forum/viewtopic.php?f=58&t=78673&start=20:
L Level = Helligkeitswert [0-100] Integer als % Wert; 0 = Aus; 100 = Ein; 101 = Ignorieren
OT On Time = Einschaltdauer [0 - 108000] Basiseinheit: Sekunden; mit 0 = Dauer an = 31 hrs
RT Ramp (up) Time = Rampenzeit [ 0 - ?? ] Basiseinheit: Sekunden
H Hue = Farbwert "H" [0° - 360°] in Grad
SAT Saturation = Sättigung = "S" [0-100] Integer als % Wert
RTTOV Ramp Time to OFF Value = Ausschalt-Rampenzeit Dauer [ 0 - ?? ] Ausschalt-Rampenzeit: Wert
RTTOU Ramp Time to OFF Unit = Ausschalt-Rampenzeit-Einheit {0, 1, 3} Ausschalt-Rampenzeit: Wert 0 = sec; 1 = min; 3 = ms

Ok, I played around a little and the only thing missing compared to the original parameters seems to be DURATION_UNIT and
DURATION_VALUE.
The following call will work and the light will transition to 100% in 5 seconds:
service: homematicip_local.put_paramset
data:
device_address: "0033E0C99248BE"
channel: 1
paramset_key: VALUES
paramset:
RAMP_TIME_UNIT: 0
RAMP_TIME_VALUE: 5
DURATION_UNIT: 0
DURATION_VALUE: 0
LEVEL: 1

Good job!

For some reason, when adding a ramptime in a CCU-Program the OT-value (DURATION_VALUE?) will be 111600 instead of 0.
I tried both, and they both worked (I'm not sure what would happen after the 111600 seconds though ;-)

Good job!

thanks!

Please test with version 1.53.0b0.
Beta can be enabled in HACS.

click on the integration
open the menu on the upper right
re-download
enable show beta

Tested 1.53.0b0: The light will turn on as expected, but will turn off agian instantly.
I tested again with service call homematicip_local.put_paramset as desribed above with DURATION_VALUE: 0 and there it is happening too. I'm very sorry but I would swear, that it worked with duration=0 when I initially posted the solution.
It seems that it needs to be 111600 instead of 0 after all like in the CCU-program, as I commented above after posting the initial solution.
Tripple tested with this command:
service: homematicip_local.put_paramset data:   device_address: "0033E0C99248BE"   channel: 1   paramset_key: VALUES   paramset:     RAMP_TIME_UNIT: 0     RAMP_TIME_VALUE: 5     DURATION_UNIT: 0     DURATION_VALUE: 111600     LEVEL: 1
Again, very sorry, that I didn't notice the first time...

No problem. Thanks for feedback.

Please retest with 1.53.0b1

1.53.0b1 shows the same behaviour as 1.53.0b0. The light is turning right off again.

Please add a debug log

There is no log message generated after sending the command. But the device behaves excactly as if 0 was transmitted instead of 111600.

ok, just found out about the option to debug an integration:
Here's the log message:
2024-01-08 18:34:58.201 DEBUG (MainThread) [hahomematic.client] PUT_PARAMSET: 0033E0C99248BE:2, VALUES, {'COLOR_TEMPERATURE': 3105, 'DURATION_UNIT': <TimeUnit.SECONDS: 0>, 'DURATION_VALUE': 0, 'RAMP_TIME_UNIT': <TimeUnit.SECONDS: 0>, 'RAMP_TIME_VALUE': 5, 'LEVEL': 1.0}

Please add the integration diagnostics.
Click on the integration / download diagnostics.

config_entry-homematicip_local-06cd027a37c2659929908f1af7e66f0a.json.txt

Are you using this service call?
service: light.turn_on
target:
  entity_id: light.wohnzimmer_licht_schrankwand
data:
  transition: 5

yes

Please retest with the latest beta (b2).

I can confirm that it's working now with 1.53.0b2.
Thank you for your support and for fixing this issue!


Restructure readme

Content should flow better headings should be

Description
Usage

examples next to each usage
link to working examples (new page)

Motivation

other tools, mention gavizo

Known limitations

Drawing renderer
Description
Render drawings from draw.io from a URL or embedded into a webpage.
Maintain interactive support in the drawing in the rendered output, e.g. links, layers and pages.
Other tools
There are some other tools available that permit similar behaviour, namely:

Draw.io Embed-Diagrams - presents drawings as PNG files, can click-to-open them as a SVG

Supports links, pages and layers but only via popup

https://github.com/jgraph/drawio-html5

Requires the 'host application' to provide the data to the tool, rather than the image data coming from a URL

Supported environments

[x] - Html
[x] - GitHub pages
[ ] - GitHub flavoured markdown; script tags are modified in the content
[x] - Regular markdown

Usage
Include this script anywhere:

Embed drawings using any of the below approaches
Embedded content

This is an analogue of  and is equivalent to embedding the drawing based on the embed option in draw.io.
Relative content

This is an analogue of .
Examples
Embedded content
<div class="drawio-diagram" data-diagram-data="zVbbjtsgEP0aPyaywU7Sx1x3H1r1sq2q9qXCNrFpMFgY57Jf38Fgx5a77a6UlTYPyXCYYWDOgYmH18X5TpEy/yBTyj3kp2cPbzyEFqEP3wa4WCDEkQUyxVILBVfggT1SB7q4rGYprQaOWkquWTkEEykETfQAI0rJ09BtL/kwa0kyOgIeEsLH6HeW6tyhwezddeKesix3qRdobidikhwyJWvh8nkI75uPnS5Iu5Y7aJWTVJ56EN56eK2k1NYqzmvKTWnbstm43ROz3b4VFfo5AYfP9c/NHcK/gstS/pgvjvcIT4IoRHahI+G1K8lGkRMTGYBfqEiposqdQF/aqml6hqSrXBccgABMRSv2SOLGwYdxKZnQDTfRyos2gJBay8rybwIIZ5kAm9O9WepIlWZAy9LBWpaAViVJYCtfzWAzCQHZS6GdipDJ43YP0fT8ZGWCrt4gYyoLqtUFXNoA39XASTiYh3Z86gvC0Zj3tNBSS5wGs27pKw9gOCpeRgse0WLJMNuUtflJgaYpk86CKlUeWhuaWFFyczwC0oREwpjmapCCcUZUY1Y5k+IN0foKNCIfj2jE0W1o/FZR9TH+bR4k5HMSU25DO05m3Jw+hmLPMt2djzNxsI651uaBW5oEaNeFoWcoI+xVwYnpTVBobuZacqmajeD5djnb3uqGzoP/UnsjZmHYI/dldzYa3dnRDYMuUBqTFU1f6vP09zq36Hsjsk9AkzYXF29iqbUswKFR36prRj0GXDvCqybZsipt/zSckHawZ2eati4wHuoySQWaMmi9e2benmkCGUGtRMN7sjM4PDm7mFQsmdRsQjktgNBqEswADoK5WUEqBZkmAVpMS+gp4wf8FWXT/jf5x7sezcaqabGXqebayZu53r8lvP0D">

Works on https://laingsimon.github.io/render-drawing/

Relative content

Works on https://laingsimon.github.io/render-drawing/

How it works
The above script will perform the following steps:

Include a link to the stylesheet for this tools: https://laingsimon.github.io/render-drawing/drawio-renderer.css
Include a link to the draw.io render script: https://www.draw.io/js/viewer.min.js
Once the page has finished loading
Look for elements with the drawio-drawing css-class
For each element, render the drawing based on whether it has a data-drawing-data or data-diagram-url attribute

Motivation
This solution supports URL based rendering of the image as if it was an image, as an analogue to gravizo for DOT drawings.
Drawings can be easily embedded within a page by using tooling within Draw.io. This works without any issue, however requires the data about the drawing to be embedded in other content.
Drawings drawn from a file (as produced by saving the drawing to a file) isn't natively supported.
This means that you should save the drawing as a PNG with the data embedded. Once again this works fine, and achieves the expected behaviour as part of this tool - but with the following drawbacks

It is less clear (although would become common practice) that the PNG contains drawing data

An XML - or other identified file - would convey this meaning more effectively

PNGs are non-interactive therefore the following functionality from draw.io isn't supported

Links
Pages
Layers

It was desired that a tool should be able to:

Render a drawing from a hosted file (so that becomes the only file requiring an edit if the drawing needs to be changed)
Render a drawing in a familiar fashion - as similar to img tags as possible
Render a drawing in SVG format to preserve Link, Page and Layer support
Render a drawing from any webpage and (github) markdown content

All but the last point has been covered, due to enforced limitations over the


gtkwave: 3.3.111 -> 3.3.113

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/gtkwave/versions.
meta.description for gtkwave is: "VCD/Waveform viewer for Unix and Win32"
meta.homepage for gtkwave is: "http://gtkwave.sourceforge.net"
meta.changelog for gtkwave is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.3.113 with grep in /nix/store/fk885ba9yk7gk4a8r5iwav96icxxzy73-gtkwave-3.3.113
found 3.3.113 in filename of file in /nix/store/fk885ba9yk7gk4a8r5iwav96icxxzy73-gtkwave-3.3.113

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
gtkwave

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/fk885ba9yk7gk4a8r5iwav96icxxzy73-gtkwave-3.3.113 \
  --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 gtkwave https://github.com/r-ryantm/nixpkgs/archive/31ae091c93177c318b7654aee85d48069d1bee84.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/fk885ba9yk7gk4a8r5iwav96icxxzy73-gtkwave-3.3.113
ls -la /nix/store/fk885ba9yk7gk4a8r5iwav96icxxzy73-gtkwave-3.3.113/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 run on x86_64-linux 1

1 package built:

gtkwave

Maintainer pings
cc @thoughtpolice @jiegec for testing.


Add capability to propagate CMAKE_MODULE_PATH from package to caller

Hope I didn't miss anything in the docs, code nor other issues. I very recently started using CPM and it worked great without any troubles installing. The only slight hiccup I had was that my expectation was that CMAKE_MODULE_PATH from packages used would be propagated to the caller so I could use include with a cmake module from an included package.
My concrete case was using Catch2 which has a Catch.cmake  in its extras directory for test registration with ctest.
Their docs explicitly state that one simply has to do include(Catch) so naturally my first attempt was:

<EMAIL_ADDRESS>
include(Catch)

which failed due to not finding Catch.cmake. I later found that Catch2 even goes out of their way to make sure when included as a subdirectory that it propagates the CMAKE_MODULE_PATH to the caller.
https://github.com/catchorg/Catch2/blob/8008625d7e00d42120b1e10e991f044c280dc88a/CMakeLists.txt#L49
Ideally CPM would forward it (or add an option to do so) to the caller of CPMAddPackage too if that is possible.
My luckily very easy workaround for now was to simply add list(APPEND CMAKE_MODULE_PATH ${Catch2_SOURCE_DIR}/extras) to the cmake file.

Hey thanks for the issue! This is an interesting use-case and breaking for CPM as it adds an additional scope between add_subdirectory and the caller. However, if it a common pattern, it might make sense to add an extra parameter to CPMAddPackage, that could be used to specify variables that should be promoted to the outer scope.
Until then, manually updating the module path as you did seems to be a good way to go.


Question about usage without polluting the build files

Hi Eugene,
Just found out about this thing which might be a solution for the problem I've felt I've had for ages when trying to work with many small modules which is my preferred way of keeping stuff tidy.
Background:
Back in the day, I was using Maven and independent non-monorepo micromodules. Typically, for a monolith webapp I could have more than 20 different pom based modules and working with them simultanously in an Eclipse workspace.
m2eclipse, the eclipse plugin for Maven had this really nice thing that it could handle the classpath resolution so that if you had A depending on B-SNAPSHOT and you actually had B-SNAPSHOT in your workspace, it would automatically be a source dependency instead of a managed maven dependency.
This probably 15 years ago and it was really powerful. There was nice ui for it too, since you'd have the vcs url in your pom, you could just start working on A and if you noticed you needed to fix something in B, you would just right-click the dependency and something like "materialize as source project" and it would git checkout and fix it all up within seconds.
I've been missing this thing ever since starting with sbt and I never really felt anyone knew what I was talking about.
Lately I've been doing a lot of work in node and there you have npm link which basically solves the same problem in a very smooth way.
But now I'm back in Scala land and I'm working with this module A depending on B. I need to iterate over changes in B that I use in A and I need to first change the version of B in A/build.sbt to -SNAPSHOT and then I need to iterate the whole cycle of

B> publishLocal
A> ;reload ;clean ;~test:compile

over and over again.
That's the backstory. And this project really looks like it could solve some of my issues. I however feel my hands are a bit tied in that I wouldn't want to mess up this clients build definitions too much with my workflow specific things.
Therefore I'm wondering if there's a smooth way to use a separate .sbt file not under vcs that could inject these settings non-intrusively…?
So if I could leave the A/build.sbt like:
 "org.myorg" %% "b" % "1.0",

but then have a viktor.sbt file gitignore that switched this out to:
 ProjectRef(IO.toURI("~" / "projects" / "b"), "org.myorg" %% "b" % "1.0")

My sbt foo is still not good enough to tell if this is possible?
Anyway, thanks for this project! (and a bunch of other too :) )

This is an interesting constraint. Thanks for taking your time to post this! Here's the user story I am hearing:

I want to git clone some random project A from GitHub, and start hacking on its transitive dependency B without messing up the original build.sbt of A.

Does the capture the idea? I think we can do this if we mimicked the way subproject dependencies work today, instead of just using it like sriracha is doing right now. To satisfy the user story I am picturing a new srirachaResolver that gets added to all subprojects if the plugin is enabled. When the dependency resolution asks "hey do you have "org.myorg" %% "b" % "1.0"" it would ignore the version part and say yes.

I want to git clone some random project A from GitHub, and start hacking on its transitive dependency B without messing up the original build.sbt of A.

Yes, that's definitely the gist! Sorry about the essay version of it :)
You think it would be hard to implement this?

The resolver itself might not be that hard, but it also needs everything else subproject dependency takes for granted, like making sure it becomes part of the build, and that compile would trigger transitive compilation. All that would be some trial-and-error work.

Just found your blogpost from two years ago and also the comment from OlegYch:
object BuildUtil {
private val localLibs = Try(IO.read(file("local-libs.txt"))).map(_.split('\n').map(_.trim).toSet).getOrElse(Set())
implicit class ProjectExt(p: Project) {
/**
* if artifactId is in local-libs.txt then add project at a sibling directory with that name as a dependency, otherwise add that artifact as a regular dependency
*/
def addAcmeLib(artifactId: String, version: String) = {
val org = "com.acme"
if (localLibs(artifactId)) {
val ref = ProjectRef(file("..") / artifactId, artifactId)
val exclude = allDependencies ~= (_.map(_.exclude(org, artifactId)))
p.dependsOn(ref).aggregate(ref).settings(exclude)
} else {
p.settings(libraryDependencies += org %% artifactId % version)
}}}}

If allDependencies ~= (_.map(_.exclude(org, artifactId))) thing works fine, maybe this is all I need to switch it out without needing to change the build.sbt?

Hm, don't know what I meant with that last comment… I guess the idea looks like its just the same as sriracha.
I'm revisiting this now since we're working with modularizing very fine grain libs and would like to temporarily work with them like a monorepo when figuring out the architecture while still handling them in separate git repos and isolated versioning+publishing.
If I understand the problem, it's that a plugin can only inject settings like allDependencies but cannot stuff into dependsOn because this is not a setting. So therefore we're using enriched methods like def sourceDependency(ref: ClasspathDep[ProjectReference], bin: ModuleID) on the project definition instead. But the problem is then that I cannot externalize this from the vcs'd build definition…
So I would like by some kind of external definitions on .gitignore to:

[x] Remove the binary dependency - seems easy enough with allDependencies ~= (.map(.exclude………
[ ] Add the source dependency

I'm looking into the API - is there no way that could be done with extraProjects, maybe by an extra indirection? Or will I hit something like https://github.com/sbt/sbt/issues/4976 then?
Is a resolver the only reasonable option?


Fix native C-API test for setting empty strings on native

These test are not executed on CI. Reason for doing this was that it wasn't public API and the test mostly acts as C-API alignment examples. But seems like there are now actual schema migration tests, etc. in there. Should we start executing these on CI?

We probably should. Otherwise the chance of them growing stale is too big.


Client control 'transaction_limit' None bug fix

Simulated bug fix

On initial start incorrectly calculates all historic traded data available for matching during cycle
Fix removes this by setting the current traded volume on init
Bug present when restricting data to inplay or data was recorded after initial opening

Coverage increased (+0.03%) to 93.444% when pulling f1a203d0c7ce336ce6addedafa986dde84527a79 on dev into f726f373e445b2444d4ef3928329a408c0f092c4 on master.


RANGER-5018: checkstyle complince updates - agents-audit

What changes were proposed in this pull request?
Updated agents-audit module sources to comply with the checkstyle requirements (from RANGER-5017).
How was this patch tested?
Build with unit tests completed successfully.

Committed in master branch:
commit 1d53fc84dc9a7294b17335ae7c42d6cbd5ea4704
Author: Madhan Neethiraj<EMAIL_ADDRESS>Date:   Thu Dec 5 14:09:26 2024 -0800

    RANGER-5018: checkstyle complince updates - agents-audit


[1.11] Updated module 004 module to reproduce data loss issues

Backport of https://github.com/quarkus-qe/beefy-scenarios/pull/125

waiting for CI, otherwise looks good


Typescript definition "object" types issue

Hi,
When importing into my typescript project, I was forced to import it as a js library and not use the type definition. This was due to several parameters defined as object types.
Typescript does not like this, and so it should either be changed to any or an interface should be created for such parameters.
example:
type StageCallback = (input: any, config?: object) => any;

the config?: object means that we are unable to send in any config parameters. It should either be config?: any or config?: IStageCallbackConfig where you define the interface elsewhere.
There are several appearances of this which need fixing in the definition file

I was too lazy to provide definitions for all the entities, and also I thought that object is stricter than any, but maybe I was wrong.
_Any_way, I've just replaced object with any. Is it good now? Yeah, it isn't good in a sense that it does not provide the full typings for everything, but can it at least be imported now?


Add dark theme

Save our eyes. And batteries.
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme

Hello 🙋🏻♂ I would like to go ahead and tackle this issue.
If it's up for grabs?
The website definitely has a very very white ⚪ background.
But the rest of the site [code snippets] are all in a dark theme anyways.
If I did put together a PR for this issue, would you like to have an icon/svg that users could click to change it back and forth?
Or is this more of a just use system defaults kind of thing.
Just let me know 👌🏻
Thanks


adding zero index to Y axis

Issue Link
All Submissions

[ ] Have you followed the guidelines in our Contributing document?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions

[ ] Does your submission pass tests?
[ ] Have you lint your code locally prior to submission?

Changes to Core Features

[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your core changes, as applicable?
[ ] Have you successfully ran tests with your changes locally?

@Ashutosh00710 my please, thank you also for the awesome graph!


Lots of compiler errors for msvc 2017. Any ideas/plans?

Try build x64 Debug UNICODE.

I'm getting lots of compilation warnings (+one error in line 1083 - undefined string) when building with DUNICODE:
x86_64-w64-mingw32-gcc -DUNICODE -D_UNICODE  -DWEBVIEW_WINAPI=1 -lole32 -lcomctl32 -loleaut32 -luuid -c -o webview-example.exe main.c
with main.c from the README.
After changing string to url in line 1083 and adding, it compiles but doesn't show the window :(
Removing -DUNICODE -D_UNICODE from command line works fine and shows webview dialog.


⚠ Bofrost.de has degraded performance

In 702a16a, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1065 ms

Resolved: Bofrost.de performance has improved in a9d6473.


The method in 0.1.1.RELEASE-nacos-discovery refers to Spring-commons method for version 2.0 causing an error

Describe what happened (or what feature you want)
0.1.1.RELEASE nacos-discovery 调用Spring-commons的方法为2.0以上的jar包中的
Caused by: java.lang.NoSuchMethodError: org.springframework.cloud.client.serviceregistry.AbstractAutoServiceRegistration.(Lorg/springframework/cloud/client/serviceregistry/ServiceRegistry;Lorg/springframework/cloud/client/serviceregistry/AutoServiceRegistrationProperties;)V
Describe what you expected to happen
NacosAutoServiceRegistration构造方法中super(serviceRegistry, autoServiceRegistrationProperties);为2.0的commons中的，与Spring cloud的依赖版本冲突
How to reproduce it (as minimally and precisely as possible)
Tell us your environment
Java 1.8 Spring cloud Dalston.SR1
Anything else we need to know?

NacosAutoServiceRegistration  in  version  0.1.1.RELEASE rely on spring-cloud-commons  1.3.5.RELEASE which is compatible with Edgware. see more information in 版本说明 https://github.com/spring-cloud-incubator/spring-cloud-alibaba/wiki/版本说明

升级cloud版本到Edgware.SR5解决该问题


[Event Request] Page "Service Order Statistics"  Function "UpdateHeaderInfo" OnAfterCalcTotalAmount2

Again Exchange Part Calculation
 [IntegrationEvent(true, true)]
    local procedure OnAfterUpdateHeaderInfo()
    begin
    end;

Proteced Var
TotalAmount2: array[7] of Decimal;
IndexNo: Integer;
 local procedure UpdateHeaderInfo(IndexNo: Integer; var VATAmountLine: Record "VAT Amount Line")
    var
        CurrExchRate: Record "Currency Exchange Rate";
        UseDate: Date;
begin
        TotalServLine[IndexNo]."Inv. Discount Amount" := VATAmountLine.GetTotalInvDiscAmount;
        TotalAmount1[IndexNo] :=
          TotalServLine[IndexNo]."Line Amount" - TotalServLine[IndexNo]."Inv. Discount Amount";
        VATAmount[IndexNo] := VATAmountLine.GetTotalVATAmount;
        if "Prices Including VAT" then begin
            TotalAmount1[IndexNo] := VATAmountLine.GetTotalAmountInclVAT;
            TotalAmount2[IndexNo] := TotalAmount1[IndexNo] - VATAmount[IndexNo];
            TotalServLine[IndexNo]."Line Amount" :=
              TotalAmount1[IndexNo] + TotalServLine[IndexNo]."Inv. Discount Amount";
        end else
            TotalAmount2[IndexNo] := TotalAmount1[IndexNo] + VATAmount[IndexNo];
**OnAfterCalcTotalAmount2()**
        if "Prices Including VAT" then
            TotalServLineLCY[IndexNo].Amount := TotalAmount2[IndexNo]
        else

Please always put the full detailed signature of the requested events and the parameters passed in the call.
GlobalVarAccess was deprecated in 16.x, there is concept of protected var instead. You can list here the global vars that have to be protected and accessible from extensions.

Done :)
Protected vars not needed, wenn Sender is included. I changed it and removed parameter.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Send confirmation email to referrer

Coverage increased (+0.06%) to 91.95% when pulling 858a6c26fa5456e9f5ece3a135ae3827e3f63f13 on send-confirmation-email-to-referrer into e35ec18a68b3f2b0397e0afe04e5c3c724cd3733 on staging.


WAGTAILIMAGES_BACKENDS

.. is removed from code. How to force Wagtail to use Wand as default image resizer engine? Wand is really far better for creating high quality thumbnalis, Pillow is quick and less resource hungry, but quality of thumbnails generated by Wand are significally better .

Simplest way to do this would be to uninstall Pillow, which would make Wagtail use Wand instead.
Please use the support group. for future support questions.

Really?
  File "/srv/wag/lib/python3.4/site-packages/wagtail/wagtailimages/fields.py", line 3, in <module>
    from PIL import Image
ImportError: No module named 'PIL'


DBZ-2618 Support Vitess in local and snapshot docker builds

https://issues.redhat.com/browse/DBZ-2618

Very nice; thanks1


IP fragmentation reassembly

There are two parts to IP fragmentation:

Spike uses the three-tuple to redirect the fragment packet to the correct spike from the special backend pool consisting of all spikes.
The receiving spike stores the fragments in a buffer, and when all fragments of a given packet is received, directs that packet to the correct backend.

This PR includes implementation only for step 2. I held back implementation of step 1 because iirc someone is already working on backend pools.
There are a few issues with this PR, including:

The Maglev paper suggests using the recursion control field of the GRE to ensure fragments are not redirected twice. However, there is no other supported scenario (as far as I can imagine) where the spike receives a packet with GRE below IPV4. Currently the implementation is set not to check the recursion control field.
I implemented the reassembly in Lua instead of Go because it seems wasteful to transfer entire packet contents to Go just for reassembly. I might be mistaken, or there might be a better way to offload work to Go.
The implementation is a little messy; it might be good to isolate the IP fragmentation code from the rest of packet decoding.

Is this one ready? I saw #32 (which this depends on) was initially a WIP; should they just be merged together?

Yeah, this one is ready. #32 isn't ready yet, though -- the tests have yet to be made fully automated.

Looks like you merged #32 into this, so it's not possible to merge this until that one is ready.  If they don't depend on each other, then please separate the commits.

Oh, sorry, I didn't know you couldn't merge them separately. They are technically independent but #32 is necessary to make sure this is working, so I don't think it's a good idea to separate the commits. I think merge both, and leave fully automated testing to another PR.

Ok, will take a look.

These commits address all the comments in the review (that I haven't replied to), and also fix a few bugs in my implementation.

Awesome, thanks.  I will try and get to this sometime soon.

I did the diff of the output on the sample pcap file with the master branch. They differ, but I couldn't find any differences when visually inspecting a few packets. The outputs from tshark -r out.pcap (which shows packet metadata) match, though.

Those pull requests aren't related to this PR.  Please strip those commits from the branch.

Splitting up the changes into smaller PRs, these are only the relevant changes now.

Looks like the branch still contains commits not relevant to this PR, e.g. bce1803.  Could you please remove those?

Okay, those are stripped too.

I figured out why the capture files differ- you fixed a subtle bug that existed previously where we computed the total length of the outer IP packet by incorrectly using the length of the whole ethernet packet, rather than the length of the inner IP packet.


12/08 publish for azps-5.2.0

Docs Build status updates of commit aa2549f:
:warning: Validation status: warnings

File
Status
Preview URL
Details

azps-5.2.0/Az.DataFactory/Get-AzDataFactoryV2DataFlow.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.DataFactory/Remove-AzDataFactoryV2DataFlow.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.DataFactory/Set-AzDataFactoryV2DataFlow.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.KeyVault/Add-AzKeyVaultKey.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.KeyVault/Get-AzKeyVaultCertificate.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.KeyVault/Get-AzKeyVaultKey.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.KeyVault/Remove-AzKeyVaultKey.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.KeyVault/Undo-AzKeyVaultSecretRemoval.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Monitor/Get-AzActivityLogAlert.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Monitor/Get-AzAlertHistory.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Monitor/Get-AzAlertRule.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Monitor/New-AzAlertRuleEmail.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Monitor/New-AzAlertRuleWebhook.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzApplicationGatewayClientAuthConfiguration.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzApplicationGatewaySslProfilePolicy.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzExpressRouteCircuitConnectionConfig.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzNetworkWatcher.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzNetworkWatcherFlowLog.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzNetworkWatcherFlowLogStatus.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzNetworkWatcherNextHop.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzNetworkWatcherPacketCapture.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzNetworkWatcherReachabilityProvidersList.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzNetworkWatcherReachabilityReport.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzNetworkWatcherSecurityGroupView.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzNetworkWatcherTopology.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzNetworkWatcherTroubleshootingResult.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Get-AzVpnClientPackage.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Invoke-AzNetworkWatcherNetworkConfigurationDiagnostic.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/New-AzApplicationGatewayClientAuthConfiguration.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/New-AzNetworkWatcher.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/New-AzNetworkWatcherFlowLog.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/New-AzNetworkWatcherNetworkConfigurationDiagnosticProfile.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/New-AzNetworkWatcherPacketCapture.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/New-AzNetworkWatcherProtocolConfiguration.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/New-AzPacketCaptureFilterConfig.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Remove-AzApplicationGatewayClientAuthConfiguration.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Remove-AzApplicationGatewaySslProfilePolicy.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Remove-AzExpressRouteCircuitConnectionConfig.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Remove-AzNetworkWatcher.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Remove-AzNetworkWatcherFlowLog.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Remove-AzNetworkWatcherPacketCapture.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Resize-AzVirtualNetworkGateway.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Set-AzApplicationGatewayClientAuthConfiguration.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Set-AzApplicationGatewaySslProfilePolicy.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Set-AzNetworkWatcherConfigFlowLog.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Set-AzNetworkWatcherFlowLog.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Start-AzNetworkWatcherResourceTroubleshooting.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Stop-AzNetworkWatcherPacketCapture.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Test-AzNetworkWatcherConnectivity.md
:warning:Warning
View (azps-5.2.0)
Details

azps-5.2.0/Az.Network/Test-AzNetworkWatcherIPFlow.md
:warning:Warning
View (azps-5.2.0)
Details

This comment lists only the first 50 files in the pull request.

azps-5.2.0/Az.DataFactory/Get-AzDataFactoryV2DataFlow.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Set-AzDataFactoryDataFlow.md'.
Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Remove-AzDataFactoryDataFlow.md'.

azps-5.2.0/Az.DataFactory/Remove-AzDataFactoryV2DataFlow.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzDataFactoryDataFlow.md'.
Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Set-AzDataFactoryDataFlow.md'.

azps-5.2.0/Az.DataFactory/Set-AzDataFactoryV2DataFlow.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzDataFactoryDataFlow.md'.

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Add-AzApplicationGatewaySslProfilePolicy.md'.

azps-5.2.0/Az.Network/Remove-AzExpressRouteCircuitConnectionConfig.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: 'New-AzExpressRouteCircuitConnectionConfig.md'.

azps-5.2.0/Az.Network/Remove-AzNetworkWatcher.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzNetworkWatcherConnectionMonitor'.

azps-5.2.0/Az.Network/Remove-AzNetworkWatcherFlowLog.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzNetworkWatcherConnectionMonitor'.
Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzNetworkWatcherFlowLog'.

azps-5.2.0/Az.Network/Remove-AzNetworkWatcherPacketCapture.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzNetworkWatcherConnectionMonitor'.

azps-5.2.0/Az.Network/Resize-AzVirtualNetworkGateway.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Set-AzVirtualNetworkGatewayVpnClientConfig.md'.

azps-5.2.0/Az.Network/Set-AzApplicationGatewayClientAuthConfiguration.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Add-AzApplicationGatewayClientAuthConfiguration.md'.

azps-5.2.0/Az.Network/Set-AzApplicationGatewaySslProfilePolicy.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Add-AzApplicationGatewaySslProfilePolicy.md'.
Line 0, Column 0: [Warning-file-not-found] Invalid file link: './New-AzApplicationGatewaySslProfilePolicy.md'.

azps-5.2.0/Az.Network/Set-AzNetworkWatcherConfigFlowLog.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzNetworkWatcherConnectionMonitor'.

azps-5.2.0/Az.Network/Set-AzNetworkWatcherFlowLog.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzNetworkWatcherConnectionMonitor'.
Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzNetworkWatcherFlowLog'.

azps-5.2.0/Az.Network/Start-AzNetworkWatcherResourceTroubleshooting.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzNetworkWatcherConnectionMonitor'.

azps-5.2.0/Az.Network/Stop-AzNetworkWatcherPacketCapture.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzNetworkWatcherConnectionMonitor'.

azps-5.2.0/Az.Network/Test-AzNetworkWatcherConnectivity.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzNetworkWatcherConnectionMonitor'.

azps-5.2.0/Az.Network/Test-AzNetworkWatcherIPFlow.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './Get-AzNetworkWatcherConnectionMonitor'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Install fails without Python

Bug report
Describe the bug
There's a dependency on Python runtime to install this JavaScript library.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:

Install minimal OS such as Arch/Void
Create a SvelteKit app
Add this lib as a dev dependency
Run Pnpm installation
See error without python runtime

Expected behavior
Python runtime not required for JS library installation.
Screenshots

System information

OS: Arch GNU/Linux aarch64
Browser (if applies): n/a
Version of supabase-js: 1.35.3
Version of Node.js: 16.15.1

Additional context
Deep dependency in realtime lib, at least two pictured above, are triggering the error. Can be reproduced from an Android device using proot-distro inside Termux for mock IoT setup if you don't have a keyboard handy.

@vhscom i'll ask the team to take a look and get back to you on this one. thanks for your patience!

@vhscom there's nothing we can do b/c realtime-js has https://github.com/theturtle32/WebSocket-Node as a dependency and that requires bufferutil.
we just discussed moving to https://github.com/websockets/ws where bufferutil is optional (see: https://github.com/websockets/ws#opt-in-for-performance).


Quick change for docker-compose

Just useful for older versions of Docker apparently.

@mgifford Thank you for this PR and contributing to the project!


How do I inline the style in React Component develement?

I want to develop a react component, but it has two problems.

how to inline the style in js file?
how to remove the hash in build assets?

I would recommend you look at https://github.com/emotion-js/emotion for the CSS.
For the hash see:
https://github.com/timarney/react-app-rewired/issues/301

hash problem I understand.
css , I mean, the less styles don't extract css files, just build styles in js file, not css in js

Try https://github.com/webpack-contrib/mini-css-extract-plugin maybe.

@timarney 😅


Visualization with using rosbag

Hi, how can i visualize with using rosbag file.

Hi, i downloaded rosbag file, i run eagle_rt launch but doesnt work,  are rosbag file topics or topics format different?

According to my research, i open google earth and import kml file, is right?

Right.

Finally, can i visualize like youtube video, if this is possible, how can i do?

To do this demo, you need to use autoware (https://github.com/Autoware-AI/autoware.ai). By starting up autoware's localization, we output pose by lidar localizar, pcd, and vectormap , pose by eagleye_rt(using fix2pose), and visualize them by rviz .
Data to be used ROSBAG https://www.dropbox.com/sh/ks5kg8033f5n3w8/AADv9plEjXnwlxex23Z91kR_a?dl=0 https://www.dropbox.com/sh/mhdib1m1oivotiu/AAD0UnANDsuIsKqcSKHt9WAJa?dl=0 PCD and Vector Map https://drive.google.com/file/d/1Uwp9vwvcZwaoZi4kdjJaY55-LEXIzSxf/view

there is no imu or can_twist data in this bag file

You cannot run eagleye with the sample data of autoware ai.
Please run autoware ai's localizer and eagleye with eagleye's sample data.

i got it, downloaded eagle_sample.bag, pcd and vector map.

i select all pcd files for map, csv files for vector map and tf launch file and run it.

and load bag file

and i select eagle_rt.launch file for localization and load.

finally,  i open rviz and start bag file

doesnt work? are these steps correct or not?

You cannot run eagleye with the sample data of autoware ai(sample_moriyama_....bag).. Please run autoware ai's localizer and eagleye with eagleye's sample data.
the sample data of eagelye https://www.dropbox.com/sh/ks5kg8033f5n3w8/AADv9plEjXnwlxex23Z91kR_a?dl=0 https://www.dropbox.com/sh/mhdib1m1oivotiu/AAD0UnANDsuIsKqcSKHt9WAJa?dl=0

can you explain? i dont understand.

Please run eagleye_rt.launch in a terminal.
Also, please run fix2poze.launch with it.

Hi,
i run eagle_rt.launch and then run fixpose. After that open autoware and load pointcloud, vector map and tf.

After that open rviz.

which frame should be selected for target frame and fixed frame.

Sorry for the late reply, but I will respond in due course.
You do not need to use lidar localizer.
As for frame selection, my memory is dim, so you can try either one.

Since fix2pose sends tf, I think we can check and debug it.
https://github.com/MapIV/eagleye/blob/master/eagleye_util/fix2pose/src/fix2pose.cpp#L131

This issue is closed for now. If you have problems again, please reopen this issue.


Fix case sensitive fluent icon search service

Q
A

Bug fix?
[X]

New feature?
[ ]

New sample?
[ ]

Related issues?
Nothing logged I could find

What's in this Pull Request?
There is an issue in the Icon Picker control where searching for Fluent icon names is case sensitive. For example, searching for "aadlogo" will return an icon, whereas searching for "AADLogo", which is the friendly name of the icon, returns nothing.
Searching for "aadlogo"

Searching for "AADLogo"

This fix ensures that the casing of the search term is ignored so that icons are returned regardless of lower/uppercase characters.
Thanks!

Thank you @mbice for the fix!
I've merged it with a small change: I reverted back !startsWith to startsWith === false because this change reverses the default behavior.

Thanks for the merge, @AJIXuMuK.
Sorry, I should have documented the change to "startsWith" as well. I noticed that this method is not always being called with the startsWith parameter, as it's optional. In the case of the iconPicker, nothing gets passed in, so startsWith === false will never evaluate as true. In the case of the icon picker this means it will always string match from the starting of the string. I changed it to !startsWith so that either explicitly passed in as "false" or not provided would be true.
Thoughts?
Here's the call from icon picker:


build: use okp4d docker image instead of wasmd

In prevision to use all module of okp4d in smart contract, I've replaced the wasmd docker image by ok4d image. The version has been fixed to the latest available (3.0.0).

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

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


ParsePortSpec: handle IPv6 addresses

split out of https://github.com/docker/docker/pull/20315
in order to fix https://github.com/docker/docker/issues/11518
Signed-off-by: Michael Stapelberg<EMAIL_ADDRESS>

Can this be merged? This is kind of essential as you can't bind containers to IPv6-Addresses at the moment. @LK4D4 you seem the most active contributor from the Docker team. Can you review this?

We should add a test case as well, once we work out the implementation.

@dnephin I don’t have strong opinions on how the code should look like. Would you want to add a test and refactor it so that it corresponds to your ideals? :)

I opened #19 with those changes


Upgrade to NB-23

This PR addresses the following updates:

Integration of NB-23
Removal of outdated NB-23 patches
Upgrade of nbcode
Enhancement of frontend components to align with NB-23 requirements

@sid-srini I have tried to address the review comments. Thanks