Own sqrt and log returning NaN for correct multi-thread behaviour

Motivation: See https://github.com/trixi-framework/Trixi.jl/issues/1766
Inspiration for implementation: https://discourse.julialang.org/t/fastest-sqrt-and-log-with-negative-check/107575
I replaced for the moment only those sqrt and log where the argument can turn negative. Not sure if we want to use the custom implementation of sqrt_ if it is really faster (for whatever reason).

 Range (min … max):  7.880 ms …  11.458 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     8.562 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   8.565 ms ± 180.060 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                              ▁▃▅▇▇█▅▂
  ▂▂▁▂▂▁▂▁▂▂▂▂▂▂▂▂▂▂▂▃▃▃▄▄▄▅▆▇█████████▆▄▄▃▃▃▂▃▃▂▂▂▂▂▂▂▂▂▂▂▂▂ ▃
  7.88 ms         Histogram: frequency by time        9.13 ms <

 Memory estimate: 0 bytes, allocs estimate: 0.

4 Threads:

BenchmarkTools.Trial: 2000 samples with 5 evaluations.
 Range (min … max):  2.503 ms …   4.925 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     2.709 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   2.741 ms ± 161.206 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

           ▂▇█▇▁
  ▂▂▁▂▂▂▂▃▅█████▇▇▆▅▄▃▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▁▂▁▁▁▁▁▂▂▁▂▂▁▁▂▂▂▁▂▂▂ ▃
  2.5 ms          Histogram: frequency by time         3.5 ms <

 Memory estimate: 3.73 KiB, allocs estimate: 9.

Standard sqrt and log :
1 Thread:

BenchmarkTools.Trial: 2000 samples with 5 evaluations.
 Range (min … max):  8.083 ms …  11.872 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     8.670 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   8.724 ms ± 244.216 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                    ▃▆▆█▅▃ ▁
  ▂▂▁▂▂▂▂▂▂▂▂▂▃▄▄▅▆▇█████████▆▆▄▄▄▃▄▃▃▃▃▃▂▃▂▂▃▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂ ▃
  8.08 ms         Histogram: frequency by time        9.65 ms <

 Memory estimate: 0 bytes, allocs estimate: 0.

4 Threads:

BenchmarkTools.Trial: 2000 samples with 5 evaluations.
 Range (min … max):  2.449 ms …  4.265 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     2.676 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   2.686 ms ± 89.104 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                     ▁▆█▆▆▅▄▃
  ▂▁▁▁▂▂▂▁▂▂▂▂▂▂▂▃▃▅▇█████████▆▅▃▂▂▂▂▁▂▂▂▂▂▂▁▂▂▁▁▁▂▂▂▁▂▁▂▂▂▂ ▃
  2.45 ms        Histogram: frequency by time        3.02 ms <

 Memory estimate: 3.73 KiB, allocs estimate: 9.

tree_3d_dgsem/elixir_mhd_ec.jl with conservative surface flux flux_hlle and initial_refinement_level = 4:
Custom sqrt, log :

1 Thread:

BenchmarkTools.Trial: 1000 samples with 3 evaluations.
 Range (min … max):  50.370 ms … 70.366 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     52.456 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   52.799 ms ±  1.403 ms  ┊ GC (mean ± σ):  0.00% ± 0.00%

             ▁▃▇█▆▃▂
  ▂▁▁▂▂▁▂▂▂▃▅███████████▇▅▄▄▃▃▃▃▃▃▂▃▂▂▂▃▂▂▃▂▂▂▂▁▂▂▂▁▂▂▂▁▁▁▂▁▂ ▃
  50.4 ms         Histogram: frequency by time          58 ms <

 Memory estimate: 0 bytes, allocs estimate: 0.

8 Threads:

BenchmarkTools.Trial: 1000 samples with 3 evaluations.
 Range (min … max):  14.900 ms …  19.075 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     16.890 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   16.838 ms ± 431.002 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                               ▂▁▄▂▂ ▁▄ ▆█▇▆▅▃▅▁
  ▂▁▁▁▁▁▁▁▁▂▁▂▂▁▂▃▁▁▄▂▄▃▄▄▄▅▄▇██████▇████████████▇▆▆▄▃▂▂▃▃▂▂▂▂ ▄
  14.9 ms         Histogram: frequency by time           18 ms <

 Memory estimate: 1.41 KiB, allocs estimate: 5.

Standard sqrt log:
1 Thread:

BenchmarkTools.Trial: 1000 samples with 3 evaluations.
 Range (min … max):  50.199 ms … 66.471 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     51.948 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   52.097 ms ±  1.086 ms  ┊ GC (mean ± σ):  0.00% ± 0.00%

               ▂▃█▇█▄▄
  ▂▂▂▂▂▂▂▂▃▃▄▄▆████████▅▆▄▃▃▃▂▂▂▂▃▂▂▂▁▂▂▂▂▂▂▂▁▁▁▂▂▂▁▁▁▂▁▁▁▁▁▂ ▃
  50.2 ms         Histogram: frequency by time        56.3 ms <

 Memory estimate: 0 bytes, allocs estimate: 0.

8 Threads:

BenchmarkTools.Trial: 1000 samples with 3 evaluations.
 Range (min … max):  14.270 ms …  18.180 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     16.018 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   15.950 ms ± 373.664 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                                        ▁▁▃▄▄▇▇█▇▃▂▁
  ▂▁▁▁▁▁▁▁▁▁▂▁▂▁▁▂▂▃▃▃▃▃▃▄▅▄▄▄▄▆▅▄▆▅▇▇▆▆█████████████▆▆▅▄▃▃▂▂▃ ▄
  14.3 ms         Histogram: frequency by time         16.7 ms <

 Memory estimate: 1.41 KiB, allocs estimate: 5.

Implementation of log:
https://github.com/JuliaLang/julia/blob/c0c676b3c8af3078f5cbc7da03acb8eff09f6c1d/base/special/log.jl#L261-L297
Implementation of sqrt:
https://github.com/JuliaLang/julia/blob/c0c676b3c8af3078f5cbc7da03acb8eff09f6c1d/base/math.jl#L690-L693

@ranocha Maybe I found something that suits our needs:
As for the sqrt_llvm we could call the LLVm implementation via
log_(x::Float64) = ccall("llvm.log.f64", llvmcall, Float64, (Float64, ), x)
log_(x::Float32) = ccall("llvm.log.f32", llvmcall, Float32, (Float32, ), x)

Which actually return NaN or NaN32 if called with negative arguments.
to still enable usage of algorithmic differentiation we would still provide
log_(x::Real) = x < zero(x) ? oftype(x, NaN) : Base.log(x)

Repeating the benchmarks from above:
t0 = tspan[1]
u0 = sol.u[2]
du = similar(u0)

using BenchmarkTools
b = @benchmarkable Trixi.rhs!(du, u0, semi, t0) evals=5 samples=2000 seconds=120
run(b)

Custom sqrt, log :
1 Thread:

BenchmarkTools.Trial: 2000 samples with 5 evaluations.
 Range (min … max):  7.622 ms …  11.196 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     8.287 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   8.300 ms ± 221.435 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                        ▄██▅▃
  ▂▂▂▂▂▂▂▂▂▂▂▂▂▂▃▃▄▄▄▆▇▇██████▅▄▄▃▃▂▃▂▃▂▂▂▂▂▂▂▂▁▂▂▂▂▂▂▂▂▁▁▂▁▂ ▃
  7.62 ms         Histogram: frequency by time        9.24 ms <

 Memory estimate: 0 bytes, allocs estimate: 0.

4 Threads:
BenchmarkTools.Trial: 2000 samples with 5 evaluations.
 Range (min … max):  2.188 ms …  12.552 ms  ┊ GC (min … max): 0.00% … 14.41%
 Time  (median):     2.427 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   2.433 ms ± 246.131 μs  ┊ GC (mean ± σ):  0.04% ±  0.32%

                       ▃▃▂▆▇█▇█▇▆▁▁
  ▂▁▂▂▂▂▂▂▂▃▃▄▃▄▄▅▅▇█▇█████████████▆▄▄▃▃▃▃▂▃▂▂▂▂▂▁▂▂▁▁▁▁▂▂▁▂▂ ▄
  2.19 ms         Histogram: frequency by time        2.73 ms <

 Memory estimate: 3.73 KiB, allocs estimate: 9.

Base sqrt, log :

1 thread:

BenchmarkTools.Trial: 2000 samples with 5 evaluations.
 Range (min … max):  7.984 ms …  10.680 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     8.644 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   8.643 ms ± 161.477 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                               ▂▃▆█▇▅▁
  ▂▂▂▁▂▂▂▁▂▂▂▂▂▁▂▂▂▂▂▂▃▃▃▃▄▄▄▇▇███████▆▅▄▃▃▃▂▃▂▂▂▂▂▂▂▂▁▂▁▂▂▂▂ ▃
  7.98 ms         Histogram: frequency by time        9.19 ms <

 Memory estimate: 0 bytes, allocs estimate: 0.

4 threads:
BenchmarkTools.Trial: 2000 samples with 5 evaluations.
 Range (min … max):  2.459 ms …  12.842 ms  ┊ GC (min … max): 0.00% … 13.44%
 Time  (median):     2.704 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   2.777 ms ± 330.314 μs  ┊ GC (mean ± σ):  0.03% ±  0.30%

       ▃▆█▇▆▆▆▅▄▁▂                                            ▁
  ▅▅▆▇████████████████▇▇██▇▇▆▄█▆▆▆▆▅▇▄▆▅▆▆▅▄▄▁▄▁▄▁▄▅▅▁▁▆▄▅▅▁▄ █
  2.46 ms      Histogram: log(frequency) by time      4.06 ms <

 Memory estimate: 3.73 KiB, allocs estimate: 9.

tree_3d_dgsem/elixir_mhd_ec.jl with conservative surface flux flux_hlle and initial_refinement_level = 4:
t0 = tspan[1]
u0 = sol.u[2]
du = similar(u0)

using BenchmarkTools
b = @benchmarkable Trixi.rhs!(du, u0, semi, t0) evals=5 samples=2000 seconds=120
run(b)

Custom sqrt, log :
1 thread:

BenchmarkTools.Trial: 1000 samples with 3 evaluations.
 Range (min … max):  49.495 ms …  56.905 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     51.709 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   51.772 ms ± 582.180 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                               ▃▆▅█▄▅▃▃▅▃▂▃▁▁▁  ▂ ▂ ▃ ▁
  ▂▂▂▁▁▂▁▁▂▁▁▂▂▂▂▂▂▁▃▁▁▂▂▃▃▃▅▆▇████████████████▆█▇███▇█▆▅▄▃▃▂▃ ▄
  49.5 ms         Histogram: frequency by time         52.9 ms <

 Memory estimate: 0 bytes, allocs estimate: 0.

 8 threads:

 BenchmarkTools.Trial: 1000 samples with 3 evaluations.
 Range (min … max):  14.770 ms …  20.781 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     17.246 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   17.192 ms ± 509.890 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                                     ▁▁█▇▆▄▅▂▂
  ▂▁▁▁▁▁▂▁▁▁▂▂▁▁▁▂▂▃▂▄▂▃▃▄▄▃▃▅▇▇█▆▅▆▇█████████▇▄▄▄▄▃▃▂▂▂▂▂▁▂▁▂ ▄
  14.8 ms         Histogram: frequency by time         18.7 ms <

 Memory estimate: 1.41 KiB, allocs estimate: 5.

Base sqrt, log :

1 thread:

BenchmarkTools.Trial: 1000 samples with 3 evaluations.
 Range (min … max):  50.024 ms … 65.471 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     52.495 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   52.629 ms ±  1.034 ms  ┊ GC (mean ± σ):  0.00% ± 0.00%

                    ▄▃▅▇█▇▄▂▂▁
  ▂▁▂▂▂▁▁▂▂▂▃▃▂▃▄▃▆████████████▇▄▃▄▂▃▂▃▂▂▂▂▂▂▂▂▂▂▁▂▂▂▂▂▁▁▂▁▁▂ ▃
  50 ms           Histogram: frequency by time        56.5 ms <

 Memory estimate: 0 bytes, allocs estimate: 0.

8 threads:
BenchmarkTools.Trial: 1000 samples with 3 evaluations.
 Range (min … max):  14.153 ms …  20.093 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     16.617 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   16.375 ms ± 843.102 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                                ▁▃██▅▁▁
  ▂▃▃▃▄▄▄▃▅▃▃▃▃▃▃▃▃▃▂▂▃▃▄▄▅▅▄▅▆▆███████▆▅▄▃▃▃▃▃▂▂▂▂▂▂▁▁▂▂▂▁▁▁▂ ▃
  14.2 ms         Histogram: frequency by time         18.7 ms <

 Memory estimate: 1.41 KiB, allocs estimate: 5.

I also looked into https://github.com/trixi-framework/Trixi.jl/blob/main/examples/p4est_3d_dgsem/elixir_navierstokes_taylor_green_vortex.jl
with surface_flux = flux_hlle and initial_refinement_level = 3 for the multi-threaded case (12 threads)
Own LLVM-based version:
BenchmarkTools.Trial: 2000 samples with 5 evaluations.
 Range (min … max):  6.213 ms …  10.392 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     7.246 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   7.234 ms ± 408.024 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

                          ▁ ▂          ▁▆▅█▃
  ▁▁▁▂▁▁▁▂▂▃▄▄▄▆▅▅▇▇▅█▆▇██████▇▅▅▅▅▅▄▅▅█████▇▅▆▅▄▄▄▄▄▂▃▃▃▃▂▂▂ ▃
  6.21 ms         Histogram: frequency by time         8.1 ms <

 Memory estimate: 1.52 KiB, allocs estimate: 5.

Base sqrt, log:
BenchmarkTools.Trial: 2000 samples with 5 evaluations.
 Range (min … max):  6.181 ms …   1.306 s  ┊ GC (min … max): 0.00% … 2.06%
 Time  (median):     7.174 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   7.988 ms ± 29.055 ms  ┊ GC (mean ± σ):  0.17% ± 0.05%

                  ▂▃▄▅█▅█▇▄▁▄▂                ▂       ▃▂▃
  ▂▁▂▁▂▁▂▃▄▄▅▅▇▆▇▆█████████████▇▆▅▅▅▆▆▅▆▅▅▅▆▇▆██▅▃▄▃▄████▅▅▃ ▅
  6.18 ms        Histogram: frequency by time        8.37 ms <

 Memory estimate: 1.52 KiB, allocs estimate: 5.

Thanks for looking at the performance in such detail! Have you also compared what kind of performance we get if we just call LLVM's sqrt and log without checking the values for anything?
I am currently thinking that we could default to just using LLVM's sqrt and log and make it configurable (with a compile time preference) to use the default Julia versions.
This way, we get the best performance by default but can go back to the actual Julia default in case of troubles (e.g., when using AD or on GPUs)

Have you also compared what kind of performance we get if we just call LLVM's sqrt and log without checking the values for anything?

You mean by not providing the fallbacks
@inline sqrt_(x::Real) = x < zero(x) ? oftype(x, NaN) : Base.sqrt(x)
@inline log_(x::Real) = x < zero(x) ? oftype(x, NaN) : Base.log(x)

?

Have you also compared what kind of performance we get if we just call LLVM's sqrt and log without checking the values for anything?

You mean by not providing the fallbacks
@inline sqrt_(x::Real) = x < zero(x) ? oftype(x, NaN) : Base.sqrt(x)
@inline log_(x::Real) = x < zero(x) ? oftype(x, NaN) : Base.log(x)

?

Yes, exactly. But I realized that this seems to be implemented as a regular ccall function call, so it probably will not work for SIMD nor will it allow inlining, so I'm not sure it is even faster than the other approaches.

Interestingly, the checks conclude significantly faster than e.g. in https://github.com/trixi-framework/Trixi.jl/pull/1799 or https://github.com/trixi-framework/Trixi.jl/pull/1779

Interestingly, the checks conclude significantly faster than e.g. in https://github.com/trixi-framework/Trixi.jl/actions/runs/7473729770/job/20338465157?pr=1799 or https://github.com/trixi-framework/Trixi.jl/actions/runs/7477448569/job/20350230409?pr=1779

That is indeed interesting... do you have an explanation?

That is indeed interesting... do you have an explanation?

Looks like there are benchmarks for entire simulations required to see why the simulations are faster using the new approach.

Interestingly, the checks conclude significantly faster than e.g. in https://github.com/trixi-framework/Trixi.jl/actions/runs/7473729770/job/20338465157?pr=1799 or https://github.com/trixi-framework/Trixi.jl/actions/runs/7477448569/job/20350230409?pr=1779

That is indeed interesting... do you have an explanation?

Looks like there are benchmarks for entire simulations required to see why the simulations are faster using the new approach.

I think it's not necessarily the simulations being faster but better caching enabled a few days ago in the Julia CI repos. For example, compare
  2 dependencies successfully precompiled in 52 seconds. 454 already precompiled.

in the new run https://github.com/trixi-framework/Trixi.jl/actions/runs/7485852919/job/20375059019?pr=1781#step:7:488 vs
  448 dependencies successfully precompiled in 507 seconds. 8 already precompiled.

in the old run https://github.com/trixi-framework/Trixi.jl/actions/runs/7473729770/job/20338465157?pr=1799#step:7:934
Together with the precompilation with coverage (from 356 seconds to 36 seconds), this explains the roughly 13 minutes difference of the CI runs.

Thanks a lot for the investigation! It looks like a promising approach. However, there are some CI failures. The unstructured_dgmulti fails for a free stream test - which is fine and can be handled by increasing the tolerance, I think. However, the parabolic stuff fails at elixir_navierstokes_convergence_walls_amr.jl: GradientVariablesEntropy, which seems to be a bit more delicate.

However, there are some CI failures. The unstructured_dgmulti fails for a free stream test - which is fine and can be handled by increasing the tolerance, I think.

In fact for the new version the errors are even slightly lower, so probably nothing to worry about

However, the parabolic stuff fails at elixir_navierstokes_convergence_walls_amr.jl: GradientVariablesEntropy, which seems to be a bit more delicate.

Hm yes, that is a bit surprising. Convergence looks fine though:
####################################################################################################
l2
rho                 rho_v1              rho_e
error     EOC       error     EOC       error     EOC
4.61e-04  -         3.24e-04  -         1.52e-03  -
2.48e-05  4.21      1.96e-05  4.05      9.30e-05  4.03
1.11e-06  4.49      1.19e-06  4.04      5.80e-06  4.00
6.49e-08  4.09      7.33e-08  4.03      3.87e-07  3.90
4.22e-09  3.94      4.62e-09  3.99      3.00e-08  3.69

mean      4.18      mean      4.02      mean      3.91
----------------------------------------------------------------------------------------------------
linf
rho                 rho_v1              rho_e
error     EOC       error     EOC       error     EOC
2.75e-03  -         2.86e-03  -         1.29e-02  -
1.25e-04  4.46      1.95e-04  3.87      9.34e-04  3.79
6.37e-06  4.30      1.18e-05  4.05      6.23e-05  3.91
4.73e-07  3.75      6.21e-07  4.25      5.52e-06  3.50
3.24e-08  3.87      4.05e-08  3.94      6.86e-07  3.01

mean      4.09      mean      4.03      mean      3.55
----------------------------------------------------------------------------------------------------

What's missing from your POV? AFAICT, we still need to
a) provide a Preferences.jl-based compile-time switch to allow one to select the default sqrt/log implementations
b) possibly provide a (non-exported) function such as use_llvm_functions!(::Bool) (name tbd.) for convenience
If you need help with a)/b), there's precedence in the Trixi Framework, so please let me know.

I guess pointing me to some source code realizing this should be enough to extrapolate from that :+1:

Something like
https://github.com/trixi-framework/P4est.jl/blob/21de33062c697e9d0ae4c7cf290390440abf47c1/src/P4est.jl#L6-L12
https://github.com/trixi-framework/P4est.jl/blob/21de33062c697e9d0ae4c7cf290390440abf47c1/src/LibP4est.jl#L16-L22

Regarding point b) from Michael above, there is also, e.g.,
https://github.com/trixi-framework/P4est.jl/blob/21de33062c697e9d0ae4c7cf290390440abf47c1/src/P4est.jl#L51-L68
in P4est.jl, which is similar.

Thanks for the links! Please take a look at the changes.

One thing that came to my mind due to a failing test in another PR where I added the @muladd macro:
Could it be that with the ccalls some operations are no longer fused (maybe addition/multiplication of a result of a  `sqrt')  and thus the tests slightly deviate?

Do you have an idea what's going on with the parabolic convergence elixir?

One thing that came to my mind due to a failing test in another PR where I added the @muladd macro:
Could it be that with the ccalls some operations are no longer fused (maybe addition/multiplication of a result of a  `sqrt')  and thus the tests slightly deviate?

Do you have an idea what's going on with the parabolic convergence elixir?

One thing that came to my mind due to a failing test in another PR where I added the @muladd macro:
Could it be that with the ccalls some operations are no longer fused (maybe addition/multiplication of a result of a `sqrt') and thus the tests slightly deviate?

I don't think so. The implementation of sqrt uses the same ccall under the hood and the basic implementation of log is not inlined as well.

@DanielDoehring Could you please run the automated benchmarks on this branch as described in https://trixi-framework.github.io/Trixi.jl/stable/performance/#Automated-benchmarking? You should make sure to use a workstation for this that doesn't run other expensive stuff. And you should be prepared to wait a few hours until everything finishes.

@DanielDoehring Could you please run the automated benchmarks on this branch as described in https://trixi-framework.github.io/Trixi.jl/stable/performance/#Automated-benchmarking? You should make sure to use a workstation for this that doesn't run other expensive stuff. And you should be prepared to wait a few hours until everything finishes.

I'll see what I can do - unfortunately, for reliable performance measure I would need to block an entire node of our compute cluster for multiple hours, which might take quite some time to get scheduled. Alternatively, I can run this as a non-exclusive job at the expense of getting possibly less reliable results.

@DanielDoehring Could you please run the automated benchmarks on this branch as described in https://trixi-framework.github.io/Trixi.jl/stable/performance/#Automated-benchmarking? You should make sure to use a workstation for this that doesn't run other expensive stuff. And you should be prepared to wait a few hours until everything finishes.

Unfortunately, I get an error when (presumably) executing the benchmarks of the main branch:
ERROR: ArgumentError: Package Trixi not found in current path.
- Run `import Pkg; Pkg.add("Trixi")` to install the Trixi package.

PkgBenchmark: Running benchmarks...

The script I execute is
using PkgBenchmark, Trixi

results = judge(Trixi,
             BenchmarkConfig(juliacmd=`$(Base.julia_cmd()) --project=. --check-bounds=no --threads=2`), # target
             BenchmarkConfig(juliacmd=`$(Base.julia_cmd()) --project=. --check-bounds=no --threads=2`, id="main") # baseline
       )

#export_markdown(pkgdir(Trixi, "benchmark", "results.md"), results)
export_markdown("results.md", results)

while I also tried
using PkgBenchmark, Trixi

results = judge(Trixi,
             BenchmarkConfig(juliacmd=`$(Base.julia_cmd()) --check-bounds=no --threads=2`), # target
             BenchmarkConfig(juliacmd=`$(Base.julia_cmd()) --check-bounds=no --threads=2`, id="main") # baseline
       )

#export_markdown(pkgdir(Trixi, "benchmark", "results.md"), results)
export_markdown("results.md", results)

I installed Trixi in dev mode from my fork of Trixi and switched to the to be tested branch.

Did you install the development version of Trixi.jl also in the benchmark project as done in
https://github.com/trixi-framework/Trixi.jl/blob/14151e636ef654cb5421b3a7e498a9d76ed46a64/.github/workflows/benchmark.yml#L44-L47
in our GitHub action? I think the docs should be improved to describe this step in more detail (or at all 😅).

Did you install the development version of Trixi.jl also in the benchmark project as done in
https://github.com/trixi-framework/Trixi.jl/blob/14151e636ef654cb5421b3a7e498a9d76ed46a64/.github/workflows/benchmark.yml#L44-L47

No - I will give this a try :+1:

I just found a problem in the benchmarks config. You need to update your local main branch and the branch of this PR.
You should also run it with Julia 1.9 or delete the --check-bounds=no specification for Julia 1.10.

I'm running some stuff locally. It looks like the benchmarks setup is abit bit-rotten...

Did you install the development version of Trixi.jl also in the benchmark project as done in
https://github.com/trixi-framework/Trixi.jl/blob/14151e636ef654cb5421b3a7e498a9d76ed46a64/.github/workflows/benchmark.yml#L44-L47
in our GitHub action? I think the docs should be improved to describe this step in more detail (or at all 😅).

Hm, I still get the
ERROR: ArgumentError: Package Trixi not found in current path.
- Run `import Pkg; Pkg.add("Trixi")` to install the Trixi package.

error, even after instatiating the package in the benchmarks directory both on main and NaNMath branch.

1 Thread
Results
A ratio greater than 1.0 denotes a possible regression (marked with :x:), while a ratio less
than 1.0 denotes a possible improvement (marked with :white_check_mark:). Only significant results - results
that indicate possible regressions or improvements - are shown below (thus, an empty table means that all
benchmark results remained invariant between builds).

 As far as I understand, no benchmarks show regressions in two cases (either the same number of threads and your/mine server or fixed server and a different number of threads). Thus, I assume that there are no serious performance regressions in this PR.

I ran another test to make sure and there are no shared elixirs with increased runtime for both single and multi threaded between both runs on the same system.
Additionally, as already observed, there are also no elixirs for which there are increases in runtime between my second run and the run you posted.


Updating GET decorator to support query parameters

Coverage remained the same at 100.0% when pulling 35141c9717feb56ac5e0173e592d13fa30bad287 on dev into 28c485cfd00436f1f55f96840de332106d5ef120 on master.


⚠ Bofrost.lu has degraded performance

In 0b8f442, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2056 ms

Resolved: Bofrost.lu performance has improved in eebb11d after 46 minutes.


Can't derive Archive for recursive types

#[derive(Archive)]
struct Example {
    ex: Vec<Example>,
}

error[E0275]: overflow evaluating the requirement `Vec<Example>: Archive`
  --> src/profile.rs:22:10
   |
22 | #[derive(Archive)]
   |          ^^^^^^^
   |
   = help: see issue #48214
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

Try adding #[recursive] to the field. See the Archive derive macro for more details.


Cannot push with non-standalone file

I have a script bound to a spreadsheet file, and I was able to gapps init id using the script id from the Project properties. It downloaded my files without any problems.
On the other side, when trying to gapps push, it returns the File not found error. Is that why you recommended to only use standalone scripts ? I'm a newbie with google scripts, what would then be the good practice to access a spreadsheet's data from a standalone script ?
Thanks in advance for the support

You can't edit bound scripts.
The best way for me is create a trigger programmatically https://developers.google.com/apps-script/guides/triggers/installable#managing_triggers_programmatically
function createSpreadsheetEditTrigger() {
  var ss = SpreadsheetApp.getActive();
  ScriptApp.newTrigger('myFunction')
      .forSpreadsheet(ss)
      .onOpen()
      .create();
}

Hey @Fandekasp . Did that solution work for you? I will close this but please reopen if needed.


node-canvas as optionalDependency

For the browserify usecase, node-canvas is a tricky requirement for vega: it relies on the Cairo library, requires a native package build, and its linking to Cairo is notoriously wonky. It would be great if it was possible to install vega without the node-canvas dependency, given that it's not necessary in browsers or with svg output.

The cairo requirement makes vega hard to install on Heroku.
I've had success using tmpvar/jsdom and domenic/svg2png, which relies in turn on phantomjs to provide the headless bits.

Vega's renderers have been broken out as a separate project (vega/vega-scenegraph) and the node-canvas dependency has been correspondingly moved as well. Unfortunately, I don't believe we can currently mark node-canvas as an optionalDependency as all the renderers (Canvas, SVG DOM and SVG String) create a node-canvas instance for text bounds calculation (e.g., to make sure legends end up in the right place).
However, we welcome pull requests to vega/vega-scenegraph to loosen this dependency. It certainly has been a sticking point for a lot of environments.


proposal: net/http: basic seek support for io.FS

Support for io.FS in net/http was added in 7211694a1e3f9eaebff7074944feead968e00e72
I have been experimenting lately with serving the content of a tar or a zip file via the http.FS. Supporting Seek completely is the most challenging part (and a bad experience, because it breaks at runtime, on specific files - when the MIME type must be detected).
However after analyzing the code of net/http, it appears that Seek is only called in 2 cases:

sniff the MIME ContentType and seek back to the beginning afterward
for range requests

Instead of properly implementing Seek I attempted an alternative approach, faking just enough of the Seek method to support:

sniff the MIME ContentType and seek at the start afterward (by buffering the first 512 bytes)
seek forward for the ranges requests (by discarding the bytes read and failing on non-ascending ranges)

Non-ascending multi-range request will fail on the first request going backward (except if the previous ranges were within sniffLen). And a malicious actor could request the last byte as a range forcing the server to read the whole file (kind of an amplification attack).
I have created an importable package to experiment with this approach:
https://git.sr.ht/~oliverpool/exp/tree/main/item/seekfaker/seekfaker.go
It seems to work (the tests do work at least :), but strongly relies on the internal of net/http (making it quite brittle).
I think it would be a nice addition to the stdlib, to:

make it stable
improve the integration of io.FS (by reducing drastically the work of io.FS implementers)

The comment added in afd792feb567f0848ddc05f6a90a7b7672fe4974 could then be reworded to state // The files provided by fsys must implement io.Seeker to efficiently support range requests.
Draft for the changes to the stdlib: https://git.sr.ht/~oliverpool/go/tree/httpfs_seekable/item/src/net/http/fsys.go (adapted from the fs.go file).
2023-08-07: updated wording to address the misunderstanding of https://github.com/golang/go/issues/61791#issuecomment-1666970791

sniff the MIME ContentType and seek at the start afterward (by buffering the first 512 bytes)

Isn't it seeking to the start already?
https://github.com/golang/go/blob/460dc37c885b83a27d589befe3f52097fe3363b0/src/net/http/fs.go#L238-L248

CC @neild @bradfitz

I don't think we want the complexity of wrapping a non-io.Seeker in something that tries to implement Seek.
If you want to serve a non-seekable filesystem, like the contents of a tar, you can do so fairly simply with a handler that opens the file and uses io.Copy to serve it. This won't handle Range requests (serving the entire file in response to one), but I believe it will handle Content-Type detection.
But it doesn't seem unreasonable to relax the requirement that fs.File files served by net/http don't need to implement io.Seeker, especially since #51971 is adding ServeFileFS.
If we do that, then I think the way is to change serveContent to not require a seekable input. It can defer content-type detection to ResponseWrite.Write (I'm not sure why it isn't doing that now--historical accident, or is there a better reason?), and either ignore Range requests for non-seekable files or implement them by discarding the skipped portions of the file.

I think this could also be achieved by a wrapper FS that would wrap Files to implement "stream seek" (forward seek by discarding or backwards seek not further than size of buffered last written bytes).

I'm not sure why it isn't doing that now--historical accident, or is there a better reason?

Answering my own question: ServeContentType can detect a content type when the response doesn't include the first bytes of the file, such as when responding to a HEAD request or a range request.

If we do that, then I think the way is to change serveContent to not require a seekable input. It can defer content-type detection to ResponseWrite.Write (I'm not sure why it isn't doing that now--historical accident, or is there a better reason?), and either ignore Range requests for non-seekable files or implement them by discarding the skipped portions of the file.

I think my prototype is implementing this suggestion.
The ioFileSeekFaker struct is just a way to have this functionality implemented without having to add more logic to the already quite complex serveContent. Besides it only slows down the non-seeker case. Implementing this inside serveContent would mean something like:

move the DetectContentType buffer at the top level, to be able to serve it later (sendContent = io.MultiReader(bytes.NewReader(ctypeBuf), content))
add the io.CopyN(io.Discard, ...) on "simple" range request
add the io.CopyN(io.Discard, ...) on "multiple" range request and stop on non-ascending range (or respond with StatusRequestedRangeNotSatisfiable immediately)

I don't believe this is a good idea. Essentially everything passed to net/http should implement Seek. Otherwise range requests fail, and if range requests fail, then downloads can't be resumed, structured files can't be fetched incrementally, and so on.
Chrome and most browsers that preview PDF files fetch the specific sections use range requests to fetch the specific file sections they need to render the current page, instead of having to download the entire file just to show page 1. Long ago, before Go handled range requests well, I noticed that reading PDFs on Go servers was incredibly slow. It turned out this was because Chrome was assuming that range requests are always supported, and so it would do a range request for a specific block of the file, Go would send back the entire file, and Chrome would extract the one block it wanted. Then the next block that needed to be read, same thing. It turned viewing a single page from what should have been sub-linear amounts of bandwidth to almost quadratic. Maybe Chrome has been fixed now, but that experience taught me that in the modern world you're just not a real web server if you don't support range requests.
If we did the "seek by reading and discarding" implementation of range requests, that would fix the bandwidth issue in the PDF failure but not the overall cost. It would create a nice low-bandwidth denial-of-service for the server: a client could connect and ask for the very last byte of the file and cause the server to process the entire compressed data stream.
Given that modern web servers must support range requests and range requests must have Seek to be implemented efficiently, it seems OK to me to leave things as they are and strongly encourage fs.File implementations used with net/http to implement Seek.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Chrome and most browsers that preview PDF files fetch the specific sections use range requests to fetch the specific file sections they need to render the current page, instead of having to download the entire file just to show page 1.

Apparently it only performs "single-range" requests. Or do you know of any "multiple-range" requests widely used?

It would create a nice low-bandwidth denial-of-service for the server

Yes, this has been acknowledged in the first message. A mitigation would be to limit the max possible seek, however it would mean that the "good" actors will have to download the entire file in case they make such a range-request (making for a terrible user experience, as you noted).

strongly encourage fs.File implementations used with net/http to implement Seek

Currently it is more of an obligation (than just a mere encouragement :)

My current understanding is that such "hack" should be better served by a package outside of the stdlib (with sufficient warning regarding DoS/bad user experience).
And regarding my first argument "make it stable", it is probably not even relevant since the numbers of bytes read for MIME sniffing is unlikely to change in the future.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group


Require serde with derive

Codecov Report

Merging #18 (7e17cf8) into main (f4d0456) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #18   +/-   ##
=======================================
  Coverage   94.38%   94.38%
=======================================
  Files           7        7
  Lines         178      178
=======================================
  Hits          168      168
  Misses         10       10

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 f4d0456...7e17cf8. Read the comment docs.


Tooltips for ascii text

Suggested by Ben855#0855
http://www.unit-conversion.info/texttools/ascii/

Too difficult to differentiate between normal numbers and ascii


Is it possible to configure base url of Openai API like the official openai lib?

In some areas like the mainland of China, Openai API cannot be called directly. It would be necessary to call Openai API through a proxy. To do that, a proxy url should be set to substitute api.openai.com. For the official lib, I can directly set openai.api_base to the proxy url. Is it possible to do so in this lib? If so, how to do that? Thx.

@yunwuu yes, you can do that in the same way as with the official library:
import { Configuration, OpenAIApi } from "openai-edge"
const configuration = new Configuration({
  apiKey: "YOUR_API_KEY",
  basePath: "https://example.com/api",
})
const openai = new OpenAIApi(configuration)

@dan-kwiat Hello, does this fastapi like url can work? I using basePath but it doesn't work


Initial ULTRA Documentation

Adds instructions for training and evaluation, and instructions for creating a custom agent.
This new documentation is put in ultra/docs where ultra/README.md can reference them.

Will add this once the ultra branch is merged into master.

Will add this once the ultra branch is merged into master.


include/1 error

For following two sample files:
foo.pro:
:- initialization(main).

:- include('bar.pro').

bar.pro:
main :-
    write(hi), nl, halt.

Trealla will run with following error:
% tpl foo.pro
ERROR: infix op ':-' missing params, line 1
ERROR: syntax error, excess terms
ERROR: consult 'bar.pro', line=1, 'main :-'
ERROR: consult 'bar.pro', line=1, ':- include('bar.pro').'

GProlog, SWI and YAP all run successfully.

Thanks, fix confirmed.


Make instance type OR AZ configurable.

At the moment instance type is hardcoded in the code:
https://github.com/aws-cloudformation/aws-cloudformation-resource-providers-awsutilities-commandrunner/blob/18d7024520d8b9e3adb29aae475a31b8cf3d8969/src/main/java/software/awsutility/cloudformation/commandrunner/CreateHandler.java#L51
This creates an issue in AZs that do not support t3.micro.
Example of the error from AWS Console:
Your requested instance type (t3.micro) is not supported in your requested Availability Zone (us-east-1e). Please retry your request by not specifying an Availability Zone or choosing us-east-1a, us-east-1b, us-east-1c, us-east-1d, us-east-1f. (Service: AmazonEC2; Status Code: 400; Error Code: Unsupported; Request ID: removed; Proxy: null)

Solution:

Option 1: make instance type configurable
Option 2: make Availability Zone configurable

Hello,
I have taken this up as a FR.
For now, as a quick fix I recommend that you modify the file CreateHandler.java and just modify the instance type to your desired value.
Once you've made the code change you can just re-register the resource using the register.sh script and that will unblock you right away.
Please let me know if you have any questions!

Hi @shantgup !
Thanks for your reply and suggestion. Yeah, I'll try the workaround later this week or next week.
Cheers!

Hi @shantgup,
I am having issues building the project after updating t3.micro to t2.micro.
I followed Developer Build Steps and installed correct versions of Java and Maven:
$ java -version
openjdk version "13.0.2" 2020-01-14
OpenJDK Runtime Environment (build 13.0.2+8)
OpenJDK 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing)
$ mvn -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /Users/viktary/.sdkman/candidates/maven/current
Java version: 13.0.2, vendor: Oracle Corporation, runtime: /Users/viktary/.sdkman/candidates/java/13.0.2-open
Default locale: en_AU, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

Running ./scripts/build.sh fails with compilation errors:
$ ./scripts/build.sh
Explicitly specify value for tagging
Resource schema is valid.
Generated files for AWSUtility::CloudFormation::CommandRunner
[INFO] Scanning for projects...
[INFO]
[INFO] --< software.awsutility.cloudformation.commandrunner:awsutility-cloudformation-commandrunner-handler >--
[INFO] Building awsutility-cloudformation-commandrunner-handler 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- jacoco-maven-plugin:0.8.4:prepare-agent (default) @ awsutility-cloudformation-commandrunner-handler ---
[INFO] argLine set to -javaagent:/Users/viktary/.m2/repository/org/jacoco/org.jacoco.agent/0.8.4/org.jacoco.agent-0.8.4-runtime.jar=destfile=/GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/jacoco.exec,excludes=**/BaseConfiguration*:**/BaseHandler*:**/HandlerWrapper*:**/ResourceModel*
[INFO]
[INFO] --- exec-maven-plugin:1.6.0:exec (generate) @ awsutility-cloudformation-commandrunner-handler ---
Explicitly specify value for tagging
Resource schema is valid.
Generated files for AWSUtility::CloudFormation::CommandRunner
[INFO]
[INFO] --- build-helper-maven-plugin:3.0.0:add-source (add-source) @ awsutility-cloudformation-commandrunner-handler ---
[INFO] Source directory: /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk added.
[INFO]
[INFO] --- maven-resources-plugin:2.4:resources (default-resources) @ awsutility-cloudformation-commandrunner-handler ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ awsutility-cloudformation-commandrunner-handler ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 11 source files to /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[45,50] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[50,54] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[54,66] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[140,29] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[159,43] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapperExecutable.java:[45,64] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapperExecutable.java:[50,54] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapperExecutable.java:[54,66] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapperExecutable.java:[131,29] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapperExecutable.java:[150,43] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/src/main/java/software/awsutility/cloudformation/commandrunner/DeleteHandler.java:[26,39] cannot find symbol
  symbol:   method getId()
  location: variable model of type software.awsutility.cloudformation.commandrunner.ResourceModel
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/ResourceModel.java:[58,17] cannot find symbol
  symbol: method getId()
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/ResourceModel.java:[59,51] cannot find symbol
  symbol: method getId()
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[51,41] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[55,53] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[68,5] method does not override or implement a method from a supertype
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[83,9] cannot find symbol
  symbol:   variable loggerProxy
  location: class software.awsutility.cloudformation.commandrunner.HandlerWrapper
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[85,30] cannot find symbol
  symbol:   variable loggerProxy
  location: class software.awsutility.cloudformation.commandrunner.HandlerWrapper
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[86,9] cannot find symbol
  symbol:   variable loggerProxy
  location: class software.awsutility.cloudformation.commandrunner.HandlerWrapper
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[95,13] cannot find symbol
  symbol: variable loggerProxy
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[96,13] cannot find symbol
  symbol: variable loggerProxy
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[102,45] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[103,21] cannot find symbol
  symbol: variable serializer
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[108,17] cannot find symbol
  symbol:   variable loggerProxy
  location: class software.awsutility.cloudformation.commandrunner.HandlerWrapper
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[120,13] cannot find symbol
  symbol:   method writeResponse(java.io.OutputStream,software.amazon.cloudformation.proxy.ProgressEvent<software.awsutility.cloudformation.commandrunner.ResourceModel,software.awsutility.cloudformation.commandrunner.CallbackContext>)
  location: class software.awsutility.cloudformation.commandrunner.HandlerWrapper
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[125,5] method does not override or implement a method from a supertype
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[133,5] method does not override or implement a method from a supertype
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[138,5] method does not override or implement a method from a supertype
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[142,26] wrong number of type arguments; required 1
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[158,5] method does not override or implement a method from a supertype
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[163,5] method does not override or implement a method from a supertype
[INFO] 31 errors
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  4.628 s
[INFO] Finished at: 2021-11-17T00:25:02+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project awsutility-cloudformation-commandrunner-handler: Compilation failure: Compilation failure:
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[45,50] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[50,54] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[54,66] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[140,29] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[159,43] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapperExecutable.java:[45,64] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapperExecutable.java:[50,54] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapperExecutable.java:[54,66] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapperExecutable.java:[131,29] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapperExecutable.java:[150,43] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/src/main/java/software/awsutility/cloudformation/commandrunner/DeleteHandler.java:[26,39] cannot find symbol
[ERROR]   symbol:   method getId()
[ERROR]   location: variable model of type software.awsutility.cloudformation.commandrunner.ResourceModel
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/ResourceModel.java:[58,17] cannot find symbol
[ERROR]   symbol: method getId()
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/ResourceModel.java:[59,51] cannot find symbol
[ERROR]   symbol: method getId()
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[51,41] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[55,53] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[68,5] method does not override or implement a method from a supertype
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[83,9] cannot find symbol
[ERROR]   symbol:   variable loggerProxy
[ERROR]   location: class software.awsutility.cloudformation.commandrunner.HandlerWrapper
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[85,30] cannot find symbol
[ERROR]   symbol:   variable loggerProxy
[ERROR]   location: class software.awsutility.cloudformation.commandrunner.HandlerWrapper
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[86,9] cannot find symbol
[ERROR]   symbol:   variable loggerProxy
[ERROR]   location: class software.awsutility.cloudformation.commandrunner.HandlerWrapper
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[95,13] cannot find symbol
[ERROR]   symbol: variable loggerProxy
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[96,13] cannot find symbol
[ERROR]   symbol: variable loggerProxy
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[102,45] wrong number of type arguments; required 2
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[103,21] cannot find symbol
[ERROR]   symbol: variable serializer
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[108,17] cannot find symbol
[ERROR]   symbol:   variable loggerProxy
[ERROR]   location: class software.awsutility.cloudformation.commandrunner.HandlerWrapper
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[120,13] cannot find symbol
[ERROR]   symbol:   method writeResponse(java.io.OutputStream,software.amazon.cloudformation.proxy.ProgressEvent<software.awsutility.cloudformation.commandrunner.ResourceModel,software.awsutility.cloudformation.commandrunner.CallbackContext>)
[ERROR]   location: class software.awsutility.cloudformation.commandrunner.HandlerWrapper
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[125,5] method does not override or implement a method from a supertype
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[133,5] method does not override or implement a method from a supertype
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[138,5] method does not override or implement a method from a supertype
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[142,26] wrong number of type arguments; required 1
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[158,5] method does not override or implement a method from a supertype
[ERROR] /GitHub/aws-cloudformation-resource-providers-awsutilities-commandrunner/target/generated-sources/rpdk/software/awsutility/cloudformation/commandrunner/HandlerWrapper.java:[163,5] method does not override or implement a method from a supertype
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
$

Any help or ideas are appreciated.
As an option I'd like to suggest a quick fix:  update t3.micro to t2.micro because t2.micro is supported in all 6 AZs in us-east-1 (N. Virginia). It is older and a bit more expensive, but for the CommandRunner it does not really matter. It is a short-lived instance.

This PR fixes the build: https://github.com/aws-cloudformation/aws-cloudformation-resource-providers-awsutilities-commandrunner/pull/29


OpenAI Tools / function calling v2

This PR follows #2488
The implementation has been updated to use the new guided generation.
If during a query, the user sets tool_choice to auto, the server will use the template system used in #2488.
However, if a specific function is defined, guided generation will be used to only generate the parameters.
Everything is detailed in the openai_tools_calls.py example.

Testing the tools/function calls feature using the example provided (in openai_tools_calls.py) it works fine as is, but when you go further in the chat and ask another question that needs a function calling, it never goes to tools but the assistant would reply  'call_get_current_weather_0 was called with arguments .... ' but not using tool_calls.
See the gist here
Tested it in other setups/functions, and it is always the case, the second function call would fail (tool_calls=None) and the assistant would reply 'call_function_name_0 called with ... '

Can we go further on reducing the templating to purely JSON schema? I believe it is possible by framing it as
{
"tool_choice": one of the tool name
"tool_params": constrained schema
}

thank you for your work.
I successfully installed vllm using your branch. When I start openai.api_server and call it, the error AttributeError: 'ActorHandle' object has no attribute 'tokenizer' occurs, #3301 solves the above error.
After openai.api_server is started, you can use the /v1/chat/completions interface to call services and function calling functions normally. However, when I call the /v1/completions interface, an error will appear. AttributeError: 'CompletionRequest' object has no attribute 'tool_choice'
Modify vllm/entrypoints/openai/protocol.py.  Adding tools and tool_choice in class CompletionRequest to solve this problem.

@simon-mo : I so removed everything about the jinja template.
I think that was not such a great idea on my side.
The template is now passed as an argument in requests.
tool_params is None, a generic template defined in protocol.py is used.
See the dict TOOLS_TEMPLATE in the sample script openai_tools_calls.py.
@mn9891 : I suspect a bad model for this use case. I started my development with NeuralHermes-7B, but there's a recent model based on Mistral 7B developed by NousResearch that has been trained to call functions which is really great:
https://huggingface.co/FoxEngineAi/Hermes-2-Pro-Mistral-7B_AWQ-GEMM_4_128_True
@Uhao-P : CompletionRequest is not supposed to call functions.
Maybe there are some missing type checking, it'll check this soon.

@FlorianJoncour could you share a sample of a fully formatted prompt containing tools? Say, for a Mistral model?

Thank you, there's an edge case I hadn't considered. It's possible that the model generates a list of function calls in JSON rather than making the calls one after the other.
Now, I was able to make the example script work with Mistral-7B-Instruct-v0.2 despite the fact that it's not trained for this.

When I use a Python script to make a function call, it succeeds regardless of whether the stream is set to true or false. However, when I integrate with the frontend, and the stream is set to true, the frontend doesn't parse the received results well, and the arguments are always truncated. Comparing ChatGPT with VLLM, ChatGPT returns the arguments in a streaming fashion, whereas VLLM returns a complete set of arguments.

I am eagerly awaiting this too. Is there any area where contributions would be welcomed to help merge this?

hi, is this PR being worked on?

hope this feature release as soon as possible.

@FlorianJoncour could you share a sample of a fully formatted prompt containing tools? Say, for a Mistral model?

Is it possible to share a fully formatted prompt sample?
That helps a lot anyone fine tuning models...

is the holdup the naming convention or what am i missing ?

I think it's more that there are other PRs open on this (e.g. #4656 ) but all of them have shortcomings and are pretty opinionated in one way or another. Tool choice for non-auto tool calling is now supported via guided decoding, but "auto" tool choice is a lot harder to get right because different models use different tool choice prompt templates, use different tokens for indicating tool calls, etc. all of which have to be parsed based on the model-specific format and (ideally) streamed back to the client in an OpenAI API-compatible way, which none of the current PRs fully support

https://github.com/mistralai/mistral-common/tree/main/src/mistral_common/protocol/instruct
should be a decent starting ground / if noone can agree

I'm trying to work on a PR for an implementation that's less opinionated and would work with Mistral 7B Instruct v0.3, as well as the Hermes 2 Pro models  by Nous Research & other tool-calling-capable open models in #5649


[Key Vault] Skip tests when vault SKU is incompatible

Description
I recently got our weekly sovereign cloud tests running again, and test runs show that some tests -- namely, those that deal with key release -- require a premium vault SKU in order to work. Standard SKUs are used in China cloud tests, so we need to skip these when necessary.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

/check-enforcer evaluate

/check-enforcer override


Move writing of the event log to the FS background service

Is your feature request related to a problem? Please describe.
Writing the event log could take a while and is done in the EVS context by command:
https://github.com/nasa/cFE/blob/e80aae94e0f56b868657daba965c590766a4dc57/modules/evs/fsw/src/cfe_evs_log.c#L126-L136
Describe the solution you'd like
Move to the FS background service like the rest of the logs
Describe alternatives you've considered
None
Additional context
Code review
Requester Info
Jacob Hageman - NASA/GSFC

Might benefit from the general solution to #1473 (related to #994)

Note since the semaphore is locked for both file writing and sending events, any task trying to send an event will get held up until the write completes.


Difficulty with use in reactjs

I'm attempting to use videojs-ima as a plugin on top of the reactjs example found in the guides page. But It seems like videojs-ima really disagrees with being used in webpack.
I have an instance of the player on my page, but when I try to load the plugin using this.player.ima I get an error and no advertisement appears as expected
Error in question:
Uncaught TypeError: this.player.ima is not a function

Is there a way to implement this plugin with react?
This is the component I'm using, that I attempted to modify to use reactjs-ima
import React from 'react';
import videojs from 'video.js'
import 'videojs-ima'

export default class VideoPlayer extends React.Component {
  componentDidMount() {
    // instantiate Video.js
    this.player = videojs(this.videoNode, this.props, function onPlayerReady() {
      console.log('onPlayerReady', this)
      let options = {
          id: this.videoNode,
          adTagUrl: 'http://pubads.g.doubleclick.net/gampad/ads?sz=640x480&iu=/124319096/external/ad_rule_samples&ciu_szs=300x250&ad_rule=1&impl=s&gdfp_req=1&env=vp&output=xml_vmap1&unviewed_position_start=1&cust_params=sample_ar%3Dpremidpostpod%26deployment%3Dgmf-js&cmsid=496&vid=short_onecue&correlator='
      }
      this.player.ima(options)
    });
  }

  // destroy player on unmount
  componentWillUnmount() {
    if (this.player) {
      this.player.dispose()
    }
  }

  // wrap the player in a div with a `data-vjs-player` attribute
  // so videojs won't create additional wrapper in the DOM
  // see https://github.com/videojs/video.js/pull/3856
  render() {
    return (

          <video ref={ node => this.videoNode = node } className="video-js"></video>

    )
  }
}

Same exact issue. Would really appreciate some insight into getting this to work.
I've got all the required dependencies, but the player object does not have an ima key, and this results in the above error.

Bueller?

The codepen you linked looks like a regular videojs-ima integration. I'll take a look and see if I can make this work, its just going to take a bit longer because I've never used reactjs.

@ypavlotsky appreciate you taking a look. There's another gotcha I experienced where the player object created by videojs('YOUR_VIDEO_ID') loses access to ima on the video object after the component is unmounted. This can be resolved by calling dispose() on the videojs instance during componentWillUnmount()

@jackson-sandland One work-around that I have been using to solve the issue of plugins like ima not being applied to the videojs object after you import it using webkit is to include the videojs script into the index.html and follow the instructions that the videojs-ima guide provides (you shouldn't need to make a new javascript file like they did though) and the result of this will be a global videojs property on window so you can basically use the code above if you change this.player = videojs(...)  to this.player = window.videojs(...) and remove the imports so you don't include the library code twice

@ngood97 thanks for mentioning that idea. We'd prefer not to have to get the plugin off the window object, but I will take a look at this approach.

After some investigating, I think the suggestion by @ngood97 might be the best approach right now as videojs-ima doesn't seem to work well with the reactjs setup..

using next.js, and player.ima is not a function appear too.
Layout.js
import Router from 'next/router'
import Head from 'next/head'

export default ({ children, title="主页" }) => (

            <title>{title}</title>
            <meta charSet="utf-8" />
            <meta
                name="viewport"
                content="width=device-width,user-scalable=no,initial-scale=1,maximum-scale=1,minimum-scale=1"
            />
            <link rel="stylesheet" href="../static/css/style.css" />
            <link rel="stylesheet" href="../../node_modules/video.js/dist/video-js.min.css" />
            <link rel="stylesheet" href="../../node_modules/videojs-contrib-ads/dist/videojs.ads.css" />
            <link rel="stylesheet" href="/dist/videojs.ima.css" />

        {children}

)

videopage.js
import React from 'react'
import VideoDetailLayout from '../components/Layout/videoDetailLayout'
import 'videojs-ima'
import videojs from 'video.js'

// import 'videojs-contrib-ads'

export default class VideoDetail extends React.Component {
    componentDidMount () {
        this.player = videojs(this.videoNode, {}, ()=> {
            var options = {
                id: 'content_video',
                adTagUrl: 'http://pubads.g.doubleclick.net/gampad/ads?sz=640x480&' +
                    'iu=/124319096/external/ad_rule_samples&ciu_szs=300x250&ad_rule=1&' +
                    'impl=s&gdfp_req=1&env=vp&output=xml_vmap1&unviewed_position_start=1&' +
                    'cust_params=sample_ar%3Dpremidpostpod%26deployment%3Dgmf-js&cmsid=496&' +
                    'vid=short_onecue&correlator='
              };

              player.ima(options);
          });
    }
    componentWillUnmount() {
        if (this.player) {
          this.player.dispose()
        }
      }
    render () {
        return (

                <VideoDetailLayout>

                    <video
                        ref={ node => this.videoNode = node}
                        id="content_video" className="video-js vjs-default-skin"
                        poster = "/static/demo.png" controls preload="auto" width="640"
                        height="360">
                        <source src="//commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4"
                            type="video/mp4" ></source>
                        </video>

                </VideoDetailLayout>

        )
    }
}

a test code
some advise would appreciate,
thank

Hi all,
I recently had trouble using the videojs-ima plugin using a webpack setup as well. Because of the difficulty we decided to update the readme with a guide for this implementation.
Please see this: https://github.com/googleads/videojs-ima#es6-imports
I will be closing the issue, but please feel free to reopen it if there are changes to the guide that should be made.


PE-2203: Adds test case for custom tags

App-Name and App-Version

Depends on core: https://github.com/ardriveapp/ardrive-core-js/pull/213/files


[AutoPR datafactory/resource-manager] fix: datafactory character encoding

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/6686

(message created by the CI based on PR content)

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/5747


An error message pops up when attach to progress.

Environment

Steps to Reproduce

Launch VS and create new python application
Add an input('>') at the top of your code
Add some more python code after that with breakpoint(s)
Start WITHOUT debugging
Debug > Attach to Process

Expected behavior
The "Attach to Progress" screen pops up without any error.
Actual behavior
An error message pops up.

Log
ActivityLog.zip

Thank you. I've filed internal bug 1240218.

Upstream bug has been resolved.


Clicks/pops glitch playing audio in Firefox when using ASIO audio interface

I've noticed that when playing audio streams (e.g., Soundcloud) or the samples in the Demos here , that I get clicking/popping or glitching occurring in a fairly regular pattern. I've been on Mozilla support and tried a host of troubleshooting suggested, leading to the discovery shown by about:support#media where the audio backend listed is WASAPI.
On the latest version of FF, on my Win10 machine, routing sound in Windows to my MOTU Audio Interface via ASIO at 48kHz is when this happens. Sound is not glitchy on YouTube, or most other video formats. It appears to be related to audio streaming only. What is interesting is that if I set the Windows Sound Control Panel to be 44.1kHz, the glitching stops, the sound plays clean (this requires a page refresh). If I set it back to 48kHz, it glitches again (after a page refresh). I first thought this to be a sample rate mismatch, but then found another app that had the same glitch issues. Further investigation into that app's settings revealede that the default settings was to use WASPI, even though it was still routed to my MOTU (now sure how that works, since it is ASIO - but I'm not real knowledgeable on Windows Audio). In that app, I was able to select ASIO instead of WASPI, set my MOTU device, choose 48kHz, and the sound in that app then played PERFECTLY!
What I gathered from that is that the issue is not with sample rate mismatch, but with using WASAPI with my ASIO MOTU audio interface. It appears that there is no way to change from WASAPI to ASIO in FF like there is with the other app mentioned.
Is there a reason for this? And can it be improved? I'm not sure exactly what in the WASAPI to MOTU signal chain that might be causing this glitching to occur, but it is remedied in other apps by utilizing the correct ASIO driver for the output device. Any advice would be appreciated.

I've noticed that when playing audio streams (e.g., Soundcloud) or the samples in the Demos here , that I get clicking/popping or glitching occurring in a fairly regular pattern. I've been on Mozilla support and tried a host of troubleshooting suggested, leading to the discovery shown by about:support#media where the audio backend listed is WASAPI.

Thanks for filing an issue!
Generally, when there's a problem in Firefox, it's best to open a bug in its tracker. If this happens in the future, https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Audio%2FVideo%3A cubeb is a direct link that will place the ticket in the correct component. We receive an email here or there, so in the grand scheme of things we'll find it in either location, but cubeb is used by other programs than Firefox, so Firefox-specific issues are best directed to Firefox's own tracker.
I've opened https://bugzilla.mozilla.org/show_bug.cgi?id=1846409 for you, you can simply log in with your GitHub account. I've asked for a number of easy-to-gather information that will help us understand what is going on, please don't hesitate to ask if you have any question.
But in any case, I can answer some of your questions here -- but if possible, it would be best if we would discuss your issue with Firefox on bugzilla.

On the latest version of FF, on my Win10 machine, routing sound in Windows to my MOTU Audio Interface via ASIO at 48kHz is when this happens. Sound is not glitchy on YouTube, or most other video formats. It appears to be related to audio streaming only. What is interesting is that if I set the Windows Sound Control Panel to be 44.1kHz, the glitching stops, the sound plays clean (this requires a page refresh). If I set it back to 48kHz, it glitches again (after a page refresh). I first thought this to be a sample rate mismatch, but then found another app that had the same glitch issues. Further investigation into that app's settings revealede that the default settings was to use WASPI, even though it was still routed to my MOTU (now sure how that works, since it is ASIO - but I'm not real knowledgeable on Windows Audio). In that app, I was able to select ASIO instead of WASPI, set my MOTU device, choose 48kHz, and the sound in that app then played PERFECTLY!

When you say "on the latest version", does it mean it was working well before? Youtube and others use high-latency playback, optimized for robustness, whereas SoundCloud uses a very low latency API that is a bit more glitch prone (but it should generally work well -- I'm not saying there isn't a bug here). I think it must be related to sample-rate conversion somewhere in the chain, thanks for trying a couple of things out.

What I gathered from that is that the issue is not with sample rate mismatch, but with using WASAPI with my ASIO MOTU audio interface. It appears that there is no way to change from WASAPI to ASIO in FF like there is with the other app mentioned.

WASAPI is the native API to do audio input/output on Windows, and ASIO drivers are usually provided by audio equipment manufacturers. It's possible to use WASAPI to output to any sound card, but generally the playback will be more robust against high machine load (or allow achieving lower latency) if using ASIO. There's no general rule, but it's generally recommended to directly use ASIO drivers in music software (e.g. a Digital Audio Workstation, that kind of thing).

Is there a reason for this? And can it be improved? I'm not sure exactly what in the WASAPI to MOTU signal chain that might be causing this glitching to occur, but it is remedied in other apps by utilizing the correct ASIO driver for the output device. Any advice would be appreciated.

Unfortunately, the licence for the ASIO SDK is absolutely incompatible with the free software licence of Firefox. I wish we could use it, but as far as I know, we are not allowed to do so, for legal reasons. It might be possible to make a build of Firefox that can talk to an ASIO driver, but I don't think we'd be allowed to distribute it.

Didn't know about the ASIO SDK license, which is a problem it seems with all OSS. :-/ Come to think of it though, what about ASIO4ALL? Isn't that free? How do they get around it? So, for an application to talk to an ASIO driver, it requires a license? I thought that would be just for the driver manufacturers.

ASIO4ALL isn't free software, as in this definition, it simply doesn't have a cost. To use the ASIO SDK, we'd have to sign an agreement with Steinberg, and all sorts of other things that would violate Firefox's free software licence. https://www.steinberg.net/developers/ has some info.

At any rate, given the continual frustration to get my Tabs back on bottom after seemingly every update to FF and Mozilla not seeming to care about user feedback, and now this, perhaps it's a good time to find another browser. I appreciate your help and feedback. I'll see what Mozilla has to say, but I'm not hopeful a fix is coming. Cheers.

Well, I'm a full time employee at Mozilla working on audio and video stuff, and I seem to care about your feedback, and if you get me the info we need in the other ticket, we can try to figure out what's up with your system. We have hundreds of millions of users that use Firefox, a fraction of which use professional sound cards every day without any problems (myself included), so surely something is off somewhere, but we can't figure out why without doing a bit of diagnosis.
That said, you do https://www.userchrome.org/how-create-userchrome-css.html and then put https://github.com/MrOtherGuy/firefox-csshacks/blob/master/chrome/tabs_on_bottom.css in the file userChrome.css, you'll have the tabs on the bottom like it used to be, it takes less than 5 minutes and works well.

Agreed. Steinberg is the absolute worst. Recently bought Cubase Pro 12 and regret it now.
I also agree that you DO seem to care about this user. My sentiment comes after nearly two decades of using FF and being what feels like continually frustrated. Things break. Features disappear randomly. Requests ignored. And the general sentiment I see over and over in the forums that Mozilla devs have their own ideas about how things should be done and ignore the rest. I suspect there is some truth to that.
Anyway, I do rely on MrOtherGuy's efforts to keep up with the changes so that we can all continue to enjoy our tabs on the bottom. But that shouldn't be necessary simply because Mozilla chooses not to make this feature a user option, although it has been requested by many for years. So, you might imagine how we users feel that our needs/wants are being ignored.
Support on issues seems to be very good in my experience. It's just responsiveness to user needs/wants that seems lacking.
Please don't take my frustration the wrong way. I do appreciate all you folks do in making FF what it is, and despite the frustration, I do continue to use it for now. So there's that. ;-) Cheers.


Add necessary vars to update modal price

Adding some HTML vars here so that the price in the modal updates on quantity change.
I will add a corresponding PR for JS updates on the ti-ext-cart extension.

Thank you, TIL about the input jquery event lol. Pushed a few changes on both PRs, have a look and let me know before I merge.

Looks good to me.
Thanks.

On 6 May 2020, at 20:59, Sam Poyigi<EMAIL_ADDRESS>wrote:

Thank you, TIL about the input jquery event lol. Pushed a few changes on both PRs, have a look and let me know before I merge.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.