Add operator version check to cluster

Closes #633

@ibolton336 awesome to see you getting your hands into some of the controller side!

Nice work on this so far @ibolton336 , added some comments to try to help tie up the last pieces.

PR is looking great, thanks for working with me on this @ibolton336 !

Two final small tweaks suggested to re-use consts instead of passing configmap ns/name around. Other than that, LGTM! Is operator PR next?

Thanks for all of the reviews & helping me get up to speed @djwhatle
Operator PR is all done - https://github.com/konveyor/mig-operator/pull/568
UI PR is almost done - need to handle the key not found warning condition. https://github.com/konveyor/mig-ui/pull/1122

@ibolton336 I think we have a problem: when the non-host cluster doesn't have the OPERATOR_VERSION key, other clusters will show up with warnings, making it look like the configmap is missing there.
See screenshot. My OCP 3.11 cluster has latest operator and has `OPERATOR_VERSION: latest, but still raises a warning that makes it unclear what to do.

We also have the problem of: when the host migcluster updates, the other migcluster won't realize it needs to update as well to check again if versions are aligned.

Some possible solutions to the above:

Piggyback on the connection check that migcluster controller does every 1 minute, add some logic that will:

For each cluster, compare the configmap with OPERATOR_VERSION in it, see if matches that clusters status.operatorVersion
If the two don't match, enqueue the cluster for reconcile which will update the status.version and re-run validations
In MigCluster version validation code (already included in this PR), when we detect OPERATOR_VERSION has changed, pull all known MigClusters and set refresh.true on their specs so that they will re-check compatibility with the host cluster.
At this point, all version match validations should be correct

I added a commit, check it out.

Here's what it looks like when there's a version mismatch and it is resolved.
https://user-images.githubusercontent.com/7576968/109848450-48f7e200-7c1e-11eb-919d-89305aad0955.mov
Here's what it looks like when versions previously matched, but now are mismatched
https://user-images.githubusercontent.com/7576968/109848476-51501d00-7c1e-11eb-999c-05eb3c2aa9f3.mov

@ibolton336 I think I had the wrong idea about how we should handle a situation where the configmap w/ version info can't be found. In this case we still should update the status.OperatorVersion to be a blank string. If the user downgrades the version will be stuck on what is was previously (my fault).
Submitting fix

@ibolton336 I'm not sure what's causing it, but there's a bug here leading to repeated reconcile of the MigCluster when the cluster version can't be found in configmap. Working through finding the bug, need to resolve this to avoid serious perf issues.


Panel content centering and title style

With the code below, the top-right corner of the main Panel and its title are not colored. This is fixed if I uncomment the title_style line.
Additionally, I wanted justify = :center to center the entire top half of the main Panel but it has not effect.
julia> function tableKM620_options()
           material_option_numbers = RenderableText(join(string.(collect(1:nrow(tableKM620))), "\n"))
           tableKM620_materials_string = RenderableText(join(tableKM620."Material", "\n"))
           tableKM620_note_string = RenderableText("Ferritic steel includes carbon, low alloy, and alloy steels,\nand ferritic, martensitic, and iron-based age-hardening stainless steels.")
           vline = vLine(material_option_numbers, style = "cyan")
           material_note = Panel(tableKM620_note_string,
                                   title = "Note",
                                   style = "cyan",
                                   fit = true)
           options_panel = Panel(material_option_numbers * " " * vline * " " * tableKM620_materials_string / " ", material_note,
                                   title = "Table KM-620 Options",
                                   #title_style = "cyan bold",
                                   style = "cyan bold",
                                   justify = :center,
                                   title_justify = :center,
                                   fit = true)
           return options_panel
       end
tableKM620_options (generic function with 1 method)

julia> tableKM620 = DataFrame("Material" => ["Ferritic steel",
                                        "Austenitic stainless steel and nickel-based alloys",
                                        "Duplex stainless steel",
                                        "Precipitation hardening, nickel based",
                                        "Aluminum",
                                        "Copper",
                                        "Titanium and zirconium"])
7×1 DataFrame
 Row │ Material
     │ String
─────┼───────────────────────────────────
   1 │ Ferritic steel
   2 │ Austenitic stainless steel and n…
   3 │ Duplex stainless steel
   4 │ Precipitation hardening, nickel …
   5 │ Aluminum
   6 │ Copper
   7 │ Titanium and zirconium

julia> tprint(tableKM620_options())
╭────────────────────────────── Table KM-620 Options ───────────────────────────────╮[/cyan bold]
│  1 │ Ferritic steel                                                               │
│  2 │ Austenitic stainless steel and nickel-based alloys                           │
│  3 │ Duplex stainless steel                                                       │
│  4 │ Precipitation hardening, nickel based                                        │
│  5 │ Aluminum                                                                     │
│  6 │ Copper                                                                       │
│  7 │ Titanium and zirconium                                                       │
│                                                                                │
│  ╭──── Note ───────────────────────────────────────────────────────────────────╮  │
│  │  Ferritic steel includes carbon, low alloy, and alloy steels,               │  │
│  │  and ferritic, martensitic, and iron-based age-hardening stainless steels.  │  │
│  ╰─────────────────────────────────────────────────────────────────────────────╯  │
╰───────────────────────────────────────────────────────────────────────────────────╯

HI,
Thanks for getting in touch.
That seems to be a bug with the way the title line of the panel is created, will fix asap.
For the centering, that's not how it currently works:

using Term

small = Panel(; width=20)
large = Panel(; width=50)

print(Panel(small/large; fit=false, justify=:center))

gives:
╭──────────────────────────────────────────────────────────────────────────────────────╮
│                  ╭──────────────────╮                                                │
│                  ╰──────────────────╯                                                │
│                  ╭────────────────────────────────────────────────╮                  │
│                  ╰────────────────────────────────────────────────╯                  │
╰──────────────────────────────────────────────────────────────────────────────────────╯

and that's because small / large creates a new renderable with width=50 and the entire renderable is centered within the panel. Information about the individual panels is lost by that point so the justify=:center cannot justify each sub-panel.
So currently you'd have to stack the subpanels in a way where the top panel is already centered:
using Term
import Term.layout: Spacer

small = Panel(; width=20)
space = Spacer(15, 2)

large = Panel(; width=50)

print(Panel((space * small * space) / large; fit=false, justify=:center))

╭──────────────────────────────────────────────────────────────────────────────────────╮
│                                 ╭──────────────────╮                                 │
│                                 ╰──────────────────╯                                 │
│                  ╭────────────────────────────────────────────────╮                  │
│                  ╰────────────────────────────────────────────────╯                  │
╰──────────────────────────────────────────────────────────────────────────────────────╯

This is a bit tedious though, so I think I should add versions of vstack and hstack that let users specify how things should be justified so that you can do something like: vstack(small, large; justify=:center) to get what you need.

The title style bug will be fixed in next release - and the release will also include versions of vstack/hstack which allow for centering. I'll notify you when this comes out.

The next version will have code to left/right align and center two renderables: https://github.com/FedeClaudi/Term.jl/blob/545345c44a90eb0eb4ba91334a5945f87616c1d3/src/layout.jl#L148
with also three shorthand notation function: ⊏, ⊐, ⊔ (left, right, center) which can be combined with the stacking function:

p1 = Panel(; width=25)
p2 = Panel(; width=50)

print(
    ⊐(p1,  p2) |> /
  )

                         ╭───────────────────────╮
                         ╰───────────────────────╯
╭────────────────────────────────────────────────╮
╰────────────────────────────────────────────────╯

I'm not very happy with the syntax, but the idea is that you can combine justification with stacking to get the result you're looking for.

Here's the docs: https://fedeclaudi.github.io/Term.jl/dev/basics/content_layout/#Justify

Functionality is great, but the syntax is unfortunate. I tried to work out something better with function composition, but that only seems to work with unary operators. I will probably go with the first method suggested in the docs:
p1, p2 = rightalign(p1, p2)
print(p1/p2)

Maybe a modifying version would be convenient?
rightalign!(p1, p2)
print(p1/p2)

Yeah, I'm not very happy with the syntax too.
Perhaps the best way is to provide additional functions that directly combine justification with vertical stacking: leftstack, centerstack, rightstack... but it starts becoming a lot of function names to remember. I would like to come up with a clever syntax that reduces cognitive load on the user...
My hesitation with the modifying version of these functions is that they potentially change the type of the renderable, though there might be a way to avoid that perhaps...
I'm happy the functionality is good, not I need to come with something clever to make it more intuitive to use!

The next version will have centering, leftalign, and rightalign to do the alignment alone or cvstack, lvstack, rvstack to simultaneously align and vertically stack renderables.


Backport Release 2.17.0 into master

Signed-off-by: Julien Pivotto<EMAIL_ADDRESS>

Note: this Pull Request must me merged, not rebased or squashed.


'content' property can't be CSS Code, e.g. content: '\2022'; throws error

Bug: CSS Code can't be used in the content property, for example content: '\2022'; doesn't work
For a bullet I can't use \2022 as I do in normal CSS. It however works with the character itself ●  (i.e. content: '●';) which is even better. It just is not the way you do it in CSS. I moved some CSS to styled-components and it took me a while to realize what's going on...
Reproduction
https://codesandbox.io/s/styled-components-playground-5hcj9?fontsize=14&hidenavigation=1&theme=dark
Steps to reproduce
Just open the codesandbox link and you'll see the error in the line content: '\2022';
Expected Behavior
Should render a bullet point
Actual Behavior
Throws an error

You'll have to escape the backslash so it's not evaluated in JS. There's a prior issue for this here: https://github.com/styled-components/styled-components/issues/3210#issuecomment-663869829


[IDE][InterfaceGen] Always print the top-level decl in header file generated interfaces.

While the decls being printed for header file generated interfaces were mapped from the top-level clang decls in that file, the Swift decls they correspond to may not be top-level. E.g. top-level functions in the header file can be mapped to property accessors on the Swift side, which were being printed simply as "get" at the top level.
This updates header interface generation to map each decl to its top-level decl before printing.
Resolves rdar://problem/63409659

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - 5cb1f30994358afd0495f06bb887080b543325de

@swift-ci please test OS X Platform


PHPDoc optimizations + median fix

I'm happy to make the first pull request on this repository.
The median function wasn't working. So I fixed it. Also, there where a lot of wrong return types so I changed them to the right ones. (Vips\Image -> Image)
Not sure if I've fixed the _is2D function (should we loop over $value or $value[0]?)

Wow you found a lot of a problems, good job!
The _is2D one should have been caught by the tests, that's strange. I'll have a look.
The median should have been tested too, I'll add one there as well.

I added some more tests to master, _is2D and median are now both checked.


Easier interchangeability with torch optimizers

https://github.com/manuel-delverme/constrained_optimization/blob/bcf17e4a00c656562f1d88d39d1cb6d911b00817/src/torch_constrained/constrained_optimizer.py#L58-L59
The user should be the one performing the zero_grad() step. This would make the constrained_optimizer easily interchangeable with torch optimizers.
Note: we would still have to zero the gradients after extrapolation.

I've been thinking about this for a bit.
The reason we have explicit zero_grads is to do gradient accumulation e.g. two backwards one step.
I didn't want to deal with gradient accumulation with extrapolation so i ended up adding that silent zero.
Do you have an use case where zero_grad is not used? right now you can freely zero twice, the overhead is minimum.


Functors: Turns out they are pretty simple

I implemented @jpfairbanks idea in #194. It seems like it's pretty simple and straightforward, I'm not sure if there is other stuff to do with it. Eventually, it would be cool if the declaration of AbstractFunctor and AbstractMonoidalFunctor could be done automatically, based on the theory signature, but I think that would not change the current design which is done manually.

Some further context, which I know @jpfairbanks is aware of but @olynch may not be: we have an existing implementation of functor in core/Syntax.jl. It's not that great, and we should eventually replace it entirely with something along these lines. However, one thing that the current implementation gets right, and that @jpfairbanks noted at the end of #194, is that you don't have to write boiler plate code for every term constructor in the GAT. It doesn't have to happen in this PR, but whatever eventually replaces the existing functor should not require any boilerplate either.

Yeah I think that having a generic
struct DictFunctor{T} <: AbstractFunctor
   dom::T
   codom::T
   generators::Dict{GATExpr, GATExpr}
end

that stores the map of the generators explicitly as a dictionary would be good. If you wanted to put more of the computation into the julia runtime, then you could have subtype of AbstractFunctor that used dispatch to decide what to do for each generator. Then the method lookup table machinery in julia would be used instead of this dict. I'm not sure which performance option is better, but my understanding of julia suggests that an explicit dict would be faster for large categories and if you needed to make changes, but if you have large hom expressions, but few generators, then the julia machinery might be faster.

OK, I just wrote a macro that automatically creates a abstract type for a "theory map", writes the necessary boilerplate for applying elements of this abstract type to term constructors, and also optionally implements a dict-based concrete struct that has a dict for each type of term, and uses that dict for generators.
Example usage
using Catlab.Theories, Catlab.Present

@present C1(FreeCategory) begin
  A::Ob
  B::Ob
  C::Ob
  f::Hom(A,B)
  g::Hom(A,B)
  h::Hom(B,C)
end

A,B,C = generators(C1,:Ob)
f,g,h = generators(C1,:Hom)

F = DictFunctor(C1, C1, Dict(:A => A, :B => B, :C => C), Dict(:f => f, :g => f, :h => h))

> F(compose(g,h))
compose(f,h)

The code generated by
@theory_map AbstractFunctor(Category(ObExpr, HomExpr)), dict_impl => DictFunctor

is
    abstract type AbstractFunctor end
    function dom(f::AbstractFunctor)::Category
        #= /g/Catlab.jl/src/core/Syntax.jl:430 =#
    end
    function codom(f::AbstractFunctor)::Category
        #= /g/Catlab.jl/src/core/Syntax.jl:431 =#
    end
    begin
        #= /g/Catlab.jl/src/core/Syntax.jl:454 =#
        function (F::AbstractFunctor)(x::HomExpr{:id})
            #= /g/Catlab.jl/src/core/Syntax.jl:455 =#
            id(map(F, x.args))
        end
    end
    begin
        #= /g/Catlab.jl/src/core/Syntax.jl:454 =#
        function (F::AbstractFunctor)(x::HomExpr{:compose})
            #= /g/Catlab.jl/src/core/Syntax.jl:455 =#
            compose(map(F, x.args))
        end
    end
    begin
        struct DictFunctor <: AbstractFunctor
            dom::Any
            codom::Any
            ob_map::Dict{Symbol, ObExpr}
            hom_map::Dict{Symbol, HomExpr}
        end
        begin
            #= /g/Catlab.jl/src/core/Syntax.jl:474 =#
            function (F::DictFunctor)(x::ObExpr{:generator})
                #= /g/Catlab.jl/src/core/Syntax.jl:475 =#
                F.ob_map[x.args[1]]
            end
        end
        begin
            #= /g/Catlab.jl/src/core/Syntax.jl:474 =#
            function (F::DictFunctor)(x::HomExpr{:generator})
                #= /g/Catlab.jl/src/core/Syntax.jl:475 =#
                F.hom_map[x.args[1]]
            end
        end
    end

There are definitely some rough spots, but I wanted to share my progress so far.

Can I have some feedback on this code/direction for this to go in?

Sorry, this fell off my radar. I'll get back to it soon.

I think with a test for FreeSMC in addition to FreeCat, this should be ready. Can't wait to update all our examples to use the DictFunctor!

Oh no.... it looks like I have accidentally depended on something that was introduced post-1.0: "cannot add methods to an abstract type". What does this mean?

It looks like there isn't really a workaround for 1.0 if we want to do this the way we are doing it. The alternative would be to define a function that "calls" the functor, so instead of F(x), we would have call_functor(F,x). I think I'm going to change to that, and I'll open an issue to move to F(x) once we can drop 1.0 compatibility.

I'm really stumped by the following error message.
Functors: Error During Test at /g/Catlab.jl/test/theories/Functor.jl:36
  Test threw exception
  Expression: fmap(F1, compose(g, h)) == compose(f, h)
  MethodError: no method matching fmap(::Main.TestTheories.TypeF1, ::Catlab.Theories.FreeCategory.Hom{:generator})
  Closest candidates are:
    fmap(!Matched::Catlab.Theories.DictFunctor, ::Catlab.Theories.HomExpr{:generator}) at /g/Catlab.jl/src/core/Syntax.jl:484
    fmap(!Matched::Catlab.Theories.DictSymmetricMonoidalFunctor, ::Catlab.Theories.HomExpr{:generator}) at /g/Catlab.jl/src/core/Syntax.jl:484
  Stacktrace:
   [1] (::getfield(Catlab.Theories, Symbol("##4#6")){Main.TestTheories.TypeF1})(::Catlab.Theories.FreeCategory.Hom{:generator}) at /g/Catlab.jl/src/core/Syntax.jl:464
   [2] iterate at ./generator.jl:47 [inlined]
   [3] _collect at ./array.jl:632 [inlined]
   [4] collect_similar(::Array{Catlab.Theories.FreeCategory.Hom{:generator},1}, ::Base.Generator{Array{Catlab.Theories.FreeCategory.Hom{:generator},1},getfield(Catlab.Theories, Symbol("##4#6")){Main.TestTheories.TypeF1}}) at ./array.jl:561
   [5] map(::Function, ::Array{Catlab.Theories.FreeCategory.Hom{:generator},1}) at ./abstractarray.jl:1987
   [6] fmap(::Main.TestTheories.TypeF1, ::Catlab.Theories.FreeCategory.Hom{:compose}) at /g/Catlab.jl/src/core/Syntax.jl:464
   [7] top-level scope at none:0
   [8] include at ./boot.jl:317 [inlined]
   [9] include_relative(::Module, ::String) at ./loading.jl:1044
   [10] include at ./sysimg.jl:29 [inlined]
   [11] include(::String) at /g/Catlab.jl/test/theories/Theories.jl:1
   [12] macro expansion at /g/Catlab.jl/test/theories/Theories.jl:26 [inlined]
   [13] macro expansion at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.0/Test/src/Test.jl:1083 [inlined]
   [14] top-level scope at /g/Catlab.jl/test/theories/Theories.jl:26

When I run methods(fmap), I get
10 methods for generic function fmap:

    fmap(T::AbstractTheoryMap, x::Expr) in Catlab.Syntax at /g/Catlab.jl/src/core/Syntax.jl:411
    fmap(F::Catlab.Theories.AbstractFunctor, x::Catlab.Theories.HomExpr{:id}) in Catlab.Theories at /g/Catlab.jl/src/core/Syntax.jl:464
    fmap(F::Catlab.Theories.AbstractFunctor, x::Catlab.Theories.HomExpr{:compose}) in Catlab.Theories at /g/Catlab.jl/src/core/Syntax.jl:464
    fmap(F::Catlab.Theories.AbstractSymmetricMonoidalFunctor, x::Catlab.Theories.HomExpr{:id}) in Catlab.Theories at /g/Catlab.jl/src/core/Syntax.jl:464
    fmap(F::Catlab.Theories.AbstractSymmetricMonoidalFunctor, x::Catlab.Theories.HomExpr{:compose}) in Catlab.Theories at /g/Catlab.jl/src/core/Syntax.jl:464
    fmap(F::Catlab.Theories.AbstractSymmetricMonoidalFunctor, x::Catlab.Theories.ObExpr{:otimes}) in Catlab.Theories at /g/Catlab.jl/src/core/Syntax.jl:464
    fmap(F::Catlab.Theories.AbstractSymmetricMonoidalFunctor, x::Catlab.Theories.HomExpr{:otimes}) in Catlab.Theories at /g/Catlab.jl/src/core/Syntax.jl:464
    fmap(F::Catlab.Theories.AbstractSymmetricMonoidalFunctor, x::Catlab.Theories.ObExpr{:munit}) in Catlab.Theories at /g/Catlab.jl/src/core/Syntax.jl:464
    fmap(F::Catlab.Theories.AbstractSymmetricMonoidalFunctor, x::Catlab.Theories.HomExpr{:braid}) in Catlab.Theories at /g/Catlab.jl/src/core/Syntax.jl:464
    fmap(F::Main.TestTheories.TypeF1, morph::Catlab.Theories.HomExpr{:generator}) in Main.TestTheories at /g/Catlab.jl/test/theories/Functor.jl:27

which includes a method that should be selected... Is there something that I'm missing?

OK, I don't know what the problem is, but it probably has to do with the generated code, since the stack trace points to the definition of fmap in map_term_constructor.

Sorry I've been slow to get back to this one, and thanks a lot for working on it.
In addition to several unaddressed comments dating back to the original PR, I'll add this comment. Overall I like the approach of having abstract types for functors with different concrete implementations, e.g. based on dictionaries. I am concerned about two related things:

We already have a functor function in the Syntax submodule. I don't want to end up with two totally disjoint implementations of functors that do basically the same thing. It doesn't necessarily have to happen in this PR, but we need to converge to a single system.

The essential property of functors (or more generally homomorphisms of models of GATs) out of GAT expressions is that they are completely determined by their action on generators. Thus as a matter of principle, it should not be necessary to manually write code for every other term constructor (compose, otimes, etc). Practically speaking, it's not too big a deal for small theories like Category or SymmetricMonoidalCategory, but for big theories like we have in GLA, you're going to have a write a ton of boilerplate code. Although it has other issues, this is something that the current functor gets right: it works for any GAT, with no boilerplate required.

I'm confident there's a way to do this that will make everyone happy and get the benefits of both approaches. I'll think about it and follow up with more thoughts.

Yeah I agree that we need to have one system for functors and that the point of this is to minimize the amount of boilerplate. Maybe we should address the fact that the GATExprs don't store julia functions in the head of each term constructor and instead have to do the invoke_term business https://github.com/AlgebraicJulia/Catlab.jl/blob/da743c821cfa4923cb2f283b16d64a11ced2548c/src/core/GAT.jl#L676
before we implement the generic functor refactor. If we stored julia functions in the GATExpr, would you need to implement boilerplate for this method?

You mentioned that possibility before and I think it's a really good idea. If we switch from symbols to functions, we can avoid the ugly and slow reflection performed by invoke_term. I like the idea of addressing this first, then revamping the functor interface along the lines of this PR, but now without the boilerplate problem.

2. The essential property of functors (or more generally homomorphisms of models of GATs) out of GAT expressions is that they are completely determined by their action on generators. Thus, as a matter of principle, you shouldn't have to manually write code for every other term constructor (`compose`, `otimes`, etc). Practically speaking, it's not too big a deal for small theories like `Category` or `SymmetricMonoidalCategory`, but for big theories like we have in GLA, you're going to have a write a ton of boilerplate code. Although it has other issues, this is something that the current `functor` gets right: it works for any GAT, with no boilerplate required.

I'm pretty sure that @theory_map writes that boilerplate automatically... Unless I'm misunderstanding your point.

Oh, maybe I'm misunderstanding the code, but I was referring to lines like
function (F::AbstractMonoidalFunctor)(f::ObExpr{:otimes})
  otimes(map(x->F(x), f.args))
end

which looked like boilerplate. Let's discuss further today to make sure we're on the same page.

Let's resurrect this PR. In response to your question:
function (F::AbstractMonoidalFunctor)(f::ObExpr{:otimes})
  otimes(map(x->F(x), f.args))
end

is in fact automatically generated by @theory_map.

I would also like to resurrect this PR! However, I'd suggest that we postpone that until after our current push on ACSets is finished, hopefully early next year. At that point, I'd like to make a big effort to overhaul how functors are handled in Catlab and the ideas in this PR should certainly be part of that.

@epatters, is this PR superceded by the recent FinFunctors PRs?

Only partly. With regard to the category of categories, what is now in Catlab supersedes this PR and goes a fair bit beyond it, implementing the full 2-category structure of Cat. OTOH, this PR made a start on doing things more generically, with types for monoidal functors and symmetric monoidal functors.
I suppose there are tradeoffs between coding everything by hand, like I've done for FinCat, and taking a more automated approach based on the GATs, as in this PR. Given the fundamental role played by Cat, I think it's reasonable to have a dedicated implementation for FinCat, just like we do for FinSet, even if there is a certain amount of boilerplate. However, when we turn to the full menagerie of 2-categories of categories with extra structure ("doctrines"), we're going to need a more automated approach.
I will close this PR for now, but we should revisit these ideas, especially in conjunction with the (eventual) rewrite of the GAT system.


Int typed UWDs

Adds additional compatibility to typed UWDs to allow for Int types and Expr types. (Currently, only Symbol types are supported.)

This is mergable as soon as tests pass!


feat: switch siteflow API dev to EKS

Context
https://hpinc.kanbanize.com/ctrl_board/49/cards/13104/details/

Closing this PR due to it's public and showing our dev links is not expected behavior


BUG: deleted message can be query

in admin mesage menu,delete message
Deletion Date is update ，but  deleted message can be query
and  batch delete can cause this error (single delete is alright):
Failed to delete: (400, 1102) Invalid value:<PHONE_NUMBER>849465856,5710782368017874944,5719789567299297280

It's the desired behavior that soft-deleted records (e.g. messages) can be queried by admins, and it should be not visible to users.

For batch message deletion, what's your HTTP request URL and request body to request batch deletion?

It's the desired behavior (Not a bug) that soft-deleted records (e.g. messages) can be queried by admins, and it should be not visible to users.
For batch message deletion, what's your HTTP request URL and request body to request batch deletion?

yeah , i mean query by client-side，so it might be a bug
url:  http://xxx:8510/messages?ids=5629717565288382464,5638724764566433792  httpMethod:DELETE

Thanks for reporting.
I will fix related bugs in 6 hours when I am available.

take your time

Fixed.
And there is a related enhancement and I have created another ticket to track: https://github.com/turms-im/turms/issues/979


[ex] Ping timeout crashes the client handler.

When a pong is not received, the following code is ran:
  defp ping(%{pong_received: false}=state),
    do: goaway(state, :ping_timeout)

goaway always returns :ok.
This breaks in this chain:
      :send_ping ->
        state
          |> ping
          |> handler_loop(so_far)

as we are passing [:ok, <<>>] to handler_loop.
Rough crash looks like:
{:function_clause,
 [{Loqui.RanchProtocol, :handler_loop, [:ok, ""],
   [file: 'ex/loqui/lib/loqui/ranch_protocol.ex', line: 70]},
  {Loqui.Server.Http, :loop, 1,
   [file: 'ex/loqui/lib/loqui/server.ex', line: 47]}]}

So, I think crashing the client is expected for a pong failing, but the error isn't right, correct?

Also, this is a server problem, correct?

Duh, correct. The traceback is in server.ex too. My bad


Function names not highlighted in Go

According to Nord golang has colored function names (See official Nord page), however they are missing on my setup. Could you please help me figure out why functions aren't highlighted?

OS: Ubuntu 20.04
Terminal: Gnome Terminal (with Nord theme)
Vim 8.1 with Nord theme. Here the .vimrc

Hi @jdzikowski :wave:
I mostly use Goland (respectively _IntelliJ Ultimate with the official Go plugin to make it the same like the standalone Goland IDE) so I'm currently not up-to-date regarding the state of editor support for Go in Vim, but I know that there's also the govim project that aims to be the main Go plugin for Vim. The plugin is mainly written in Go using the fantastic gopls project which is finally an official language server for Go. This means it natively understands it's own syntax better than using Vimscript. vimgo is mostly developed and maintained by members of the Go team so I guess this is a goof sign for the future of the project 😄
Anyway, the vim-go project was the first Go plugin, is still quite popular and after checking out the repository right now I see it's still actively developed and also already makes use of gopls as main engine.
The plugin is kept minimal, but it can be configured in almost all aspects so you need to enable some option in order to “beautify“ the highlighting. Make sure to check out their extensive tutorial as well as their great :help documentation that also includes the required information about the highlighting configurations.
To answer your question: I guess the option you're looking for it g:go_highlight_functions.
Here's an example with only some of the options you'd like to enable for a better highlighting, but also see :help go.syntax for even more options and details:
let g:go_highlight_structs = 1
let g:go_highlight_methods = 1
let g:go_highlight_functions = 1
let g:go_highlight_function_parameters = 1
let g:go_highlight_operators = 1
let g:go_highlight_types = 1
let g:go_highlight_fields = 1
let g:go_highlight_build_constraints = 1
let g:go_highlight_generate_tags = 1
let g:go_highlight_format_strings = 1
let g:go_highlight_variable_declarations = 1
let g:go_highlight_variable_assignments = 1
let g:go_auto_type_info =1
let g:go_fmt_autosave = 1
let g:go_mod_fmt_autosave = 1
let g:go_gopls_enabled = 1

Thanks, that did the job. This line here is the most important though the others come in handy:
let g:go_highlight_functions = 1
I'm closing the issue since it's resolved.


[g2o] Update to 20230223_git

Fixes #33041, update g2o to 20230223_git.
Solve the following error:
warning: There should be no absolute paths, such as the following, in an installed package:
  G:\vcpkg\packages\g2o_x64-windows
  G:\vcpkg\installed
  G:\vcpkg\buildtrees\g2o
  G:\vcpkg\downloads
Absolute paths were found in the following files:
  G:\vcpkg\packages\g2o_x64-windows\include\g2o\config.h
error: Found 1 post-build check problem(s). To submit these ports to curated catalogs, please first correct the portfile: G:\vcpkg\ports\g2o\portfile.cmake

[x] Changes comply with the maintainer guide
[x] SHA512s are updated for each updated download
[ ] The "supports" clause reflects platforms that may be fixed by this new version
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

I've also tried to make vcpkg work with latest g2o on my setup.
Seems like for windows you also need to add the "openblas" dependency. Dont know if it will make it work for this PR for sure but I guess worth a try.

Duplicate of #42600.


There is a need for event in IdentityOptions

Hi
I am trying to set identityoptions from database.
There is a event for ConfigureApplicationCookie
            services.ConfigureApplicationCookie(options =>
            {
                options.EventsType = typeof(CustomCookieAuthenticationEvents);
            });

But there is no event for identityoptions. If you use appsettings.json for settings, It is very easy.
But if you use database for settings, you have to deal with it.
I think it can be added. I mean:
services.ConfigureIdentityOptions(options =>
            {
                 options.EventsType = typeof(CustomIdentityOptionsEvents);
            }

public class CustomIdentityOptionsEvents  : IdentityOptionsEvents
    {
        private readonly IUnitOfWork _unitOfWork;
        private readonly ILogger<CustomCookieAuthenticationEvents> _logger;

        public CustomIdentityOptionsEvents  (IUnitOfWork unitOfWork, ILogger<CustomCookieAuthenticationEvents> logger)
        {
            _unitOfWork = unitOfWork;
            _logger = logger; // _logger.LogInformation($"{}");
        }

        public override Task ....
        {
        }

thanks
good work

Nothing else except some raw security code has these types of event hooks, it's not something we'd consider for identity, which is meant to be opinionated.


Rename Context with Input

Coverage decreased (-0.02%) to 18.482% when pulling 682e0a5d43fc0fd53e59fc7b473a5757d2e5df0c on input into 27b63211a09014ca12457bc73bd243929bac1cac on master.


Support changes to Fn JSON format

See https://github.com/fnproject/fn/issues/662 (issue) and https://github.com/fnproject/fn/pull/724 (implementation).
Information that was previously stored in FN-prefixed headers has been promoted to first-class JSON fields. Details in the references above.

Fixed


FaultInjection: Fix random number generation

rand() is not thread-safe, so instead use absl::InsecureBitGen and absl::Uniform to generate random numbers.

Thanks for reviewing!


Dedicated servers can only have maximum 15 workers UNLESS you use WorldOptions.sav

Hey.
It would be great to include in readme that BaseCampWorkerMaxNum is basically ignored from PalWorldSettings.ini.
If you want to have more workers then you edit world options from your single player save and grab WorldOptions.sav from it then paste it into your PalworldServer\Pal\Saved\SaveGames\0\XXXXXXXXXXX folder.
You can edit WorldOptions with this: https://gist.github.com/cheahjs/300239464dd84fe6902893b6b9250fd0
So you can either remove WorldOptions.sav (like the readme is recommending) or you can keep it BUT you have to use uesave and bat/py files from above to edit it.

Thanks for the idea, but I think it's a bit off topic for the instructions which I'm trying to keep as clear as possible.


[Shadow] Shadow does not appear if overflow: hidden is set

iPhone 6, iOS 8.1.1
var TestKit = React.createClass({
  render: function() {
    return (
      <View style={styles.main}>
        <Box/>
      </View>
    );
  }
});

var Box = React.createClass({
  render: function() {
    return (
      <View style={styles.box}></View>
    );
  }
});

var styles = StyleSheet.create({
  main: {
    flex: 1,
    backgroundColor: "#f1f1f1",
    justifyContent: "center",
    alignItems: "center"
  },
  box: {
    height: 100,
    width: 100,
    backgroundColor: "#ffffff",
    borderRadius: 10,
    shadowColor: "#000000",
    shadowOpacity: 0.8,
    shadowRadius: 2,
    shadowOffset: {
      height: 1,
      width: 0
    }
  }
});

cc @sahrens If I remember correctly, it's not rendering shadows for phones that are not good enough and by default the simulator fits that.

Some images for this, the shadows is rendered fine on 4s, 5 but not 5s and 6:

Shadow is NOT visible on iPhone 6
Shadow is visible on:

iPhone 5 Simulator
iPad Retina Simulator
iPad 2 Simulator

Shadow is NOT visible on

iPhone 5s Simulator
iPhone 6 Simulator
iPhone 6+ Simulator
iPad Air Simulator

Our GPU fill-rate gating was only for some specific product code, and was no longer necessary after we switched to assets for shadows instead of the layer properties.  There shouldn't be anything in the infra intentionally disabling shadows, probably just some sort of bug - cc @a2, @nicklockwood
That said, I would recommend using assets instead of the shadow properties in general - they tend to perform much better on older devices.

On Mar 29, 2015, at 12:27 PM, Oisin Lavery<EMAIL_ADDRESS>wrote:
Shadow is NOT visible on iPhone 6
Shadow is visible on:
iPhone 5 Simulator
iPad Retina Simulator
iPad 2 Simulator
Shadow is NOT visible on
iPhone 5s Simulator
iPhone 6 Simulator
iPhone 6+ Simulator
iPad Air Simulator
—
Reply to this email directly or view it on GitHub.

The problem is the shadow properties only work on old devices, not the new
ones.
On Monday, March 30, 2015, Spencer Ahrens<EMAIL_ADDRESS>wrote:

Our GPU fill-rate gating was only for some specific product code, and was
no longer necessary after we switched to assets for shadows instead of the
layer properties. There shouldn't be anything in the infra intentionally
disabling shadows, probably just some sort of bug - cc @a2, @nicklockwood
That said, I would recommend using assets instead of the shadow properties
in general - they tend to perform much better on older devices.

On Mar 29, 2015, at 12:27 PM, Oisin Lavery<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>> wrote:
Shadow is NOT visible on iPhone 6
Shadow is visible on:
iPhone 5 Simulator
iPad Retina Simulator
iPad 2 Simulator
Shadow is NOT visible on
iPhone 5s Simulator
iPhone 6 Simulator
iPhone 6+ Simulator
iPad Air Simulator
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/facebook/react-native/issues/449#issuecomment-87484660
.

--
Regards,
Truong Ngoc Dai

:+1: I noticed this today and would be happy to attempt to fix the bug if someone could point me in the right direction.

as far as I get, setShadowOpacity mysteriously not working inside of RCTSetProperty on iPhone simulator running iPhone 5s, iPhone 6, and iPhone 6 plus.

What's the current state of this?

I see the shadow now on the iPhone 5s simulator: https://rnplay.org/plays/6_nkSA
Also see the shadow on the iPhone 6 device.
@oisinlavery Still seeing this issue?

I see the shadow on my iPhone 5s. Let's reopen this if anyone has the issue again.

I found that the shadow disappears once I set overflow: 'hidden' in the view's style. Is this intended behavior?

The shadow typically displays outside the bounds of the view, so if you set
overflow hidden I would expect it to clip the shadow. If you really need
overflow hidden, you could put the shadow properties on a wrapper view that
doesn't hide the overflow?
On Mon, Jun 15, 2015 at 1:10 PM Marius Bergmann<EMAIL_ADDRESS>wrote:

I found that the shadow disappears once I set overflow: 'hidden' in the
view's style. Is this intended behavior?
—
Reply to this email directly or view it on GitHub
https://github.com/facebook/react-native/issues/449#issuecomment-112192402
.

I expected it to clip the overflowing content of the view (like when you have rounded corners), but not the shadow. Apparently this is a very subjective expectation and having a container view for the shadow properties works just as well.

Am 15.06.2015 um 22:53 schrieb Spencer Ahrens<EMAIL_ADDRESS>The shadow typically displays outside the bounds of the view, so if you set
overflow hidden I would expect it to clip the shadow. If you really need
overflow hidden, you could put the shadow properties on a wrapper view that
doesn't hide the overflow?
On Mon, Jun 15, 2015 at 1:10 PM Marius Bergmann<EMAIL_ADDRESS>wrote:

I found that the shadow disappears once I set overflow: 'hidden' in the
view's style. Is this intended behavior?
—
Reply to this email directly or view it on GitHub
https://github.com/facebook/react-native/issues/449#issuecomment-112192402
.

—
Reply to this email directly or view it on GitHub.

@mbrgm: our base reference to all of those questions is the web. Can you add a shadow and overflow hidden on a div in a jsfiddle and see what happens?

@vjeux As I expected, the shadow is visible.
https://jsfiddle.net/L55drqzg/1/

cc @nicklockwood

Yeah, we should try to follow web where possible, but this might be kinda tricky - what do you think, @nicklockwood?

@sahrens I agree, we should try to emulate CSS, as we do for all other aspects of border rendering.
There's a fix I need to make to clipping that will fix this as a side effect anyway.
The best solution in the meantime is to nest two views, with the shadow on the outer view and clipping on the inner view (this is basically what my fix will be, but it'll be done opaquely by the framework instead of explicitly).

What's the status on this?

I'm looking into addressing this, but it will take a while. FWIW, It's not a bug; this is how shadows are supposed to work on iOS, and there are fairly simple workarounds (nesting two views). But we would ideally like React to conform to the CSS spec here, so I'm working to make that happen.

Sorry, I see I already said allthat earlier ¯_(ツ)_/¯

Any updates on this? Thanks...

No progress, I'm afraid. I'd still advocate the nested views approach for now.

Hey folks, I'm moving this one over to ProductPains as per our new policy! Give it an upvote there if you believe this is an important fix: https://productpains.com/post/react-native/shadow-does-not-appear-if-overflow-hidden-is-set-on-ios/
In the meantime, feel free to use the approach that maestro @nicklockwood suggested above. I'm going to close the issue as there isn't much benefit to having it open here and on ProductPains.

Any updates on that? Still experiencing it pon iOS 10.3.3, iPhone 7, overflow: 'hidden' no shadows :/

The workaround to have the shadow style properties in the container View and the overflow: "hidden" style in the inner view is not working for me, perhaps because my container View needs to have position: "absolute" on it.
What I see visually is that the overflow: "hidden" style is ignored and I have the proper shadows.

If anyone runs into this when dealing with an Animated.View, make sure you make both View components be an Animated.View component.  You will also need to set the height on the contained Animated.View in order for overflow: hidden to work on it.

Still happening as of today 😕

+1
Still happening today no shadows when using overflow: hidden


README changes, add FUNDING.yml, disable blank issues

README.md: Direct link to latest release, typo fix, formatting
Also shorten avatar URLs.
『Sorey』, SweetLilyCake, and GameKuchen's avatars were already broken.
Create FUNDING.yml:
https://help.github.com/en/github/administering-a-repository/displaying-a-sponsor-button-in-your-repository
Disable blank issues:
https://help.github.com/en/articles/configuring-issue-templates-for-your-repository

@rauenzi

@rauenzi Is this going to get merged?

Sure, I'll make modifications after.


Add iOS 13 setting setAllowHapticsAndSystemSoundsDuringRecording

📳 iOS 13 added this wonderful new setting you can set on AVAudioSesssion that allows haptics and system sounds while recording is active. Setting this to true means that your own haptics, incoming notifications, etc will trigger the haptic engine rather than being silenced.
Note: Even if you're not actively recording audio just instantiating an instance of AKMicrophone will silence haptics unless you have this setting enabled.

Thanks!


Is QGC master code ready for EKF2 testing using Px4Flow for stable hovering?

I am wondering if the master firmware in QGC is ready to use EKF2 for stable hovering test with Px4FLow. If not, then how about Github master firmware. Please clarify this for me so I can test this today.
Thank you

There is no "QGC master" and "Github master". There is just "master" which refers to the latest code. @ChristophTobler will be able to confirm whether we have full EKF2 optical flow support on master.
Please refrain from opening multiple issues for the same topic, or we will close them.


Running the experimental pipeline?

Hi all!
Let me first thank you for making your source code available!
I was interested in reproducing some of your runs (Table 1 and Figure 3) and found it a bit difficult to do. I found some code to work on the covertype dataset, but nothing else. Is there documentation or some shell scripts that allow me to run more experiments? :-) If not, would it be possible to get a short overview how the code is supposed to be run?
Thank you!
Martin

Hi Martin,
thank you for your interest in our work!
Although @kexinrong  has written all of the cpp code, I will try to the best of my knowledge give you a high-level idea of how to run the experiments until Kexin can chime in. There are roughly two separate folders to look into:

Benchmark: includes instructions for ASKIT and FIGTree.
HBE: includes high level instructions for HBE. The basic way the main programs interact with files is through a config file. This assumes that the data have been normalized so that each dimension of the data has variance 1.

In terms of the experiments, for each dataset in question there are a few things that need to be done:

Preprocess the dataset in order for each column to have variance 1.
Given a kernel (e.g. gaussian) and a bandwidth (typically set to sqrt(2) * n**(-1./(d+4)) for gaussian), compute the ground truth kernel density for the dataset using ComputeExact.cpp that reads a config file where the number of random queries M is specified.
At this point you can run the experiment using ASKIT or FIGTRee.
For HBE, RS:

Run FindAdaptiveEps to find the epsilon parameter for RS, HBE to use in the experiments for comparison.
Run BatchBenchmark to get results on RS, and variants of HBE.

Paris - Thanks for the information!
Hi Martin:
Thanks for reaching out. Please refer to Pari's comments on the overall project structure and preprocessing. A few additions/clarifications:
For Table 1:  RunAdaptive would be the main program for timing/accuracy measurements.  BatchBenchmark is for results related to sketching.
For Figure 3: Diagnosis outputs the estimates of relative variances for RS and HBE for a given dataset.
You can change the main program by modifying the executable in cmake.
Hope it helps!

Thank you, @kexinrong and @psiminelakis! I'll try to work from what you described. It's a bit unfortunate that there is no bash script that exemplifies how to run everything for at least one of the datasets.
I hope it's ok if I keep this open and get back to you if I have more questions.

One additional note: with the new updated datasets, it should be easier to get an example run. For example, if you compile the RunAdaptive as the main executable, you can run adaptive sampling with RS, with eps=0.2 using
./hbe conf/shuttle.cfg gaussian 0.2 true
To run adaptive sampling with HBE, with eps=0.9
./hbe conf/shuttle.cfg gaussian 0.9
The top of each main program contains some comments on example usage.
I also suggest start trying with the shuttle dataset since it's smaller and easier to debug.


Installation question: kubernetes cluster storage class and provisioner

Dear all,
I'm trying to deploy kubeless (version 0.2.3) in top of a kubernetes cluster version 1.7 (with 2 nodes), but I'm unable to make the kafka-0 pod run. It stucks in Pending.
When describing, I get:
Events:
Type     Reason            Age               From               Message

Warning  FailedScheduling  5s (x7 over 36s)  default-scheduler  PersistentVolumeClaim is not bound: "datadir-kafka-0" (repeated 3 times)
and when describing the datadir-kafka-0 pvc I get
Events:
Type    Reason         Age               From                         Message

Normal  FailedBinding  5s (x5 over 54s)  persistentvolume-controller  no persistent volumes available for this claim and no storage class is set
Of course it seems that I don't have the StorageClass deployed (default) neither the provisioner.
I could deploy the same kubeless version in a minikube, but it seems that minikube have the StorageClass deployed by default and the default-storageclass addon enabled.
Therefore the question is: How can I enable the correct Storage Class and a proper provisioner?. In addition to this, should the installation sntructions take this into account?
Thank you in advance
Best

So the Kakfa container is not starting indeed because it cannot find a PV to match the PV claim. So you need to create a PV by hand or configure dynamic storage provisioning.
This is a k8s configuration issue
That said, if you just want to experiment with http triggered functions you can keep on going. The Kafka pod is only required for PubSub functions. Bottom line, kubeless works 50% without Kafka running.

Agree, this is a k8s conf issue, but IMHO it is worth to warn in the installation instructions that you need to configure it, and hopefully to point to some reference to configure the PV and/or SC in the proper way in order to get your kafka up and running
Thanks

For newbs running into this error it would definitely be helpful to have a section in the troubleshooting section about this.

@sabrehagen good idea. We should do that. Especially with the latest refactor, kakfa will actually be optional so we need to clarify all of this in the docs.


Rename on_failure callback to on_connection_failure

"on_failure" is very generic and doesn't state what the failure was. When someone is using lori, they will have an "on_failure" callback that could be any number of failures for that actor. Switching the name to "on_connection_failure" should make it considerably more clear.
Closes #78

Hi @SeanTAllen,
The changelog - changed label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do.
Release notes are added by creating a uniquely named file in the .release-notes directory. We suggest you call the file 79.md to match the number of this pull request.
The basic format of the release notes (using markdown) should be:
## Title

End user description of changes, why it's important,
problems it solves etc.

If a breaking change, make sure to include 1 or more
examples what code would look like prior to this change
and how to update it to work after this change.

Thanks.

This PR wasn't quite right and I'll be doing a separate commit to fix up the issues.


Mark indexstore enum flag types with flag_enum attribute

This makes adjustments to the two indexstore bit flag types: indexstore_symbol_property_t and indexstore_symbol_role_t.

Their enum declarations are now marked with __attribute__((flag_enum))
The functions that return these two types now return the appropriate enum type, instead of uint64_t

The motivation for these changes is for use from Swift. Now, these bit flags are imported into Swift as OptionSets.

This change has some slight overlap with #256 and #281, both contain the same #ifndef __has_attribute handling. Once one merges, I can update the other.

cc @benlangmuir

Friendly ping @benlangmuir

Sorry this got lost.  I don't think this change is safe. Using the enum types as  the return value changes the ABI (they will become 32bit int), and could cause it to silently change again once we add enough cases that they need 64bits of space again.  In C++ we could specify the underlying enum type, but that isn't standard in C.  While clang can support it as a C extension, I'm not sure we want to rely on that for other compilers

Can the flag_enum attribute change go in, even if the return types are left unchanged?
No to push back on anything you said, I am curious about two parts:

Are you able to share more about the ABI requirements? I wouldn't have guessed that there are clients of libIndexStore that don't get rebuilt along with updates.
What are the downsides to relying on extensions to make the enum 64bit?

Thank you, as always, for reviewing

Can the flag_enum attribute change go in, even if the return types are left unchanged?

Yeah, that should be fine.

Are you able to share more about the ABI requirements? I wouldn't have guessed that there are clients of libIndexStore that don't get rebuilt along with updates.

The indexer (IndexStoreDB, or Xcode's internal indexer) load this library with dlopen from the toolchain, and need to support multiple toolchain versions at the same time. So this library needs to be ABI stable - i.e. we cannot remove existing symbols or change their signatures, although it's fine to add new functions.   We could potentially break the ABI by updating the major version and updating all the clients to handle the new ABI.  But our clients would need to be able to handle both the old and new ABIs for a while (probably 1 year or more) in order to transition. So we'd need a really good reason to do that.

What are the downsides to relying on extensions to make the enum 64bit?

It just makes the library less portable.  We're in the process of upstreaming this library to llvm.org, and upstream clang is built by several different compilers for different platforms.  If this extension is available in all those compilers, and doesn't produce any warnings in the default setup, maybe it would be fine to use.

Following up on the 64bit point, you had said:

and could cause it to silently change again once we add enough cases that they need 64bits of space again.

If enough cases are added to push it over 32bit, then compiler extensions will be required to make the enum 64bits. Is this enough motivation to go down that path sooner than later? Or do you think it's better to wait until the need forces their use?

If enough cases are added to push it over 32bit, then compiler extensions will be required to make the enum 64bits. Is this enough motivation to go down that path sooner than later? Or do you think it's better to wait until the need forces their use?

Better to wait, I think.  Even if we had large enough values, we don't need to specify an explicit size unless the compiler doesn't support implicitly widening it.

TIL that clang implicitly widens the size of an enum to long if its member values don't fit int.

Would it work if we added _reserved members to these enums, with a value such as 1L << 63 to force these types to be 64bit now?

I took a look and that works on most compilers https://godbolt.org/z/6HpZjW, but it fails on MSVC when building in C mode (in C++ it's fine).
If you can find a workaround for msvc I'd be okay with taking the change.

Thanks for investigating!
I'm not seeing anything that would make it work for MSVC C. Maybe Apple does not need Windows need ABI compatibility at this time, like it does elsewhere?
If MSVC C does not support larger enums – I'm not finding any extensions to allow it, then these option set types would never support more than 32 members without breaking MSVC C.

I'm not seeing anything that would make it work for MSVC C. Maybe Apple does not need Windows need ABI compatibility at this time, like it does elsewhere?

😞 that's unfortunate.  I don't think we want to have an unstable ABI, since that makes the library unsafe to use in a lot of context. We could theoretically bump the major version at the point we actually need 64 bits, but that would be a big disruption.
What about using a typedef of uint64_t on platforms that don't support this?  For adding cases to the enum it would be a mess once we get to 33 bits, but we could define global constants if necessary.
For example, what if we did something like the NS_OPTIONS macro, which checks for C++11 as well as clang's extension to allow fixed size enums outside C++, and if those aren't available it uses a typedef?  That way we get the behaviour we want in clang and swift and C++11, and other cases fallback to a typedef, which is ABI-compatible.

What about using a typedef of uint64_t on platforms that don't support this?

I was just thinking exactly this too. This plan sounds good to me. 👍

I've updated the PR to add INDEXSTORE_OPTIONS, which is just like {NS,CF}_OPTIONS. The bit field types (indexstore_symbol_property_t and indexstore_symbol_role_t) will now be declared as a sized enum when used in C++ or ObjC contexts, and otherwise these types will be typedefed accordingly.

The reason I had the typedef in the macro is because the C++ doesn't need a typedef, enum types are usable by name by default. Also, the typedef results in a compilation error with c++98 (see below), but does c++98 matter?
For contrast, without typedef:
enum NAME : uint64_t {
    ...
};

With typedef:
typedef enum NAME : uint64_t NAME;
enum NAME : uint64_t {
    ...
};

In ObjC, the typedef lets the enum be referenced directly by name (enum foo_t vs foo_t), but C++ already allows enums to be referenced without the keyword. I thought it was weird to introduce an unnecessary typedef.
In the "with typedef" case, c++98 results in a compilation error:
error: definition of type 'foo' conflicts with typedef of the same name

This could be worked around by prepending or appending an underscore to the name, if compiled under c++98.

Huh, I see NS_OPTIONS in C++ is actually using a typedef over the underlying type and then declaring a separate anonymous enum.

Yeah. Which way do you prefer this to be implemented here? I think for my Swift bridging motivations, the C++ case doesn't matter so I'm happy to follow NS_OPTIONS even though it seems less ideal.

I would mimic NS_OPTIONS as long as it does what you need it to.  If we get C++ import support and need to change it in the future, that should be fine.

@swift-ci please test

I'm happy to rebase this. In my previous related change, I did two PRs, one that targeted upstream-with-swift and another that targeted swift-5.1-branch.

@hyp tells me we want:

upstream-with-swift
apple/stable/20190619

swift-5.1 is locked down at this point

I've changed this PR to target upstream-with-swift. I'll open a PR to target apple/stable/20190619.

@swift-ci please test

@swift-ci please test

Seems like the PR into apple/stable/20190619  can be closed https://github.com/apple/swift-clang/pull/352. Is this still good? Should I open PRs into any other branches?

@swift-ci please test

@swift-ci please test

@swift-ci please test

@swift-ci please test

would it help to rebase?

I rebased.

I don't see how that would help, but we can try.  The failures looked unrelated to me.

@swift-ci please test

@swift-ci please test

Actually, after talking with Mishal, we decided to just merge this.

@benlangmuir thanks for helping me see this through


chore: update about; fix readme link

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


How to swagger ignore specific lines in the documentation?

How can I avoid going into referencing vendor's specific docs in swagger models?
I am using the struct below but I don't want the code to also reference the ObjectId struct from bson. Can I swagger ignore just a line?
// MyStruct description
type MyStruct struct {
	NumID            int           `json:"num_id" bson:"num_id"`
	MitId     bson.ObjectId `json:"mit_id" bson:"mit_id,omitempty"`
	progress       bool          `json:"progress" bson:"progress"`
}

I am trying to avoid this behavior:

Having the same issue with bson.ObjectId referencing vendor's definition

for me the following code works normal
type SelectionRuleVO struct {
	SelectionCount uint32 `json:"selectionCount"` // total number of selections
	/* UniqueSelectionCount uint32 `jsonx:"uniqueSelectionCount"` */

	MaxSameSelections uint32 `json:"maxSameSelections"` // maximum number of same selections
}


Where are the Docs?

Here is where the link takes me:
Package not found
No package named purescript-webdriver exists in the database. If you think this is an error, please let us know by opening an issue, or visiting us on #purescript IRC on Freenode.

They're published again now, such as they are.


Qemu exporter always outputs 0W

Bug description
Following https://hubblo-org.github.io/scaphandre-documentation/references/exporter-qemu.html, I first try stdout exporter on the host which seems to successfully retrieve rapl metrics:
sudo RUST_BACKTRACE=full ./target/debug/scaphandre stdout
Scaphandre stdout exporter
Sending ⚡ metrics
Measurement step is: 2s
Host:   0 W
        package         core            dram            uncore
Top 5 consumers:
Power           PID     Exe
No processes found yet or filter returns no value.
------------------------------------------------------------

Host:   6.279447 W
        package         core            dram            uncore
Socket0 6.279447 W |    5.607462 W      1.159405 W      0 W

Top 5 consumers:
Power           PID     Exe
0.080505 W      91      "ksmd"
0.080505 W      1288    "NetworkManager"
0.080505 W      1294    "iio-sensor-prox"
0.080505 W      1329    "thermald"
0 W     1       "systemd"
------------------------------------------------------------

However, when running qemu exporter, it does seem to run w/o issues, but 0W is written.
On the host:
sudo RUST_BACKTRACE=full ./target/debug/scaphandre qemu
Scaphandre qemu exporter
Sending ⚡ metrics

Inside the VM (it does pick up on the processes running inside the VM):
vagrant@cluster-0-master-0:~/git/scaphandre$ sudo RUST_BACKTRACE=1 ./target/debug/scaphandre --vm stdout -t 15
scaphandre::sensors::powercap_rapl: Powercap_rapl path is: /var/scaphandre
Scaphandre stdout exporter
Sending ⚡ metrics
Measurement step is: 2s
Host:   0 W
Top 5 consumers:
Power           PID     Exe
No processes found yet or filter returns no value.
------------------------------------------------------------

Host:   0 W
Socket0 ---- W |

Top 5 consumers:
Power           PID     Exe
0 W     2065    "scaphandre"
0 W     1502    "containerd"
0 W     1       "systemd"
0 W     2       "kthreadd"
0 W     3       "rcu_gp"

Mount is there, but energy_uj always 0:
vagrant@cluster-0-master-0:~/git/scaphandre$ cat /var/scaphandre/intel-rapl\:0/energy_uj
0

To Reproduce
I can recreate a simple Vagrantfile if it is helpful, but Im hoping I just missed a step somewhere.
Expected behavior
Power output showing values >0W.
Environment

On the host:
Ubuntu 20.04.4 LTS
5.15.0-41-generic
Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz

Using:
Vagrant 2.2.19
generic/ubuntu2004 (libvirt, 4.1.0)
(kvm) QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.23)

In the VM:
Ubuntu 20.04.4 LTS
5.4.0-122-generic

qemu exporter output:
path: /var/lib/libvirt/scaphandre
Got topo uj diff: Record { timestamp:<PHONE_NUMBER>.873728237s, value: "23439820", unit: MicroJoule }
Got 465 processes to filter.
Found a process with /usr/bin/qemu-system-x86_64
Number of filtered qemu processes: 1
Working on [ProcessRecord { process: Process { pid: 15167, stat: Stat { _private: (), pid: 15167, comm: "qemu-system-x86", state: 'S', ppid: 1, pgrp: 15166, session: 15166, tty_nr: 0, tpgid: -1, flags: 138412416, minflt: 35210, cminflt: 0, majflt: 1, cmajflt: 0, utime: 13453, stime: 2050, cutime: 0, cstime: 0, priority: 20, nice: 0, num_threads: 7, itrealvalue: 0, starttime: 161143, vsize:<PHONE_NUMBER>, rss: 332498, rsslim:<PHONE_NUMBER>3709551615, startcode:<PHONE_NUMBER>3392, endcode:<PHONE_NUMBER>8253, startstack:<PHONE_NUMBER>69440, kstkesp: 0, kstkeip: 0, signal: 0, blocked: 268444224, sigignore: 4096, sigcatch: 16963, wchan: 0, nswap: 0, cnswap: 0, exit_signal: Some(17), processor: Some(11), rt_priority: Some(0), policy: Some(0), delayacct_blkio_ticks: Some(0), guest_time: Some(9940), cguest_time: Some(0), start_data: Some(94247886257888), end_data: Some(94247889329520), start_brk: Some(94247912988672), arg_start: Some(140726210876573), arg_end: Some(140726210879061), env_start: Some(140726210879061), env_end: Some(140726210879452), exit_code: Some(0) }, owner: 64055, root: "/proc/15167" }, timestamp:<PHONE_NUMBER>.926784707s }, ProcessRecord { process: Process { pid: 15167, stat: Stat { _private: (), pid: 15167, comm: "qemu-system-x86", state: 'S', ppid: 1, pgrp: 15166, session: 15166, tty_nr: 0, tpgid: -1, flags: 138412416, minflt: 35120, cminflt: 0, majflt: 1, cmajflt: 0, utime: 13447, stime: 2049, cutime: 0, cstime: 0, priority: 20, nice: 0, num_threads: 6, itrealvalue: 0, starttime: 161143, vsize:<PHONE_NUMBER>, rss: 332498, rsslim:<PHONE_NUMBER>3709551615, startcode:<PHONE_NUMBER>3392, endcode:<PHONE_NUMBER>8253, startstack:<PHONE_NUMBER>69440, kstkesp: 0, kstkeip: 0, signal: 0, blocked: 268444224, sigignore: 4096, sigcatch: 16963, wchan: 0, nswap: 0, cnswap: 0, exit_signal: Some(17), processor: Some(11), rt_priority: Some(0), policy: Some(0), delayacct_blkio_ticks: Some(0), guest_time: Some(9935), cguest_time: Some(0), start_data: Some(94247886257888), end_data: Some(94247889329520), start_brk: Some(94247912988672), arg_start: Some(140726210876573), arg_end: Some(140726210879061), env_start: Some(140726210879061), env_end: Some(140726210879452), exit_code: Some(0) }, owner: 64055, root: "/proc/15167" }, timestamp:<PHONE_NUMBER>.871368763s }, ProcessRecord { process: Process { pid: 15167, stat: Stat { _private: (), pid: 15167, comm: "qemu-system-x86", state: 'S', ppid: 1, pgrp: 15166, session: 15166, tty_nr: 0, tpgid: -1, flags: 138412416, minflt: 35120, cminflt: 0, majflt: 1, cmajflt: 0, utime: 13442, stime: 2048, cutime: 0, cstime: 0, priority: 20, nice: 0, num_threads: 6, itrealvalue: 0, starttime: 161143, vsize:<PHONE_NUMBER>, rss: 332498, rsslim:<PHONE_NUMBER>3709551615, startcode:<PHONE_NUMBER>3392, endcode:<PHONE_NUMBER>8253, startstack:<PHONE_NUMBER>69440, kstkesp: 0, kstkeip: 0, signal: 0, blocked: 268444224, sigignore: 4096, sigcatch: 16963, wchan: 0, nswap: 0, cnswap: 0, exit_signal: Some(17), processor: Some(11), rt_priority: Some(0), policy: Some(0), delayacct_blkio_ticks: Some(0), guest_time: Some(9931), cguest_time: Some(0), start_data: Some(94247886257888), end_data: Some(94247889329520), start_brk: Some(94247912988672), arg_start: Some(140726210876573), arg_end: Some(140726210879061), env_start: Some(140726210879061), env_end: Some(140726210879452), exit_code: Some(0) }, owner: 64055, root: "/proc/15167" }, timestamp:<PHONE_NUMBER>.820526859s }]
Time_pdiff=7 time_tdiff=404
Ratio is 0
Adding 0 uJ
()
Updated /var/lib/libvirt/scaphandre/scaphandre-test_cluster-0-master-0/intel-rapl:0
...

Converting the division here to floats worked, but Im unsure if that is following correct power calculation logic.
Now I see in the VM:
Host:   1.861659 W
Socket0 1.861659 W |

Top 5 consumers:
Power           PID     Exe
1.861659 W      2102    "scaphandre"
0.169241 W      1502    "containerd"
0 W     1       "systemd"
0 W     2       "kthreadd"
0 W     3       "rcu_gp"

Had the same issue and thought about the same fix in Line 84.
However, I don't thinkt that the results displays the consumption in Watts but instead returns the consumed power in uJ between two records, though I'm also not quite sure about it


Combine WowerlayContainer into Wowerlay

Please check if the PR fulfills these requirements

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

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Changelog

Please check if the PR fulfills these requirements
[ ]  The commit message follows our guidelines
[ ]  Tests for the changes have been added (for bug fixes / features)
[ ]  Docs have been added / updated (for bug fixes / features)

It has not been checked whether the requirements have been met.

Please check if the PR fulfills these requirements
[ ]   The commit message follows our guidelines
[ ]   Tests for the changes have been added (for bug fixes / features)
[ ]   Docs have been added / updated (for bug fixes / features)

It has not been checked whether the requirements have been met.

added


feat(RingTheory/Smooth): define standard smooth algebras

We define the notion of a submersive presentation and predicates when such a presentation is standard smooth. An algebra is called standard smooth if it admits a standard smooth presentation.
This contribution was created as part of the AIM workshop "Formalizing algebraic geometry" in June 2024.
Co-authored-by: Andrew Yang @erdOne
Co-authored-by: Jung Tao Cheng @rontaucheng

This only contains definitions. Follow-up PRs are in the pipeline to resolve the first three TODOs in the module docstring.

My only concern with this PR is that the name SubmersivePresentation already contains the word submersive, even though the data and assumptions are only introduced in order to be able to define the jacobian. "Submersion" basically means "smooth" already.
I would suggest renaming SubmersivePresentation as PreSubmersivePresentation, and have SubmersivePresentation extend PreSubmersivePresentation which the two extrafields jacobian_isUnit and isFinite.

My only concern with this PR is that the name SubmersivePresentation already contains the word submersive, even though the data and assumptions are only introduced in order to be able to define the jacobian. "Submersion" basically means "smooth" already.
I would suggest renaming SubmersivePresentation as PreSubmersivePresentation, and have SubmersivePresentation extend PreSubmersivePresentation which the two extrafields jacobian_isUnit and isFinite.

And then remove the IsStandardSmooth typeclass for PreSubmersivePresentations? Or have both IsStandardSmooth and SubmersivePresentation?

And then remove the IsStandardSmooth typeclass for PreSubmersivePresentations?

Yes, and then, IsStandardSmooth would only be a RingHom property, which would assert the existence of a SubmersivePresentation.

Thanks for the suggestions @joelriou and @MichaelStollBayreuth. I adapted them in the latest commit.

Anything else I should address here?

Thanks for all the reviews!
bors r+


Token and Certificate Endpoint Authorization

Adds options to be able to pass a Bearer Token or client certificate (pfx/cer) to the endpoint for authorization.  Also fixes a strange bug with getRequestOptions where an endpoint with no parameters throws and error.

App.js is a just example of usage. Probably it's not clear, so I'd better move it to example folder

But thanks for PR


AWS Security Hub Findings Property Names Case Issue

Bug description
Example data in DefectDojo/django-DefectDojo#2594 and DefectDojo/sample-scan-files#55 and tests must have been incorrectly formatted or there has been an API change in AWS. The top-level JSON object is {"findings": []}, not {"Findings": []} with a capital F. This breaks ingestion of AWS Security Hub exports.
Steps to reproduce
Steps to reproduce the behavior:

Upload recent export from AWS Security Hub from a current AWS account.
Error occurs because JSON property mapping is case sensitive and exported findings are not ingested.

Expected behavior
Proper parsing of the file.
Deployment method (select with an X)

[ ] Kubernetes
[X] Docker
[ ] setup.bash / legacy-setup.bash

Environment information

Operating System: AWS ECS Fargate
DefectDojo Commit Message: 1.8.x (cherry-picked from dev branch)

Sample scan files (optional)
See above.
Screenshots (optional)
N/A
Console logs (optional)
N/A
Additional context (optional)
N/A

I will be drafting a PR to fix this ASAP tomorrow after discovering it initial testing this afternoon.

After more debugging, it appears we receive them from Event Bus, and somehow the casing is changing when it arrives to our Lambda functions. This is not what we control, but how AWS parses it. Since this is a common integration pattern, I move forward to check for one in the other. I will be opening a support ticket with AWS in the interim and report back here with a linked issue.


Link to Figma file giving 404 error

I was able to view this figma file but late last week it started giving 404 errors for myself and a colleague.

Sorry about that, the permissions on the file somehow got reverted. You should be able to access it now!

back in action. thank you :)


Error when dvl sensor attached to whoi gliders

@dtdavi1 I hope this isn't a major sensor plugin type problem, but simply a wrong sensor definition problem. I am still familiarizing myself with SDF/URDF definitions.
I was trying to put whoi_teledyne_whn sensor at the nps_uw_sensor_gazebo repository to a glider at https://github.com/Field-Robotics-Lab/glider_hybrid_whoi. I've found an example in the repository and copy-pasted the sensor definitions. I've replaced the code block at the sensor definition xacro file. it did show dvl sensor visually, but the sensor plugin did not load correctly.
[Err] [SensorManager.cc:333] Unable to create sensor of type[dsros_dvl]

<!-- DVL sensor -->
<!-- <xacro:dvl_plugin_macro
  namespace="${namespace}"
  suffix=""
  parent_link="${namespace}/base_link"
  topic="dvl"
  scale="0.62"
  noise_sigma="0"
  noise_amplitude="0"
  update_rate="7"
  reference_frame="world">
  <origin xyz="0.0 0.0 -0.0825" rpy="0 ${0.5*pi} 0" />
</xacro:dvl_plugin_macro> -->

<xacro:include filename="$(find nps_uw_sensors_gazebo)/urdf/whoi_teledyne_whn.xacro"/>
<xacro:teledyne_whn_macro
  name="dvl" namespace="dvl" xyz="0 0 0"
  dvl_topic="dvl" ranges_topic="ranges"
  robot_link="${namespace}/base_link" joint_xyz="0 0 0"/>

If you need a place to test, it's at dvl_sensor branch. You may run with roslaunch glider_hybrid_whoi_gazebo start_demo_kinematics.launch

@woensug-choi The launch file was missing an argument in the Gazebo launch portion.  The DVL sensor is part of the ds_sim package, so you need to explicitly load the library when Gazebo is started.  I added the line to the start_demo_kinematics.launch file (line 11) and pushed it back up to the repository.

@dtdavi1  Thank you! Something that could have taken me much time to figure out!


Removed column not null constraint on tf_dest_tablecolumns.path

The removal of the null constraint from the migration file needs to occur in a new changeset because the existing change sets are part of released code.


docs: reorganize the use cases directory

Signed-off-by: Daniel Hu<EMAIL_ADDRESS>Pre-Checklist
Note: please complete ALL items in the following checklist.

[x] I have read through the CONTRIBUTING.md documentation.

Description

reorganize the use cases directory
Related Issues

N/A
New Behavior (screenshots if needed)

N/A

To be translated after this pr is merged. @IronCore864


Watson Knowledge Catalog - fix manta registry

Describe the bug
When deploying WKC on Cloud Pak for Data 4.5.x, the Manta catalog source and images reference the manta registry for which the standard ICR key does not apply.
Behaviour:

Catalog source in openshift-marketplace shows ImagePullBackoff
Lock-up of OLM, no operators install (including the platform operator)

Solution
Create ImageContentSourcePolicy to redirect manta registries to icr.io.

[x] Quick-fix: Create ICSP, including special handling for ROKS (updating /etc/containers/registries.conf)
[ ] Make ICSP dependent on installation of WKC
[x] Use /etc/containers/registries.d to make config more dynamic

[ ] Simplify how node settings are applied. Rather than having multiple DaemonSets in kube-system, only use one that will apply all changes.


Provide --proxy and catch more usocket errors when checking for update

The changes here are three:

Catch USOCKET:NS-ERROR and USOCKET:SOCKET-ERROR when checking for an SDK update. Originally we caught USOCKET:NS-HOST-NOT-FOUND-ERROR, but this allowed other related errors through, causing the app to crash.
Provide --proxy to be used by quilc::latest-sdk-version and those behind network restrictions. This one makes me slightly uncomfortable, since it may be confused with providing a proxy for the server itself.
Replace the off-by-default --skip-version-check with the off-by-default --check-sdk-version. Network issues may cause the app to crash or be slow while waiting for the update check to finish; IMO this should be opt-in. Also, this option now causes the program to exit (with an appropriate return code).

@notmgsk please fix merge conflicts


Convert AssetsContractController from BaseControllerV1 to BaseControllerV2

Considering that converting TokenDetectionController to BaseController v2 took longer than expected due to unforeseen changes, we want to be more conscientious about converting AssetsContractController.
Figure out all of the changes we would want to make in upgrading this controller, outline those changes here and create new tickets if appropriate.

Define internal messenger actions/events types.

Define messenger actions for all public methods of AssetsContractController class.
Define AssetsContractControllerActions, AssetsContractControllerEvents, AssetsContractControllerGetStateAction (using ControllerGetStateAction type), AssetsContractControllerStateChangeEvent (using ControllerStateChangeEvent type)

Replace constructor option callbacks with messenger actions/events

onPreferencesStateChange

PreferencesController:stateChange
Use PreferencesControllerStateChangeEvent

onNetworkDidChange

NetworkController:networkDidChange
Use NetworkControllerNetworkDidChangeEvent

getNetworkClientById

NetworkController:getNetworkClientById
Use NetworkControllerGetNetworkClientByIdAction

Define AllowedActions union type and add the above as its members.

Export this type so it's usable by tests and other internal modules, but exclude it as a package-level export.

Replace the callback invocations in the constructor with subscribe() calls, using the existing listener logic.

Define AssetsContractControllerMessenger using the types defined in the above bullet points.

AssetsContractController extends BaseControllerV2.

AssetsContractConfig

Move properties of this type to private class fields of the AssetsContractController class.
Set default values from this.defaultConfig object.
Replace this.configure calls with assignments to corresponding class fields.

constructor

Replace super call so that it conforms to V2 requirements.
Remove this.initialize()
Remove override name class field.

Replace all private keywords for class fields and methods with # prefix.

Refactor tests. Use withController pattern.|

Notes:

This controller has an empty state object.
Consider replacing type annotation for SINGLE_CALL_BALANCES_ADDRESS_BY_CHAINID with satisfies keyword.

All of the steps above are correct. Rename to not be called Controller and remove it from using the BaseController class. This file probably needs a redesign.

Some functions seems to be just helper function used within the controller only for example getERC20Standard which can be private instead


Error on install: Syntax error or access violation: 1067 Invalid default value for 'end_time'

Fixes #1042

This is exactly what I did to fix it locally! :+1:


Expect 0 assertions to fix #2382

Fixes QUnit complaining about exiting test early.

Note that while this does fix #2382, I don't really like that we are ignoring the test.  We should probably update it to have the expected behavior for this browser configuration, rather than exiting early.

I'm fine ignoring the test for browsers that are wrong. If they fix the browser it will start working again, so I don't see an issue here.

Well for one thing, the date that is tested is just for the US.  Other time zones may exhibit this bug on other dates.

I agree its not perfect. We had a function to detect DST and use it -- I think we should do that more often (and cache the results, because they are expensive).
I'm merging this as-is.

Merged in 27e22be08e5f7706a950d5ffb92020204eb37373

Merged in 27e22be08e5f7706a950d5ffb92020204eb37373


http auth broken

If I define credentials for basicAuth, the UI will prompt for login. After logging in the UI fails to render correctly.  It looks like to me the web app isn't using the credentials when making API calls. Not sure though.
basicAuth:
  username: admin
  password: my-password

Which version do you using?

Hi! I'm using 3.0.0-rc.7

Fixed with the latest RC.8 release


[util] Add auto installer

Bash script for latest DXVK libs installation into wine prefixes. Release files copied only when they are newer than files in prefix or when prefix files is missing. As dependencies it uses grep, jq, cut and bash-helpers lib. See https://github.com/nafigator/bash-helpers. If bash-helpers not exists in bash includes than script sources it from github.

For testing purposes you can use install.sh from my branch:
curl -s https://raw.githubusercontent.com/nafigator/dxvk/auto-installer/install.sh | WINEPREFIX=~/.wine bash
Also, script accepts params:
-v --version
-h --help
-d --debug

Combine them as follows:
curl -s https://raw.githubusercontent.com/nafigator/dxvk/auto-installer/install.sh | WINEPREFIX=~/.wine bash -s - <params>
Example:
curl -s https://raw.githubusercontent.com/nafigator/dxvk/auto-installer/install.sh | WINEPREFIX=~/.wine bash -s - -dv

To offer a bit of context: dxvk used to have an installation script, but everyone and their dog seemed to take issues with it for some reason or another, which created unnecessary focus on what is (ultimately) a less important aspect of the project, so the decision was taken to remove it from the repo and let people create and maintain their own, should they feel the need. I doubt this point will be walked back on.

To offer a bit of context: dxvk used to have an installation script, but everyone and their dog seemed to take issues with it for some reason or another, which created unnecessary focus on what is (ultimately) a less important aspect of the project, so the decision was taken to remove it from the repo and let people create and maintain their own, should they feel the need. I doubt this point will be walked back on.

Fair enough. It's ok to close this without merge. In this case I'll think about  own gist or repo for this script. Hope it'll be useful for someone.


Bump kind and k8s versions used in e2e workflow

Moving this into https://github.com/humio/humio-operator/pull/732


I hate to put offtopic stuff here, but you're being pretty hostile

I saw that you where against fabric and about your mods getting support at ALL (i don't use it myself mind you) because some of the community was "childish" which is a pretty terrible reason to say the least (it's literally just a method of modding, what your notion of their userbase may be doesn't have anything to do with supporting it or not)
Then a guy asked for a discord and instead of a yes or no you just closed his request twice and marked it as spam
There's also the fact that you blocked comments in the curseforge page
I'm not trying to attack you, but think it over, not everyone is the bad guy

Somebody is porting Mine Menu to Fabric atm.
He could find the Discord information, if he looked at some of my other mods CF page.
I'm not sure where you have the idea of not supporting my mods from, I spend hundreds of hours a year doing so. It's just Mine Menu, that I don't really care about much, but still do some updating.
Comments on CF is off for some of my mods, because people kept asking the exact same questions hundreds of times.
As for Fabric, I do not intend to ever have anything to do with it, after getting death treats for not updating the mod I at the time did support for Fabric.


fix(client): set Path as the default of Original

Routings without the leading slash like app.get('foo', ...) works well, but it seems like hc fails to extract its type correctly.
You can't access hc<typeof app>('/').foo.$get, which works on runtime though.
The author should do the following, if applicable

[x] Add tests
[x] Run tests
[x] bun run format:fix && bun run lint:fix to format the code
[ ] ~Add TSDoc/JSDoc to document the code~ not needed, I guess

Looks good to me! I'll merge this now. Thank you for your contribution.


feat(graph): add support for filtering users by type

This adds support for equality filters on the userType property of users  for the /users endpoint.
It also changes the behavior of the /users endpoint to only return federated users when explicitly request via a userType filter.
E.g. to search for federated users with matching "albert" you can use:
`$filter=userType eq 'Federated'&$search="albert"`

Related Issue: #9702

@ScharfViktor could you please take a look at the changes I made to the acceptance tests? Does it make sense? I am not an expert on those PHP based tests.


Models with pre made grids

Describe your changes
Pre-made RandomForestClassifier added
Usage
from sklearn_evaluation.grid import RandomForestClassifierGrid
from sklearn import datasets
from sklearn.model_selection import train_test_split

X, y = datasets.make_classification(200, 20, n_informative=5, class_sep=0.65)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3)

# grid has values: tiny, small, medium, large, xlarge
model = RandomForestClassifierGrid(grid="large")

# train all models and return the best one
model.fit(X, y)

Plot results
model.confusion_matrix()

model.roc()

model.feature_importances()

# https://sklearn-evaluation.ploomber.io/en/latest/api/plot.html#grid-search
model.grid_search()

Issue ticket number and link
Closes #183
Checklist before requesting a review
Not ready for review

:books: Documentation preview :books:: https://sklearn-evaluation--215.org.readthedocs.build/en/215/

@edublancas please check if this is the right direction so I can complete this PR with proper tests and documentation.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

36 of 60 (60.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.7%) to 93.754%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sklearn_evaluation/grid/classifier_grid.py
21
30
70.0%

src/sklearn_evaluation/grid/random_forest_classifier_grid.py
12
27
44.44%

Totals

Change from base Build<PHONE_NUMBER>:
-0.7%

Covered Lines:
2612

Relevant Lines:
2786

💛  - Coveralls

I almost missed this, please tag me as reviewer, otherwise if you just tag me, there's a higher chance I don't see it.
my feedback:
overall this looks great! What will make things easier for us is if you add a new section in the docs describing how to use this new module, this way we'll be able to click on the doc preview, then click on the binder link and then run your code. to ensure a binder button is added, you need to make your tutorial runnable by adding some metadata (here's an example: https://raw.githubusercontent.com/ploomber/sklearn-evaluation/master/docs/quickstart/classification.md) - the content between --- is the metadata
I see that plotting methods such as confusion_matrix are using the training data for plotting. while this is acceptable, it's common practice to have a separate test set and use this for evaluation/plotting. So we should give that option:
clf = grid.RandomForestClassifierGrid("tiny")
clf.fit(X, y)

clf.set_test_data(X_test, y_test)

# uses X_test and y_test
clf.confusion_matrix()

maybe if they don't call set_test_data we can use the training data but show a warning? It's usually a bad idea to compute metrics on the training data, but some users might still want to do it (e.g., to evaluate under/overfitting)
also, it should be clear in the docs and tutorial that calling the plotting methods will use the best_estimator_ - I'm unsure how GridSearchCV defines what "best" is so we should look into that to see how we can expose a setting that allows users to change the definition of "best"
as a convention, fit should return self. Also, I see that the GridSearchCV obj is accessible from self.classifier, I think a better name would be grid_search_cv, another convention is that attributes that are accessible after calling fit, should have a _ suffix, so let's make it grid_search_cv_

Cool stuff.
Does the user has any control on those? like changing the estimators criterion etc?
It'd probably change frequently

regarding Ido's point. I think this is important. However, I'd say let's push this to v2. Let's deploy this first and then if people like it, we can think of ways for customizing the grids.

@edublancas  I think we should define the parameters for the different grid sizes to make the test and PR complete.
Also, I added a new example. Please verify it's a good example and that it's OK to use this dataset.
took it from here
https://github.com/sharmaroshan/Heart-UCI-Dataset
https://www.kaggle.com/datasets/redwankarimsony/heart-disease-data

@edublancas we need to define grid sizes. now it's just initialized with arbitrary data.

        {
            GridTypes.TINY: {
                "n_estimators": [1, 10],
                "criterion": ["gini", "entropy"],
                "max_features": ["sqrt", "log2"],
            },
            GridTypes.SMALL: {
                "n_estimators": [1, 10, 50],
                "criterion": ["gini", "entropy"],
                "max_features": ["sqrt", "log2"],
            },
            GridTypes.MEDIUM: {
                "n_estimators": [1, 10, 50, 100],
                "criterion": ["gini", "entropy"],
                "max_features": ["sqrt", "log2"],
            },
            GridTypes.LARGE: {
                "n_estimators": [1, 5],
                "max_features": ["sqrt", "log2"],
                "max_depth": [2, 4],
                "min_samples_split": [2, 5],
                "min_samples_leaf": [1, 2],
                "bootstrap": [True],
            },
            GridTypes.X_LARGE: {
                "n_estimators": [1, 10, 50, 100],
                "max_features": ["sqrt", "log2"],
                "max_depth": [2, 4],
                "min_samples_split": [2, 5],
                "min_samples_leaf": [1, 2],
                "bootstrap": [True],
            },
        }

@edublancas 2 things

according to the RandomForestClassifier API the criterion takes 3 possible arguments: {gini, entropy, log_loss}. Change to these instead of squared_error?
Increasing the grid size increases the run time, which affects the tests. How do we want to tackle it? should I test only "tiny" grid?

** I pushed the changes to make it clear.

Fixed namings
New grid values
Testing only "tiny" grid

Yes, we should adjust according to the specs.
We'd probably want a run for each at least on the first stage IMO (and as long as it doesn't block the CI completely), and then we can convert to tiny. Another option is to cover all of the combinations via tiny and that should be a good enough test.

according to the RandomForestClassifier API the criterion takes 3 possible arguments: {gini, entropy, log_loss}. Change to these instead of squared_error?

you're right. I was looking at the regressor docs, squared_error isn't a valid value for the classifier


Update Docker instructions

I updated the docker instructions for those of us who are using the newer Macs with the M1 chip. Thank you @mikeessen for your help with this one and providing me with some commands to try :)
I just did this yesterday to set-up my new laptop....so I verified the steps too!

Jenkins Linux s390x Build #11078 [push] Update Docker instructio... started at 12:15

Jenkins Linux ppc64le Build #10125 [push] Update Docker instructio... started at 12:20

Jenkins Linux amd64 Build #11069 [push] Update Docker instructio... passed after 1 hr 43 min

Jenkins Linux s390x Build #11078 [push] Update Docker instructio... aborted after 2 hr 5 min

@hamptonm1 @mikeessen thanks for updating and verifying the new M1 instructions.


Added Berries and Cherries support (and rimraf)

First of all I added support for the Five-SeveN | Berries and Cherries. It's as accurate as I could get it, and is almost the same as this guide suggests, and compared with visual inspection of course.
Second, I switched out rm -rf for the npm package rimraf, as it is supported on all platforms. Previously, if you tried to build the project on windows it'd fail, as the rm command doesn't exist on windows.

Sorry for the @chescos, but could you review this PR?

Thanks for your contribution! Sorry for the late reply, been a little busy lately.
Looks interesting, however, the paintkit config looks arbitrary, did you just try out numbers until the output looked somewhat correct?
The thing is, those properties are specified for each skin in the game files. For the Five-SeveN | Berries And Cherries, the actual config looks like this:
"1002"
{
	"name"		"aa_fade_red_blue"
	"description_string"		"#PaintKit_aa_fade_red_blue"
	"description_tag"		"#PaintKit_aa_fade_red_blue_Tag"
	"style"		"6"
	"pattern"		"fade"
	"color0"		"88 16 16"
	"color1"		"72 16 19"
	"color2"		"15 14 14"
	"color3"		"31 80 136"
	"pattern_scale"		"2.000000"
	"phongexponent"		"34"
	"phongalbedoboost"		"80"
	"ignore_weapon_size_scale"		"1"
	"only_first_material"		"1"
	"pattern_offset_x_start"		"-1.480000"
	"pattern_offset_x_end"		"0.600000"
	"pattern_offset_y_start"		"0.000000"
	"pattern_offset_y_end"		"1.000000"
	"pattern_rotate_start"		"10.000000"
	"pattern_rotate_end"		"20.000000"
	"wear_remap_min"		"0.000000"
	"wear_remap_max"		"0.100000"
}

I'm not sure if our algorithm makes sense for this skin though, as it has a variable rotation as well as a variable X and Y axis (Fade skins only have a variable rotation). Theoretically, the output should still be good as the Y axis doesn't seem to matter much and we support the X axis.
Could you update your PR with the correct config values and manually check if the output still makes sense?

No problem, I understand!
You are correct, that was my methodology, kinda. I started off with the values that you mention, from the items_game.txt, and they were completely off-basis, so I experimented by adjusting values slightly one at a time to hone in close to what the consensus is for berries and cherries.
It is definitely not 100% accurate, and I'd completely understand if you don't accept this PR. I consider it good enough for me, and I'll probably just extend the base class in my own project if it isn't good enough to be included.

Ahhh okay, got it!
Sorry but in this case, I prefer not to merge this as the method to achieve the results is too random.
If you want, you can clean this PR up to only include the rimraf addition (or open a new one for that) - I'd gladly merge that one. If you don't want to bother with that, just let me know, and I can open a PR for it as well.

Ahhh okay, got it!
Sorry but in this case, I prefer not to merge this as the method to achieve the results is too random.
If you want, you can clean this PR up to only include the rimraf addition (or open a new one for that) - I'd gladly merge that one. If you don't want to bother with that, just let me know, and I can open a PR for it as well.

Done!

Great, thank you!


Cloudflare Issues

http://d.l33t.tech/18zOO/2kRihqGt
When using my cloudflare url, it does not work properly. When using my direct url, it does. I don't want my "live" url to be displayed though. Is there a way to let this work with cloudflare or could there be a way added to do a "live" url?

I think adding a 'live' config option should work.
I'll try to add it tomorrow, but I'm getting ready to leave on vacation, apologies if I forget to do it.

No worries. Cheers mate!

https://github.com/yariplus/bukkit-plugin-nodebb-integration/releases/tag/v0.7.0-beta.9
Added configs for websockets.
Use command /nodebb live {url}
It works on my server, but I haven't tested it thoroughly.

Tim to the rescue once again! Thanks man.


fix undefined: base64.RawURLEncoding

simple test
name := base64.RawURLEncoding.EncodeToString("string")
without this smaller fix i have error
undefined: base64.RawURLEncoding

This patch is wrong. We intentionally want
(*Encoding).WithPadding to not modify
the receiver (otherwise it's possible to
modify existing base64.StdEncoding.
Please see the relevant CL for discussion.


fix regex stateful bug and literal bug

A JavaScript RegExp object is stateful,so when there is more then one vpn connection in mac, the result is not what is expected.

Thanks for fixing this!

Released as version 0.3.0 🙌