LoadError: UndefVarError: imshow not defined

I have this error
LoadError: UndefVarError: imshow not defined
while loading untitled, in expression starting on line 3
 in include_string(::String, ::String) at loading.jl:441
 in include_string(::Module, ::String, ::String) at eval.jl:34
 in (::Atom.##59#62{String,String})() at eval.jl:73
 in withpath(::Atom.##59#62{String,String}, ::String) at utils.jl:30
 in withpath(::Function, ::String) at eval.jl:38
 in macro expansion at eval.jl:71 [inlined]
 in (::Atom.##58#61{Dict{String,Any}})() at task.jl:60

when i run this:
using ImageView, TestImages
img = testimage("mandrill")
imshow(img)

But... I have installed "ImageView" and "TestImages" correctly :c

In such cases, the first thing to try is ImageView.imshow(img). My guess is you are using some other package that also exports imshow. Do you ever see a warning that's something like, WARNING: both ImageView and SomePackage export "imshow"; uses of it in module Main must be qualified?

It didn't work with ImageView.imshow(img) :(

What does Pkg.status("ImageView") say?

- ImageView                     0.2.0

You're on a very old release, see https://github.com/timholy/ImageView.jl/releases.
There's something holding you back from getting the latest version. Can you post the entire contents of Pkg.status()?

 - ASTInterpreter                0.0.4
 - AbstractTrees                 0.0.4
 - ArgParse                      0.5.0
 - Atom                          0.5.10
 - AutoGrad                      0.0.6
 - AutoHashEquals                0.1.1
 - AxisAlgorithms                0.1.6
 - BinDeps                       0.5.0
 - Blink                         0.5.2
 - Blosc                         0.2.0
 - BufferedStreams               0.3.2
 - BusinessDays                  0.6.2
 - COFF                          0.0.2
 - CRC                           1.2.0
 - CSV                           0.1.4
 - Calculus                      0.2.2
 - CatIndices                    0.0.2
 - CategoricalArrays             0.1.3
 - Clustering                    0.8.0
 - CodeTools                     0.4.5
 - Codecs                        0.3.0
 - ColorTypes                    0.2.12
 - ColorVectorSpace              0.1.12
 - Colors                        0.6.9
 - Combinatorics                 0.4.0
 - Compat                        0.25.1
 - Compose                       0.5.1
 - Conda                         0.5.3
 - Contour                       0.3.0
 - CustomUnitRanges              0.0.4
 - DBAPI                         0.0.3
 - DSP                           0.2.0
 - DWARF                         0.1.0
 - DataArrays                    0.3.12
 - DataFrames                    0.9.1
 - DataStreams                   0.1.3
 - DataStructures                0.5.3
 - DecFP                         0.3.0
 - DecisionTree                  0.6.0
 - DiffBase                      0.1.0
 - Distances                     0.4.1
 - Distributions                 0.12.5
 - DualNumbers                   0.3.0
 - ELF                           0.1.0
 - EzXML                         0.4.3
 - FileIO                        0.3.1
 - FixedPointNumbers             0.2.1
 - Formatting                    0.2.1
 - ForwardDiff                   0.4.2
 - GLM                           0.7.0
 - GZip                          0.3.0
 - Gadfly                        0.6.1
 - Gallium                       0.0.4
 - Graphics                      0.2.0
 - HDF5                          0.8.1
 - HTTPClient                    0.2.1
 - Hexagons                      0.1.0
 - Hiccup                        0.1.1
 - HttpCommon                    0.2.7
 - HttpParser                    0.2.0
 - HttpServer                    0.2.0
 - HypothesisTests               0.5.1
 - IJulia                        1.5.0
 - ImageCore                     0.0.5
 - ImageMagick                   0.1.8
 - ImageView                     0.2.0
 - Images                        0.5.14
 - Interact                      0.4.5
 - Interpolations                0.6.1
 - Iterators                     0.3.1
 - JDBC                          0.1.0
 - JLD                           0.6.10
 - JSON                          0.12.0
 - JavaCall                      0.5.0
 - JuMP                          0.16.2
 - JuliaParser                   0.7.4
 - JuliaWebAPI                   0.2.1
 - Juno                          0.2.7
 - KernelDensity                 0.3.2
 - Knet                          0.8.2
 - LNR                           0.0.2
 - LaTeXStrings                  0.2.1
 - Lazy                          0.11.6
 - LegacyStrings                 0.2.1
 - LibCURL                       0.2.1
 - Libz                          0.2.4
 - LightGraphs                   0.7.6
 - LightXML                      0.5.0
 - LineSearches                  0.1.5
 - Loess                         0.2.0
 - Logging                       0.3.1
 - MLBase                        0.6.1
 - MNIST                         0.0.2
 - MXNet                         0.2.1
 - MachO                         0.0.4
 - MacroTools                    0.3.6
 - MappedArrays                  0.0.7
 - MathProgBase                  0.6.4
 - MbedTLS                       0.4.5
 - Measures                      0.1.0
 - Media                         0.2.7
 - Mocha                         0.2.0
 - Mustache                      0.1.4
 - Mux                           0.2.3
 - NaNMath                       0.2.4
 - NearestNeighbors              0.2.0
 - Nettle                        0.3.0
 - NullableArrays                0.1.0
 - ODBC                          0.5.2
 - ObjFileBase                   0.0.4
 - OffsetArrays                  0.3.0
 - Optim                         0.7.8
 - PDMats                        0.6.0
 - Parameters                    0.7.2
 - ParserCombinator              1.7.11
 - PolynomialFactors             0.0.5
 - Polynomials                   0.1.5
 - PositiveFactorizations        0.0.4
 - Primes                        0.1.3
 - ProtoBuf                      0.4.0
 - PyCall                        1.12.0
 - PyPlot                        2.3.2
 - QuadGK                        0.1.2
 - QuantEcon                     0.10.1
 - RCall                         0.6.4
 - Ratios                        0.0.4
 - Reactive                      0.5.0
 - Reexport                      0.0.3
 - Requests                      0.4.1
 - Requires                      0.3.0
 - ReverseDiffSparse             0.7.2
 - Rmath                         0.1.6
 - Roots                         0.3.1
 - Rotations                     0.3.5
 - SHA                           0.3.2
 - SIUnits                       0.1.0
 - ScikitLearnBase               0.3.0
 - ShowItLikeYouBuildIt          0.0.1
 - Showoff                       0.1.1
 - SortingAlgorithms             0.1.1
 - SpecialFunctions              0.1.1
 - StaticArrays                  0.3.1
 - StatsBase                     0.13.1
 - StatsFuns                     0.5.0
 - StructIO                      0.0.2
 - TerminalUI                    0.0.2
 - TestImages                    0.2.0
 - TexExtensions                 0.0.3
 - TextWrap                      0.2.0
 - TiledIteration                0.0.2
 - Tokenize                      0.1.8
 - URIParser                     0.1.8
 - VT100                         0.0.2
 - WeakRefStrings                0.2.0
 - WebSockets                    0.2.3
 - WoodburyMatrices              0.2.2
 - ZMQ                           0.4.2
 - Zlib                          0.1.12
8 additional packages:
 - AxisArrays                    0.1.4
 - Cairo                         0.3.0
 - IniFile                       0.3.1
 - IntervalSets                  0.1.1
 - RangeArrays                   0.2.0
 - Tk                            0.5.2
 - Winston                       0.13.1
 - ZipFile                       0.4.0

OK, so you don't have any pinned or dirty packages. However, the Image-related packages are held back to very old versions. @tkelman, is this a resolver issue or an upper bounds issue?
We really need some tool that says "here's why I'm not upgrading Pkg X." I keep trying to stay out of Pkg (there have to be some limits on the number of areas I dig into...), but if it's really a linear programming optimization then presumably one is optimizing some kind of w⋅v where v is the vector of version numbers and w is a weight vector, perhaps all-ones by default? In that case, by customizing w it seems like you gain the ability to diagnose package conflicts: if you supply a weight of all-zeros to everything but, e.g., Images, then the resulting proposed changes seem like they should give a great deal of insight into what's holding back Images.

What platform, what Julia version? Probably something there is upper-bounding Images, not positive what.
Some way of influencing the resolver's objective function would be incredibly useful, I agree. Something like "recommended bounds" in addition to minimum requirements as a way of increasing the weight on certain versions, and a "no longer maintained" indicator as a way of decreasing the weight on old versions could be ways of doing that.

@wilsontov, perhaps the best expedient would be to say Pkg.pin("Images", v"0.11.0") and then tell us what, if anything, gets uninstalled.

Or try running
for (pkg, ver) in Pkg.installed()
    reqs = Pkg.Reqs.parse(Pkg.dir("METADATA", pkg, "versions", string(Base.thispatch(ver)), "requires"))
    for req (dep, bounds) in reqs
        if any(x -> x.upper != typemax(VersionNumber), bounds.intervals)
            info("$pkg v$ver has upper bounds on $dep")
        end
    end
end

@timholy
julia> Pkg.pin("Images", v"0.11.0")
INFO: Creating Images branch pinned.00000000.tmp
ERROR: MethodError: no method matching create_branch(::Base.LibGit2.GitRepo, ::String, ::Void)
Closest candidates are:
  create_branch(::Base.LibGit2.GitRepo, ::AbstractString, ::Base.LibGit2.GitCommit; force) at libgit2/reference.jl:119
 in (::Base.Pkg.Entry.##31#33{String,String})(::Base.LibGit2.GitRepo) at ./pkg/entry.jl:321
 in with(::Base.Pkg.Entry.##31#33{String,String}, ::Base.LibGit2.GitRepo) at ./libgit2/types.jl:701
 in pin(::String, ::String) at ./pkg/entry.jl:295
 in pin(::String, ::VersionNumber) at ./pkg/entry.jl:348
 in (::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#pin,Tuple{String,VersionNumber}})() at ./pkg/dir.jl:31
 in cd(::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#pin,Tuple{String,VersionNumber}}, ::String) at ./file.jl:59
 in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, ::Vararg{Any,N}) at ./pkg/dir.jl:31
 in pin(::String, ::VersionNumber) at ./pkg/pkg.jl:198

@tkelman
INFO: ForwardDiff v0.4.2 has upper bounds on DiffBase
INFO: ColorVectorSpace v0.1.12 has upper bounds on FixedPointNumbers
INFO: ImageMagick v0.1.8 has upper bounds on Images
INFO: ImageMagick v0.1.8 has upper bounds on FixedPointNumbers
INFO: ReverseDiffSparse v0.7.2 has upper bounds on ForwardDiff
INFO: ASTInterpreter v0.0.4 has upper bounds on AbstractTrees
INFO: ColorTypes v0.2.12 has upper bounds on FixedPointNumbers
INFO: ImageCore v0.0.5 has upper bounds on FixedPointNumbers
INFO: Optim v0.7.8 has upper bounds on LineSearches
INFO: Optim v0.7.8 has upper bounds on ForwardDiff
INFO: Images v0.5.14 has upper bounds on FixedPointNumbers
INFO: ImageView v0.2.0 has upper bounds on Images
INFO: JuMP v0.16.2 has upper bounds on ForwardDiff
INFO: JuMP v0.16.2 has upper bounds on ReverseDiffSparse
INFO: JuMP v0.16.2 has upper bounds on MathProgBase
INFO: DataArrays v0.3.12 has upper bounds on julia
INFO: Colors v0.6.9 has upper bounds on FixedPointNumbers
INFO: Rotations v0.3.5 has upper bounds on StaticArrays

When was the last time you ran Pkg,update() ? What is versioninfo() ? If you go into ~/.julia/v0.5/METADATA and run git status, what does it say?

I ran Pkg.update() today.
julia> Pkg.update()
INFO: Updating METADATA...
INFO: Updating ZeroRPC master...
INFO: Computing changes...
INFO: No packages to install, update or remove

julia> versioninfo()
Julia Version 0.5.2
Commit f4c6c9d (2017-05-06 16:34 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, sandybridge)

And i dont have /.julia/v0.5/METADATA, i have /.julia/v0.6/METADATA:
karther@karther:~/.julia/v0.6/METADATA$ git status
En la rama metadata-v2
Su rama está actualizada con «origin/metadata-v2».
nothing to commit, working directory clean

Interesting indeed. You're running Julia 0.5.2 but only have a v0.6 package directory? Did you do something to symlink one to the other? That won't work, because package versions also depend on the Julia version, so you need to have two separate package folders for two different versions of Julia.

Why would ZeroRPC show up in Pkg.update but not Pkg.status? Something about your setup (anything in juliarc?) seems customized in a way that doesn't make a lot of sense without more explanation.

@wilsontov, any further help we can give or should I close this? It looks like you've customized your setup in some way that's breaking things, your best strategy is to wipe your .julia directory and start from scratch.

If you post ~/.julia/v0.5/REQUIRE I'm happy to try reproducing this - if you don't have a file there, then we don't have enough info about what you've customized to debug this

This is a problem with the package management, and without more info we can't do any more anyway.


bootstrap-toggle not working in angular 11

I am using bootstrap-toggle with angular 11

can someone please help me on priority

@minhur @gitbrent


feat(app): create heater shaker wizard intro page

re #9283
Overview
This PR adds detail to the heater shaker setup wizard introduction page.
Note: designs aren't 100% correct yet because Modal, banner, and button designs need to be updated

Story:

Changelog

add information to Introduction component and add a heater shaker and screwdriver image
create new ModalPage, Overlay, and TitleBar all added to Atoms in the APP (tried to keep as much of the props the same from the legacy version)
make story for TitleBar and ModalPage

Review requests

locally, in ModuleSetup/index, change the model to equal a different module that you have connected to see the banner to launch the wizard. Click on the button to proceed to wizard. Examine the first introduction page.
the text should follow the design and the boxes of the items needed for the heater shaker setup should follow the design
there should be 4 boxes (thermal adapter, labware, heater shaker, screwdriver)
review how it looks and compare to designs. It should be as close to the figma as possible.

Note: Labware and thermal adapter don't work yet until Heater shaker is added toLabwareDeifinitions2
Risk assessment
low

@jerader I updated the image of the screwdriver in figma


Weed constantly giving timeout error

We are saving image to weedFS but for past few days we are getting many saving timeout error.. Could this be due to low memory? or someother reasons.. Can any has any suggestions about it?

The upload happens within your data center or across internet? Try to change the idleTimeout.

weed volume -h
-idleTimeout int
connection idle seconds (default 10)

hi.. just for information that our master Max and #Volumes became equal could that be an issue as well?
Topology
Data Center	Rack	RemoteAddr	#Volumes	Max
DefaultDataCenter	DefaultRack	----:8080	674	2000
DefaultDataCenter	DefaultRack	----:8080	2270	2270

It's across the internet.. we are sending a HTTP request to upload the image

Also, we have started weeds as
exec {{seaweedfs_path}} -v 0 server -filer true -ip {{seaweedfs_master_ip}} -dir {{storage_dir}} -volume.max 2270 -volume.images.fix.orientation false -pulseSeconds 5
I didnt see any such option there but yes we have coded timeout to 5000 means 2 seconds

weed server -h
-idleTimeout int
connection idle seconds (default 10)

Okay sir one last thing..
my current -volum.max is 2270..
If I will increase that max size..
and start weed again.. Will that harm already created volumes ? or something horrible will happen to existing images?

No. But can your disk fit that many volumes when all volumes reach the 30GB limit?

We have 1 master and 1 volume right now..
master showing free storage as 5.987601252352 TB<PHONE_NUMBER>352 byte)
volume showing free storage as 4.424445792256 TB
Is that enough?

No. Each volume max size is 30GB, unless you change the limit. See "weed server -h" for help.

hi.. just for information that our master Max and #Volumes became equal
could that be an issue as well?
Topology
Data CenterRackRemoteAddr#VolumesMax
DefaultDataCenter DefaultRack <IP_ADDRESS>:8080
http://<IP_ADDRESS>:8080/ui/index.html 674 2000
DefaultDataCenter DefaultRack <IP_ADDRESS>:8080
http://<IP_ADDRESS>:8080/ui/index.html 2270 2270
Regards
Junaid Farooq
Software Developer, Evercam.io
+92334- <+92347-8666955>6944005 |<EMAIL_ADDRESS>| Evercam
http://evercam.io/ | Skype: darulehsan1
https://mail.google.com/mail/u/0/#
http://www.facebook.com/ijunaid8088 http://pk.linkedin.com/in/iamjunnii
http://github.com/ijunaid8088 http://twitter.com/ijunaid8088
On 27 October 2016 at 11:01, Chris Lu<EMAIL_ADDRESS>wrote:

The upload happens within your data center or across internet? Try to
change the idleTimeout.
weed volume -h
-idleTimeout int
connection idle seconds (default 10)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/chrislusf/seaweedfs/issues/381#issuecomment-256553993,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AM7wj7HEW9ZLjQnnOn2t_srKFJ_8xuaqks5q4D49gaJpZM4Kh9er
.


[Bug report] OB catalog UTs failed on Mac

Version
main branch
Describe what's wrong
OB catalog UTs failed on Mac
Error message and/or stacktrace
The OB Docker log can be found:

[ERROR] OBD-1007: (<IP_ADDRESS>) The value of the ulimit parameter "max user processes" must not be less than 120000 (Current value: 56081), Please execute echo -e "* soft nproc 120000\n* hard nproc 120000" >> /etc/security/limits.d/nproc.conf as root in <IP_ADDRESS>. if it dosen't work, please check whether UsePAM is yes in /etc/ssh/sshd_config.

How to reproduce
pull the main branch and run ./gradlew :catalogs:catalog-jdbc-oceanbase:test -PskipDockerTests=false on MacOS
Additional context
modify code below of org.apache.gravitino.integration.test.container.BaseContainer can fix.
this.container =
        new GenericContainer<>(requireNonNull(image, "image is null"))
            .withCreateContainerCmdModifier(
                cmd ->
                    cmd.getHostConfig()
                        .withSysctls(
                            Collections.singletonMap("net.ipv4.ip_local_port_range", "20000 40000"))
                        .withUlimits(new Ulimit[] {new Ulimit("nproc", 120000L, 120000L)}));

This can be fixed by modifying the code in org.apache.gravitino.integration.test.container.BaseContainer :
this.container =
new GenericContainer<>(requireNonNull(image, "image is null"))
.withCreateContainerCmdModifier(
cmd ->
cmd.getHostConfig()
.withSysctls(
Collections.singletonMap("net.ipv4.ip_local_port_range", "20000 40000"))
.withUlimits(new Ulimit[] {new Ulimit("nproc", 120000L, 120000L)}));
In addition, you should use Servbay to check your development environment, which is more useful than Docker on Mac.

In addition, you should use Servbay to check your development environment, which is more useful than Docker on Mac.

Hi @unfixa1 , can you explain more? The link to Servbay seems broken

@featherchen
Could you please leave a message here so that I can assign this issue to you?


New version: Microsoft.WindowsADK version 10.1.25398.1

Pull request has been created with Komac v1.11.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

URL wrong. Should be like https://download.microsoft.com/download/6/7/4/674ec7db-7c89-4f2b-8363-689055c2b430/adk/adksetup.exe


Solving dependencies fails.

Solving dependencies fails with this error:
Solving dependencies... /var/lib/gems/2.3.0/gems/solve-3.1.0/lib/solve/ruby_solver.rb:80:in block in resolve': undefined method name' for nil:NilClass (NoMethodError)         from /var/lib/gems/2.3.0/gems/solve-3.1.0/lib/solve/ruby_solver.rb:79:in each'
from /var/lib/gems/2.3.0/gems/solve-3.1.0/lib/solve/ruby_solver.rb:79:in inject'         from /var/lib/gems/2.3.0/gems/solve-3.1.0/lib/solve/ruby_solver.rb:79:in resolve'
from /var/lib/gems/2.3.0/gems/solve-3.1.0/lib/solve.rb:64:in it!'         from /var/lib/gems/2.3.0/gems/elm_install-1.1.0/lib/elm_install/installer.rb:40:in results'
from /var/lib/gems/2.3.0/gems/contracts-0.16.0/lib/contracts/method_reference.rb:43:in send_to'         from /var/lib/gems/2.3.0/gems/contracts-0.16.0/lib/contracts/call_with.rb:79:in call_with'
from /var/lib/gems/2.3.0/gems/contracts-0.16.0/lib/contracts/method_handler.rb:138:in block in redefine_method'         from /var/lib/gems/2.3.0/gems/elm_install-1.1.0/lib/elm_install/installer.rb:26:in install'
from /var/lib/gems/2.3.0/gems/contracts-0.16.0/lib/contracts/method_reference.rb:43:in send_to'         from /var/lib/gems/2.3.0/gems/contracts-0.16.0/lib/contracts/call_with.rb:79:in call_with'
from /var/lib/gems/2.3.0/gems/contracts-0.16.0/lib/contracts/method_handler.rb:138:in block in redefine_method'         from /var/lib/gems/2.3.0/gems/elm_install-1.1.0/lib/elm_install.rb:41:in install'
from /var/lib/gems/2.3.0/gems/elm_install-1.1.0/bin/elm-install:18:in block (2 levels) in <top (required)>'         from /var/lib/gems/2.3.0/gems/commander-4.4.3/lib/commander/command.rb:178:in call'
from /var/lib/gems/2.3.0/gems/commander-4.4.3/lib/commander/command.rb:153:in run'         from /var/lib/gems/2.3.0/gems/commander-4.4.3/lib/commander/runner.rb:446:in run_active_command'
from /var/lib/gems/2.3.0/gems/commander-4.4.3/lib/commander/runner.rb:68:in run!'         from /var/lib/gems/2.3.0/gems/commander-4.4.3/lib/commander/delegates.rb:15:in run!'
from /var/lib/gems/2.3.0/gems/commander-4.4.3/lib/commander/import.rb:5:in block in <top (required)>'
=== Running 'ruby --version' reports:
ruby 2.3.3p222 (2016-11-21) [x86_64-linux-gnu]
Any other things I can report to help diagnose the problem, please let me know.
I just upgraded my system to Debian 9 from 8, was all working previously. I guess a version of something is diferent now...

Yes I installed it as a ruby gem.
It did work on Debian 8 (ruby 2.1.5) just fine, but not this version of elm-install, I was running something older but not sure what.

Managed to reproduce it. I'll look into it and get back to you.

Yes some dependency changed and causing this bug. Until I can fix it I recommend using the npm package or the binaries that are available in the releases page.

Thanks. Unfortunately npm won't install as per the other issue. I tried downloading the binaries, but they also do not run, or I do not understand how to install them and use them (tried unpackaging under /opt and running there).

Released v1.1.1 on rubygems with the fix. Let me know if it works.

Thanks, 1.1.1 installs as a gem and the issue is fixed. Thanks for sorting it so quickly.


mate.eom: 1.20.0 -> 1.20.1

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/eom/versions.
These checks were done:

built on NixOS
/nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1/bin/eom passed the binary check.
/nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1/bin/.eom-wrapped passed the binary check.
2 of 2 passed binary check by having a zero exit code.
0 of 2 passed binary check by having the new version present in output.
found 1.20.1 with grep in /nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1
directory tree listing: https://gist.github.com/b79b00c09fe3737a787425500dfcaf9e
du listing: https://gist.github.com/4ff844a1cc38d84e737d23f9140417ca

meta.description for mate.eom is: '"An image viewing and cataloging program for the MATE desktop"'.
cc @romildo for testing.
Experimental: this build is cached with Cachix. To use the cache follow these experimental instructions:
One time setup in nixpkgs Git checkout:
cachix use r-ryantm
git remote add r-ryantm https://github.com/r-ryantm/nixpkgs.git

Test this build:
git fetch r-ryantm && git checkout 2934f16553461f9afd90fdb1ce40b8a922053b23 && nix-shell --pure -I nixpkgs=. -p mate.eom

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: mate.eom
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: mate.eom
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1
shrinking /nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1/bin/.eom-wrapped
shrinking /nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1/lib/eom/plugins/libreload.so
shrinking /nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1/lib/eom/plugins/libfullscreen.so
shrinking /nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1/lib/eom/plugins/libstatusbar-date.so
gzipping man pages under /nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1/share/man/
strip is /nix/store/4mf2xm9p32lzrim927yk92xhx35yaz62-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1/lib  /nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1/bin
patching script interpreter paths in /nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1
checking for references to /build in /nix/store/lxzkljx1yfkgqxpqgrf710ic9iq4qv3z-eom-1.20.1...

Success on aarch64-linux (full log)
Attempted: mate.eom
Partial log (click to expand)
shrinking /nix/store/v8lydyzc5gz1mddbjhxs3dx7qji273zj-eom-1.20.1/lib/eom/plugins/libstatusbar-date.so
shrinking /nix/store/v8lydyzc5gz1mddbjhxs3dx7qji273zj-eom-1.20.1/lib/eom/plugins/libreload.so
shrinking /nix/store/v8lydyzc5gz1mddbjhxs3dx7qji273zj-eom-1.20.1/lib/eom/plugins/libfullscreen.so
shrinking /nix/store/v8lydyzc5gz1mddbjhxs3dx7qji273zj-eom-1.20.1/bin/.eom-wrapped
gzipping man pages under /nix/store/v8lydyzc5gz1mddbjhxs3dx7qji273zj-eom-1.20.1/share/man/
strip is /nix/store/min150lkigznaayzpwvf8d4jdl1dqvx6-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/v8lydyzc5gz1mddbjhxs3dx7qji273zj-eom-1.20.1/lib  /nix/store/v8lydyzc5gz1mddbjhxs3dx7qji273zj-eom-1.20.1/bin
patching script interpreter paths in /nix/store/v8lydyzc5gz1mddbjhxs3dx7qji273zj-eom-1.20.1
checking for references to /build in /nix/store/v8lydyzc5gz1mddbjhxs3dx7qji273zj-eom-1.20.1...
/nix/store/v8lydyzc5gz1mddbjhxs3dx7qji273zj-eom-1.20.1


TRSv390 - update pillow vulnerability

Codecov Report
Base: 32.51% // Head: 32.51% // No change to project coverage :thumbsup:

Coverage data is based on head (6d5bb40) compared to base (44d91b3).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #190   +/-   ##
========================================
  Coverage    32.51%   32.51%
========================================
  Files           91       91
  Lines         3266     3266
  Branches       552      552
========================================
  Hits          1062     1062
  Misses        2204     2204

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Difference between swoole and swoole-nyholm

It would be nice were the difference between the two runtimes documented; I'm unsure which runtime to select, or whether they are production-ready (the version number doesn't indicate so).
Could you clarify the documentation a little?

If you are creating an application build on top of PSR 7 the swoole-nyholm package is the correct one as that is the one working with psr middlewares and https://github.com/php-runtime/swoole-nyholm#psr and will install the nyholm/psr7 package to provide that support.
If you are in a symfony application which returning the Kernel in your index.php you can use the https://github.com/php-runtime/swoole#symfony. Same for laravel applications.
If you creating pure php application based on swoole request response classes you can use the swoole: https://github.com/php-runtime/swoole#pure-php.
So it depends on the framework you want to use which package you need to install.
Why overall the packages still are 0.x there are not many changes for swoole or roadrunner. As they are not a lot of rocket science here and I would consider them as stable. On other side on runtimes like bref there is still a lot of changes as you can see in the history.

Thank you, that cleared things up. Concerning the version numbers; I tend to treat pre-1.0 releases with caution, as the API might change. Is there any particular reason why the version number of the stable runtimes isn't incremented past 1.0 yet? (Not trying to be mean-spirited but honestly curious.)

We should not forget about the project target:

It is not "the source of all runtimes", but rather a temporary place where runtimes can live before they move in to Bref/Swoole/RoadRunner etc.

So if all goes right the runtime will be official supported by there organisation and will live there. I still would say the packages should be released as a group as 1.0 to be sure that all work together like expected. Still think people have a false feeling about 0.x packages. There are packages which release every half year a new major release and there are packages which were on 0.x for years like phpffmpeg and php imagine, which were more stable libraries then any frameworks around them. I never understand the no 0.x package policy in some companies. Still this is my personally opinion and doesn't represent maybe the main maintainers opinion on this topic.

Fair enough, that is reasonable and I'm thankful for all the effort as-is.
That being said, I know there are stable 0.x packages, but I don't like having to worry about things breaking in production because some vendor wasn't as responsible with backwards-compatibility as you or eg. the phpffmpeg developers are.
0.x indicates changes may happen at new release. >1.x indicates changes should not happen; that gives a soft guarantee that I can update to a new patch or minor release without monitoring the change logs too closely.


Refactor of labels logic

Codecov Report
Attention: Patch coverage is 90.90909% with 1 line in your changes missing coverage. Please review.

Project coverage is 84.49%. Comparing base (bd285f6) to head (86ecc44).
Report is 2 commits behind head on main.

Files with missing lines
Patch %
Lines

src/spatialdata_plot/pl/render.py
90.90%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #336      +/-   ##
==========================================
+ Coverage   79.26%   84.49%   +5.22%
==========================================
  Files          11        8       -3
  Lines        1799     1554     -245
==========================================
- Hits         1426     1313     -113
+ Misses        373      241     -132

Files with missing lines
Coverage Δ

src/spatialdata_plot/pl/render.py
94.40% <90.90%> (-0.40%)
:arrow_down:

... and 5 files with indirect coverage changes


Update ethereum version for correct transaction root calculation

Update ethereum to 0.4.2 which contains the correct transaction root calculation logic.
Fixes #180

@sorpaas please merge again tgmichel-tests, fixed the test (transaction-root is already hashed).

Is there any difference between:
https://github.com/paritytech/trie/blob/master/trie-root/src/lib.rs#L106
and
https://github.com/paritytech/parity-common/blob/master/triehash/src/lib.rs#L79
?

@sorpaas apparently the web3-eth names that field transactionRoot (without an s) instead transactionsRoot (like we do, and follows the original ethereum spec). Same goes for receiptRoot:
https://github.com/ethereum/web3.js/blob/1.x/packages/web3-eth/types/index.d.ts#L390
That's why the test still fails.

I sent an issue to clarify this:
https://github.com/ethereum/web3.js/issues/3777

@tgmichel Yeah that's really confusing, but it's a problem unrelated to this PR I think. Geth/OE both have transactionsRoot in their names.


Ceph monitoring Improvement

ceph monitoring improvement.

modify check-ceph for warning escalation to critical
add new check-ceph-usage check for cluster raw capacity
fix check-raid and check-storcli related bugs

FWIW the Ruby good looks idiomatic and good quality to me :+1: Of course, I am unable to speak to the program execution, but it certainly reads well.


When alerts only configured notifiers that are not webhook forwarded, rancher server returns secrets "Webhook -receiver" not found error

What kind of request is this (question/bug/enhancement/feature request):
bug/enhancement
Steps to reproduce (least amount of steps as possible):

Create a new alert group, add an alert rule, and configure a notifier that is not webhook forwarded. (slack, or email).
Make the alert rule trigger alert, then check on the rancher server master container log

Result:
Users can still receive alert messages normally but receiving these error logs, which can be annoying
2020/09/17 01:42:53 [ERROR] ClusterAlertGroupController c-tz5cn/cag-s5kr2 [cluster-alert-group-controller] failed with : Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found
2020/09/17 01:42:53 [ERROR] ClusterAlertGroupController c-tz5cn/cag-s5kr2 [cluster-alert-group-controller] failed with : Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found
2020/09/17 01:42:53 [ERROR] ClusterAlertRuleController c-tz5cn/car-74thf [cluster-alert-rule-controller] failed with : Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found
2020/09/17 01:42:54 [ERROR] ClusterAlertGroupController c-tz5cn/cag-s5kr2 [cluster-alert-group-controller] failed with : Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found
2020/09/17 01:42:54 [ERROR] ClusterAlertRuleController c-tz5cn/car-74thf [cluster-alert-rule-controller] failed with : Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found

Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
v2.4.8
Installation option (single install/HA):
HA

gz#13134
gz#13273

The error log also happens when a Slack notifier is configured in a existing group alert such as "A set of alerts for node"
Rancher: v2.4.8
Install: HA

Reproduced on v2.4.8
Add a Slack notifier. Create a new Alert Group, and add a Node based Alert rule and add the Slack notifier.

any ideas how to fix this?

those are just error logs for now and will be addressed in https://github.com/rancher/rancher/pull/29889 https://github.com/rancher/rancher/pull/29890 respectively

Rancher version: v2.4-head (11/16/2020) 36358bd29
I don't see the webhook errors in the Rancher server logs. Alerts are getting sent to the slack notifier.
Rancher version: v2.5-head (11/16/2020) 71da1569f
I don't see the webhook errors in the Rancher server logs. Alerts are getting sent to the slack notifier, this might be a separate issue. Details here https://github.com/rancher/rancher/issues/29318#issuecomment-728291662. But is blocking the End-to-End validation in 2.5-head

Closed #30088 as v2.4-head was validated.

Rancher version: v2.5-head (11/17/2020) 71da1569f Single install.
I got the alerts now after further testing https://github.com/rancher/rancher/issues/29318#issuecomment-728291662. But I'm still seeing the webhook errors in the Rancher logs.

k8s v1.19.4-rancher1-1
RKE DO (1 etcd, 1 control plane, 3 workers)
Cluster provisioned as standard user (not as default admin)
loglevel is Debug in this case

2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'p-rbn2n/memory-close-to-resource-limited': handler project-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [ERROR] error syncing 'p-rbn2n/projectalert-workload-alert': handler project-alert-group-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'p-c6zpr/memory-close-to-resource-limited': handler project-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'p-rbn2n/less-than-half-workload-available': handler project-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/kube-components-alert': handler cluster-alert-group-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'p-c6zpr/projectalert-workload-alert': handler project-alert-group-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/event-alert': handler cluster-alert-group-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'p-c6zpr/less-than-half-workload-available': handler project-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/etcd-alert': handler cluster-alert-group-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] 2020/11/17 14:33:15 http: TLS handshake error from <IP_ADDRESS>:32918: remote error: tls: bad certificate
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/node-alert': handler cluster-alert-group-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/no-leader': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/high-number-of-leader-changes': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/etcd-system-service': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/cluster-scan-scheduled-all': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/node-disk-running-full': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/scheduler-system-service': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/cluster-scan-manual-all': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/deployment-event-alert': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/high-memmory': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/high-cpu-load': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/cluster-scan-scheduled--failure-only': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/cluster-scan-alert': handler cluster-alert-group-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [DEBUG] The config stay the same, will not update the secret
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/controllermanager-system-service': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/db-over-size': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing
2020/11/17 14:33:15 [ERROR] error syncing 'c-tz6tj/cluster-scan-manual-failure-only': handler cluster-alert-rule-controller: Update Webhook Receiver Config: Get secret: secrets "webhook-receiver" not found, requeuing

@GGGitBoy can u please help to check the v2.5-head version, thanks.

@izaac
The version 71da156 may not have the committed yet.
this PR has been merged in 71ea711, so I think it will be work after version v2.5-head 71ea711

@GGGitBoy I will check the latest build then thanks for taking a look.

Rancher version v2.5-head (11/20/2020) f67129249
Rancher version master-head (11/20/2020) 2d92095ee
I no longer see the webhook errors when using the Slack notifier.


Notifications via DingTalk service sometimes unsuccessful

Environment (please complete the following information):

OS: Ubuntu 16.04.4 LTS
EaseProbe Version v1.5.0

Describe the bug
When using the DingTalk notification service, some exception notifications can be sent out and some cannot. The message is as follows:
WARN [2024-01-07T10:12:38+08:00] [dingtalk / Dingtalk alert service / Notification] Retried to send 1/3 - Error response from Dingtalk [%!d(float64= 40035)] - [{"errcode":40035, "errmsg": "Missing parameter json"}]
Expected behavior
The notifications either both succeed or fail, and the feedback from the DingTalk service response shows that the request is not compliant. I'm not sure what's wrong.

Thank you for submitting this issue, the error message Missing parameter json may be caused by special characters that are incompatible with the JSON format.
Could you check if there are any such characters in your configuration file?
Alternatively, kindly provide the content of your configuration file(ensuring data anonymization if needed) so that we can  identify and resolve the issue.

@samanhappy is right. Providing more information is also better. By the way, I will also do some tests to check if there are some potential bugs or compatibility issues.

My configuration file does not contain these characters
config notify part:

notify:
  dry: true # dry notification, print the Discord JSON in log(STDOUT)
  timeout: 20s # the timeout send out notification, default: 30s
  retry: # somehow the network is not good and needs to retry.
    times: 3 # default: 3
    interval: 5s # default: 5s

  wecom:
    - name: "Wecom alert service"
      webhook: "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx"
  dingtalk:
    - name: "Dingtalk alert service"
      webhook: "https://oapi.dingtalk.com/robot/send?access_token=xxx"

  log:
    - name: "Local Log"
      file: "/mnt/logs/easeprobe_notify.log"
      dry: true

Could you please provide the complete configuration content to let us test it in our local enviroment?

# Global settings for all probes and notifiers.
settings:

  # The customized name and icon
  name: "EaseProbe" # the name of the probe: default: "EaseProbe"
  #icon: "https://path/to/icon.png" # the icon of the probe. default: "https://megaease.com/favicon.png"
  # Daemon settings

  # pid file path,  default: $CWD/easeprobe.pid,
  # if set to "", will not create pid file.
  #pid: /var/run/easeprobe.pid
  #timeformat: "2006-01-02 15:04:05"

  # A HTTP Server configuration
  http:
    ip: <IP_ADDRESS> # the IP address of the server. default:"<IP_ADDRESS>"
    port: 8181 # the port of the server. default: 8181
    refresh: 5s # the auto-refresh interval of the server. default: the minimum value of the probes' interval.
    log:
      file: /mnt/logs/easeprobe_http_access.log # access log file. default: Stdout
      # Log Rotate Configuration (optional)
      self_rotate: true # true: self rotate log file. default: true
                        # false: managed by outside  (e.g logrotate)
                        #        the blow settings will be ignored.
      size: 10 # max of access log file size. default: 10m
      age: 7 #  max of access log file age. default: 7 days
      backups: 5 # max of access log file backups. default: 5
      compress: true # compress the access log file. default: true
    # SLA Report schedule
    sla:
       #  daily, weekly (Sunday), monthly (Last Day), none
      schedule : "daily"
      # UTC time, the format is 'hour:min:sec'
      time: "23:59"
      # debug mode
      # - true: send the SLA report every minute
      # - false: send the SLA report in schedule
      debug: false
      # SLA data persistence file path.
      # The default location is `$CWD/data/data.yaml`
      # Use the following to disable SLA data persistence
      # data: "-"
      backups: 5 # max of SLA data file backups. default: 5
               # if set to a negative value, keep all backup files

# HTTP Probe configuration
http:
  - name: 通知-example.com
    url: https://example.com
    timeout: 20s
    interval: 15m
    # HTTP SUCCESS response code range, default is [0, 499]
    success_code:
      - [200,206]
      - [300,308]

  - name: 通知-数据接口1
    url: http://<IP_ADDRESS>:8085
    timeout: 20s
    interval: 15m
    # HTTP SUCCESS response code range, default is [0, 499]
    success_code:
      - [200,206]
      - [300,308]

  - name: 通知-数据接口2
    url: http://<IP_ADDRESS>:8083
    timeout: 20s
    interval: 5m
    # HTTP SUCCESS response code range, default is [0, 499]
    success_code:
      - [200,200]

  - name: 通知-数据接口3
    url: http://<IP_ADDRESS>:8084
    timeout: 20s
    interval: 5m
    # HTTP SUCCESS response code range, default is [0, 499]
    success_code:
      - [200,200]

# TCP Probe Configuration
notify:
  dry: true # dry notification, print the Discord JSON in log(STDOUT)
  timeout: 20s # the timeout send out notification, default: 30s
  retry: # somehow the network is not good and needs to retry.
    times: 3 # default: 3
    interval: 5s # default: 5s

  wecom:
    - name: "Wecom alert service"
      webhook: "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx"
  dingtalk:
    - name: "Dingtalk alert service"
      webhook: "https://oapi.dingtalk.com/robot/send?access_token=xxx"

  log:
    - name: "Local Log"
      file: "/mnt/logs/easeprobe_notify.log"
      dry: true

Appreciated for the thorough response, the configuration content does not include any special characters as you mentioned, I apologize for my hasty speculation.
After checking the code I find that the notification content will incorporate the error message related to the probe, and it will be logged in the following format:
ERRO[2024-01-08T16:12:33+08:00] [http / 通知-example.com] error making get request: Get "https://example.com1": dial tcp: lookup example.com1: no such host
Could you please check your enviroment for a similar log entry? I've tested the configuration, but I was unabled to reproduce the Dingtalk error.

Some online blogs say that error 40035 is related with invalid json payload. But as i tested, easeprobe produces valid json payload which match the request of dingtalk official document.
It is also wired that some exception notifications can be sent out and some cannot (some problem with dingtalk api server?)
If possible, could you please add a log to notify/dingtalk/dingtalk.go SendDingtalkNotification function and deploy it on your local machine? So when meet this error again, you will know what message easeprobe sent?

Thank you for your reply, it's strange, I don't know what's wrong with the configuration file to configure the logging, but my corresponding directory did not find the program running log nor notification logs
file: "/mnt/logs/easeprobe_notify.log"
log: /mnt/logs/easeprobe_http_access.log

The console displays the following logs, but no log files are found in the corresponding log directory
INFO[0000] Clean data file: data/data.yaml-2023-09-11T10_58_25.259281271Z
INFO[0000] Load the configuration file successfully!
INFO[0000] Successfully created the PID file: /home/tbcc/release/easeprobe/easeprobe.pid
INFO[0000] Application Log File [Stdout] - Self-Rotate
INFO[0000] Web Access Log File [/mnt/logs/easeprobe_http_access.log] - Self-Rotate
INFO[2024-01-09T09:38:52+08:00] [Web] Access Log output file: /mnt/logs/easeprobe_http_access.log
INFO[2024-01-09T09:38:52+08:00] [Web] HTTP server is listening on <IP_ADDRESS>:8181
INFO[2024-01-09T09:38:52+08:00] Probe [http] - [通知-Thermoberg CCDCC] base options are configured!
INFO[2024-01-09T09:38:52+08:00] [Metric] Counter <EaseProbe_http_total> is created!
INFO[2024-01-09T09:38:52+08:00] [Metric] Gauge <EaseProbe_http_duration> is created!
INFO[2024-01-09T09:38:52+08:00] [Metric] Gauge <EaseProbe_http_status> is created!
INFO[2024-01-09T09:38:52+08:00] [Metric] Gauge <EaseProbe_http_sla> is created!
INFO[2024-01-09T09:38:52+08:00] [Metric] Counter <EaseProbe_http_status_code> is created!
INFO[2024-01-09T09:38:52+08:00] [Metric] Gauge <EaseProbe_http_content_len> is created!

log under notify seems not work, i will check what happens and try to fix it.
notify:
  log:
    - name: "Local Log"
      file: "xxxxx"
      dry: true

please change dry to false. dry run means the log will not be notified.

/mnt/logs/easeprobe_http_access.log only active when you call easeporbe via port 8181, for example, curl http:<IP_ADDRESS>:8181/metrics. it logs when easeprobe access by other users.
and for /mnt/logs/easeprobe_notify.log, you need to change dry: false.

I have both of these parameters set to false. i'll keep an eye on it for a while

notify:
  dry: true # dry notification, print the Discord JSON in log(STDOUT)
  timeout: 20s # the timeout send out notification, default: 30s
  retry: # somehow the network is not good and needs to retry.
    times: 3 # default: 3
    interval: 5s # default: 5s

based on the manual in https://github.com/megaease/easeprobe/blob/main/docs/Manual.md#72-notification-configuration notify doesn't has field of dry. manual says all the notifications in notify has parameters of dry.
if you want to set filed like dry for all notifications, you should set them in settings. like https://github.com/megaease/easeprobe/blob/main/docs/Manual.md#73-global-setting-configuration this.

This error still exists, added the log level to info, but the logs don't see anything useful, is it possible to see the request body of the push message in debug mode?

Hi, i will make a pr to do that. Please wait.

Hi, can you download the newest version of code from github and use make command to compile it. Then try it again? I am sure this time the error message will provide more information about it.

A new version of easeprobe is released, reopen this issue if the problem is still there.


cudnnFind/Get interoperability

Update to algo. search so that it is no longer binary on/off. Now it is either off, a heuristic search (cudnnGet*) or an explicit search (cudnnFind*). cudnnFind gives ~10-20% speed up when used on resnet50 (bs128) relative to using cudnnGet. The extra compile time is minimal but for now I leave the explicit search turned off and default to the heuristic search. Open to suggestions.

Would it be possible to run the first few iterations running the sub-optimial kernel while compiling the optimal one? Then when the optimal kernel is ready use it.


cam kb updates - 20180828

Found the stale link and resolved it.

cancelling this pull request and will open a new one because I need to include another file that contained the invalid link.


Connect the TypeColor class in CLI and update the pokemon details view.

inkjs is using chalk and it does not support all color code, so we need to create a function in CLI.


Navigation optimisation

@franco you are to fast;-)
This are the last things for the css modification!
".collapsing" not needed anymore!
grouping classes for optimisation!

Merged, thanks!


Move ginkgo binary to tests output dir

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

/ok-to-test

/test all

/lgtm
/approve

/cherry-pick release-v1.1

/cherry-pick release-v1.2


Option to remove [data-theme] from being added

Considering the fact that repainting (by calling paint() again) doesn't update the theme (which is an issue in and of itself),
I would like an option that does not set the data-theme attribute at all so that it can be determined by the Tailwind theme provider what styles to apply to the heatmap.
For now, I have to use this workaround:
).then(() => (cal.current as any).calendarPainter.root?.attr('data-theme', null))

You're right about the theme not being updated when calling paint again. I have created an issue for that.
Regarding the data-theme presence, can you not just override your tailwind theme css, like the docs website is doing ? (https://cal-heatmap.com/assets/css/styles.a42314ed.css)

I can override it, it's just extra work. However, I guess it's not entirely necessary if the updating for the theme is fixed

In case anyone else comes across this and didn't understand the approach above in the context of React:
If you are trying to dynamically adjust the theme when a user toggles dark/light mode on your page, you can do this in a non-standard-react way.
const [themeMode] = useLocalstorageState('theme', 'light');
const prevThemeMode = useRef(themeMode);

  useEffect(() => {
    if (prevThemeMode.current !== themeMode) {
      // there is no built in way to dynamically update the theme, and we don't want to destroy/repaint the entire calendar as that leads to some odd behaviors
      // @ts-ignore
      calInstance.calendarPainter.root?.attr('data-theme', themeMode);
      prevThemeMode.current = themeMode;
    }
  }, [themeMode, prevThemeMode]);


Fix GR scraper

It got ':' (ASCII 58 is ':') instead of literal ':'.
Just replace it back.
Add an example.
Closes: https://github.com/openZH/covid_19/issues/279

What about #271? Consuming the JSON should be super easy. Or do you want to fix this first?

This first. This is easy fix.
Consuming JSON next, it is easy, but still non-zero amount of work :)

Gottcha!

@metaodi Thank you!


Request undefined

I saw you found a tricky way to instantiate classes more performant. Also you have a typo in Response.js, line 1001, there should be Response.prototype, not Request.prototype

Just got this with v6.4.3 as well
Relevant stacktrace
Uncaught Exception: ReferenceError: Request is not defined
    at method (/home/bobby/src/safe.fiery.me/node_modules/hyper-express/src/components/http/Response.js:1001:13)
    at /home/bobby/src/safe.fiery.me/node_modules/hyper-express/src/shared/operators.js:117:31
    at Array.forEach (<anonymous>)
    at inherit_prototype (/home/bobby/src/safe.fiery.me/node_modules/hyper-express/src/shared/operators.js:107:30)
    at /home/bobby/src/safe.fiery.me/node_modules/hyper-express/src/shared/operators.js:103:57
    at Array.forEach (<anonymous>)
    at inherit_prototype (/home/bobby/src/safe.fiery.me/node_modules/hyper-express/src/shared/operators.js:103:42)
    at Object.<anonymous> (/home/bobby/src/safe.fiery.me/node_modules/hyper-express/src/components/http/Response.js:977:1)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)

Good catch, for some reason, I was able to run the tests fine on Node v18 on my end hence this update even went out with a typo in the first place. Regardless, I've gone ahead and fixed the typo/pushed other changes in v6.4.4. Let me know If the issue still persists.


BBtargets Content

Hello, may I ask you a question? What are the requirements for the content BBtargets  ? Can I input it by myself (I can specify a line by myself)? Or do I have to get it from the diff file by libxml2 as the step 5? thanks!

Sure, you can write the BBtargets file manually. The file contains multiple lines, each line has the following structure
file_name,target_line_number
For example
main.c,1234


String.split()

Well done @rgsilva! I'm glad you're back to the patches :)
You just missed to add a test to help us to see if further commits break something.

Thanks @muriloadriano! It's good to be back! 8D
I just added a simple test for split: string_016.test.


rename step_size to stride

step_limit in bcube_strider.py keeps its name

Oops, forgot to update test files

cd docs
make doctest

should work now


Remove darwin/amd64 from OS arch support

What this PR does / why we need it:
darwin/amd64 is blocking the build-cross target in Makefile, we don't have a proper reason to keep that.
The related error:
1 errors occurred:
--> darwin/amd64 error: exit status 2
Stderr: # k8s.io/cloud-provider-openstack/pkg/csi/cinder
pkg/csi/cinder/nodeserver.go:419:23: r.NeedResize undefined (type *"k8s.io/mount-utils".ResizeFs has no field or method NeedResize)

make: *** [Makefile:311: build-cross] Error 1

Which issue this PR fixes(if applicable):
fixes #
Special notes for reviewers:

Release note:

NONE

/lgtm

/override openlab/cloud-provider-openstack-acceptance-test-e2e-conformance
/override openlab/cloud-provider-openstack-acceptance-test-e2e-conformance-stable-branch-v1.19
/override openlab/cloud-provider-openstack-acceptance-test-e2e-conformance-stable-branch-v1.20
/override openlab/cloud-provider-openstack-acceptance-test-e2e-conformance-stable-branch-v1.21

/override openlab/cloud-provider-openstack-acceptance-test-keystone-authentication-authorization
/override openlab/cloud-provider-openstack-multinode-csi-migration-test

/approve


Merge to live - 4/7

@Rick-Anderson ... There's one entry on the build report to :eyes: ...

mimengis ... ms-author-invalid ... aspnetcore/signalr/java-client.md ... Invalid value for 'ms.author', 'mimengis' is not a valid Microsoft alias.


Docs regarding the awsutils provider

what

Docs regarding the awsutils provider

why

Let people know

references

Previous PR https://github.com/cloudposse/terraform-aws-s3-bucket/pull/119

/test all


iOS support

subj

In terms of iOS support, do you mean the ability to export an iOS supported format or an iOS client library to wrap the Parrot API? or both? :)

iOS client library something similar to what Applanga does. In theory I can help you with that =)

That'd be a great addition to the project. At some point it'd be great to have platform specific libraries. So if you want to work on the iOS client that'd be great. Any kind of contribution to the project is more than welcome.


How to specify external formatting program for compound filetypes?

I am using WordPress.vim addon which changes filetype for WordPress files to the compound file type php.wordpress.
I am trying to specify the autoformat programs for this compound filetype using the following, but it is not working
let g:formatprg_wordpress = "/Users/sudar/Dropbox/code/wp/phptidy/phptidy.php"
let g:formatprg_args_wordpress = "-q -c=/Users/sudar/Dropbox/code/dotfiles/vim/vim/phptidy-config.php"

Let me know how I should specify the autoformat program for these compound filetypes.

What filetype does vim detect for these files?
Type :echo &ft when you open such a file.

The filetype that vim uses is php.wordpress

I can't seem to reproduce.
I installed wordpress.vim, created a file called foo.php.wordpress and opened it.
But the filetype is empty. Do I miss something?

WordPress.vim doesn't work based on filetypes, it works on based on the location in which the file is placed.
After you install WordPress.vim, you need to download and extract the latest version of WordPress somewhere in your file system. After that you need to set the path to where you extracted WordPress file by adding the following in your ~/.vimrc
let g:wordpress_vim_wordpress_path="path/to/wordpress"

After that if you open any PHP file inside this path the file type will be automatically set to php.wordpress
Anyways you don't have to do all the above things to test vim-autoformat. You can simply test it out by running the following vim command
set ft=php.wordpress

I gave the example of WordPress.vim because that is what I am using, but the real question is how should I define the formatting program (and arguments) for compound filetypes (ie) there are more than one filetype defined for a file. Usually this is done by appending both filetypes using a .. eg: php.wordpress, html.ruby etc.
Most vim addons (like syntastic) handle composite or compound filetypes by splitting them into simple types and then applying all rules of the simple types.
So I need to how define external formatting programs (and arguments) in vim-autoform for composite/compound filetypes like php.wordpress. Thanks.

It doesn't make sense to apply multiple formatters if the filetype is composite.
In your case I suppose you just want to apply the php formatter.
Since a vim global variable can't contain dots (so g:formatprg_php.wordpress doesn't work) I see two options:

only look at the last part of the extension
replace the dots in the filetype by underscores

I personally think the first option makes most sense, because it is very unlikely that one would want to
have a different formatter for wordpress-specific php code.
Do you have any other suggestions?
If not, I could push a patch.

I personally think the first option makes most sense, because it is very unlikely that one would want to
have a different formatter for wordpress-specific php code.

Actually no. We need to use a different autoformatter for WordPress since it follows a different coding standard. Someone who is programming in PHP and WordPress would have to use a different code formatter for PHP and a different one for WordPress even though they both have the same syntax and have the same filename extension. So, the first option wouldn't work.
I think the second option is the best. (ie) replace dots with underscores.
Or an even better but slightly complex solution is to split the filetypes based on dot and then apply individual filetypes. I think this is slightly standard among different addons (or at least the one that I have used).
BTW, I solved my problem my explicitly specifying the filetype while invoking the Autoformat command. I didn't know about it when I opened this ticket.
Also thanks for an excellent addon and also for listening to my feature request.

I don't see the benefit of applying multiple formatters in a sequence by default. If wordpress code has different conventions than regular php code, you only want to apply the wordpress formatter since applying a php formatter afterwards would probably screw things up again.
Also it is not clear in which order the formatters should be applied. In contrast with utilities like error checkers, the order affects the final result. If you want to apply formatters in a sequence, you should explicitly say so. Currently you could do that by wrapping all formatters in a custom shell script, and use the shell script in g:formatprg_<ft>.
So I understand that you solved your problem by something like
au filetype php.wordpress noremap <F3> :Autoformat wordpress<CR><CR>

which is a fair solution in my opinion. But I guess that replacing dots with underscores would be even nicer.
I will look into that.

@sudar I pushed a solution. Please verify if this works for you.

I don't see the benefit of applying multiple formatters in a sequence by default. If wordpress code has different conventions than regular php code, you only want to apply the wordpress formatter since applying a php formatter afterwards would probably screw things up again.

I was comparing this plugin with syntastic's behaviour, but I think I agree with you. It doesn't make sense to have two formatters for a single file.

So I understand that you solved your problem by something like

Yes. In fact I was just calling the command directly from vim. (I try to use as less mapping as possible :) )

I pushed a solution. Please verify if this works for you.

Just checked it and it works perfectly.
Once again thanks for the excellent plugin and also for spending time to implement my feature request.


Scale issue with more than 10 cards

Hello,
Actually i have two issues:
The first one, if you just try to add more than 10 cards (in your demo: http://codepen.io/loringdodge/pen/ZGvMxE),
the 11th card and above will have the same width/height and the the scale will will move bigger and bigger than usual.

the second one, i have seen the move back implimented, but no undo function to get the card destroyed back.

Hey @drwhite00 ,
Thanks for pointing out all this awesome stuff. I especially liked the infinite cards moving to the right. Unfortunately, this component was not meant for production purposes and was tied to a post that I wrote. If you plan on putting this in a production project, I can put it in a little bit to fix these problems.
Loring


Add support for certificates hot reload

Description
Added support for certificates hot reload
Issues Resolved
#4427
Check List

[ ] New functionality includes testing
[ ] New functionality has been documented
[ ] New Roles/Permissions have a corresponding security dashboards plugin PR
[ ] API changes companion pull request created
[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@willyborankin Can you open a documentation PR for this as well since this adds a new setting?


fix(taskDSLFilters): set default value for dsl Filters

This commit adds a default value for task DSL filters
To Test this please contact me
Closes DCOS-21063

Integration Tests


USE_SWIG_DIRECTORS, no swig present

Fixes #15, maybe

@vigsterkr Still have /* #undef USE_SWIG_DIRECTORS */ even after explicit -DUSE_SWIG_DIRECTORS=ON. (The logs here print out config.h now.)

@dougalsutherland seems to work on linux:
https://travis-ci.org/conda-forge/shogun-cpp-feedstock/builds/309085123#L3009
i cannot find any data on windows...

Huh, I guessed I looked at the wrong build earlier. That's Mac actually, but if you download the log from CircleCI it also works there. It's not printed out on Windows because the other test fails first, but I'll assume it works there and merge this.


Selenium Template throws error on Release Pipeline import

CredScan.
Error while creating release definition: A credential or other secret was detected in one or more plaintext variables.
Remove all secrets or convert all variable types to secure.
...
Variables (and their corresponding stage) that need to be secured: DefaultConnectionString (Release)

Note: The edits on this PR have been tested according to the steps in the corresponding AzureDevOpsLabs.com lab.

fixed and released


Build fails with "Starting SSR Build..."

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

App Id
d3srkgpabkig16
Region
eu-central-1
Amplify Console feature
Build settings
Describe the bug
Starting from 11 May 2021, with no changes in our code or build configuration, all of our builds have started failing with
Starting SSR Build...
AccessDenied

Expected behavior
Build should be successful since no change
Reproduction steps
Just re-run the pipeline
Build Settings
BuildSpec: |
        version: 1
        frontend:
          phases:
            preBuild:
              commands:
                - yarn install
            build:
              commands:
                - next build && next export
          artifacts:
            baseDirectory: out
            files:
              - '**/*'
          cache:
            paths:
              - node_modules/**/*

Additional information
No response

@tjto we identified an issue in how we detect your SSR app and have resolved the issue. Can you retry your build and let us know if  you are unblocked?

@nimacks At the moment I am blocking by https://github.com/aws-amplify/amplify-console/issues/1825 so cannot verify yet

This also happens to our build number 352
We got the same error
Starting SSR Build...
AccessDenied

and then on the following builds, the error is the exact same as #1825.
We're also using Next.js and I don't know if that's relevant as the problem is in the Cloning the Repository stage.

We've deployed a fix for this issue. Can you try again and let us know when you're unblocked?

We've deployed a fix for this issue. Can you try again and let us know when you're unblocked?

I'm experiencing the same problem - should I redeploy and see what happens, or is there another intermediary step that I should take?
Thanks

It is fixed. Thanks

@ssousa33 After re-run the pipeline the second time, it is back to failed with same error.
Other app has same symptom as well

@ssousa33 After re-run the pipeline the second time, it is back to failed with same error.
Other app has same symptom as well

my app is live again -  there is a new cloudfront redirect in the "Rewrites & Redirects" dialog in the amplify gui console. had to play with the existing rewrites but it seems okay for now

@tjto is this resolved now?

@nimacks It is not resolved. Try with 4.50.0 as @ssousa33  suggested but no luck.

@nimacks, same here, now.  all build steps pass until :
2021-05-13T14:23:23.093Z [INFO]: Export successful. Files written to /codebuild/output/src806663020/src/tuned-next/out 2021-05-13T14:23:23.099Z [INFO]: Done in 94.23s. 2021-05-13T14:23:23.103Z [INFO]: Starting SSR Build... 2021-05-13T14:26:10.028Z [INFO]: Error Terminating logging...

@nimacks build and deploy succeed now but deployed app gives an "redirected too many times" error.
Rewrites and redirects rule
/<*> | /index.html | 404 (Redirect)
Amplify Deploy log
2021-05-13T20:08:48 [INFO]: Beginning deployment for application xxxxxxxx, branch:<branch>, buildId 0000000XYZ
2021-05-13T20:08:48 [INFO]: SSR Deployment complete

App is not accessible

@heikkikurkela can you please share your appId

@tjto @heikkikurkela there was an issue with our detection of Next.js apps. The issue has been resolved, and I manually restored your app framework to what it was before. Please try another build and let us know if you continue to face this issue. thanks!

Seems to work now.

@Athena96 could you give us a brief explanation of what and why such a problem occurred? You have introduced a new detection feature or something? Everything worked fine until May 11th and then the builds suddenly broke down. Something has had to change.
Appreciate your reply and thanks in advance!


🤷♂Should we move to an mturk population

Reasons not to:

WBL subsidises students
Many classic experiments were conducted with student populations, and using this sample would let us replicate those studies
We already have data on a number of the WBL participants

Reasons to:

Larger sample pool means we don't worry about "burning" participants
It may be easier to construct groups with particular distributions of characteristics when we have more (and more diverse) people to work with
May be able to use CSS lab panel to get psychometric and demographic data on participants cheaply

Alternatively, we can move to the WBL panel when we want the student population in particular.

Potential reasons to still do something with WBL:

We've already invested in a long term relationship with WBL, and we don't want that time to be wasted or burn our relationship?

Closing in favor of Both/And.


Split Tinkerbell provider sources by purpose

Arrange sources by purpose to create lower cognitive load on developers.
The Tinkerbell provider bundles huge amounts of logic into the tinkerbell.go. This change separates code into logical source files that represent a shared purpose making it easier to rationalize where logic may live. For example, cluster creation logic resides in create.go.
See https://dave.cheney.net/practical-go/presentations/gophercon-israel.html#_arrange_files_by_import_statements

/cc @panktishah26 @gwesterfieldjr @jacobweinstock @abhinavmpandey08 @pokearu @ptrivedi

/approve


Toggle between directory-selection mode and live_grep/file_find mode in path

Is your feature request related to a problem? Please describe.
I would like to use live_grep/find_files in path (the folder the file_browser is currently in) in telescope-file-browser.
Describe the solution you'd like
What I think would be nice is to have a functionality to toggle between directory-selection mode and live_grep/file_find mode in path. I have a workflow described in https://github.com/nvim-telescope/telescope.nvim/issues/2201#issuecomment-1521122021 where I need to work outside both CWD and root directory. So far, since you must change CWD or root directory to use live_grep/find_file, I set search_dirs = { desired_directory } to use live_grep/find_files in a desired directory, which is quite cumbersome to type in command mode manually. Telescope-file-browser provides a nice interface for navigating directory structure (which Telescope doesn't provide), which I think would be very useful to be combined with live_grep/find_files that can be run in path.
Describe alternatives you've considered
Since telescope-file-browser provides easy functionality to change CWD (change_cwd), I can achieve my goal by 1. changing CWD, and 2. live_grep/find_files with search_dirs = { vim.fn.getcwd() }. However, it is not as simple as toggling between directory-selection mode and live_grep/find_file, and most importantly, you must change CWD every time you want to live_grep/find_file in a different directory.

I commented a potential solution here https://github.com/nvim-telescope/telescope.nvim/issues/2201#issuecomment-1485886554
But I'm currently now this
local actions = require("telescope.actions")
local action_state = require("telescope.actions.state")
local fb_utils = require("telescope._extensions.file_browser.utils")
local builtin = require("telescope.builtin")

-- helper function
local open_using = function(finder)
  return function(prompt_bufnr)

    -- gets selections based off tab-selected multi-select entries
    local selections = fb_utils.get_selected_files(prompt_bufnr, false)
    local search_dirs = vim.tbl_map(function(path)
      return path:absolute()
    end, selections)

    -- if nothing is multi-selected, just use the current `path` value
    if vim.tbl_isempty(search_dirs) then
      local current_finder = action_state.get_current_picker(prompt_bufnr).finder
      search_dirs = { current_finder.path }
    end
    actions.close(prompt_bufnr)
    finder({ search_dirs = search_dirs })
  end
end

require("telescope").setup({
  extensions = {
    file_browser = {
      mappings = {
        i = {
          ["<A-g>"] = open_using(builtin.live_grep),
          ["<A-f>"] = open_using(builtin.find_files),
        },
      },
    },
  },
})

The reason why we've resisted adding this to telescope because this can be a fairly opinionated workflow. Even for just myself, I've changed how the search_dirs option is determined for find_files, live_grep. I've yet to find, or hear a good solution that works for most everyone and that can be fairly easily incorporated into telescope, or at least worth the effort.
I hope that helps.


destroy() does not remove the .flatpickr-wrapper element created by the static option

I don't know it this is intended, but flatpickr is not removing the wrapper element created by the option static when destroying the instance. It's causing an issue with React when dismounting a component with a flatpickr instance inside it. React throws an error when it tries to remove an element which wasn't created by itself.

Reproduction links:
flatpickr not removing the wrapper: http://jsbin.com/cipuzovuvi/2/edit?html,js,output
React error: http://jsbin.com/xatabawigo/edit?html,js,output
It should be simple to fix this, just remove the wrapper element after moving the original input element to where it was before, but I'm not familiar with flatpickr internals.
wrapper.parentNode.insertBefore(input, wrapper);
wrapper.remove();

Your Environment

flatpickr version used: 4.5.0
Browser name and version: Chrome 68, Firefox 60
OS and version: Ubuntu 18.04

Why all of those issues are closed?


Docker 1.13 swarm-mode support for contiv

Moved to docker client library in docknet (from samalba)
Create networks in docker with 'Attachable' option
Use swarm mode as an env option and create swarm-mode cluster
demo-v2plugin target to create v2plugin and enable swarm-mode
Updated plugin to use alpine base image

LGTM


Hudi upsert hangs

Describe the problem you faced
When we upsert data into Hudi, we're finding that the job just hangs in some cases. Specifically, we have an ETL pipeline where we re-ingest a lot of data (i.e. we upsert data that already exists in the Hudi table). When the proportion of data that is not new is very high, the Hudi spark job seems to hang before writing out the updated table.
Note that this currently affects 2 of the 80 tables in our ETL pipeline and the rest run fine.
To Reproduce
See gist at: https://gist.github.com/bwu2/89f98e0926374f71c80e4b2fa5089f18
The code there creates a Hudi table with 4m rows. It then upserts another 4m rows, 3.5m of which are the same as the original 4m.
Note that bulk parallelism of the initial load is deliberately set to 1 to ensure we avoid lots of small files.
Running this code on an EMR cluster (either interactively in a PySpark shell or spark-submit) causes the upsert job never to finish, being stuck somewhere in the Spark job with description (from the Spark history server):
count at HoodieSparkSqlWriter.scala:255 (after the stage mapToPair at HoodieWriteClient.java:492 and before/during the stage count at HoodieSparkSqlWriter.scala:255).
For a table this small, it shouldn't matter about cores/memory/executors/instance type but we have varied these too with no success.
Expected behavior
Expected the upsert job to succeed and the total number of rows in the table to be 4.5m.
**Environment Description
Running on EMR 5.29.0

Hudi version : tested on 0.5.0, 0.5.1 and latest build off master

Spark version : 2.4.4

Hive version : N/A

Hadoop version : 2.8.5 (Amazon)

Storage (HDFS/S3/GCS..) : S3

Running on Docker? (yes/no) : NO

An update on this: the job did eventually complete. But took 2.4 hours (other similar jobs ran more than 9 hours before we had to kill them). This doesn't seem reasonable for such a small table.

Reposting my response here..
There seems to be a lot of common concerns here.. https://cwiki.apache.org/confluence/display/HUDI/Tuning+Guide is an useful resource, that hopefully can benefit here..
Few high level thoughts:
It would be good to layout if the most time spent is on the indexing stages (ones tagged with HoodieBloomIndex) or the actual writing..
Hudi does keep the input in memory to compute the stats it needs to size files. So if you don't provide sufficient executore/rdd storage memory, it will spill and can cause slowdowns.. (covered in tuning guide & have seen this happen with users often)
On workload pattern itself, BloomIndex range pruning can be turned off https://hudi.apache.org/docs/configurations.html#bloomIndexPruneByRanges if the keys ranges are random anyway.. Generally speaking, unless we have RFC-8 (record level indexing), cases of random write/upserting majority of the rows in a table, may give bloom index overhead, since the bloom filters/ranges are not at all useful in pruning out files . We have an interim solution coming out in the next release.. falling back to plain old join to implement the indexing.
In terms or MOR and COW, MOR will help only if you have lots of updates and bottleneck is on the writing..
If listing is an issue, please turn the following so the table is listed once and we re-use the filesytem metadata hoodie.embed.timeline.server=true
I would appreciate a JIRA, so that I can break each into sub-task and tackle/resolve independently..
I am personally focussing on performance now and want to make it lot faster in 0.6.0 release. So all this help would be deeply appreciated

@vinothchandar Thanks for taking the time to reply!
Let me describe the simplest example of this problem on a tiny COW data set: Create a data frame with 4m rows and one column with values 1, 2, 3....4m in that column. Bulk insert that into Hudi (using the one column as the {{recordkey}}). This takes ~1 minute to run and the data size is about 30MB. Now upsert the same data frame into the table a second time. This take >2 hours to run.
Alternatively, if we upsert a new data frame with values 4000001...8m (still 4m rows upserted), this takes ~1 minute to run.
To answer your other queries:

almost all of the time is spent in the  {{HoodieSparkSqlWriter}} job (and within that job, the {{count at HoodieSparkSqlWriter.scala}} stage (the BloomIndex parts run quickly).
it seems highly unlikely to be resource constraint issue with such a small example.

Shall i raise a Jira for this? Or is this the expected behavior for such a workload?

There must be something else going on.. just used my own benchmark jobs to generate a pattern where the records are fully overwritten in a second (and a third) batch and it actually finishes fine..
hudi:hoodie_benchmark->connect --path file:///tmp/hudi-benchmark/output/org.apache.hudi
35394 [Spring Shell] INFO  org.apache.hudi.common.table.HoodieTableMetaClient  - Loading HoodieTableMetaClient from file:///tmp/hudi-benchmark/output/org.apache.hudi
35415 [Spring Shell] INFO  org.apache.hudi.common.util.FSUtils  - Hadoop Configuration: fs.defaultFS: [file:///], Config:[Configuration: core-default.xml, core-site.xml, mapred-default.xml, mapred-site.xml, yarn-default.xml, yarn-site.xml, hdfs-default.xml, hdfs-site.xml], FileSystem: [org.apache.hadoop.fs.LocalFileSystem@6851d345]
35416 [Spring Shell] INFO  org.apache.hudi.common.table.HoodieTableConfig  - Loading table properties from file:/tmp/hudi-benchmark/output/org.apache.hudi/.hoodie/hoodie.properties
35416 [Spring Shell] INFO  org.apache.hudi.common.table.HoodieTableMetaClient  - Finished Loading Table of type COPY_ON_WRITE(version=1) from file:///tmp/hudi-benchmark/output/org.apache.hudi
Metadata for table hoodie_benchmark loaded
hudi:hoodie_benchmark->commits show
36774 [Spring Shell] INFO  org.apache.hudi.common.table.timeline.HoodieActiveTimeline  - Loaded instants [[20200213134159__clean__COMPLETED], [20200213134159__commit__COMPLETED], [20200213134410__clean__COMPLETED], [20200213134410__commit__COMPLETED], [20200213134548__clean__COMPLETED], [20200213134548__commit__COMPLETED]]
╔════════════════╤═════════════════════╤═══════════════════╤═════════════════════╤══════════════════════════╤═══════════════════════╤══════════════════════════════╤══════════════╗
║ CommitTime     │ Total Bytes Written │ Total Files Added │ Total Files Updated │ Total Partitions Written │ Total Records Written │ Total Update Records Written │ Total Errors ║
╠════════════════╪═════════════════════╪═══════════════════╪═════════════════════╪══════════════════════════╪═══════════════════════╪══════════════════════════════╪══════════════╣
║<PHONE_NUMBER>4548 │ 384.8 MB            │ 0                 │ 34                  │ 3                        │ 4080024               │ 1211376                      │ 0            ║
╟────────────────┼─────────────────────┼───────────────────┼─────────────────────┼──────────────────────────┼───────────────────────┼──────────────────────────────┼──────────────╢
║<PHONE_NUMBER>4410 │ 379.9 MB            │ 0                 │ 34                  │ 3                        │ 4040016               │ 1199234                      │ 0            ║
╟────────────────┼─────────────────────┼───────────────────┼─────────────────────┼──────────────────────────┼───────────────────────┼──────────────────────────────┼──────────────╢
║<PHONE_NUMBER>4159 │ 374.8 MB            │ 34                │ 0                   │ 3                        │ 4000008               │ 0                            │ 0            ║
╚════════════════╧═════════════════════╧═══════════════════╧═════════════════════╧══════════════════════════╧═══════════════════════╧══════════════════════════════╧══════════════╝

hudi:hoodie_benchmark->

and the times below in ms
 grep -n -e totalCreateTime -e totalUpsertTime  /tmp/hudi-benchmark/output/org.apache.hudi/.hoodie/*.commit
/tmp/hudi-benchmark/output/org.apache.hudi/.hoodie/20200213134159.commit:697:  "totalCreateTime" : 195060,
/tmp/hudi-benchmark/output/org.apache.hudi/.hoodie/20200213134159.commit:698:  "totalUpsertTime" : 0,
/tmp/hudi-benchmark/output/org.apache.hudi/.hoodie/20200213134410.commit:697:  "totalCreateTime" : 0,
/tmp/hudi-benchmark/output/org.apache.hudi/.hoodie/20200213134410.commit:698:  "totalUpsertTime" : 193693,
/tmp/hudi-benchmark/output/org.apache.hudi/.hoodie/20200213134548.commit:697:  "totalCreateTime" : 0,
/tmp/hudi-benchmark/output/org.apache.hudi/.hoodie/20200213134548.commit:698:  "totalUpsertTime" : 182277,

Can we drill into your dataset?  are you generating tons of files due to granular partitionining? can you share the spark UI and the hudi cli output like above?

Ok, thanks for this.
I have run the jobs again. First, insert 4m records, then upsert 3m of them, then upsert 4m, then upsert 4m. The two jobs upserting 3m records work fine and quickly, but the one where upsert 4m takes >200 times as long.
My results (from a synthetic dataset) are:
hudi:json_data->commits show --limit 4 ╔════════════════╤═════════════════════╤═══════════════════╤═════════════════════╤══════════════════════════╤═══════════════════════╤══════════════════════════════╤══════════════╗ ║ CommitTime     │ Total Bytes Written │ Total Files Added │ Total Files Updated │ Total Partitions Written │ Total Records Written │ Total Update Records Written │ Total Errors ║ ╠════════════════╪═════════════════════╪═══════════════════╪═════════════════════╪══════════════════════════╪═══════════════════════╪══════════════════════════════╪══════════════╣ ║<PHONE_NUMBER>3937 │ 25.5 MB             │ 0                 │ 1                   │ 1                        │ 4000000               │ 3000000                      │ 0            ║ ╟────────────────┼─────────────────────┼───────────────────┼─────────────────────┼──────────────────────────┼───────────────────────┼──────────────────────────────┼──────────────╢ ║<PHONE_NUMBER>4532 │ 25.5 MB             │ 0                 │ 1                   │ 1                        │ 4000000               │ 4000000                      │ 0            ║ ╟────────────────┼─────────────────────┼───────────────────┼─────────────────────┼──────────────────────────┼───────────────────────┼──────────────────────────────┼──────────────╢ ║<PHONE_NUMBER>4325 │ 25.6 MB             │ 0                 │ 1                   │ 1                        │ 4000000               │ 3000000                      │ 0            ║ ╟────────────────┼─────────────────────┼───────────────────┼─────────────────────┼──────────────────────────┼───────────────────────┼──────────────────────────────┼──────────────╢ ║<PHONE_NUMBER>4218 │ 25.5 MB             │ 1                 │ 0                   │ 1                        │ 4000000               │ 0                            │ 0            ║ ╚════════════════╧═════════════════════╧═══════════════════╧═════════════════════╧══════════════════════════╧═══════════════════════╧══════════════════════════════╧══════════════╝
and the times:
grep -n -e totalCreateTime -e totalUpsertTime  *.commit<PHONE_NUMBER>4218.commit:36:  "totalCreateTime" : 30012,<PHONE_NUMBER>4218.commit:37:  "totalUpsertTime" : 0,<PHONE_NUMBER>4325.commit:36:  "totalCreateTime" : 0,<PHONE_NUMBER>4325.commit:37:  "totalUpsertTime" : 46879,<PHONE_NUMBER>4532.commit:36:  "totalCreateTime" : 0,<PHONE_NUMBER>4532.commit:37:  "totalUpsertTime" : 10347280,<PHONE_NUMBER>3937.commit:36:  "totalCreateTime" : 0,<PHONE_NUMBER>3937.commit:37:  "totalUpsertTime" : 44598,

Ok, after reading https://github.com/apache/incubator-hudi/issues/800 (which is simialr), I think this is a memory issue (even though GC seems to be a small proportion of the total time, according to the Spark history server & we're not getting any OOME).
When I double the spark.executor.memory the job runs much faster. I'm sure there are maybe other optimizations and/or tuning I can consider also.
Is it normal/expected that an upsert with mostly updates would require more memory than an upsert with mostly inserts?

Even #800 is a reasonable workload.. I don't understand what's going on here .. Its just a single file being versioned.. same as the next two commits, which seems to be faster.. Is there a way you can give me a reproducible snippet of code? (I think you mentioned this is synthetic data)

See: https://gist.github.com/bwu2/e432a42f51519f27197f4785af3e1abf

Started on this.. Was trying to port to scala, since I am not super familiar with pySpark. Will resume today and circle back. :)

I ported your code to scala and looking into the issue now.. Will keep you posted.
val HUDI_FORMAT = "org.apache.hudi"
val TABLE_NAME = "hoodie.table.name"
val RECORDKEY_FIELD_OPT_KEY = "hoodie.datasource.write.recordkey.field"
val PRECOMBINE_FIELD_OPT_KEY = "hoodie.datasource.write.precombine.field"
val OPERATION_OPT_KEY = "hoodie.datasource.write.operation"
val BULK_INSERT_OPERATION_OPT_VAL = "bulk_insert"
val UPSERT_OPERATION_OPT_VAL = "upsert"
val BULK_INSERT_PARALLELISM = "hoodie.bulkinsert.shuffle.parallelism"
val UPSERT_PARALLELISM = "hoodie.upsert.shuffle.parallelism"
val config = Map(
"table_name" -> "example_table",
"target" -> "file:///tmp/example_table/",
"primary_key" ->  "id",
"sort_key" -> "id"
)
val readPath = config("target") + "/*"

val json_data = (1 to 4000000).map(i => "{\"id\":" + i + "}")
val jsonRDD = spark.sparkContext.parallelize(json_data, 2)
val df1 = spark.read.json(jsonRDD)
println(s"${df1.count()} records in source 1")

df1.printSchema

// Runs quick
df1.write.format(HUDI_FORMAT)
      .option(PRECOMBINE_FIELD_OPT_KEY, config("sort_key"))
      .option(RECORDKEY_FIELD_OPT_KEY, config("primary_key"))
      .option(TABLE_NAME, config("table_name"))
      .option(OPERATION_OPT_KEY, BULK_INSERT_OPERATION_OPT_VAL)
      .option(BULK_INSERT_PARALLELISM, 1)
      .mode("Overwrite")
      .save(config("target"))

println(s"${spark.read.format(HUDI_FORMAT).load(readPath).count()} records in Hudi table")

// Runs quick
df1.limit(3000000).write.format(HUDI_FORMAT)
    .option(PRECOMBINE_FIELD_OPT_KEY, config("sort_key"))
    .option(RECORDKEY_FIELD_OPT_KEY, config("primary_key"))
    .option(TABLE_NAME, config("table_name"))
    .option(OPERATION_OPT_KEY, UPSERT_OPERATION_OPT_VAL)
    .option(UPSERT_PARALLELISM, 20)
    .mode("Append")
    .save(config("target"))

println(s"${spark.read.format(HUDI_FORMAT).load(readPath).count()} records in Hudi table")

// Runs very slow
df1.write.format(HUDI_FORMAT)
  .option(PRECOMBINE_FIELD_OPT_KEY, config("sort_key"))
  .option(RECORDKEY_FIELD_OPT_KEY, config("primary_key"))
  .option(TABLE_NAME, config("table_name"))
  .option(OPERATION_OPT_KEY, UPSERT_OPERATION_OPT_VAL)
  .option(UPSERT_PARALLELISM, 20)
  .mode("Append")
  .save(config("target"))

println(s"${spark.read.format(HUDI_FORMAT).load(readPath).count()} records in Hudi table")

@lamber-ken is right.. I am looking into why the DiskBasedMap is so slow (there was a recent change.. wondering if its a regression.. ) Will raise a JIRA nonetheless..
So bit more explanation..The big difference is that all 4M entries go to one file and its a degenerate workload (i.e a single field record) where the metadata to data overhead is lot.. We have a spilling mechanism to handle large number keys merging into a single file (like the spill map you will see in spark shuffle) and that seems to be performing poorly..

https://issues.apache.org/jira/browse/HUDI-625 filed this to look into this scenario..
@bwu2 In the meantime, could you run your benchmark against a real dataset with more fields so number of files spread out and record sizes are larger.

Thanks for your replies!
@lamber-ken I will try again with that setting. Does increasing the memory available by setting option("hoodie.memory.merge.max.size", "2004857600000") work better than increasing executor memory orhoodie.memory.merge.fraction? Will it not result in an OOME?
@vinothchandar Yes, we are re-running against real datasets in the next couple of days. I will report back. But do note that the original problem actually arose on a real dataset not a degenerate or artificial workload: it was not a particularly wide table (with 6 or 7 fields), with about 4m rows bulk inserted and then another 4m upserted (of which most were the same rows).

@bwu2 Got it.. I think the root issue is that the map is spilling more than needed. I am trying to understand why.. Will update the JIRA as I uncover stuff. if its easy, we can target a fix in the next 0.5.2 release itself.

Fix landed on master


Bump version to 1.2.2

Signed-off-by: Annie Lee<EMAIL_ADDRESS>Issue #, if available:
Description of changes:
Bump version to 1.2.2
CheckList:

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Approved, but don't merge until CI passes (i.e. the required deps pushed up first)

@leeyun-amzn your DCO check needs a proper e-mail, currently lists Annie Lee<EMAIL_ADDRESS>please do fix for future commits.


Added a first-pass POC for rebase script in Python

Signed-off-by: Steve Kuznetsov<EMAIL_ADDRESS>

@kargakis


Explain how dependency injection works, best practices

[ ] Singleton nature of DI, and how providers: [ ... ] works (https://github.com/dart-lang/angular/issues/495)
Just see #992 for details.

WIP in https://github.com/dart-lang/angular/issues/465.

Landed #992.


Query entities by attrs only is retrieving nothing

Using this endpoint to retrieve all entities having the flow attribute:
/ngsi-ld/v1/entities?attrs=flow
is retrieving an empty array
While adding an idPattern seems to make it work properly:
/ngsi-ld/v1/entities?attrs=flow&idPattern=(?i).*River.*
is retrieving all entities having a flow attribute and containing "river" within their id

Indeed, the attrs query parameter is currently only used for the representation of the results, and not to select the entities that should be part of the result (but it should, as per the specification).