Checkout the HEAD SHA for docs builds

What does this PR do?
https://github.com/Lightning-AI/lightning/commit/0a3db23cc4471d00ab94d3976579b331443470dc#diff-02dbc35a6a8a8f65d291727a704a253056019b7ea277be0160c4843567def6e3R7 changed the event type to pull_request_target.
This event type has the advantage sharing secrets with forks. This is important so fork PRs can build docs or they would be blocked.
By design, this event type runs using master's changes (the PR base) for security reasons.
One workaround for this (at the cost of security) is to checkout the PR head SHA.
Not doing this is what caused #15473 to appear as green when in reality the changes were broken.
Since that has been merged and the errors now appear in master, this PR needs to be force merged. Failures here are expected and caused by #15473
This will help unblock #15508
Does your PR introduce any breaking changes? If yes, please list them.
None
cc @tchaton @rohitgr7 @carmocca @akihironitta @borda

@Borda Turns out this solution is not complete. The contents of the repository are checked out to the latest versions, but not the workflow changes themselves (if present).
We'll need to find a different solution:

Remove secrets by making the template public (no longer need _target)
Do not allow docs PRs from contributors (remove _target)
Port docs build setup to Azure

Turns out this solution is not complete.

It was complete, and it was known that the CI can't be edited in the same PR s the package can not be leaked, as the same applies to TPU tests...

We'll need to choose a different solution:
a) Avoid the need for secrets by making the template public (no longer need _target)
b) Do not allow docs PRs from contributors (remove _target)
c) Port docs build setup to Azure

yes, that is what I asked @williamFalcon two days ago too :)
but corrections:
add A) we do not make a template public but the built wheel package
add B) it is not correct; your app docs as required check for add app code changes so you effectively ban any contributor editing app's codebase :/
add C) still, the package can be leaked so almost the same as A)


Data documentation

What changes are you trying to make? (e.g. Adding or removing code, refactoring existing code, adding reports)
What did you learn from the changes you have made?
Was there another approach you were thinking about making? If so, what approach(es) were you thinking of?
Were there any challenges? If so, what issue(s) did you face? How did you overcome it?
How were these changes tested?
A reference to a related issue in your repository (if applicable)
Checklist

[ ] I can confirm that my changes are working as intended

Thank you so much for reviewing my assignment.
For all 3 I've added citation for all 3.
Regarding  the sampling approach I was referring to category materials and methods where researchers used strata by sampling individual Glossophaga soricina bats from different times and locations within the Area de Conservación de Guanacaste, Costa Rica, during a specified period. It ensures that the samples represented from  various subgroups within the bat population that reflects to the  stratified random sampling.


Update npm.md

Spelling correction

@v-geberr Thank you for fixing this, I am merging it now and it should be live shortly. Thank you.


Any plans for DRM, CSAI and SSAI Support?

@luchfilip as we are planning to working on this, it would be great if you provide us urls of this types!

@luchfilip You can check latest version of library, and let us know!


Migrate HTTP server to net/http

Fixes #4979 (although more work will be needed to completely remove fasthttp, see below)
Necessary (but not quite sufficient) to fix also:

#5392
#6246

This PR changes the HTTP server's listeners from fasthttp to net/http and fixes (or enables fixing) a lot of the scenarios that are blocked by #4979. Immediately, this should enable the web server to use HTTP/2 when TLS is enabled.
Included and not included
What this PR includes:

Changes the listeners for the 3 HTTP servers (app, healthz, pprof) from using fasthttp to using the standard library (net/http)
Changes all built-in middlewares used by the servers above to be based on net/http

What this PR does NOT include:

No handler has been updated from fasthttp to net/http, and handlers continue to work thanks to the "adapters"

This is not something new as in Dapr 1.10, all requests go through adapters twice to be converted fasthttp(listener + built-in middlewares)->net/http (middleware components)->fasthttp (handlers). Now there's only one conversion: net/http(everything but handlers)->fasthttp(handlers)

Does not change the router, which is still the fasthttp one. This is blocking updating handlers from fasthttp to net/http, and needs to be done in a separate PR.
Does not enable H2C. Should be done in a separate PR.
Some unit tests, including many (not all) in pkg/http still use fasthttp to create the test server. This isn't a concern at least until the handlers are migrated, but it should be changed in the future.

All features continue to work as expected, as testified by the fact that tests have not changed. Only one exception to this rule is that when performing HTTP->gRPC invocations, the "dapr-host" metadata is not included anymore (this is probably ok also because HTTP->gRPC service invocation is being deprecated)
Next steps

[ ] Update the router to one based on net/http, and apply the adapters only on individual handlers rather than on the router itself.
[ ] Migrate the Universal API adapter from fasthttp to net/http
[ ] Migrate APIs that can use streaming (such as service invocation) to be based on net/http and leverage streaming for input and output
[ ] Migrate all other APIs from fasthttp to either net/http handlers or Universal APIs.

/ok-to-test

/ok-to-perf

/ok-to-perf

Long have we waited for this change... Very curious about the perf results

@yaron2 all perf tests are passing, and looks like perf may actually be improving
Looking at the service invocation perf test (which is particularly useful here as it is among those more sensitive to the web server's own perf):
This PR

P50: 1.38ms
P90: 1.98ms

Three recent perf tests from master ([1]https://github.com/dapr/dapr/actions/runs/4722541970) 2 3)

Added latency avg: 1.76ms / 1.50ms / 1.47ms
P90: 2.86ms / 2.13ms /2.09ms

/ok-to-perf

This is a horrible regression in general, at the very least for 1.9 we had ~1.10ms for P90 and I am quite certain for 1.10 as well (will check later for 1.10.0). The regression in master started before this PR

@yaron2 Not sure about 1.9 because logs have expired for those runs.
This is what I could find from the release-1.10 branch:
First

Second

@yaron2 Not sure about 1.9 because logs have expired for those runs.
This is what I could find from the release-1.10 branch:
First
Second

Right, the first run is an outlier, the 2nd was the more common perf numbers we've seen. Now we need to check what caused the regression

In any case, this should not block this PR, correct? As it seems at the very least this isn't causing further regression (and may be having a positive impact actually)
PS: I wonder if it's also possible the perf regression may not be our code but some infra-related thing. Since between the two runs linked above on release-1.10, the biggest difference seems to be time. Just wondering.

We will want to merge this at the beginning of the 1.12 milestone to make sure we can release 1.11 compatible versions to test thoroughly.

This is disappointing as we had this scheduled for 1.11. We have work that depends on this right now that was scheduled for 1.11: complete streaming (still in preview), high-level crypto, among others.

This is sad as we had this scheduled for 1.11. We have work that depends on this right now that was scheduled for 1.11: complete streaming (still in preview), high-level crypto, among others.
Any chance we can get this into 1.11 and unblock these scenarios?

Good things are never too late. I agree that merge it later then we have enough time to ensure it is good enough.
Not only for this PR, for other big PRs, I do not want to merge them near the end of the milestone.

BTW, do we also need to migrate in all components? It looks a big job.

BTW, do we also need to migrate in all components? It looks a big job.

Middleware components support the net/http signatures

/ok-to-perf

/ok-to-perf

/ok-to-perf

/ok-to-perf

/ok-to-perf

/ok-to-perf

/test-sdk-all

/test-sdk-all

/ok-to-test

/test-sdk-all

@artursouza
Fixed all the issues reported by the SDK tests:

Java: issue was with the shutdown sequence. Stopping a net/http server returns an error always, which normally is ErrServerClosed, and had to be ignored.
Python: issue was related to trace headers not being converted between net/http and fasthttp. The routes are still implemented as fasthttp, but the middleware that sets the tracing span now uses net/http. I added a temporary compatibility layer to make it work (until the routes are converted to net/http)


pressStyle behaviour changed somewhere between 1.6 and 1.49, so all styles have to be stated

Current Behavior
I picked up a project using 1.6.3 with Buttons often used like this:
<Button chromeless color="black" bg="white" pressStyle={{opacity: 0.9}}>Whatever</Button>

When the button is pressed, the bg and color used to be respected, but now (since I just updated to 1.49.x, thinking it would behave the same due to the semver being a minor) I have to add bg: "white", color: "black" into my pressStyle to get back the old behaviour.
Expected Behavior
I would expect the behaviour to remain the same from 1.6 to 1.49 as it is not a major change.
Tamagui Version
1.6.3

Reproduction
<Button chromeless color="black" bg="white" pressStyle={{opacity: 0.9}}>Whatever</Button>

### System Info

_No response_

yeah, this also no longer works:
import { Button, styled } from 'tamagui'

export const MyButton = styled(Button, {
  variants: {
    test: {
      true: {
        backgroundColor: 'yellow',
        pressStyle: {
          backgroundColor: 'red',
        },
      },
    },
  } as const,
})

backgroundColor red is not respected :/

yall gotta fill in the info - platform especially

fixed in 1.50.1 (going out in a minute)

Has this been fixed? I am experiencing the same behavior in 1.73.0.

1.73.1 fixes


Figure out where to direct users for Moderne languages

We've removed the Moderne supported languages page and the roadmap. The OpenRewrite docs were pointing to that - but I'm not sure where the new one is. Once we figure out where the new page will be, we should update the rewrite-docs accordingly.

When asking about this internally - it seems like there's no intention to create a doc with this so I guess I'll just close this for now. If we have any information about supported languages in the future - I'll figure out where to add said doc at that time.


Error demo

R: @jeffposnick @addyosmani
Adds default and catch handler to routing demo.

Coverage increased (+0.01%) to 78.742% when pulling ffbd945fbf159461fbebed8ffcb64996bb05a53d on error-demo into 1f47e0f12959e9a82f082082c6f5877a4588790c on v3.

Coverage increased (+0.01%) to 78.742% when pulling ffbd945fbf159461fbebed8ffcb64996bb05a53d on error-demo into 1f47e0f12959e9a82f082082c6f5877a4588790c on v3.


go for the number Pi and find out how many decimal places we can get, etc.

https://github.com/UoA-eResearch/ResBaz24Python/blob/8df7c237900fcd2bcc1eed7495a2bf0aa2415962/ResBaz_Intro_to_Python.ipynb#L2

out of redefined scope


Segfault in AdvancedVI when involving  Diagonal specializations

Hitting segfaults in the following example. This seems unique to the case where D <: Diagonal.
using ADTypes
using Enzyme
using Distributions
using LinearAlgebra
using StableRNGs
using Random
using Optimisers
using Functors
using Test
using LogDensityProblems

struct MvLocationScale{
    S, D <: ContinuousDistribution, L, E <: Real
} <: ContinuousMultivariateDistribution
    location ::L
    scale    ::S
    dist     ::D
    scale_eps::E
end

Functors.@functor MvLocationScale (location, scale)

struct RestructureMeanField{S<:Diagonal,D,L,E}
    model::MvLocationScale{S,D,L,E}
end

function (re::RestructureMeanField)(flat::AbstractVector)
    n_dims = div(length(flat), 2)
    location = first(flat, n_dims)
    scale = Diagonal(last(flat, n_dims))
    return MvLocationScale(location, scale, re.model.dist, re.model.scale_eps)
end

function Optimisers.destructure(q::MvLocationScale{<:Diagonal,D,L,E}) where {D,L,E}
    (; location, scale, dist) = q
    flat = vcat(location, diag(scale))
    return flat, RestructureMeanField(q)
end

# This specialization improves AD performance of the sampling path
function Distributions.rand(
    rng::AbstractRNG, q::MvLocationScale{<:Diagonal,D,L}, num_samples::Int
) where {L,D}
    (; location, scale, dist) = q
    n_dims = length(location)
    scale_diag = diag(scale)
    return scale_diag .* rand(rng, dist, n_dims, num_samples) .+ location
end

struct Problem end

function LogDensityProblems.logdensity(problem, params)
	sum(params)
end

function estimate_energy_with_samples(prob, samples)
    return mean(Base.Fix1(LogDensityProblems.logdensity, prob), eachcol(samples))
end

function estimate_repgradelbo_ad_forward(params′, aux)
    (; rng, problem, adtype, restructure, q_stop) = aux
    q = restructure(params′)::typeof(restructure.model)
    samples = rand(rng, q, 3)
    energy = estimate_energy_with_samples(problem, samples)
    elbo = energy
    return -elbo
end

function mwe(T)
	adtype = AutoEnzyme()
    d    = 10
    seed = (0x38bef07cf9cc549d)
    rng  = StableRNG(seed)

    q = MvLocationScale(
        zeros(T, d), Diagonal(ones(T, d)), Normal{T}(zero(T), one(T)), T(1e-5)
    )
    params, restructure, = Optimisers.destructure(q)

    aux = (
        rng=rng,
        adtype=adtype,
        problem=Problem(),
        restructure=restructure,
        q_stop=q,
    )

    ∇x = zero(params)
    fill!(∇x, zero(eltype(∇x)))
    _, y = Enzyme.autodiff(
        set_runtime_activity(Enzyme.ReverseWithPrimal, true),
        estimate_repgradelbo_ad_forward,
        Enzyme.Active,
        Enzyme.Duplicated(params, ∇x),
        Enzyme.Const(aux)
    )
    ∇x
end

mwe(Float64)

[16416] signal (11.1): Segmentation fault
in expression starting at REPL[22]:1
getindex at ./essentials.jl:13 [inlined]
getindex at ./subarray.jl:323 [inlined]
mapreduce_impl at ./reduce.jl:260
unknown function (ip: 0x2)
macro expansion at /home/krkim/.julia/packages/Enzyme/VSRgT/src/compiler.jl:8197 [inlined]
enzyme_call at /home/krkim/.julia/packages/Enzyme/VSRgT/src/compiler.jl:7760 [inlined]
CombinedAdjointThunk at /home/krkim/.julia/packages/Enzyme/VSRgT/src/compiler.jl:7533 [inlined]
autodiff at /home/krkim/.julia/packages/Enzyme/VSRgT/src/Enzyme.jl:491 [inlined]
autodiff at /home/krkim/.julia/packages/Enzyme/VSRgT/src/Enzyme.jl:512 [inlined]
mwe at ./REPL[21]:22
unknown function (ip: 0x7f05dbd13282)
_jl_invoke at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/gf.c:2895 [inlined]
ijl_apply_generic at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/gf.c:3077
jl_apply at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/julia.h:1982 [inlined]
do_call at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/interpreter.c:126
eval_value at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/interpreter.c:223
eval_stmt_value at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/interpreter.c:174 [inlined]
eval_body at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/interpreter.c:617
jl_interpret_toplevel_thunk at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/interpreter.c:775
jl_toplevel_eval_flex at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/toplevel.c:934
jl_toplevel_eval_flex at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/toplevel.c:877
ijl_toplevel_eval_in at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/toplevel.c:985
eval at ./boot.jl:385 [inlined]
eval_user_input at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/usr/share/julia/stdlib/v1.10/REPL/src/REPL.jl:150
repl_backend_loop at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/usr/share/julia/stdlib/v1.10/REPL/src/REPL.jl:246
#start_repl_backend#46 at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/usr/share/julia/stdlib/v1.10/REPL/src/REPL.jl:231
start_repl_backend at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/usr/share/julia/stdlib/v1.10/REPL/src/REPL.jl:228
_jl_invoke at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/gf.c:2895 [inlined]
ijl_apply_generic at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/gf.c:3077
#run_repl#59 at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/usr/share/julia/stdlib/v1.10/REPL/src/REPL.jl:389
run_repl at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/usr/share/julia/stdlib/v1.10/REPL/src/REPL.jl:375
jfptr_run_repl_91949.1 at /home/krkim/.julia/juliaup/julia-1.10.6+0.x64.linux.gnu/lib/julia/sys.so (unknown line)
_jl_invoke at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/gf.c:2895 [inlined]
ijl_apply_generic at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/gf.c:3077
#1013 at ./client.jl:437
jfptr_YY.1013_82918.1 at /home/krkim/.julia/juliaup/julia-1.10.6+0.x64.linux.gnu/lib/julia/sys.so (unknown line)
_jl_invoke at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/gf.c:2895 [inlined]
ijl_apply_generic at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/gf.c:3077
jl_apply at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/julia.h:1982 [inlined]
jl_f__call_latest at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/builtins.c:812
#invokelatest#2 at ./essentials.jl:892 [inlined]
invokelatest at ./essentials.jl:889 [inlined]
run_main_repl at ./client.jl:421
exec_options at ./client.jl:338
_start at ./client.jl:557
jfptr__start_82944.1 at /home/krkim/.julia/juliaup/julia-1.10.6+0.x64.linux.gnu/lib/julia/sys.so (unknown line)
_jl_invoke at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/gf.c:2895 [inlined]
ijl_apply_generic at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/gf.c:3077
jl_apply at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/julia.h:1982 [inlined]
true_main at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/jlapi.c:582
jl_repl_entrypoint at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/src/jlapi.c:731
main at /cache/build/builder-amdci5-5/julialang/julia-release-1-dot-10/cli/loader_exe.c:58
unknown function (ip: 0x7f06480d5e07)
__libc_start_main at /usr/lib/libc.so.6 (unknown line)
unknown function (ip: 0x4010b8)
Allocations: 38356665 (Pool: 38283792; Big: 72873); GC: 56
zsh: segmentation fault (core dumped)  julia

This is on 1.10 BTW:
Julia Version 1.10.6
Commit 67dffc4a8ae (2024-10-28 12:23 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 20 × 12th Gen Intel(R) Core(TM) i7-12700H
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, alderlake)
Threads: 1 default, 0 interactive, 1 GC (on 20 virtual cores)

related: https://github.com/TuringLang/AdvancedVI.jl/pull/129

Hm, are you able to reduce this?

Let me give it a shot

@wsmoses  Would this be more useful?:
using Enzyme
using Distributions
using LinearAlgebra
using StableRNGs
using Random
using Optimisers
using Functors

struct MvLocationScale{
    S, D <: ContinuousDistribution, L, E <: Real
} <: ContinuousMultivariateDistribution
    location ::L
    scale    ::S
    dist     ::D
    scale_eps::E
end

Functors.@functor MvLocationScale (location, scale)

struct RestructureMeanField{S<:Diagonal,D,L,E}
    model::MvLocationScale{S,D,L,E}
end

function (re::RestructureMeanField)(flat::AbstractVector)
    n_dims = div(length(flat), 2)
    location = first(flat, n_dims)
    scale = Diagonal(last(flat, n_dims))
    return MvLocationScale(location, scale, re.model.dist, re.model.scale_eps)
end

function Optimisers.destructure(q::MvLocationScale{<:Diagonal,D,L,E}) where {D,L,E}
    (; location, scale, dist) = q
    flat = vcat(location, diag(scale))
    return flat, RestructureMeanField(q)
end

function Distributions.rand(
    rng::AbstractRNG, q::MvLocationScale{<:Diagonal,D,L}, num_samples::Int
) where {L,D}
    (; location, scale, dist) = q
    n_dims = length(location)
    scale_diag = diag(scale)
    return scale_diag .* rand(rng, dist, n_dims, num_samples) .+ location
end

function estimate_repgradelbo_ad_forward(params′, aux)
    (; restructure,) = aux
    q = restructure(params′)::typeof(restructure.model)
    samples = rand(Random.default_rng(), q, 3)
    mean(samples)
end

function mwe(T)
	d = 2
    q = MvLocationScale(
        zeros(T, d), Diagonal(ones(T, d)), Normal{T}(zero(T), one(T)), T(1e-5)
    )
    params, restructure, = Optimisers.destructure(q)

    aux = (
        restructure=restructure,
    )

    ∇x = zero(params)
    fill!(∇x, zero(eltype(∇x)))
    _, y = Enzyme.autodiff(
        set_runtime_activity(Enzyme.ReverseWithPrimal, true),
        estimate_repgradelbo_ad_forward,
        Enzyme.Active,
        Enzyme.Duplicated(params, ∇x),
        Enzyme.Const(aux)
    )
    ∇x
end

mwe(Float64)

That is but anything further you can do will help

Stripped a little more

using Enzyme
using Distributions
using LinearAlgebra
using Random

struct MvLocationScale{
    S, D <: ContinuousDistribution, L
} <: ContinuousMultivariateDistribution
    location ::L
    scale    ::S
    dist     ::D
end

struct RestructureMeanField{S<:Diagonal,D,L}
    model::MvLocationScale{S,D,L}
end

function (re::RestructureMeanField)(flat::AbstractVector)
    n_dims = div(length(flat), 2)
    location = first(flat, n_dims)
    scale = Diagonal(last(flat, n_dims))
    return MvLocationScale(location, scale, re.model.dist)
end

function destructure(q::MvLocationScale{<:Diagonal,D,L}) where {D,L}
    (; location, scale, dist) = q
    flat = vcat(location, diag(scale))
    return flat, RestructureMeanField(q)
end

function Distributions.rand(
    rng::AbstractRNG, q::MvLocationScale{<:Diagonal,D,L}, num_samples::Int
) where {L,D}
    (; location, scale, dist) = q
    n_dims = length(location)
    scale_diag = diag(scale)
    return scale_diag .* rand(rng, dist, n_dims, num_samples) .+ location
end

function estimate_repgradelbo_ad_forward(params′, aux)
    (; restructure,) = aux
    q = restructure(params′)::typeof(restructure.model)
    samples = rand(Random.default_rng(), q, 3)
    mean(samples)
end

function mwe(T)
	d = 2
    q = MvLocationScale(zeros(T, d), Diagonal(ones(T, d)), Normal{T}(zero(T), one(T)))
    params, restructure, = destructure(q)
    aux = (restructure=restructure,)

    ∇x = zero(params)
    fill!(∇x, zero(eltype(∇x)))
    _, y = Enzyme.autodiff(
        set_runtime_activity(Enzyme.ReverseWithPrimal, true),
        estimate_repgradelbo_ad_forward,
        Enzyme.Active,
        Enzyme.Duplicated(params, ∇x),
        Enzyme.Const(aux)
    )
    ∇x
end

mwe(Float64)

Any chance you can get rid of the distributions dependency (ccalls are fine)

The problem seemed to go away if I removed the dist field, so I couldn't simply axe it out. At this point, it is a bit of shooting in the dark for me to try to replicate the problem without dist.

Okay, the following works, so it's not obvious to me how to remove Distributions while keeping the bug:

using Enzyme
using LinearAlgebra
using Random
using Statistics

struct FakeNormal end

struct MvLocationScale{S, D, L}
    location ::L
    scale    ::S
    dist     ::D
end

struct RestructureMeanField{S<:Diagonal,D,L}
    model::MvLocationScale{S,D,L}
end

function (re::RestructureMeanField)(flat::AbstractVector)
    n_dims = div(length(flat), 2)
    location = first(flat, n_dims)
    scale = Diagonal(last(flat, n_dims))
    return MvLocationScale(location, scale, re.model.dist)
end

function destructure(q::MvLocationScale{<:Diagonal,D,L}) where {D,L}
    (; location, scale, dist) = q
    flat = vcat(location, diag(scale))
    return flat, RestructureMeanField(q)
end

function rand(
    rng::AbstractRNG, ::FakeNormal, n_dims::Int, num_samples::Int
)
	return randn(rng, n_dims, num_samples)
end

function rand(
    rng::AbstractRNG, q::MvLocationScale{<:Diagonal,D,L}, num_samples::Int
) where {L,D}
    (; location, scale, dist) = q
    n_dims = length(location)
    scale_diag = diag(scale)
    return scale_diag .* rand(rng, dist, n_dims, num_samples) .+ location
end

function estimate_repgradelbo_ad_forward(params′, aux)
    (; restructure,) = aux
    q = restructure(params′)::typeof(restructure.model)
    samples = rand(Random.default_rng(), q, 3)
    mean(samples)
end

function mwe(T)
    d = 2
    q = MvLocationScale(zeros(T, d), Diagonal(ones(T, d)), FakeNormal())
    params, restructure, = destructure(q)
    aux = (restructure=restructure,)

    ∇x = zero(params)
    fill!(∇x, zero(eltype(∇x)))
    _, y = Enzyme.autodiff(
        set_runtime_activity(Enzyme.ReverseWithPrimal, true),
        estimate_repgradelbo_ad_forward,
        Enzyme.Active,
        Enzyme.Duplicated(params, ∇x),
        Enzyme.Const(aux)
    )
    ∇x
end

mwe(Float64)

using Enzyme
using LinearAlgebra
using Random
using Statistics

Enzyme.API.printall!(true)
Enzyme.Compiler.DumpPostOpt[] = true

struct MyNormal
    sigma::Float64
    off::Float64
end

struct MvLocationScale{
    S, D, L
}
    location ::L
    scale    ::S
    dist     ::D
end

@noinline function law(dist, flat::AbstractVector)
    ccall(:jl_, Cvoid, (Any,), flat)
    n_dims = div(length(flat), 2)
    data = first(flat, n_dims)
    scale = Diagonal(data)
    return MvLocationScale(nothing, scale, dist)
end

function destructure(q::MvLocationScale)
    return diag(q.scale)
end

myxval(d::MyNormal, z::Real) = muladd(d.sigma, z, d.off)

function myrand!(rng::AbstractRNG, d::MyNormal, A::AbstractArray{<:Real})
    # randn!(rng, A)
    map!(Base.Fix1(myxval, d), A, A)
    return A
end

function man(q::MvLocationScale)
    dist = MyNormal(1.0, 0.0)

    out = ones(2,3) # Array{Float64}(undef, (2,3))
    @inbounds myrand!(Random.default_rng(), dist, out)

    return q.scale[1] * out
end

function estimate_repgradelbo_ad_forward(params, dist)
    q = law(dist, params)
    samples = man(q)
    mean(samples)
end

function mwe(T)
	d = 2
    dist = MyNormal(1.0, 0.0)
    q = MvLocationScale(zeros(T, d), Diagonal(ones(T, d)), dist)
    params = destructure(q)

    ∇x = zero(params)
    fill!(∇x, zero(eltype(∇x)))

    estimate_repgradelbo_ad_forward(params, dist)

    _, y = Enzyme.autodiff(
        set_runtime_activity(Enzyme.ReverseWithPrimal),
        estimate_repgradelbo_ad_forward,
        Enzyme.Active,
        Enzyme.Duplicated(params, ∇x),
        Enzyme.Const(dist)
    )
    ∇x
end

mwe(Float64)

fixed by https://github.com/EnzymeAD/Enzyme.jl/pull/2047

@wsmoses Any plans for the next release?


Create homepage with all generated cheatsheets

create home page referencing all generated cheatsheets, A11Y compliant.

@all-contributors please add @LiolluryZ  for starting project

@all-contributors
please add @nkCreation for contributions.
please add @awattez  for contributions.

https://github.com/all-contributors
please add @nkCreation for promotions.
please add @awattez for code.

@all-contributors
please add @nkCreation for promotions.
please add @awattez for code.

@all-contributors please add @nkCreation for promotion.

@all-contributors please add @nkCreation for promotion.


doctest doctest fails on Matlab

Tested on 2015b:
Error using doctest_run (line 64)
doctest: syntax error, expected +XFAIL_IF(varname)

Its failing on:
'"shiny Octave feature"    % doctest: +XFAIL_IF(DOCTEST_MATLAB)'

I think I broke it in 3933c99b2dccb2fc186de7d8d3415b3a61e8496c, seems the regex may not match the DOCTEST_MATLAB.

Seems to be related to (?:  (  )  ), that is, non token grouping with a token grouping inside.


CMake path should be set in constructor

Else if we skip the install the path is not set. Also the path should be absolute.

Not needed.


Answer overwritten when multiple users edit the same question

Description / Beschreibung
If two users answer a question simultaneously and then click "Proceed," only the response of the user who clicked "Proceed" first will be saved.
Expected behaviour / Erwartetes Verhalten
Based on the issue #626 and the release notes of 2.1.0, I expect the following:

Conflicts will be prevented when users attempt to edit the same values simultaneously.

Steps to reproduce / Schritte zum Reproduzieren

User 1 edits Question A in RDMO.
User 2 edits Question A in RDMO.
User 1 clicks "Proceed".
User 2 clicks "Proceed" after User 1.
Result: Question A contains the answer from User 1.

Context / Kontext
RDMO Version 2.1.3
References / Verweise

#626
Release 2.1.0

Hi @AliceWi! In your example, does User2 get a message that the value is not saved? If yes, that is (at least my) expected bahavior. If not, this might be a bug which is already fixed, but only in the upcoming release.

This is a bit odd, the proceed button on the right works a bit different as the blue one on the bottom, but both should save the input. Is the question kind of special?

Never mind, I found it. The error message is shown, but then the page is changed anyway. The same is probably the case if you use the navigation. I will look for a fix.


How to create bar chart in hygieia

@sanchitacool  use chartist.js . Refer documentation - https://gionkunz.github.io/chartist-js/

How to create chart using jira rest api


[V4] Fast Refresh should dismiss runtime errors

Type foo.bar() inside a component
See runtime error overlay
Change that to foo.baz() and save

Expected: see the foo.baz() error overlay instead.
Actual: keep seeing the foo.bar() overlay with the new error being "added" (the screen says 1 of 2 errors).
In other words, when we do a Fast Refresh, we should always be dismissing the runtime overlay first.
This is because the previous error is stale by the time you save the code and likely irrelevant.

I think maybe this function needs to dismiss the runtime ones?
https://github.com/facebook/create-react-app/blob/025f2739ceb459c79a281ddc6e60d7fd7322ca24/packages/react-dev-utils/webpackHotDevClient.js#L182

Had trouble reproducing on master. It appears to work as intended when following your repro steps (overlay only shows latest error). Maybe i missed something.

@ianschmitz
Here is how to reproduce the issue - https://recordit.co/gqVKssNvhW
Actually, You can simply do

Type {foo} and save
Change to {.} and save
Remove then save

@gaearon @ianschmitz
I spent a day debug this issue and managed to make it work, But the problem is I can't explain why it works.
I have found that somehow calling hot.check causes a runtime error even the last message from the socket is ok.
What I have done is just make it calls tryApplyUpdates when receiving a hash event instead of waiting for an ok event which will come shortly after the hash event (https://github.com/webpack/webpack-dev-server/blob/v3.11.0/lib/Server.js#L981-L989) and It solves this issue.
I have taken a look at next.js's dev-client which has a similar implementation but it doesn't have this issue.
It will be great If someone can point me to where I should take a look.
(make a draft PR: https://github.com/facebook/create-react-app/pull/9972)


is there any working convoy-glusterfs configuration ?

I dont get it.
I've been trying around for days with different version of convoy-gluster fs, different operating systems and different docker versions. but did not get ANY of them to work.
So does anyone have a working configuration of convoy glusterfs ? please post your configuration of:
os, docker-version, convoy-agent docker file version,... here
thanks

I have had success with RancherOS v0.4.5, which comes with Docker 1.10.3 using the templates in the catalog.

i guess the real question was again and still how to make convoy-glusterfs work with docker 1.11 :)

I did. I made some changes in glusterfs catalog entry because of some constraints (only 2 bricks instead of 3), and deploy convoy-gluster from catalog. Everything work as expected.
Where do you run your glusterfs server? Is it an internal stack or is it an external services?
I'm running RancherOS v0.4.5 (Docker version 1.10.3, build 20f81dd)

In last version of Rancher there is no convoy-glusterfs at all, it's deprecated ?

I am going to be experimenting with it today. Here is my docker version
docker --version
Docker version 1.12.5, build 047e51b/1.12.5
so from these posts, i feel it most likely won't work?

it looks like they removed support for glusterfs
https://forums.rancher.com/t/glusterfs-not-available-in-catalog/4278/2


Don't filter on translation table in GO.py when retrieving ensembl dump

As far as I'm aware the translation table was previously used because it was needed for the ID mapping.
If we wanted to restricted GO categories by gene type, this would be better done via biotypes.
But probably best to take all GO categories here regardless of gene biotype and to instead encourage people to filter downstream.

Thanks, Steve.


Possibly wrong indentation level for args.backend

https://github.com/mandiant/capa/blob/master/capa/main.py#L856
    if "format" in wanted:
        formats = [
            (FORMAT_AUTO, "(default) detect file type automatically"),
            (FORMAT_PE, "Windows PE file"),
            (FORMAT_DOTNET, ".NET PE file"),
            (FORMAT_ELF, "Executable and Linkable Format"),
            (FORMAT_SC32, "32-bit shellcode"),
            (FORMAT_SC64, "64-bit shellcode"),
            (FORMAT_FREEZE, "features previously frozen by capa"),
        ]
        format_help = ", ".join(["%s: %s" % (f[0], f[1]) for f in formats])
        parser.add_argument(
            "-f",
            "--format",
            choices=[f[0] for f in formats],
            default=FORMAT_AUTO,
            help="select sample format, %s" % format_help,
        )

        if "backend" in wanted:
            parser.add_argument(
                "-b",
                "--backend",
                type=str,
                help="select the backend to use",
                choices=(BACKEND_VIV,),
                default=BACKEND_VIV,
            )

Should setting the backend be dependent on the format also being set? Logically I don't think so but I may be missing something

Yeah, looks like a bug. With currently only one backend it's less of a problem, but this should be handled for https://github.com/mandiant/capa/pull/1343/files at least.

thanks @linpeiyu164 !


bug: Error exporting QuantizedBert to ONNX

When attempting to export a Q8BERT model to ONNX, TorchScript reports a runtime error.
Since the quantized forward methods embed Tensors with grads from layer instance attributes rather than input parameters, exporting the model has to be done with explicit torch script tracing; however that creates a traced model with lacks fidelity with the python model, as branching behavior is not captured.
However, attempting to create a script model with TorchScript, which should encode that behavior results in a missing config attribute on the BertModel superclass.
To Reproduce
Steps to reproduce the behavior:

Train a Q8Bert model:

 nlp-train transformer_glue \
            --task_name mrpc \
            --model_name_or_path bert-base-uncased \
            --model_type quant_bert \
            --learning_rate 2e-5 \
            --output_dir $DATA_DIR \
            --data_dir $GLUE_DIR  \
            --evaluate_during_training \
            --do_lower_case \
            --per_gpu_train_batch_size 32 \
            --per_gpu_eval_batch_size 32 \
            --max_seq_length 128

Load the 8bit model for inference

import torch
from nlp_architect.models.transformers.quantized_bert import QuantizedBertForSequenceClassification

model = QuantizedBertForSequenceClassification.from_pretrained(configs.data_dir, from_8bit=True)
device = torch.device("cuda")
model.to(device)
model.eval()

Attempt to create the script model

script_model = torch.jit.script(model)

This produces the error:

Traceback (most recent call last):
  File "convert-torch-q8bert-via-onnx-to-tensorflow.py", line 105, in <module>
    script_model = torch.jit.script(model)
  File "/home/krhys/.local/share/virtualenvs/q8bert-_S0V57VU/lib/python3.7/site-packages/torch/jit/__init__.py", line 1203, in script
    return torch.jit.torch.jit._recursive.recursive_script(obj)
  File "/home/krhys/.local/share/virtualenvs/q8bert-_S0V57VU/lib/python3.7/site-packages/torch/jit/_recursive.py", line 173, in recursive_script
    return copy_to_script_module(mod, overload_stubs + stubs)
  File "/home/krhys/.local/share/virtualenvs/q8bert-_S0V57VU/lib/python3.7/site-packages/torch/jit/_recursive.py", line 95, in copy_to_script_module
    torch.jit._create_methods_from_stubs(script_module, stubs)
  File "/home/krhys/.local/share/virtualenvs/q8bert-_S0V57VU/lib/python3.7/site-packages/torch/jit/__init__.py", line 1423, in _create_methods_from_stubs
    self._c._create_methods(self, defs, rcbs, defaults)
  File "/home/krhys/.local/share/virtualenvs/q8bert-_S0V57VU/lib/python3.7/site-packages/torch/jit/_recursive.py", line 195, in make_strong_submodule
    new_strong_submodule = recursive_script(module)
  File "/home/krhys/.local/share/virtualenvs/q8bert-_S0V57VU/lib/python3.7/site-packages/torch/jit/_recursive.py", line 173, in recursive_script
    return copy_to_script_module(mod, overload_stubs + stubs)
  File "/home/krhys/.local/share/virtualenvs/q8bert-_S0V57VU/lib/python3.7/site-packages/torch/jit/_recursive.py", line 95, in copy_to_script_module
    torch.jit._create_methods_from_stubs(script_module, stubs)
  File "/home/krhys/.local/share/virtualenvs/q8bert-_S0V57VU/lib/python3.7/site-packages/torch/jit/__init__.py", line 1423, in _create_methods_from_stubs
    self._c._create_methods(self, defs, rcbs, defaults)
RuntimeError:
module has no attribute 'config':
at /home/krhys/.local/share/virtualenvs/q8bert-_S0V57VU/lib/python3.7/site-packages/transformers/modeling_bert.py:675:15
        # We can provide a self-attention mask of dimensions [batch_size, from_seq_length, to_seq_length]
        # ourselves in which case we just need to make it broadcastable to all heads.
        if attention_mask.dim() == 3:
            extended_attention_mask = attention_mask[:, None, :, :]

        # Provided a padding mask of dimensions [batch_size, seq_length]
        # - if the model is a decoder, apply a causal mask in addition to the padding mask
        # - if the model is an encoder, make the mask broadcastable to [batch_size, num_heads, seq_length, seq_length]
        if attention_mask.dim() == 2:
            if self.config.is_decoder:
               ~~~~~~~~~~~ <--- HERE
                batch_size, seq_length = input_shape
                seq_ids = torch.arange(seq_length, device=device)
                causal_mask = seq_ids[None, None, :].repeat(batch_size, seq_length, 1) <= seq_ids[None, :, None]
                extended_attention_mask = causal_mask[:, None, :, :] * attention_mask[:, None, None, :]
            else:
                extended_attention_mask = attention_mask[:, None, None, :]

        # Since attention_mask is 1.0 for positions we want to attend and 0.0 for
        # masked positions, this operation will create a tensor which is 0.0 for
'__torch__.nlp_architect.models.transformers.quantized_bert.QuantizedBertModel.forward' is being compiled since it was called from '__torch__.nlp_architect.models.transformers.quantized_bert.QuantizedBertForSequenceClassification.forward'
at /home/krhys/.local/share/virtualenvs/q8bert-_S0V57VU/lib/python3.7/site-packages/transformers/modeling_bert.py:1014:8
    def forward(self, input_ids=None, attention_mask=None, token_type_ids=None,
                position_ids=None, head_mask=None, inputs_embeds=None, labels=None):

        outputs = self.bert(input_ids,
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~...  <--- HERE
                            attention_mask=attention_mask,
                            token_type_ids=token_type_ids,
                            position_ids=position_ids,
                            head_mask=head_mask,
                            inputs_embeds=inputs_embeds)

        pooled_output = outputs[1]

        pooled_output = self.dropout(pooled_output)

Expected behavior
It should produce a script model without error
**Environment setup: **

OS (Linux/Mac OS): Ubuntu Xenial
Python version: 3.7

Additional context
It may be possible to create pure helper quantized forward functions with explicit arguments which have the @torch.jit.script annotations which are called by the quantized layer forward methods
Note that the HuggingFace transformers Bert model can be exported to ONNX.

@kirstin-rhys waiting to hear if everything worked out for you and what was your solution.

It worked out. Sadly the export from onnx has more serious issues.
the basic method was to move the bulk of the quantized forward methods into helper functions with type annotations and annotate them for scripting, rather than tracing (i.e. @torch.jit.script) and manually run the trace with opset 11 and dummy input before exporting

hi @kirstin-rhys and @ofirzaf , I am running into the same problem of converting a quanitized model to onnx format. for that, i'm using torch.onnx.export and the error that i'm getting is
operator quantized::linear_dynamic because torch.onnx.symbolic_opset9.linear_dynamic does not exist.

It worked out. Sadly the export from onnx to tensorflow has more serious issues.
the basic method was to move the bulk of the quantized forward methods into stateless helper functions via explicit parameter passing with type annotations and @torch.jit.script annotations and manually running the trace with opset 11 and dummy input before exporting

hi @kirstin-rhys , I'm also working on exporting this into onnx. I wonder if you would like to share your code or elaborate more on how you get around this problem? Thanks!


smtweb cannot display records that have a space in their name

records can be created with a space in their label, but trying to display them in smtweb causes a django 404 error, because the url doesn't match any of the routing patterns.
Imported from Bitbucket issue 123,  created by apdavison on 01-08-2013 at 16:26, last modified: 04-19-2013 at 13:16

Fixed in r713
Trac comment by apdavison on 04-19-2013 at 13:16


IGAPP-93: Deep linking

This pull request belongs to an issue on our bugtracker.
You can find it there by looking for an issue with the key which is mentioned in the title of this pull request.
It starts with the keyword IGAPP.

Deep linking :tada:
Please review before I write tests. Some things may not be solved optimally.
You can test it either by adding uri-scheme library and executing commands as specified here https://reactnavigation.org/docs/deep-linking#test-deep-linking-on-android or by clicking on corresponding links/opening them in a browser.
Things worth mentioning:

Previously city selections are not handled, the city/language of the deep link is always permanently selected. To change this, the user has to navigate back to the city selection and select the previous city. Not really sure but I'd say that is fine as it occurs probably more often that a user wants to select the city when opening a deep linking than the opposite.
Universal links (https:// deep links) will probably not work on iOS as so called apple-app-site-association files are needed, see https://issues.tuerantuer.org/browse/IGAPP-520

* Previously city selections are not handled, the city/language of the deep link is always permanently selected. To change this, the user has to navigate back to the city selection and select the previous city. Not really sure but I'd say that is fine as it occurs probably more often that a user wants to select the city when opening a deep linking than the opposite.

I dont really agree here. If you say that integreat should handle integreat.app links then you open ALL links found in google for example.

I dont really agree here. If you say that integreat should handle integreat.app links then you open ALL links found in google for example.
 Can't we use the peek api here?
Thought about it a little more and I guess you are right. Also finally a use case for peeking :tada:

@SteffiStuffel good catch, thanks! Could you check whether this still happens?

@SteffiStuffel good catch, thanks! Could you check whether this still happens?

Nope. Is fixed now.

Maybe it would be nice, if we add an information on how to test deep linking in readme?

I updated the branch and retriggered a new build. iOS should work now


[Feature Request] Filters inputs doesn't focus when opening the filter

Feature Request
What's the feature you think Backpack should have?
When user open a filters, the focus is not on the input field, so user cannot start entering keys, but must click once again to gain focus
Have you already implemented a prototype solution, for your own project?
We added 'globally' in an app.js a small fix for select 2
$(document).on('select2:open', () => {
    document.querySelector('.select2-search__field').focus();
});

Enough for our specific case but NOT covering text input fields.
Do you see this as a core feature or an add-on?
it should be a core feature

Hello @realtebo
Thanks for the suggestion.
I think this already work on fields, you can check it on demo  ( https://demo.backpackforlaravel.com ) that when the select2 opens the search is focused so you can start typing right way.
But I am afraid it does not work the same way in select2 Filters from my tests.
I will be switching this to issue instead of Feature Request and assign @jorgetwgroup to have a look at it as he already worked on this select2 focus issues previously.
Cheers

Please, do not focus only on select2. this is easily fixable by ourselves.
Fixit for textual inputs

So that becomes a Feature and not a fix, cause until now NONE of the filters open the inputs.
I also think that this lies somewhat in a "fix" for UX/UI so I will keep this in This Week for @jorgetwgroup to have a look when he got time for it.
If it does not require massive changes we could fit this in the "fixing" pipeline for UI/UX stuff and be done with it, otherwise we will move this as a Feature Request to have a look in the next version.
Thanks again @realtebo

Jumping in. This is also something that bothered me, multiple times. I kind of agree with you Pedro that it's "a feature"... but I "kind of" agree with @realtebo too that it's a bug. After all... it doesn't behave in the expected way. And unfortunately @pxpm we DO have a filter that focuses on the input select2_multiple. So... not only is it non-intuitive... it's inconsistent... 😔 So let's call it what it is... a bug 😀
This is a small problem, but I want us to get it done in this version. These small things add up to a better UX and show how much we care.
To sum up, here are all the filter types and what we should do with each:

[x] Simple - nothing to do
[ ] Text - TODO: focus on input
[ ] Date - TODO: focus on input (will also open picker which is great)
[ ] Date range - TODO: focus on input (will also open picker which is great)
[x] Dropdown - nothing to do
[ ] Select2 - TODO: focus on input (so the user can start typing)
[x] Select2_multiple - nothing to do, already focuses on input
[ ] Select2_ajax - TODO: focus on input (so the user can start typing)
[ ] Range - TODO: focus on first input
[x] View - nothing to do

Added the PR in the PRO. https://github.com/Laravel-Backpack/PRO/pull/101
Is waiting review and should probably be merged by next Monday.
Will be closing this, thanks @realtebo for pointing that out 🙏


[Question] What's the difference between nnDetection and MedicalDetectionToolkit

:question: Question

Hi, Michael:
Thanks for sharing your nnDetection codebase. It seems very great and has potential for medical detection task.
I am familiar with medicaldetectiontoolkit, so I have two questions and hoping for your reply.
(1) What's main difference between medicaldetectiontoolkit and nnDetection?
As far as I know, when upgrading pytorch version from 0.4.1 to 1.0+, medicaldetectiontoolkit has gained great traning and inference performance. But its owner pfjaeger seems not make it as default branch.
(2) Detailed results on different dataset should be checked carefully.
Instead of most citing paper directly, I think we would better checking its real performance. For example, whether it is 10-fold cross-validation, whether it used lung mask for pre/post processing, whether it is 5 fold model, etc.
Most so called medical image SOTA paper seldom open-sourced its official code. That makes us can not reproduce and testify its real numerical results. By the way, that's why many researchers include me have much respect on Fabian and you guys in DKFZ.
Just as you read the former issue, it claims its results on LUNA16 is 0.125（72.3）0.25（83.8） 0.5（88.7） 1（91.1）2（92.8）4（93.4）8（94.8）average 88.1.
Here is my re-implementation results on LUNA16 with medicaldetectiontoolkit.
(1) Dataset
Traning and validation set: subset 0-7.
Test set: subset 8,9.
(2) Results
(1) 5 Model + 2Dc MaskRCNN (mAP10: 0.6894)
0.125（0.570）0.25（0.659） 0.5（0.776） 1（0.879）2（0.910）4（0.932）8（0.973）average 0.814.
(2) 1 Model + NoTTA + 2Dc MaskRCNN (mAP10: 0.755)
0.125（0.404）0.25（0.605） 0.5（0.709） 1（0.834）2（0.883）4（0.0.915）8（0.937）average 0.755.
(3) 1 Model + NoTTA + 2Dc FasterRCNN (mAP10: 0.5943)
0.125（0.501）0.25（0.632） 0.5（0.767） 1（0.830）2（0.883）4（0.0.915）8（0.937）average 0.782.
There are part of my results on LUNA16 and it is close with medicaldetectiontoolkit author results on LIDC-IDRI.
Table 1 from "Retina U-Net: Embarrassingly Simple Exploitation ofSegmentation Supervision for Medical Object Detection"
https://ml4health.github.io/2019/pdf/232_ml4h_preprint.pdf
Hoping to contact with you in the future.
Best,

Hi @MengzhangLI ,
thanks for your interest in nnDetection and the nice words 👍
(1)
The mdt (medical detection toolkit) compared multiple detectors and proposed Retina U-Net which is an extension of RetinaNet. It was designed as a toolkit to be used by researchers and thus requires manual hyperparameter tuning and custom dataloaders for each new dataset.
nnDetection follows nnU-Net and contains a whole self-configuring pipeline that can be applied to arbitrary new data set without manual intervention (no hyperparameter tuning required) but focuses on one base architecture (Retina U-Net). More information can be found in our publication nnDetection: A Self-configuring Method for Medical Object Detection which can be found online very soon. Future versions will potentially add more architectures and make other models (such as Mask R-CNN) available. Since those approaches need to be tested thoroughly on all datasets to ensure generalizability and performance, there is no ETA yet.
(2)
The provided Luna results were intended to reflect the literature landscape upon submission of nnDetection (March 2021). Unfortunately, it will be out of scope of this repository to reproduce the results of all previous methods. All of the included results should reflect a 10 fold cross-validation. We hope to include more benchmarks with public leaderboards and closed test sets in the future (which should be helpful to compare results).
We hope that nnDetection will foster more standardized evaluation in the medical object detection community by providing unified entrypoints to a wide number of data sets and a strong out-of-box baseline method for future research.
Hope this answer helps :)
Best,
Michael

Guten Morgan Michael,
Glad to receive your reply!
I will try your framework ASAP. Based on my previous experiments, RetinaUNet is not worse than many two-stage algorithms such as Faster RCNN and Mask RCNN on lung nodule detection tasks.
Best,
Mengzhang Li

Hi @MengzhangLI ,
great to hear 👍
Compared to typical two-stage networks, Retina U-Net is a great alternative and is applicable to a broader range of data sets. The original papers provide some Toy Experiments for different data set sizes and Retina U-Net performed quite consistently on them while the other networks suffered from severe performance drops on smaller ones.
I'll close the Issue for now, but feel free to reopen it or create a new one if any other questions arise.
Best,
Michael


Two-finger swipe horizontally on TextArea should scroll horizontally.

Similar to current vertical swipe.

Done.


add translation

Add translation for more languages than English.

We'll need support from the community to do this.


Loader is broken in latest Chrome

The loader spinning animation is not displayed properly in the latest chrome browser, Version 66.0.3359.139 (Official Build) (64-bit)
Open this link in latest chrome browser to see the issue
https://semantic-ui.com/elements/loader.html

I just tested this on 66.0.3359.139 (Official Build) (64-bit) and its working for me.

It is an issue with a Chrome extension: Loom - Video Recorder
https://chrome.google.com/webstore/detail/loom-video-recorder-scree/liecbddmkiiihnedobmlmillhodjkdmb
It interferes with the spinning animation of the loader.

Thank  you for figuring out what was causing this!  I was having the same issue.


Padding issue

Hi Olton,
I'm updating from 4.3.7 to latest release 4.4.3.
Padding stops working on cell div when I've got grid with no-gap.
Exemple : https://codepen.io/Falconpage/pen/YzNWxqp

put div into cell and apply padding to it, no-gap cancelled paddings for the cells

Thanks


Rate limit error

Rye's CI seems to run into rate limit issues using this action (correct me if I'm wrong on the source).
Here's the error from your recent contribution (v2) https://github.com/astral-sh/rye/commit/fa0b306dfa3e54be852888083e08d54fc9c44a84.
Run eifinger/setup-rye@v2
  with:
    version: latest
    enable-cache: false
Error: API rate limit exceeded for <IP_ADDRESS>. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)

Yes the reason is that I check what version latest currently refers to. For that I query all available releases. But also downloading the rye binary itself can lead to a rate limit. I need to know the version. To interact with the GitHub cache.
For normal repositories I would suggest that the action and rye version should be pinned to avoid the first issue (getting the list of available versions), but I do see the need to just use latest for your use case.
The easy workaround is to supply a GitHub token as explained here: https://github.com/eifinger/setup-rye?tab=readme-ov-file#api-rate-limit
As said above I can never fully guarantee that the rate limit won't be hit without the token because even just downloading the latest binary and ignoring the version and cache can trigger the rate limit.

Yes, but even this call can run into rate limits if it is being called more than 60 times per hour per IP.

Okay. Then maybe it's at least a reasonable optimization, what do you think?

I have some ideas that might reduce the number of calls counting against the rate limit when using latest.
In the meantime providing the token will up the limit from 60 to 1500.
Another idea is to reduce the number of calls per CI run. For example by putting the rye lint and rye format steps into the same workflow.

With https://github.com/eifinger/setup-rye/pull/197 merged we now save 1 API call when using latest.


#GH-40 @ in the standup report for people who have not submitted.

Summary
@ is added in along with the usernames/handles in the standup report for people who have not submitted.
Checklist

[x] Added or updated test cases
[x] make test Ran test cases and ensured they are passing
[x] make check-style Ran style check and ensured both webapp and server components comply the style guides

Closing and re-opening to trigger all checks.

Looks good! Thanks, @sandipagarwal for the pull request. Merging this now.


[SPARK-XXXXX][SQL][DOCS] consistency in argument naming for time functions

What changes were proposed in this pull request?

Rename documented argument format as fmt, to match the same argument name in several other SQL date/time functions, to wit, date_format, date_trunc, trunc, to_date, and to_timestamp all use fmt. Also format_string and printf use the same abbreviation in their argument strfmt.
Why are the changes needed?

Consistency -- I was trying to scour the documentation for functions with arguments using Java string formatting, it would have been nice to rely on searching for fmt instead of my more manual approach.
Does this PR introduce any user-facing change?

In the documentation only
How was this patch tested?

No tests

Test build #125030 has started for PR 29007 at commit 524023b.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29637/
Test PASSed.

Test build #125030 has finished for PR 29007 at commit 524023b.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125030/
Test FAILed.

Jenkins retest this please

OK, probably fine if it's just docs and for consistency. That's all of them?

Test build #125088 has started for PR 29007 at commit 524023b.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29695/
Test PASSed.

That's all of them?

In fact I found one more (in from_unixtime). Fixed now.
Pattern searched:

usage[^)]*format

Test build #125095 has started for PR 29007 at commit 5e2ae96.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29702/
Test PASSed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125088/
Test FAILed.

test this please

Test build #125105 has started for PR 29007 at commit 5e2ae96.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29711/
Test PASSed.

Test build #125095 has finished for PR 29007 at commit 5e2ae96.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #125105 has finished for PR 29007 at commit 5e2ae96.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125095/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125105/
Test FAILed.

May I suggest going the other way, i.e., avoiding abbreviation? I don't think there's any value in abbreviating, other than that it makes the argument's meaning less immediately clear. fmt could mean many things -- ferment, forment, foment. Of course it's kind of a standard abbreviation for CS savvy folks, but if this is for ordinary users, then it may not be.

fmt could very clearly not mean any of those things in this context 😄
Further, spelled-out format is written in the plain-English usage section of every one of these functions so I don't see any scope for confusion.
I chose to abbreviate because it was easier for my use case -- format has more than one meaning in the documentation (e.g. DDL format), so looking for fmt made my search more precise -- distinguishing argument names from plain English descriptions

Thinking about this some more, there may actually be something more important, which is compatibility with named arguments. The names in the docs should probably match the names in the code. And we can't change the names in the code because of API compatibility -- existing callers may refer to them using named arguments.

Note that this PR only changes the docstrings in the SQL API, AFAIK SQL doesn't support named arguments

People don't use those references for non-SQL calls?

no, since there are subtle but important differences and the respective APIs are easy to find right alongside one another on the Spark docs website.
I can personally assure I read R for R reference, SQL for SQL reference, and Python for python reference.
I also see headings for Java and Scala referenced in the same directory, but I rarely use those APIs so can't personally say I use them.

I also prefer 'format' in general, but if this change is the smaller one, let's just do it rather than argue it much more. Someone can bulk change it again to format if desired.

Jenkins test this please

Test build #125483 has started for PR 29007 at commit 5e2ae96.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/30096/
Test PASSed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125483/
Test FAILed.

Jenkins test this please

Test build #125685 has started for PR 29007 at commit 5e2ae96.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/30298/
Test PASSed.

Test build #125685 has finished for PR 29007 at commit 5e2ae96.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125685/
Test PASSed.

Merged to master


Requiring workbox-sw as a CommonJS module

Library Affected:
workbox-sw
Issue or Feature Request Description:
Are there any plans for supporting require('workbox-sw') as as CommonJS module? For example, browserify doesn't seem to support pkg.module as it is still just a proposal. Appending something like this to the importScripts build output would help those who depend on browserify:
if (typeof module !== 'undefined' && module.exports) {
  module.exports = WorkboxSW
}

cc @jeffposnick @philipwalton @addyosmani what do you think about this?
Personally I don't see this as a bad idea. Setting the package.json main value to a commonjs file would definitely make more sense than an iife built to be used in the browser. What do you think?

There are a few potential drawbacks:

There's a 212 byte overhead when switching from the iife to umd bundle for the v2 prod build of workbox-sw. I'm assuming that's consistent across the other packages. (This wouldn't be an issue if we explicitly shipped cjs in addition to iife and es2015 bundles, but then we'd have three different bundle formats instead of just two.)
The use of importScripts('path/to/versioned-file.v###.js') is cache-efficient, and can lead to a meaningful decrease in the number of bytes that a return visitor to a PWA downloads over the course of their interaction with a site. If the workbox-sw code is inlined in the top-level service worker, then it ends up being redownloaded each time the other contents (presumably the precache manifest) change. This is a problem when consuming Workbox as an ES2015 module, too, but at least in that scenario, it's possible to pull in smaller chunks of the code via the named exports.

It's worth evaluating those drawbacks against the benefits for Browserify users in the context of the v3 packaging/loading setup.

Gonna put this issue as chillin for now.
I'm still open to this, but there is a lot going on with V3 and you are the first person to request this feature. If others would like this then please do thumbs up or comment and we can circle back round to this.

I'm going to close this issue, if anyone wants this feature please feel free to re-open this issue.

It'd be great if this was implemented.
I'd like to migrate from sw-toolbox to workbox-sw, but since I transform all my JS with Browserify, I can't.
For example, this is how my current worker with sw-toolbox looks:
import toolbox from 'sw-toolbox'

/* some logic */

toolbox.precache(things)

Compared to that, trying the same with workbox-sw fails:
import WorkboxSW from 'workbox-sw'
const workbox = new WorkboxSW()

/* register routes, etc */

workbox.precache([])

// -> Uncaught TypeError: WorkboxSW is not a constructor

Indeed, WorkboxSW is undefined.
I'm not familiar with Webpack, but from  a quick glance, it looks like it would work if the WorkboxSW class was exported from packages/workbox-sw/controllers/WorkboxSW.mjs in the main entry point.

The following code will work:
importScripts('path/to/workbox-sw.js');

const workbox = new WorkboxSW()

// Do something with `workbox`.

workbox-sw.js needs to be either a local URL of a copy of the library we distribute, or it could point to an "unofficial" CDN URL like<EMAIL_ADDRESS>In Workbox v3, we make it easier to refer to a copy of the Workbox libraries via an official CDN URL.
The importScripts() call will take care of executing the Workbox code in the context of the service worker, and that code will automatically define the WorkboxSW interface in the service worker's global scope. It's not necessary to explicitly bundle in the Workbox code in order to accomplish what you're trying to do.

I know it's not necessary to bundle it, but I'd much prefer to skip the extra HTTP request.
Bundling also provides the flexibility to post-process the created worker, like minifying, or importing other modules in one build step.

@DecentM

I'm open to supporting this workflow if anyone is willing to have a stab at a PR. We've gone to a lot of effort to enable importing for a rollup build process, so it would be nice to have a browserify support as well.

FWIW, you can skip the extra HTTP request and post-process the final file if you explicitly concatenate the full Workbox JavaScript code into your browserify output, via something like https://stackoverflow.com/questions/36329775/gulp-browserify-then-concat-files
(It's going to be harder to do this in v3 than it is in v2, since we ship smaller standalone files that would each need to be concatenated in order to get the full Workbox codebase.)

I'm going to close this for now. With v3 we should be in a better place for ES module support and ideally everyone would be using this.


TODO: upload an offending wptreport.json


Is there a way to sort by child value using FirebaseUI?

I am using FirebaseUI for a table view. I know that using Firebase, I can sort by child value, but I can't figure out how to do this using FirebaseUI. Is it possible?

@psopher You can simply pass in a query instead of a reference in any of the constructors, for instance:
Firebase *query = [[rootRef queryOrderedByChild:@"foo"] queryEqualToValue:@"bar"];
FirebaseTableViewDataSoource *dataSource = [[FirebaseTableViewDataSource alloc] initWithQuery:query ...];

See https://github.com/firebase/FirebaseUI-iOS/blob/master/FirebaseUI/Core/API/FirebaseTableViewDataSource.h#L243-L391 for the method signatures.


Add a graph for emission calculations

Add a new function (CO2_emissions) to scaffolding to calculate the CO2 emissions
Add a new function (CO2_impact) to plots to plot it
Enhance the energy calculation notebook to calculate the emissions and plot it

Testing done:

Ran the notebook and generated the chart

@start0318 can you confirm that these are the only changes needed? I ran the notebook and it works. I will plan on merging this tomorrow morning

I don't think I changed any variable names, but I did swap the green and the red.


⚠ Bofrost.at has degraded performance

In 7568105, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2392 ms

Resolved: Bofrost.at performance has improved in 4fdd27e after 16 minutes.


More info regarding Support/Packages/Laravel

I read only the free blog of laravel beyond, so maybe this is explained in the paid book.
I see that we can use flag --support for middleware and rule, and this add them inside Support/Packages/Laravel.
For example if I create a middleware with --support this is created in:
Support/Packages/Laravel/Middleware
Why inside "Laravel" folder and not in Support/Middleware?
Also there is already a folder Support/Packages/Laravel/Middlewares (with final "s"), while our middleware is created inside  Support/Packages/Laravel/Middleware (without "s").
As I can read about Support namespace in the blog article "as the dumping ground for all little helpers that don't belong anywhere". So not sure why everything it's under "Support/Packages/Laravel" and not directly inside "Support/Middleware", etc..
Not sure if for questions like this there is another place.
Thanks

First: That additional s on Middleware is a bug an should not be there.
Second: I faced a problem with packages and namings. Imagin you install to packages: Package One, which brings custom validation rules and package two which brings rules for something not related to Laravel rules.
Now you will add a custom validation rule - extending an existing one from package one. You will put them inside Support/Rules. Adding a "rule" for package two inside the same directory require you (or your team) to remember which rule you can use as e.g. validation rule inside of Laravel or as rule for package two.
So I decided to keep things inside Support/Packages/{PackageName}/{CustomName}/{Classname}. That is the only reason why things with the support flag will be added inside this special namespace.
I'm open to other ideas.

I think that I got your point, however, for a Support/Rules or any other Support class that it's not of a package, by default it's added inside Support/Packages/Laravel which you may think that it's something of Laravel and not of your app.
Why not just leave the choice to developers how to structure the Support folder?
I mean that via command line you can specify the namespace you wish. When you need to extend a class from a package, you decide to put this inside Support/Packages/Packages/...
I didn't think about extending a package class, but immediately I think about how Laravel handle the views that you can extend of a packages. Everything is added inside views/vendor folder.
Which is similar to your solution, but you named it "Packages" instead of Vendor.
So that it's good. But let's leave this choice to developer, maybe by asking via command line like you did for app and domain.

I will talk with @alexgaal and we may revert this again. :) Thanks for the input

Fixed in #71


Make branch pruner pass SSA compliant

As title.

@guilhermeleobas this is a WIP PR for a SSA compliant version of the branch pruning alg. Hopefully it'll help with https://github.com/numba/numba/pull/7244, please let me know if you encounter any problems with it. Thanks!

Note to self: Test fails are probably from the changes in numba/core/lowering.py as the failing tests are those which are looking for patterns in DWARF information or disassembly.

Closing as it is consumed by https://github.com/numba/numba/pull/7244 which is under review.


Replace the current assets with the newer ones.

Hi @aronasorman and @cpauya  this fixes #337
I modified the post_installation.sh that removed the old assets, then run the management command so that it will replace the assets built by make assets.

Made some changes to your branch @arceduardvincent.  Tested the upgrade process as detailed by @amodia on #337.
Will merge this now so Bamboo can make the OS X installer for testing.


[Close as Dup] Create a reference case with Recommendation NNI Notebook

Once the sample notebook PR is in, let's create a reference accordingly.
https://github.com/Microsoft/Recommenders/pull/687

Dup of #957


Update README.md

Not sure if I did this right here

resolve the conflicts and do the necessary

Wait what?
What exactly do you mean ?
(The space, accidentally I added 2 spaces instead of one and then removed the space)

Okay! seems to be fine!
I actually checked your last commit!
Welcome :tada:

Thank you ^.^


Change ?de message

Proposal:
Proposal written by Dadi
What is the title of your proposal?: Change ?de message
Is it a suggestion for the website or for the bot?: Bot
Explain your proposal more accurately (It's best to give as much information as possible, so that we can implement the proposal better): Change the ?d message from
Your streak is: 1 I'll remind you to pick up your daily reward in 24 hours!``` to:
```You have successfully received $402.
Your streak is: **1**
I'll remind you to pick up your daily reward in 24 hours!```
**Why should we add this feature?:** It would look better :helicopter:

**ReportID: 85**

➤ LenoxBot commented:
Approve:
good suggestion.
SaVaGeCrEePeR28 || Furkan🍪🎲#3532

➤ LenoxBot commented:
Approve:
good suggestion
Nickkel#6515

➤ LenoxBot commented:
Approve:
good proposal
Denarioyt#3352


Fixes #502 - Update generated grpc code for the friendship system-test

@fgiorgetti just FYI, I'm going to merge this on green, since this is just generated code

Codecov Report

Merging #525 (22882fe) into main (40471c4) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #525   +/-   ##
=======================================
  Coverage   25.17%   25.17%
=======================================
  Files         115      115
  Lines       28771    28771
  Branches     4669     4669
=======================================
+ Hits         7242     7243    +1
  Misses      20561    20561
+ Partials      968      967    -1

Flag
Coverage Δ

unittests
25.17% <ø> (+<0.01%)
:arrow_up:

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

Impacted Files
Coverage Δ

src/router_core/address_watch.c
79.74% <0.00%> (+1.26%)
:arrow_up:

Continue to review full report at Codecov.

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


Logging on errors thrown in loader

I am trying to debug a loader, but when it crashes I can't seem to log. Here is the trace I get.
I want to wrap these error messages and log tips for fixing them to the user. It doesn't seem possible.
node:internal/errors:465
    ErrorCaptureStackTrace(err);
    ^

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /xxx/src/index.ts
    at new NodeError (node:internal/errors:372:5)
    at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:80:11)
    at defaultGetFormat (node:internal/modules/esm/get_format:122:38)
    at defaultLoad (node:internal/modules/esm/load:21:20)
    at ESMLoader.load (node:internal/modules/esm/loader:431:26)
    at ESMLoader.moduleProvider (node:internal/modules/esm/loader:350:22)
    at new ModuleJob (node:internal/modules/esm/module_job:66:26)
    at #createModuleJob (node:internal/modules/esm/loader:369:17)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:328:34)
    at async ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:82:21) {
  code: 'ERR_UNKNOWN_FILE_EXTENSION'
}

My issue was that my static imports inside my loader were throwing an error which are obviously not possible to catch.


Can't create repository behind nginx reverse proxy

Gitea version (or commit ref): 1.1.0+771-g7e6c198
Git version: 1.9.1
Operating system: Debian 7.11
Database (use [x]):

[ ] PostgreSQL
[x] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[x] No
[ ] Not relevant

Log gist: Nothing special in the logs. Just shows that it returned 200: https://gist.github.com/7d6de273198fd5f1930710fc9edb69ed
Nginx access log (nothing in the error log): <IP_ADDRESS> - - [20/Nov/2017:15:52:49 +0100] "GET /repo/create HTTP/1.1" 499 0 "-" "BrowserUserAgent"

Description
I am trying to setup Gitea behind an nginx (1.12.1) reverse proxy to enable ssl. (via proxy_pass) Everything seems to work fine besides the fact that the repository creation page (under /repo/create) does not load and eventually times out. (according to the nginx log) Accessing the page via the direct port and creating a repo works fine.
I already tried setting proxy_connect_timeout, proxy_send_timeout, proxy_read_timeout and send_timeout to higher values (150, 600, 60000) but none of them do the trick. The page works without issues when directly connecting to the port and the gitea log/console looks the same as it does when using the port.
app.ini repository:
DOMAIN           = code.website.tld
HTTP_ADDR        = sub.website.tld
HTTP_PORT        = 3000
ROOT_URL         = https://code.website.tld/

as for me, I have
DOMAIN                 = localhost
ROOT_URL               = https://[myOuterHost]:[myOuterIp]/
HTTP_ADDR              = <IP_ADDRESS>
HTTP_PORT              = [localGiteaIp]
LOCAL_ROOT_URL         = %(PROTOCOL)s://%(DOMAIN)s:%(HTTP_PORT)s/
and in apache ( I hope It doesn't have any global differences ):
ProxyPass        "/" "http://<IP_ADDRESS>:[localGiteaIp]/"
ProxyPassReverse "/" "http://<IP_ADDRESS>:[localGiteaIp]/"
and in router configuration just remap [localGiteaIp] of specific machine to [myOuterIp]
Hope, that helps

It's work for me:
app.ini:
DOMAIN           = gitea.domain.com
HTTP_ADDR        = <IP_ADDRESS>
HTTP_PORT        = 3000
ROOT_URL         = https://gitea.domain.com
nginx:
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host             $host;
proxy_set_header X-Real-IP        $remote_addr;
proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
#max_body_size will allow you to upload a large git repository
client_max_body_size 100M;
}
;)

Yeah I tried it with just these settings (I had some extra timeout stuff and headers in there) and still not difference. I suspect it might be caused by some kind of CSRF (cross site request forgery) protection, not sure if gitea has that. (I had to change something in jenkins for it to work behind an nginx proxy, that's where the idea comes from)

I'm not sure what exactly fixed this but after a recent update it started working. (I don't think anything in the setup changed at all so I guess it was a change in gitea?) Feel free to close this if nobody else has this issue.


software issue

I noticed that on the upper coin tabs for btc, bch, ltc and eth its not showing how much I invested initially

Hey @opokalypse sorry you're running into an issue. The tabs on top (for navigation between different currencies) are the current market price, not your investment. Your investment is shown on the totals page or if you click a specific currency and view it across all time.

Going to close this for now, reopen if you’re having any issues!

It's not working
On Sat, Mar 10, 2018 at 06:05 Joshua Blum<EMAIL_ADDRESS>wrote:

Closed #86 https://github.com/joshblum/profbit/issues/86.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/joshblum/profbit/issues/86#event-1514587754, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AT4VAggykbg3teYiXxu1HhMH8B-mvgiUks5tc7OOgaJpZM4Sg2jH
.

--
Nana Koranteng

I'm not wrong anything
On Sun, Mar 11, 2018 at 16:36 Nana Koranteng<EMAIL_ADDRESS>wrote:

It's not working
On Sat, Mar 10, 2018 at 06:05 Joshua Blum<EMAIL_ADDRESS>wrote:

Closed #86 https://github.com/joshblum/profbit/issues/86.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/joshblum/profbit/issues/86#event-1514587754, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AT4VAggykbg3teYiXxu1HhMH8B-mvgiUks5tc7OOgaJpZM4Sg2jH
.

--
Nana Koranteng

--
Nana Koranteng

hello?
On Sun, 11 Mar 2018 at 16:36 Nana Koranteng<EMAIL_ADDRESS>wrote:

I'm not wrong anything
On Sun, Mar 11, 2018 at 16:36 Nana Koranteng<EMAIL_ADDRESS>wrote:

It's not working
On Sat, Mar 10, 2018 at 06:05 Joshua Blum<EMAIL_ADDRESS>wrote:

Closed #86 https://github.com/joshblum/profbit/issues/86.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/joshblum/profbit/issues/86#event-1514587754, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AT4VAggykbg3teYiXxu1HhMH8B-mvgiUks5tc7OOgaJpZM4Sg2jH
.

--
Nana Koranteng

--
Nana Koranteng

--
Nana Koranteng

I don’t understand
On Mon, Mar 12, 2018 at 02:15 opokalypse<EMAIL_ADDRESS>wrote:

hello?
On Sun, 11 Mar 2018 at 16:36 Nana Koranteng<EMAIL_ADDRESS>wrote:

I'm not wrong anything
On Sun, Mar 11, 2018 at 16:36 Nana Koranteng<EMAIL_ADDRESS>wrote:

It's not working
On Sat, Mar 10, 2018 at 06:05 Joshua Blum<EMAIL_ADDRESS>wrote:

Closed #86 https://github.com/joshblum/profbit/issues/86.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/joshblum/profbit/issues/86#event-1514587754, or
mute
the thread
<
https://github.com/notifications/unsubscribe-auth/AT4VAggykbg3teYiXxu1HhMH8B-mvgiUks5tc7OOgaJpZM4Sg2jH

.

--
Nana Koranteng

--
Nana Koranteng

--
Nana Koranteng
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/joshblum/profbit/issues/86#issuecomment-372203694,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABF01MRomZ1qEmyk5NKpKLbIlX34XU2Xks5tdhKGgaJpZM4Sg2jH
.


VirtualNetwork: issue with overlapping addresses for vnetpeering

Description
Virtual network peering child resource fails with the following error
{
    "status": "Failed",
    "error": {
        "code": "VnetAddressSpaceOverlapsWithAlreadyPeeredVnet",
        "message": "Cannot create or update peering /subscriptions/a7439831-1cd9-435d-a091-4aa863c96556/resourceGroups/validation-rg/providers/Microsoft.Network/virtualNetworks/sxx-az-vnet-x-001/virtualNetworkPeerings/sxx-az-vnet-x-001-adp-sxx-az-vnet-x-peer01. Virtual networks /subscriptions/a7439831-1cd9-435d-a091-4aa863c96556/resourceGroups/validation-rg/providers/Microsoft.Network/virtualNetworks/sxx-az-vnet-x-001 and /subscriptions/a7439831-1cd9-435d-a091-4aa863c96556/resourceGroups/validation-rg/providers/Microsoft.Network/virtualNetworks/adp-sxx-az-vnet-x-peer01 cannot be peered because address space of the first virtual network overlaps with address space of virtual network /subscriptions/a7439831-1cd9-435d-a091-4aa863c96556/resourceGroups/validation-rg/providers/Microsoft.Network/virtualNetworks/sxx-az-vnet-peer-x-002 already peered with the second virtual network. Overlapping address prefixes: <IP_ADDRESS>/24.",
        "details": []
    }
}

Steps to reproduce

Run the Virtual network pipeline
Double check the deployment in portal

Screenshots

I'll hold off with that until PR #707 is merged. I don't recall that issue there

Testing environment relsted. Fixed after deletion of vnet peers on dependency vnet, probably deployed manually.


Predicate on an Embedded RLMObject inside another RLMObject

Hello guys,
I have a problem I am not sure how to sort it out.
I have a RLMObject 'A' that has another RLMObject 'B' as property.
class A : RLMObject
{
      @property _name:NSString;
      @property _b:B;
}

class B : RLMObject
{
      @property _a_property:int;
}

I would like to filter the A objects I get from my Realm file on their embedded B object.
Basically, I would like to do something like:
_name = 'Whatever Name' AND (_b != nil or _b._a_property = "5")

It is similar to a joint in SQL.
It doesn't work, because obviously _b_a_property isn't the name of a property on A...but I was wondering if any one knows if there's a way to achieve that
I absolutely need a RLMResults, so no need to suggest to work with RLMArray. I tried putting the objects one by one in an RLMArray, do manually my filtering on B, then calling sortedResultsUsingProperty on it, but Realm raise an exception because this RLMArray cannot do 'sortedResultsUsingProperty' on an RLMArray not returned by Realm...
Any help appreciated :-)
I am using Realm 0.96.3
Thank you,
Christophe

I'd expect the predicate you wrote to work as-is. What problem are you having with it?

Realm says that  _b._a_property isn't a property of A object

The following is a complete code snippet that works with the predicate you've provided (with one minor tweak: you had an unnecessary set of double quotes around the number 5). It's quite possible there's an error in how your model is declared since what you provided isn't valid code for any of the languages we support. I had to change the model code you provided significantly to make it valid.
import RealmSwift

class A: Object {
    dynamic var _name: String = ""
    dynamic var _b: B?
}

class B: Object {
    dynamic var _a_property: Int = 0
}

let realm = try! Realm()
let results = realm.objects(A).filter("_name = 'Whatever Name' AND (_b != nil or _b._a_property = 5)")
print(results)

If you're still encountering problems, please share the exact model classes you're using and the code you're using to filter the results using a predicate.

Thanks bdash, no idea what I was doing wrong before, but I adapted to the realm property names and it works fine now...mystery, but it works fine and I was just doing something bad :/
Thanks for the help !!

Looks like you're good to go. If you run into any other problems please feel free to open a new ticket.


Do not consume response when reading body

Currently, the method text and bytes to get the response body take self as input, which will consume the Response.
Can reqwest offer something such as bytes_cloned(&self) -> Result<Bytes> which will clone the body and not consuming the Response?

The reason it consumes the response is to reduce the footgun that you can call it multiple times. Calling resp.bytes() and then later on resp.bytes() won't work.
You could use the streaming methods to get the whole body and not consume the response.


Add doc dir for Keptn 0.16

Signed-off-by: Giovanni Liva<EMAIL_ADDRESS>

Thank you @StackScribe for the great work on your PR review 🙌
@oleg-nenashev I have also included the changes of #1229


[SPARK-36533][SS][FOLLOWUP] Address Trigger.AvailableNow in PySpark in SS guide doc

What changes were proposed in this pull request?
This PR addresses missing piece on adding Trigger.AvailableNow in Python code example in SS guide doc.

Why are the changes needed?
The SS guide doc doesn't mention a new trigger in Python code example.
Does this PR introduce any user-facing change?
Yes, doc change as above screenshot.
How was this patch tested?
N/A

Thanks for the quick review (again)! Merging to master.


validation: networkPerf in the request is valid

leftover from the previous validation related enhancement ( #49 )

Fixed by: 0c112098ea2a375c3347e4acd377d101db325a05


mxnet cpp-package complie failed with visual studio 2017

Description
I just get some problem while compiling mxnet1.15.1 and cpp_package on win10 with vs2017. The generated "op.h" file seems incorrect at functions like "multi_sgd_update" missing data type of parameter "lrs" and "wds" which should be "mxnet::Tuple". And this may cause compile failure of examples in cpp_packages.The information in outputs view is "argument "lrs" of operator "multi_sge_update" has unknown type ", required"", while Running OpWrapperGenerator.py. This should be a bug because of not register data type like "mxnet::Tuple" for MSVC.
What have you tried to solve it?

As a temporary method, I just comment out Line744 and Line751 in "D:\DevEnvs\mxnet\apache-mxnet-src-1.5.1-incubating\include\mxnet\tuple.h", which comment is "avoid low version of MSVC" but written as "#if !defined(_MSC_VER)" and "#endif".

Environment info (Required)
win10x64
visual studio 2017 (_MSC_VER1912)
cuda 10.1
cudnn 7.6.3

cc @leleamol


Property declared in category 'Private' Build Error

Updated Xcode to 4.2 and migrated my project. EGOGradientView is throwing this error on build now: "Property declared in category 'Private' cannot be implemented in class implementation"
in EGOGradientView.m for:
@dynamic layer;
https://github.com/enormego/EGOGradientView/blob/master/EGOGradientView.m#L37

I fixed this by just removing PRIVATE from the interface declaration.


feat(trajectory_follower): pub steer converged marker

Signed-off-by: kosuke55<EMAIL_ADDRESS>Description

pub steeer conveged info as debug marker array.

Related links

Tests performed

Notes for reviewers

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

@brkay54
sorry to be late and thanks for your feedback.
I discussed with @takayuki5168 and we decided to move these makers to interface controller_node.
It only publishes the marker once, so I think the problem was solved.

@brkay54
Could you please withdraw the change request if no problem?:pray:


Support for Aurora

Hello,
With the recent announcement of stop/start functionality for Aurora clusters, wanted to ask if there a plan for Instance Scheduler to support Aurora databases.
Kind Regards,
Maxim

The plan is to have this in the next maintenance release after we ran our tests
If you want to enable it in the meantime in you van find the line that checks for "aurora" clusters in module "schedulers -> rds_service.py line 207-209
        if rds_inst["Engine"] in ["aurora"]:
            self._logger.debug(DEBUG_UNSUPPORTED_ENGINE, rds_inst["Engine"], db_id)
            return False

Aurora will be enabled in next maintenance release together with Multi-AZ instances

Hi Maxim,
We publish the modified code shortly after a new release on AWSLabs. What you can do is subscribe to notifications for this project repository.
Hope this will work for you
Arie
On 7 Nov 2018, at 11:26, Maxim Rozin <notifications<EMAIL_ADDRESS>wrote:
Thanks for the update Arie!
Is there any way to be notified when it gets updated or perhaps to see a change log of every release?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/awslabs/aws-instance-scheduler/issues/45#issuecomment-436593255, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACBie7z8BKrT2oIQpJ-QqPMUo4AytvJmks5ussN5gaJpZM4W6sZC.

Hi @arieleeuw - any chance I can get added to the preview for Aurora compatibility? Please email<EMAIL_ADDRESS>Thank you

Any ETA on the "next maintenance release"? Been a while.

Any Update?

Fixed in v1.2.0


What makes this fast?

Hello all,
This looks like an exciting library, which appears to get good performance! I have one question: what methods are used to achieve this good performance?

cublasLT for matmul + add + activation fusing
flash attention
no padding
faster kernels for layer norm
Rust to remove the usual Python CPU bottleneck


fix auto labelling of pull requests

We have a autolabler setting in release_drafter.yml which should automatically apply labels to pull requests but it doesn't happen.
Identify the issue of why it doesn't automatically add labels based on the title of the PR or branch name and fix it.

/bounty 100$

can i work on it?

Can i work on this one?

Man, in just 10 minutes and issue is already assigned …

@alankritdabral dude I was working on this one

can I work on this if it's available? @tusharmath

Fixed


forgejo: 9.0.0 -> 9.0.1

Release Notes: https://codeberg.org/forgejo/forgejo/milestone/8544
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Please don't open multiple PRs for bumping forgejo and forgejo-lts if they were released in sync. Group them instead, just like you did in #340151 and #338212.
Also, please don't open a backport PR before the unstable/master PR has been merged.
This really shouldn't have been 3 PRs:

#351929
#351930
#351932


Remember tree location in page chooser when switching between Internal / External / Email link

Fixes #2640

Hi @ababic - could you give this a quick review please?

It looks like new a feature because Wagtail 1.4.* behaves the same way as 1.5. Are you sure that we need to merge this into 1.5.1?

@m1kola Yep, true - I think this could easily wait for 1.6 instead.

@m1kola @gasman I could be wrong, but hasn't the ability to 'edit' a link
only been in since 1.5? Forgetting selections between tabs when adding a
link isn't such a big deal (the editor likely know what they want to link
to, and can redefine things without too much trouble), and if that were the
issue being solved, I would gladly agree on postponing to a later release.
But, forgetting about pre-defined data when editing a link is, I think, a
potentially frustrating bug, and one worth fixing sooner, if it's not too
much trouble.
@gasman, what's the best way to review other's pull requests locally? It's
not something I've done before.

I could be wrong, but hasn't the ability to 'edit' a link only been in since 1.5?

That's right. I checked behaviour of tabs in chooser while adding a link on Wagtail 1.4.

@gasman, what's the best way to review other's pull requests locally? It's
not something I've done before.

I use wagtaildemo project and editable installation of Wagtail (using pip install -e). Also I think the git pr alias is very useful ;)

Thanks for the tips @m1kola!
On 5 Jun 2016 19:16, "Mikalai Radchuk"<EMAIL_ADDRESS>wrote:

I could be wrong, but hasn't the ability to 'edit' a link only been in
since 1.5?
That's right. I checked behaviour of tabs in chooser while adding a link
on Wagtail 1.4.
@gasman https://github.com/gasman, what's the best way to review
other's pull requests locally? It's
not something I've done before.
I use wagtaildemo https://github.com/torchbox/wagtaildemo project and
editable installation of Wagtail (using pip install -e). Also I think the git
pr
http://docs.wagtail.io/en/v1.5/contributing/committing.html#check-out-the-code-locally
alias is very useful ;)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/torchbox/wagtail/pull/2677#issuecomment-223828240,
or mute the thread
https://github.com/notifications/unsubscribe/AHa1BCkUfr_0U1v3z2-5WSWbe8kM3B_Nks5qIxJ0gaJpZM4ItrKz
.

Merged in ba807e5f45812e85bf83b49bf04d2c796ef63cda + parents.
Thanks @gasman and @ababic!


Crash on 177MB file

Ethics of >100MB geojson files aside, I dumped some data into said format so I could run it through tippecanoe and serve it up in vector form. I've tried some variations on running tippecanoe, but they all crash without a helpful error. -Z0 -z0 seemed to work, but somehow not sure that's what I want.
I'll try to drop the file on S3 in a bit so you can test it. Is there a known upward limit on a GeoJSON file size?
Ken-Schwencke-3836: iowa $ tippecanoe -o corn.mbtiles -f -l corn -n "Iowa has a lot of corn." corn.geojson
Sorting 327019 featuresres
327019 features, 54277103 bytes of geometry, 6867399 bytes of metadata
  6.6%  0/0/0
Ken-Schwencke-3836: iowa $ tippecanoe -o corn.mbtiles -Z15 -z15 -f -l corn -n "Iowa has a lot of corn." corn.geojson
Sorting 327019 featuresres
327019 features, 54277103 bytes of geometry, 6867399 bytes of metadata
  6.2%  0/0/0
Ken-Schwencke-3836: iowa $ tippecanoe -o corn.mbtiles -Z0 -z0 -f -l corn -n "Iowa has a lot of corn." corn.geojson
Sorting 327019 featuresres
327019 features, 54277103 bytes of geometry, 6867399 bytes of metadata
  99.9%  0/0/0
Ken-Schwencke-3836: iowa $ tippecanoe -o corn.mbtiles -Z0 -z1 -f -l corn -n "Iowa has a lot of corn." corn.geojson
Sorting 327019 featuresres
327019 features, 54277103 bytes of geometry, 6867399 bytes of metadata
  49.9%  0/0/0
Ken-Schwencke-3836: iowa $ tippecanoe -o corn.mbtiles -Z0 -z1 -f -d1 -l corn -n "Iowa has a lot of corn." corn.geojson
Sorting 327019 featuresres
327019 features, 54277103 bytes of geometry, 6867399 bytes of metadata
  49.9%  0/0/0

The whole point of tippecanoe is to let you tile gigantic GeoJSON files, so I certainly hope 100MB should work.
Without seeing your file, I bet it is in some projection other than WGS84 (EPSG:4326) so all the features are being clipped away. I added a warning for this in 263ae94e754863 but you may have an older build that doesn't include that warning.

You are absolutely correct. Reprojected it and it seems to be working well.

Great! Glad it's working for you now.


Update ihsaan.glitch.me.md

I’m still getting a consistent ~254
https://tools.pingdom.com/#5fff31f5e3400000
Also, side note: updating the website size of an existing member shouldn’t occur so frequently.
Only for major changes will updates take place for this domain in the future (this reduces spam and avoids rebuilding the main directory for minimal changes)