break-insert for lldb-mi no longer requires 'on'

In this line, we have a comment that break-insert requires on for lldb-mi: https://github.com/microsoft/MIEngine/blob/2bb9706607edf0ce839bab4eb131adc8a555b6ec/src/MIDebugEngine/Engine.Impl/DebuggedProcess.cs#L872
This is no longer true (presumably, it has been fixed upstream in lldb-mi): https://github.com/lldb-tools/lldb-mi (maybe this change: https://github.com/lldb-tools/lldb-mi/commit/e448e35a9e4da5b5a4f0f80530ba30d5a619cb3e#diff-16ecaed41b16ef0b1fd18b3f74b1a2f2).
I think fixing this will allow us to fix debugging on macOS using vscode-cpptools: https://github.com/microsoft/vscode-cpptools/issues/3829
Taking the latest version of lldb-mi from GitHub, and building it:

Including -break-insert -f on main does not work:

lldbmitest) BenMBP:attach ben$ ../../build/src/lldb-mi
(gdb)
-file-exec-and-symbols ../testdata/simple/simple
^done
(gdb)
=library-loaded,id="/Users/ben/Development/llvm-project/lldb-mi/test/testdata/simple/simple",target-name="/Users/ben/Development/llvm-project/lldb-mi/test/testdata/simple/simple",host-name="/Users/ben/Development/llvm-project/lldb-mi/test/testdata/simple/simple",symbols-loaded="1",symbols-path="/Users/ben/Development/llvm-project/lldb-mi/test/testdata/simple/simple.dSYM/Contents/Resources/DWARF/simple",loaded_addr="-",size="4096"
-break-insert -f on main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0xffffffffffffffff",func="??",file="??",fullname="??/??",line="0",pending=["on"],times="0",original-location="on"}
(gdb)
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0xffffffffffffffff",func="??",file="??",fullname="??/??",line="0",pending=["on"],times="0",original-location="on"}
(gdb)

As you can see, the breakpoint is pending and has no file/line info.

Including -break-insert -f main works:

(lldbmitest) BenMBP:attach ben$ ../../build/src/lldb-mi
(gdb)
-file-exec-and-symbols ../testdata/simple/simple
^done
(gdb)
=library-loaded,id="/Users/ben/Development/llvm-project/lldb-mi/test/testdata/simple/simple",target-name="/Users/ben/Development/llvm-project/lldb-mi/test/testdata/simple/simple",host-name="/Users/ben/Development/llvm-project/lldb-mi/test/testdata/simple/simple",symbols-loaded="1",symbols-path="/Users/ben/Development/llvm-project/lldb-mi/test/testdata/simple/simple.dSYM/Contents/Resources/DWARF/simple",loaded_addr="-",size="4096"
-break-insert -f main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000100000f26",func="main",file="simple.cpp",fullname="/Users/ben/Development/llvm-project/lldb-mi/test/testdata/simple/simple.cpp",line="15",pending=["main"],times="0",original-location="main"}
(gdb)
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000100000f26",func="main",file="simple.cpp",fullname="/Users/ben/Development/llvm-project/lldb-mi/test/testdata/simple/simple.cpp",line="15",pending=["main"],times="0",original-location="main"}
(gdb)

as you can see, this works and resolves the breakpoint, and we can see that the breakpoint is actually triggered, hence this lldb-mi could be used with MIEngine (via vscode-cpptools) to fix the macOS breakpoints-not-triggering issue (referenced above):
(gdb)
-exec-run

<snip uninteresting stuff>

(gdb)
*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={level="0",addr="0x0000000100000f26",func="main",args=[{name="argc",value="1"}],file="simple.cpp",fullname="/Users/ben/Development/llvm-project/lldb-mi/test/testdata/simple/simple.cpp",line="15"},thread-id="1",stopped-threads="all"
(gdb)

I would send a PR to remove this lldb-mi workaround, but I can't actually build this project as I don't have Windows.

@puremourning Thank you for looking into this!
Would you be willing to try out a patched MIEngine with your lldb-mi? The difference is that 870 to 874 have been removed. I am currently kicking off a release build of that branch.

Sure thing! If you drop me a link to the build artefacts (presumably I can get them from azure?) I'll drop them in an re-test.

I actually bought a copy of windows, installed it in a VM and built MIEngine myself. Setting miDebuggerPath to point at a newly build lldb-mi and copying the built binaries to the Mac and firing up vimspector...

Success! Breakpoint hit!
there's a secondary problem that extrenalConsole no longer works properly. But I think that just needs an environment variable set. I'll look into that.
here's the current diff:
--- a/src/MICore/CommandFactories/lldb.cs
+++ b/src/MICore/CommandFactories/lldb.cs
@@ -46,29 +46,6 @@ namespace MICore
             }
         }

-        protected override StringBuilder BuildBreakInsert(string condition, bool enabled)
-        {
-            // LLDB's use of the pending flag requires an optional parameter or else it fails.
-            // We will use "on" for now.
-            // TODO: Fix this on LLDB-MI's side
-            string pendingFlag = "-f on ";
-
-            StringBuilder cmd = new StringBuilder("-break-insert ");
-            cmd.Append(pendingFlag);
-
-            if (condition != null)
-            {
-                cmd.Append("-c \"");
-                cmd.Append(condition);
-                cmd.Append("\" ");
-            }
-            if (!enabled)
-            {
-                cmd.Append("-d ");
-            }
-            return cmd;
-        }
-
         public override async Task<Results> VarCreate(string expression, int threadId, uint frameLevel, enum_EVALFLAGS dwFlags, ResultClass resultClass = ResultClass.done)
         {
             string quoteEscapedExpression = EscapeQuotes(expression);
diff --git a/src/MIDebugEngine/Engine.Impl/DebuggedProcess.cs b/src/MIDebugEngine/Engine.Impl/DebuggedProcess.cs
index a3747cb..d46e510 100755
--- a/src/MIDebugEngine/Engine.Impl/DebuggedProcess.cs
+++ b/src/MIDebugEngine/Engine.Impl/DebuggedProcess.cs
@@ -866,13 +866,7 @@ namespace Microsoft.MIDebugEngine
         private string GetBreakInsertMainCommand()
         {
             // Allow main breakpoint to be pending.
-            string breakInsertMainFormat = "-break-insert -f{0} main";
-            if (this.MICommandFactory.Mode == MIMode.Lldb)
-            {
-                // break-insert -f requires 'on' in lldb scenario
-                return string.Format(CultureInfo.InvariantCulture, breakInsertMainFormat, " on");
-            }
-            return string.Format(CultureInfo.InvariantCulture, breakInsertMainFormat, string.Empty);
+            return "-break-insert -f main";
         }

         private void CheckCygwin(List<LaunchCommand> commands, LocalLaunchOptions localLaunchOptions)

It may take a while before we can ship a Microsoft Signed LLDB-MI. But if users are willing to build and use their own as a workaround, we can take this change and ship a new MIEngine.
However, we will need to have both -break-insert since we may still have users using the current lldb-mi that is shipped on older versions of MacOS. So if we want this change, MIEngine should send -break-insert -f on main and if that fails, we can send -break-insert -f main

The challenge is detecting "failure". When we send break-insert -f on main in the fixed lldb, that's actually just trying to create a breakpoint at the function on, which might exist.

This is absolutely wonderful that after a whole year of this issue festering, you two wizards are finally peeling it open.
Why not detect the version of LLDB-mi at the -break-insert -f main callsite?

If version(LLDB-mi-being-used) <= version(current-LLDB-mi-release) use -break-insert -f on main
Else use -break-insert -f main

I apologise if this is an ignorant suggestion.

@p-i- Thank you for your suggestion!
Looks like version in the latest lldb-mi returns a correctly formattted MI response while in the 3.5 version it does not.
LLDB-MI 3.5:
(gdb)
version
lldb-350.99.0
^done

latest LLDB-MI:
(gdb)
version
~"lldb version 8.0.1\n"
^done

On the face of it, I guess we can work with that. If the version response is garbage, assume it’s old lldb-mi and send the ‘compatible’ break-insert request. Then again it’s actually the lldb-mi version not the lldb version that we care about. At least since the split.

Actually, checking the version may not be needed.
I think attempting -break-insert -f main first and then sending -break-insert -f on main if it fails works.
On lldb-mi 3.5, you get an Unrecognized command for -break-insert -f main.

there's a secondary problem that extrenalConsole no longer works properly. But I think that just needs an environment variable set. I'll look into that.

I think the issue is this:
https://github.com/microsoft/MIEngine/blob/2bb9706607edf0ce839bab4eb131adc8a555b6ec/src/MIDebugEngine/Engine.Impl/DebuggedProcess.cs#L795
MIEngine sends -gdb-set new-console on and currently lldb-mi does not handle that command. We have a change I will push upstream.
I'll edit this comment with the diff's needed.

Yeah I noticed that. It’s simple enough to add that settting, but the Gdb docs say that new-console is only supported on windows And the tty command is supposed to be used elsewhere. Though that’s unsatisfactory too.
You can Actually just set LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY environment car instead which works.  maybe MIEngine should just set it when ExternalConsole is true.

@WardenGnaw  I tried testing your fixLLDB branch, it doesn't work - it just hangs. I think this is because it sends the command too early, or it never reads the command result ? Not sure.
Here's my quick implementation of the new-console command for the record:
commit d48fc781fabff4bc1b60256673c6ed072814b78c (HEAD -> master, pm/master)
Author: Ben Jackson<EMAIL_ADDRESS>Date:   Sat Jan 4 14:37:46 2020 +0000

    Support new-console GDB command.

    This is a simple way to make applications launch in a new Terminal on
    macOS. There's actually a LLDB launch flag lldb:eLaunchFlagLaunchInTTY,
    but it wasn't obvious to me how/where to store launcg options in
    lldb-mi, so setting the environment variable works just as well.

diff --git a/src/MICmdCmdGdbSet.cpp b/src/MICmdCmdGdbSet.cpp
index 162e3d5..9330a91 100644
--- a/src/MICmdCmdGdbSet.cpp
+++ b/src/MICmdCmdGdbSet.cpp
@@ -16,6 +16,7 @@
 #include "MICmnLLDBDebugSessionInfo.h"
 #include "MICmnMIResultRecord.h"
 #include "MICmnMIValueConst.h"
+#include <cstdlib>

 // Instantiations:
 const CMICmdCmdGdbSet::MapGdbOptionNameToFnGdbOptionPtr_t
@@ -28,6 +29,7 @@ const CMICmdCmdGdbSet::MapGdbOptionNameToFnGdbOptionPtr_t
         {"solib-search-path", &CMICmdCmdGdbSet::OptionFnSolibSearchPath},
         {"disassembly-flavor", &CMICmdCmdGdbSet::OptionFnDisassemblyFlavor},
         {"fallback", &CMICmdCmdGdbSet::OptionFnFallback},
+        {"new-console", &CMICmdCmdGdbSet::OptionFnNewConsole},
         {"breakpoint", &CMICmdCmdGdbSet::OptionFnBreakpoint}};

 //++
@@ -208,6 +210,41 @@ bool CMICmdCmdGdbSet::GetOptionFn(const CMIUtilString &vrPrintFnName,
   return false;
 }

+bool CMICmdCmdGdbSet::OptionFnNewConsole(
+  const CMIUtilString::VecString_t &vrWords) {
+  bool bNewConsole = false;
+  bool bOk = true;
+
+  if (vrWords.size() > 1)
+    // Too many arguments.
+    bOk = false;
+  else if (vrWords.size() == 0)
+    // If no arguments, default is "on".
+    bNewConsole = true;
+  else if (CMIUtilString::Compare(vrWords[0], "on"))
+    bNewConsole = true;
+  else if (CMIUtilString::Compare(vrWords[0], "off"))
+    bNewConsole = false;
+  else
+    // Unrecognized argument.
+    bOk = false;
+
+  if (!bOk) {
+    // Report error.
+    m_bGbbOptionFnHasError = true;
+    m_strGdbOptionFnError = MIRSRC(IDS_CMD_ERR_GDBSET_OPT_NEWCONSOLE);
+    return MIstatus::failure;
+  }
+
+  // TDDO: Like, set the environment variable ?
+  // Should we maybe set the launch flag too ?
+  if (bNewConsole) {
+    ::setenv( "LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY", "TRUE", false );
+  }
+
+  return MIstatus::success;
+}
+
 //++
 // Details: Carry out work to complete the GDB set option 'target-async' to
 // prepare
diff --git a/src/MICmdCmdGdbSet.h b/src/MICmdCmdGdbSet.h
index c88f997..38f35ae 100644
--- a/src/MICmdCmdGdbSet.h
+++ b/src/MICmdCmdGdbSet.h
@@ -81,6 +81,7 @@ private:
   bool OptionFnDisassemblyFlavor(const CMIUtilString::VecString_t &vrWords);
   bool OptionFnBreakpoint(const CMIUtilString::VecString_t &vrWords);
   bool OptionFnFallback(const CMIUtilString::VecString_t &vrWords);
+  bool OptionFnNewConsole(const CMIUtilString::VecString_t &vrWords);

   // Attributes:
 private:
diff --git a/src/MICmnResources.cpp b/src/MICmnResources.cpp
index 998c79a..6fe2eaf 100644
--- a/src/MICmnResources.cpp
+++ b/src/MICmnResources.cpp
@@ -439,6 +439,8 @@ const CMICmnResources::SRsrcTextData
         {IDS_CMD_ERR_INFO_PRINTFN_FAILED, "The request '%s' failed."},
         {IDS_CMD_ERR_GDBSET_OPT_TARGETASYNC,
          "'target-async' expects \"on\" or \"off\""},
+        {IDS_CMD_ERR_GDBSET_OPT_NEWCONSOLE,
+         "'new-console' expects \"on\" or \"off\""},
         {IDS_CMD_ERR_GDBSET_OPT_BREAKPOINT,
          "'breakpoint' expects \"pending on\" or \"pending off\""},
         {IDS_CMD_ERR_GDBSET_OPT_SOLIBSEARCHPATH,
diff --git a/src/MICmnResources.h b/src/MICmnResources.h
index 111b0c3..195784b 100644
--- a/src/MICmnResources.h
+++ b/src/MICmnResources.h
@@ -263,6 +263,7 @@ enum {
   IDS_CMD_ERR_INFO_PRINTFN_NOT_FOUND,
   IDS_CMD_ERR_INFO_PRINTFN_FAILED,
   IDS_CMD_ERR_GDBSET_OPT_TARGETASYNC,
+  IDS_CMD_ERR_GDBSET_OPT_NEWCONSOLE,
   IDS_CMD_ERR_GDBSET_OPT_BREAKPOINT,
   IDS_CMD_ERR_GDBSET_OPT_SOLIBSEARCHPATH,
   IDS_CMD_ERR_GDBSET_OPT_PRINT_BAD_ARGS,

it just hangs

Fixed it?
https://github.com/microsoft/MIEngine/pull/950

Woo \o/. with the above PR (#950) and the latest lldb-mi including the new-console patch vimspector regression tests finally pass on macOS Catalina!
BenMBP:vimspector ben$ ./run_tests
Testing with VIMSPECTOR_MIMODE=lldb
%SETUP - Building test programs...
~/.vim/bundle/vimspector/tests/testdata/cpp/simple ~/.vim/bundle/vimspector
rm -f simple variables
rm -rf simple.dSYM variables.dSYM
c++ -g -O0 -std=c++17    simple.cpp   -o simple
~/.vim/bundle/vimspector
%DONE - built test programs
Running Vimspector Vim tests

%RUN: breakpoints.test.vim
%PASS: breakpoints.test.vim PASSED

%RUN: language_go.test.vim
%PASS: language_go.test.vim PASSED

%RUN: language_python.test.vim
%PASS: language_python.test.vim PASSED

%RUN: tabpage.test.vim
%PASS: tabpage.test.vim PASSED

All done.

Now, to fix vscode-python which doesn't work with node 13.

This was fixed by #952


pagination done

pagination completed, please merge it

Please raise the pull request against the Develop branch

Cannot directly merge the branch into the Develop branch


when installing module gcc complains 'undefined reference to current_base' in simplehttp.c

I'm using libevent 2.0.12.
After "cd simplehttp ; make && make install", I switched to simplequeue to make install, but gcc began to complain, saying "../simplehttp/libsimplehttp.a(simplehttp.o): In function simplehttp_init': /home/lamusicoscos/Base/bitly-simplehttp-10406dc/simplehttp/simplehttp.c:152: undefined reference to current_base'
collect2: ld returned 1 exit status make: *** [simplequeue] Error 1".
But being with libevent 1.4, everything's OK. I'm just wondering why it happened and how can I make it work with libevent 2.0.12+.

closing


Implementation Questions

I noticed a few differences in implementation of the simple iteration algoritm that I do not understand:
(only speaking about the scripts in the pisum section)

Fortran version only times the loop,  not memory allocation of all variables etc.
Fortran version runs multiple times and reports the fastest run

Julia uses Floats for the variable ii. Using an Int instead results in a x15 speed up.
Julia only runs once, hence also includes compilation time of the function
In the Julia example there is an additional if statement.
Not including compile time and ii as Int and removing the if statement
leads to a speed up of x45 on my machine.

The Numba version (pisum.ipy) only loops 10^5 times, not 10^6.
The Numba version uses a different algorithm.

I don't know if I really understand the benchmark, but can you comment on the points above?
Thanks
Andre

@abieler thanks for your comments. Yes one night I furiously was editing and really didn't finish the work.
It should be much closer to sensible now, what do you think?

I just had a quick look at the Julia part. You are
still including the compilation time in the current version.
A few comments:
Take the x = 0.0 in f() down to the next line.
In Julia you do not need ; at the end of lines, only
when you use multiple statements in one line.
(like your if --> break statements)
Add two more lines of code:
println("simple_iter")
f(10^6)    # warm up for jit compiler
@time f(10^6)
println("pisum")
g(10^6)    # warm up for jit compiler
@time g(10^6)
The first time a function gets called in julia it is compiled (just in time
compilation),
every call after this will be using the compiled one.
There is still the inconsistency with the if-break condition that is there
in
Julia but not in the maltab simple_iter().
Generally in Julia I would recommend using the BenchmarkTools.jl package.
Pkg.add("BenchmarTools.jl")
and then simply do:
@benchmark f(10^6)
@benchmark g(10^6)
Cheers
Andre
On Thu, Dec 8, 2016 at 11:24 AM, Michael Hirsch<EMAIL_ADDRESS>wrote:

@abieler https://github.com/abieler thanks for your comments. Yes one
night I furiously was editing and really didn't finish the work.
It should be much closer to sensible now, what do you think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/scienceopen/python-performance/issues/2#issuecomment-265705962,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGwUhdmbPdu8rQw101ukIioGFq4bl9QZks5rF9rBgaJpZM4LFIst
.

Thanks. The latest commit addresses these issues


Exported h5m file does not show up anywhere

exported my geometry with "CUBIT> export dagmc "large_facets.h5m" faceting_tolerance 1.e-5". Operation ran successfully but file does not show up anywhere. Wondering why this is?

It should be written to Cubit's current working directory. You can check this with the pwd command in the console.

Its likely in your $HOME if you're in linux, on Windows could be the actual
Cubit install directory, in Mac goodness knows...
On Tue, 3 Oct 2023 at 22:07, 'Patrick Shriwise' via dagmcci <
@.***> wrote:

It should be written to Cubit's current working directory. You can
check this with the pwd command in the console.
—
Reply to this email directly, view it on GitHub
https://github.com/svalinn/Cubit-plugin/issues/152#issuecomment-1745726717,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRM655UDNWQHTODM5X2GFLX5R5ADAVCNFSM6AAAAAA5RSPG62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBVG4ZDMNZRG4
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>
--
You received this message because you are subscribed to the Google Groups
"dagmcci" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to @.***
To view this discussion on the web visit
https://groups.google.com/d/msgid/dagmcci/svalinn/Cubit-plugin/issues/152/1745726717%40github.com
https://groups.google.com/d/msgid/dagmcci/svalinn/Cubit-plugin/issues/152/1745726717%40github.com?utm_medium=email&utm_source=footer
.


Add a thin bar underneath the send amount to visually convey how much of total supply is being sent.

Description
Would be comfortable to be able to have a thin bar underneath the send amount to help convey how much value you will be sent in comparison to the total amount. This will prevent mistakes (such as adding an extra zero to the value).
Motivation
While it doesn't take long to do the math by looking up at your total supply and realize how much you would be spending there is the factor of user error. Someone (like my parents) would benefit greatly in knowing how much they would be spending, and if it makes sense.
Requirements
As the user changes the value inside the Amounts input section within the "Send" screen the bar would grow and shrink relative to the total supply.
Are you planning to do it yourself in a pull request?
No.
Images of the feature

Great idea.

We can probably solve this problem by adding a send confirmation screen.
"You are about to send X Mi (= $Y)" "Cancel OK"


don't extract input output variables

Input and output variables do not change between environments. There is no need to export them to overrides.


[inorder tree traversal]

Detailed description
add a code for program of inorder tree traversal
Context
it is important because without any traversal technique , we will not be able to traverse the tree.
Possible implementation
No response
Additional information
No response

@shivani1706 i want to do work on it, assign it to me!!

Guys please for the sake of hacktoberfest do not raise pr with irrelevant code.

I would like to work on this issue please, also could you please add hacktoberfest label, thank you!

I want to do this as a hacktoberfest contribution
Please assign this to me.

I want to do this as a hacktoberfest contribution
Please assign this to me.

please assign this,  it could be my first contribution.

I would like to contribute on this issue . Please assign this to me .

Please Assign this to me. I want to contribute to this project

Sir , can you assign this to me?

Can you assign this issue to me?

Please assign this task to me.

hello sir,can you please assign this issue to me??
Thanks in advance :)


HDDS-11388. Fix unnecessary call to the DB for ContainerBalancer#getBalancerStatusInfo

What changes were proposed in this pull request?
ContainerBalancer#getBalancerStatusInfo can get the current running balancer configuration from the in-memory configuration, which is in sync with the backing DB. Also added lock in getBalancerStatusInfo.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-11388
How was this patch tested?
Existing tests.

Seems container balancer acceptance test failed after this patch. Let me take a look first.

@ivandika3 let me know when it's ready for review.

@siddhantsangwan Hi, this patch is ready for review. Thank you.

Thank you for the review @siddhantsangwan


BrokenPipe Error Using TLS With Root Certificate

Bug Report
Version
tonic = { version = "0.11", features = ["tls"] }

❯ cargo tree | grep tonic
│   └── tonic v0.11.0
├── tonic v0.11.0 (*)
├── tonic-health v0.11.0
│   └── tonic v0.11.0 (*)
├── tonic-reflection v0.11.0
│   └── tonic v0.11.0 (*)
│   │   └── tonic v0.11.0 (*)

Platform
Darwin 0349 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:34 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T8103 arm6

Description
We recently upgraded tonic to v0.11.0 from v0.8 and are now receiving 'broken pipe' errors when trying to send requests to a remote server using tls with the mac root certificate.
called `Result::unwrap()` on an `Err` value: Status { code: Unknown, message: "transport error", source: Some(tonic::transport::Error(Transport, hyper::Error(Io, Custom { kind: BrokenPipe, error: "stream closed because of a broken pipe" }))) }

let pem = std::fs::read_to_string("/etc/ssl/cert.pem")?;
let ca = Certificate::from_pem(pem);
endpoint = endpoint.tls_config(ClientTlsConfig::new().ca_certificate(ca))?;

https://jessitron.com/2022/11/02/make-https-work-on-grpc-in-rust-load-a-root-certificate-into-the-tls-config/
If I downgrade to tonic v0.8 I can make successful requests to the server.
I have also tried using the feature tls-roots but this did not help.
I realise this will be difficult to replicate. Please let me know if there's any more detail I can provide.

I had a similar issue when connecting to a TLS url, but against an AWS registered hostname. It seems that the root certs aren't loaded by default so you need to handle that in the code yourself.
For me I needed to add the "tls-native-roots" feature (tls-root is deprecated from v0.12.2) then use the following code
let tls_config = ClientTlsConfig::new().with_native_roots();
if let Ok(endpoint) = Channel::from_shared(uri.to_string()) {
    match endpoint.tls_config(tls_config)?.connect().await {
        Ok(channel) => ...
        Err(e) => ...
}

Not sure if you found a resolution but I came across this issue while searching for solutions and thought it best to provide how I solved it.

Thanks @AlistairEpic. Really appreciate you helping on this 👍
Unfortunately I could not get past the error even when upgrading tonic to v0.12 and using "tls-native-roots"
tonic = { version = "0.12.0", features = ["tls", "tls-native-roots"] }
tonic-health = "0.12.0"
tonic-reflection = "0.12.0"

    fn endpoint(&self, endpoint: &str) -> Result<Endpoint, anyhow::Error> {
        let mut endpoint = tonic::transport::Endpoint::from_str(
            &endpoint.to_string().replace("dns:///", "dns://"),
        )?;
        if toolkit_rs::env::is_local() {
            endpoint = endpoint.tls_config(ClientTlsConfig::new().with_native_roots())?;
        }

        Ok(endpoint)
    }

status: Unknown, message: "transport error", details: [], metadata: MetadataMap { headers: {} }: transport error: connection error: stream closed because of a broken pipe

Did you manage to find a solution for this?
I just updated to tonic v0.12.3 and I am getting the same error. I did not have this error in tonic v0.11 where I don't need to specify tls_config. I cannot find anything relevant in the release notes that could have caused be causing this problem.

Also running into this, any solution here?

@milesj @goyal
When using TLS, the client connection protocol must be changed to https
https://github.com/hyperium/tonic/issues/1496#issuecomment-1708191438


Sorting with < 10% IV

I have a pidgey with 8% IV and if I sort my Pokémon according to IV it is listed with the 80% Pokémon.

Yeah this bug is already reported, im gonna fix it in the next version. Currently swamped with work-related programming.


Question regarding framework

Is it possible to just used the fine tuned model to just do encoding? Like the original version of setfit? If possible could you pls let me know how? Thanks in advance

Hi @sersoage if I understand correctly, you'd like to extract the embeddings from a fine-tuned SetFitModel right?
In that case you could use SetFitModel.model_body.encode(inputs)

Thanks!

Closing


docs: Use Sphinx for generating API docs.

This enables automatic Python/C++ API documentation generation using Doxygen, Sphinx
and two Sphinx extensions, Breathe and Exhale. The automatic C++ docs generator
executes Doxygen to generate XML outputs, which will be parsed by Breathe/Exhale
into the Sphinx domain.
To build the htmls, go to docs and run make html. The htmls will be
generated in the docs/build folder.

Also, you've moved the location of the html output for Doxygen, which will break the auto-deployment setup. Can you update the path in config.yml so that this will continue to work until we can test and iron out the Sphinx docs auto-deployment?

Also, you've moved the location of the html output for Doxygen, which will break the auto-deployment setup. Can you update the path in config.yml so that this will continue to work until we can test and iron out the Sphinx docs auto-deployment?

Yes. Done.

This only changes the location where html is generated, but doesn't actually generate any Sphinx output yet right? I don't see any make html command yet.

Correct. This still generates the Doxygen htmls. I'll generate the Sphinx output int the next commit.


Feature : Metrics for specific process

Hey, I've stumbled on your project which does exactly what I needed (so thank you :) ). I needed to monitor other processes aswell, so I've added another function in order to allow to monitor metrics for arbitrary PID (for example, child processes of the current process).
I've modified your base init_process_observer to be a simple wrapper with current PID around a new register_metrics function.
(Also, fixed the docstrings to fix the function doc on doc.rs
Best regards :)
Green.

Looks great!
Thanks!
Sorry for the late reply!


Sass class selectors use inline-color plugin

Information

Language: Sass
Plugins: inline-color

Description
When prism renders Sass using inline-color plugin, if a class selector has a color name, the inline color preview is displayed.
Code snippet
Test page - though it doesn't display usage of plugins.

.lucidagrande-normal-
black-14px
  color: var(--black)
  font-family: var(--font-family-lucidagrande)
  font-size: var(--font-size-m)

Expected behavior
Class names / any other selector should not use inline-color plugin.

The Inline color plugin simply uses the tokenization provided by Sass. This is a bug with Sass. I'll fix it.

Thanks for your quick response and help!


Domain name in Twitch API passthrough instructions and actual domain name don't match

Challenge Name

https://www.freecodecamp.org/challenges/use-the-twitchtv-json-api
Issue Description

The domain name in the Twitch API passthrough instructions (https://wind-bow.gomix.me/twitch-api) doesn't match the page's actual domain name (https://wind-bow.glitch.me/). Using the gomix.me one for the project causes a CORS warning, while using glitch.me doesn't.
The link in the project page also still says gomix.me (although it redirects to glitch.me).

Stop with the emsils

Hi @littledago22 ,
Looks like you have subscribed to all emails from freeCodeCamp.
Please follow the link below for how to unsubscribe:
https://forum.freecodecamp.com/t/faq-unsubscribe-from-github-emails-on-issue-tracker/78944
Happy Coding!

Hi @kevcomedia thanks for pointing. We have removed this challenge on staging.
This line needs to be updated, changing gomix to glitch at all its occurrences.
https://github.com/freeCodeCamp/freeCodeCamp/blob/122f685f769d699e52deac2c1dd34fe50ee8169e/seed/challenges/01-front-end-development-certification/intermediate-ziplines.json#L171
Potential contributors:
Please make a pull-request against the backup/master branch. Follow the guidelines on the backup/master branch (and not the staging, only for this issue).

I would like to take this. Can you please help me in getting started?

Sure, you can start by setting up the local dev environment. If you are stuck reach out to the
Contributors Chat room.

This is still open for contribution on the staging branch.

I will work on the staging branch to add the missing UPDATE and correct the url

@nathanhannig awesome, thanks a lot!


siege observations

now my character is only level 2 but i noticed a lot of the other kinds of troops mainly mages are missing, have they become a leveled thing?

Yes.

ah okay i see thanks


Where is the path where the labeling worker's job log is saved?

I have one question.
When using the existing 2.3.0 version of CVAT, the following log was saved in data/tasks/{task_id}/logs/task.log in the cvat_server docker container.
{"job_id":857,"task_id":881,"client_id":642278,"name":"Fit image","time":"2024-07-19T04:17:37.642000Z","payload":{},"is_active":true,"username":"user1"}
{"job_id":857,"task_id":881,"client_id":642278,"name":"Change frame","time":"2024-07-19T04:17:39.416000Z","payload":{"from":0,"to":1},"is_active":true,"username":"user1"}

After upgrading CVAT to 2.15.0, I cannot see the log. (The file is not visible.)

Do I need to turn on any related features or settings, or is the location where it's saved different?

All the logs are stored in clickhouse now (cvat_clickhouse docker container)


drivers: flash: at45: Add Reset pin

Adding Reset pin initialization during AT45 driver start-up. Usually this pin is driven high, this implementation only initializes GPIO as output with the passive state. The AT45 device incorporates an internal power-on reset circuit, so there is no initial on-off sequence.
Signed-off-by: Eug Krashtan<EMAIL_ADDRESS>

Note that I'm not commenting on whether or not the reset-gpios property makes sense -- someone who knows this driver will have to decide that.

This driver is already multi-instance, so hard-coding instance number 0 is breaking that.
Please add the state you need to the per-device state instead. Please also use DEVICE_DT_GET(DT_GPIO_CTLR(DT_DRV_INST(inst), reset_gpios)) to get the GPIO device instead of saving label properties.

@mbolivar-nordic
Thank you for comment. Please, can you point me to any Zephyr driver where getting GPIO implemented in this way? (To use as reference).

@mbolivar-nordic Thank you for comment, forgot about inst in my implementation.
Fixed.

@mbolivar-nordic Thank you for comment, forgot about inst in my implementation.
Fixed

I still see instance 0 hardcoded.

@mbolivar-nordic Thank you for comment, forgot about inst in my implementation.
Fixed

I still see instance 0 hardcoded.

Ups... Sorry, forgot to remove unused defines

This driver is already multi-instance, so hard-coding instance number 0 is breaking that.

Strange, I see no button to mark this change request as resolved....

@mbolivar-nordic I did all the requested changes, but unfortunately, I see this PR stuck in the "Changes requested" state. Could you please re-review my PR to remove this mark? Thanks!

Replaced by https://github.com/zephyrproject-rtos/zephyr/pull/34560

Hi, I was coming back around to review this today and I'm curious why you chose to replace it with another PR instead of simply force-push into this one. Usually we force-push instead of closing as this keeps the previous discussion easily visible.

@mbolivar-nordic Yes, usually I did, but this time it was overcrowded with changes in code and commit messages. I prefer to clean up my PR.


websocket_server build gives extra ‘;’ [-Werror=pedantic]

Description
when compiling foxglove bridge for humble in ubuntu 20.04 I encounter an error related to wpedantic and the presence of extra ;
--- stderr: foxglove_bridge
CMake Warning:
 Manually-specified variables were not used by the project:

CATKIN_INSTALL_INTO_PREFIX_ROOT

In file included from /opt/ros/humble/src/foxglove_bridge/foxglove_bridge_base/src/server_factory.cpp:5:
 /opt/ros/humble/src/foxglove_bridge/foxglove_bridge_base/include/foxglove_bridge/websocket_server.hpp:1047:2: error: extra ‘;’ [-Werror=pedantic]
  1047 | };
       |  ^
 cc1plus: all warnings being treated as errors
 make[2]: *** [CMakeFiles/foxglove_bridge_base.dir/build.make:132: CMakeFiles/foxglove_bridge_base.dir/foxglove_bridge_base/src/server_factory.cpp.o] Error 1
 make[1]: *** [CMakeFiles/Makefile2:117: CMakeFiles/foxglove_bridge_base.dir/all] Error 2
 make: *** [Makefile:146: all] Error 2

Version: 0.7.7-1
Platform: aarch64

Steps To Reproduce
juste trying install foxglove_bridge with rosdep :
rosinstall_generator --deps --rosdistro humble foxglove_bridge  > ros2.humble.rosinstall
cat ros2.humble.rosinstall
vcs import src < ros2.humble.rosinstall

rosdep update
rosdep install -y --ignore-src --from-paths src --rosdistro humble

colcon build --merge-install --cmake-args -DCMAKE_BUILD_TYPE=Release

Expected Behavior

Thanks for the report, could you submit a PR to fix this?

Thanks for the report, could you submit a PR to fix this?

Hi, I have created a PR to fix this issue. Can you please approve it? Don't know why, but some test for ROS rolling haven't passed, but I think that problem not in extra ";".

Closed by #311

Can you push a new tag please? Installing via rosdep is still failing. Or is there a workaround maybe?

Why does rosdep fail? This PR should not be related to that.

I think ROS only updates its package index when new tag is pushed (if I understand correctly). So it still gets the source code for v0.7.7-1 and fails
https://github.com/ros2-gbp/foxglove_bridge-release

Yes, version 0.7.8 hasn't been released yet. Why is that a problem for you? Are you depending on exactly that version or why is rosdep failing? Some log messages would be helpful


dircon segfault adding post impact velocity constrain when no impact

I recently encountered a very strange bug in dircon.cc. When adding the impact constraint when their is not impact (pre_impact_velocity == post_impact_velocity) the code will segfault (Line 252). This does not seem to happen for every robot (planar walker is fine), but it does effect both Spirit and Cassie.
I found that changing line 249/250 from:
       auto pre_impact_velocity = state_vars(i_mode - 1, pre_impact_index)                                        .tail(plant_.num_velocities());
to:
auto pre_impact_state = state_vars(i_mode - 1, pre_impact_index);
auto pre_impact_velocity = pre_impact_state.tail(plant_.num_velocities());
Fixes the issue. I don't understand why this fixes the issue because at a glance the code should do the same thing.
Here is a branch where examples/Spirit:run_spirit_jump fails due to this bug: https://github.com/KodlabPenn/dairlib/tree/dircon_segfault_post_impact_vel_demo

Haven't looked too deeply yet, but I think it's possible that the auto keyword is responsible.

Haven't looked too deeply yet, but I think it's possible that the auto keyword is responsible.

Declaring pre_impact_velocity as auto makes it type Eigen::Block and declaring it as a VectorXDecisionVariable makes it type Eigen::PlainObjectBase. The Eigen::Block declaration seems to cause issues in the drake symbolic formula.

Declaring pre_impact_velocity as auto makes it type Eigen::Block and declaring it as a VectorXDecisionVariable makes it type Eigen::PlainObjectBase. The Eigen::Block declaration seems to cause issues in the drake symbolic formula.

Yes--coming to the same conclusion here as well. I'll open a quick PR.

Yes--coming to the same conclusion here as well. I'll open a quick PR.


add notification when edit/delete device

Fixes  # THEEDGE-3465
Description
this commit fix the missing notification in case of editing name of inventory and delete device,
when working with federation at the inventory side.

Type of change
What is it?

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[x] I run npm run lint:js:fix to check that my code is properly formatted

Codecov Report
Patch coverage has no change and project coverage change: -0.15% :warning:

Comparison is base (dccd9a1) 27.14% compared to head (ccb11fc) 26.99%.

:exclamation: Current head ccb11fc differs from pull request most recent head 4b0438a. Consider uploading reports for the commit 4b0438a to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #728      +/-   ##
==========================================
- Coverage   27.14%   26.99%   -0.15%
==========================================
  Files         130      130
  Lines        3434     3453      +19
  Branches     1209     1216       +7
==========================================
  Hits          932      932
- Misses       2254     2269      +15
- Partials      248      252       +4

Files Changed
Coverage Δ

src/Routes/Devices/Inventory.js
0.00% <0.00%> (ø)

src/utils/apiWithToast.js
3.03% <0.00%> (-0.68%)
:arrow_down:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fixes #373

@f5yacobucci
What issues does this address?
Fixes #373
WIP #
...
What's this change do?
Fixes #373 -- clarifies that the BIG-IP node status will always be NotReady
Where should the reviewer start?
view changes inline
Any background context?
I did include this update in the PR for #314, but I wanted to get this critical fix out there now since that PR is still a WIP.

Good to squash and merge.


Some keybindings no longer assignable (containing [BracketLeft]/[BracketRight])

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.75.0
OS Version: Windows/Linux (both not working)

Steps to Reproduce:
I can no longer bind the following in my keybinding.json:
[
//...
  {
      "key": "ctrl+[BracketLeft]",
      "command": "type",
      "when": "editorTextFocus",
      "args": {
        "text": "{"
      }
  },
//...
]

Previously it was possible to bind this key, but with the current version it no longer works. I have a German keyboard (so "[BracketLeft]" would be the "Ü"-key), but changing the layout to English in OS settings also doesn't help. But according to this comment keyboard layout shouldn't matter anyway when using the [BracketLeft] syntax. Using "key": "ctrl+ü" also doesn't work.

same here,
I try to re assing "ctrl+:" to "editor.action.commentLine" from "breadcrumbs.focus".
If I try to do that, the new shortcut is "ctrl+F3" ("ctrl+[Period]" does the same).
I can't even disable/remove/change breadcrumbs focus (on top of not commenting the line, I now out of the editor and "ctrl+:" do not even bring me back, I have to press esc) it plainly does not work.

I have exactly the same problem as well. When I try to enter cmd+[BracketRight], it inserts "cmd+x". This problem appeared immediately after installing version 1.75.0.

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.75.0. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Ok, @VSCodeTriageBot, I added a ".0" behind "1.75" just for you x)

/duplicate of #173325 which is currently pinned at the top of the Issues page. Upcoming 1.75.1 will fix this.

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


New python API - design document

New Icechunk Python API design
The following is pseudo-code of how a new Python API may look.
Modules
We have different modules for sync and async interfaces. Most zarr users are not used to async
programming, so moving all async methods to a different module optimizes for clarity for the average user.
import icechunk.sync
import icechunk.async
import zarr

We should evaluate making icechunk.sync just icechunk, or some type of alias.
Free functions
import icechunk.sync as icechunk

# TODO: define the types for arguments and return values for these functions
#       in a way that works for all configurations and object stores

storage = .....
icechunk.exists(storage)
repo: Repository = icechunk.create_repository(storage, ...)
repo: Repository = icechunk.open(storage, ...)
repo: Repository = icechunk.open_or_create(storage, ...)

Notice, there is no way to instantiate Repository in read only mode. This is by design, it would make the API more complex for very little value. As we'll see there is the concept of Session that can in fact be read-only.
Repo management
Once we open a Repository by calling open,  create_repository or open_or_create, we can inspect it and manage it.
import icechunk.sync as icechunk

repo = icechunk.open(...)

# exception if snapshot not found
repo.create_branch("dev", "some-snapshot-id")
# exception if snapshot not found
repo.reset_branch("dev", "some-snapshot-id")

# exception if snapshot not found
repo.create_tag("v1.0.5", "some-snapshot-id")

 # returns the sequence of parent snapshot ids including some-snapshot-id
# exception if snapshot not found
repo.ancestry("some-snapshot-id") -> Iterator[str | None]

# returns branch names
repo.list_branches() -> Iterator[str]

# returns tag names
repo.list_tags() -> Iterator[str]

# returns the snapshot id pointed by a ref
# exception if ref not found
repo.get_ref(branch="main") -> str
repo.get_ref(tag="v1.0.5") -> str

Read only sessions
Having a Repository instance allows the creation of read sessions. These are created using the read_session method, and they resolve to a snapshot id at the time of creation. If a branch is reset afterwards, or a tag deleted, the session doesn't change.
import icechunk.sync as icechunk

repo = icechunk.open(...)
# exception if branch/tag/snapshot cannot be found
session = repo.read_session(branch="main")
session = repo.read_session(tag="v1")
session = repo.read_session(snapshot="abcde")

session.ancestry() -> Iterator[str | None]
session.snapshot_id -> str

# Should the session implement a zarr store directly instead?
root = zarr.group(store=session.store)

Write sessions with manual commit
import icechunk.sync as icechunk

repo = icechunk.open(...)

session = repo.write_session("main", "optional commit message")
session.describe("change the commit message")
session.description -> str | None

root = zarr.group(store=session.store)
group = root.create_group("group1")

session.commit() -> "some-snapshot-id" # the commit message can be passed here too
# calls to any session methods will fail after this, with an exception indicating the session is closed

# instead of committing user can also do
session.abandon()
# calls to any session methods will fail after this, with an exception indicating the session is closed

Dangling write sessions
Expert users may want to create new snapshots that are not tracked by any refs. These are, of course, targets for garbage collection, but this property makes them useful for quick tests, experiments and debugging sessions.
import icechunk.sync as icechunk

repo = icechunk.open(...)

session = repo.dangling_session("some-snapshot-id")

root = zarr.group(store=session.store)
group = root.create_group("group1")

session.commit() -> "some-snapshot-id" # the commit message can be passed here too

Write sessions with manual commit and rebase
import icechunk.sync as icechunk

repo = icechunk.open(...)

session = repo.write_session("main", "optional commit message")
try:
  store.commit("create group")
except Conflict as e:
  e.expected_parent -> str | None
  e.actual_parent -> str | None
  # TODO: we need a way to log conflicts
  session.rebase(BasicConflictSolver())
  session.commit("create group")

Write sessions with automatic commit and optional rebase
Sessions used as context managers commit when the context finishes.
with repo.write_session("main", "create group", rebase_with=BasicConflictSolver()) as session:
  session.describe(session.description + " - automatic commit")
  root = zarr.group(store=session.store)
  group = root.create_group("group1")

Distributed writes
TODO

We should add here a way to obtain the nodes from a Session

This is super important stuff Seba. Thanks for getting the conversation started.
Here are some comments.

General design

I really like the separation between Repository, Session, and Store.
I like separate modules from sync and async, rather than mixing them in a single class

Repository object

There are going to be repos that are, in practice, read-only--for example, if the user doesn't have write permissions. With your proposal that "there is no way to instantiate Repository in read only mode," what would happen if a user tries to create a branch? A runtime error?
Is this where you imagine GC and other maintenance functions eventually living?

Session

Overall I like it. There's a reason we have this in Arraylake.
sesion.store is exactly where I think the Zarr store should live
It may be inconvenient that the session expires after it is committed. (For example, this would break some existing demos.) But on consideration, I think this is for the best. There may be mutable Zarr objects floating around still associated with that session. Under this new model, it would be impossible to write to them--they would need to be re-instantiated. I think that's the right move. For example, it would be impossible to do (pseudocode)array = zarr.open(session.store, path="myarray")
array[:] = 1
session.commit()
array[:] = 2  # would error

Instead, the array would have to be re-opened after every commit. Are we okay with this? I think so, but worth discussing.
I really like the session context manager. This is clearly the right pattern for transactions. The only downside is that it may not play well in a distributed write context.

Dangling Write Sessions - I'm not a fan! Isn't this what branches are for? Let's encourage users to create branches liberally.
Rebase API. I really like where you're heading, but I think this API design needs its own dedicated design doc. I'd want to see a lot more examples. Let's first agree on the high-level structure.

Repo management

This whole section looks perfect to me. I strongly support making store represent just the zarr store part of the current API.
I also think the rust should follow the same convention, where a Repository is the entry point and the Store is obtained from the Repository instance. This will make it easier to make storage and settings dynamic.

Read only sessions

What is the distinction between a session and a store? I don't really understand why we need sessions in the first place, so its mostly a context thing on my part.

Instead, the array would have to be re-opened after every commit. Are we okay with this? I think so, but worth discussing.

This seems liek super bad UX to me personally. but maybe i dont understand how it fits into others workflows

@mpiannucci great feedback, some responses inline:

What is the distinction between a session and a store?

Great question. There is not a big difference, but the session could one day do more than the store. For example, we could add callbacks when sessions are created/finished; we could make the sessions persistent (and recoverable); we could add "attributes" like author, process, etc.

thinking about other ACID databases, you are not expected to get a new client after every commit typically

I think of sessions as transactions actually. In fact, that was my initial name for them. Creating a new session must be mostly a NOOP, very very cheap. All the caching happens at the Repository level.

OK I think I am understanding this better. The repository is not checked out to any given ref, instead you create sessions that point at a ref.

Some final notes before implementing:

Rust will now have the Repository, Session, and Store
The python implementation with follow the rust implementation as closely as possible
Users will always open or create a Repository, from which the storage is passed down to sessions.
Sessions and Stores will require being serializable in order to allow for distributed workloads in python.

Questions:

Should we create two different session interfaces, one for Readable and one for Writeable ? Or just one interface with a read_only flag? This would probably mean implementing a trait inheritance where WriteableSession: ReadableSession or something like that

Should we create two different session interfaces, one for Readable and one for Writeable

I think i like that approach, unless you see any complications.


Expose on[event] attributes on prototypes

Twitter Conversation which made me check this.
Looks like we should be exposing on* attributes on our prototypes (Window and HTMLElement and Document): https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects https://html.spec.whatwg.org/multipage/webappapis.html#idl-definitions
Currently we just check if an attribute named on[event] is defined on the element and execute it when triggering the event. We might just be able to fix order of the event trigger too while we're at it (#696).

Any news on this issue ?

@Sebmaster what's the latest on this? I have cherry-picked the "enable tests" commits but all the work here seems great and it would be great to rebase/finish it :)

The problem here was that window is not split into wrapper + impl class which makes mixins really difficult, so I first have to convert window to finish this.

There's got to be a better way to to the body proxy thing. I think it should be possible to do write this in the actual body interface instead of (shittily) detecting this at runtime.

What's the wrapperBody used for @domenic ? Well done on this by the way to you and @Sebmaster.
Coinidentally just finished a similar iteration for mapping on* events from a class to an existing HTMLElement
https://github.com/devpunks/snuggsi/blob/master/elements/global-event-handlers.es#L53-L110

wrapperBody is used to implement a crazy part of the spec where inside an event handler everything on document, the target element, and possibly the target element's form owner is in scope. We do this via a bunch of with statements. Basically it's all about implementing step 10 of https://html.spec.whatwg.org/#getting-the-current-value-of-the-event-handler .


Sprig is not using transactions when loading data

if something breaks when loading fixtures, e.g. because of incompatible DB schema version,
Sprig just bails out -- leaving partial data in the database.
It should use transactions for this

Hey @tilo, quick update: We've started work on this. https://github.com/vigetlabs/sprig/commit/73ef516ab2e0c17a2da774fbe769e6fc5d74ecc4
For now I think we'd like to keep existing behavior by default, but provide the option to wrap the process in a transaction via the configuration block.
We just need to clean some things up, fix up our tests for the Mongoid version of the suite run, and then we'll put this into a release.
Thanks for filing this issue.


ENH: Restore original convert_objects and add _convert

Restores the v0.16 behavior of convert_objects and moves the new
version of _convert
Adds to_numeric for directly converting numeric data
closes #11116
closes #11133

Still a few things to do:
[] Update release notes to remove new docs and add deprecation note
[] Add note about bugs fixed in convert_objects
[] Restore docs for convert_objects
[] Add tests for to_numeric
[] Add docs for to_numeric

The important changes are:
convert in ObjectManager: https://github.com/pydata/pandas/pull/11173/files#diff-e705e723b2d6e7c0e2a0443f80916abfR1521
This change requires this to 'route' to either the old or new style converter.
to_numeric: https://github.com/pydata/pandas/pull/11173/files#diff-40d1f19921aa9f2932951124fad07cc6R53
New function.

@bashtage Really thanks a lot for this!
(I am still not fully convinced the deprecation is needed, but I will try to summarize my reasons tomorrow)

@bashtage

pls move the 2 converting functions either to a new module, core/convert.py.
let's finish up the documentation changes.

pls let me know asap.

Still no tests for to_numeric or docs for this method.

looks good! ping when tests for pd.to_numeric

@jorisvandenbossche ok with this

to_numeric needs some fixes (and tests): lib is not yet imported, lib.maybe_convert_numeric expects an array so it bugs on a series as arg, and the final result needs to be boxed into a series again if the arg was a series.

Yes - it definitely needs work.  It expects something with the buffer
interface, so I need to ensure that this works as expected.
On Sun, Sep 27, 2015 at 8:12 PM Joris Van den Bossche <
<EMAIL_ADDRESS>wrote:

to_numeric needs some fixes (and tests): lib is not yet imported,
lib.maybe_convert_numeric expects an array so it bugs on a series as arg,
and the final result needs to be boxed into a series again if the arg was a
series.
—
Reply to this email directly or view it on GitHub
https://github.com/pydata/pandas/pull/11173#issuecomment-143606211.

@bashtage did you have a chance to add some tests here?

Should be ready when green I think

Can squash commits - wanted to make it easier to see changes at each stage since close to release

@jreback Green - let me know if I missed anything.  Only tick left is to add some docs although this can probably wait since convert_objects is still available.

All addressed

@jreback It is green - or should be since all required tests passed.

@bashtage thanks for all of the work on this!


Error with Permissions (Bukkit)

I have a Bukkit server, and I just installed Permissions. I tried to follow the guide to set up the permissions, but when I started up  my server I got this:
========== UNABLE TO LOAD PERMISSIONS BACKEND =========
Your configuration must be fixed before PEX will enable
Details: Error loading permissions file!
Caused by: org.bukkit.configuration.InvalidConfigurationException: while scanning an anchor
in 'string', line 22, column 16:
prefix: '&0[&4M&cO&4D&0]&r '
^
expected alphabetic or numeric character, but found [(91)
in 'string', line 22, column 18:
prefix: '&0[&4M&cO&4D&0]&r '
^
[12:19:11 INFO]: [PermissionsEx] Disabling PermissionsEx v1.23.4
] Edit by Stormbow: Removed most of the error log, unnecessary stuff. [
This is my permissions file:
] Edit by Stormbow: Moved permissons.yml file contents to Pastebin. [
EDIT: Just realized that when I copied and pasted my permissions file it doesn't show the spacing. I'm not sure how to fix that though.

Your permissions.yml file does not follow this example.
Once your file follows that example, test the server again and post here if you're experiencing continuing PEX problems.

I have tried to model my file after that example now (I have never really done this before, so sorry about the confusion), and I still have an error loading the permission file. This is it now:
groups:
Member:
options:
default: 'true'
build: 'true'
prefix: 'Member '
suffix: ''
rank: '900'
rank-ladder: Main
weight: '900'
inheritance: []
permissions:
-modifyworld.*
-nicknames.nick.self
-iDisguise.help
-iDisguise.undisguise
-iDisguise.mob.chicken
-iDisguise.mob.cow
-iDisguise.mob.llama
-iDisguise.mob.pig
-iDisguise.mob.rabbit
-iDisguise.mob.sheep
-redprotect.user
-redprotect.own.tp
-clearchat.clearmychat
Mod:
options:
default: 'false'
build: 'true'
prefix: 'Mod '
suffix: ' the Scary'
rank: '200'
rank-ladder: Main
weight: '200'
inheritance:
- Member
permissions:
-iDisguise.mob.creeper
Admin:
options:
default: 'false'
build: 'true'
prefix: '&0[&4M&cO&4D&0]&r '
suffix: ' the Awesome'
rank: '100'
rank-ladder: Main
weight: '100'
inheritance:
- Mod
permissions:
-permissions.*
-nicknames.nick
-nicknames.lookup
-iDisguise.help
-iDisguise.*
-redprotect.*
-clearchat.*
Owner:
options:
default: 'false'
build: 'true'
prefix: '&0(&8D&7R&8A&7G&8O&7N&0)&r '
suffix: ' the Almighty'
rank: '1'
rank-ladder: Main
weight: '1'
inheritance:
- Admin
permissions:
-permissions.*
-nicknames.nick
-nicknames.lookup
-iDisguise.help
-iDisguise.*
-clm.admin
-redprotect.*
-clearchat.*
-''
schema-version: 1
users:
Zodwin:
group:
- Owner
permissions:
-permissions.
-nicknames.nick
-nicknames.lookup
-iDisguise.help
-iDisguise.*
-clm.admin
-redprotect.*
-clearchat.*
WyrmWizard:
group:
- Admin
permissions:
-permissions.*
-nicknames.nick
-nicknames.lookup
-iDisguise.help
-iDisguise.*
-redprotect.*
-clearchat.*
QueenDragonling:
group:
- Admin
permissions:
-permissions.*
-nicknames.nick
-nicknames.lookup
-iDisguise.help
-iDisguise.*
-redprotect.*
-clearchat.*
JediWolfBook:
group:
- Admin
permissions:
-permissions.*
-nicknames.nick
-nicknames.lookup
-iDisguise.help
-iDisguise.*
-redprotect.*
-clearchat.*
Some things I thought might be causing the problem:
-Do I have options and then name section under users? I have a nickname plugin installed and was not sure if that would mess up the nicknames

Your permission nodes are still wrong.  It's not
-permission.node
It is
- permission.node

The plugin now loads up correctly. Do I have to have a different plugin installed to allow chat prefixes/suffixes to show up in chat?

Yep.  You need a chat management plugin.
Since almost everyone runs Spigot servers, they use EssentialsX for the basic server commands, and EssentialsXChat handles their chat management features (prefixes, suffixes, chat coloring).

Should I switch to a Spigot server, or would I be able to run those same plugins on my Bukkit server?

Technically, "Bukkit" (and "CraftBukkit") was discontinued at Minecraft 1.8 because one of the contributors was a total dickhead and claimed copyright infringement against everyone else on the project for using the code he contributed.  Some people are updating it, but I can't testify to them being any good at it since I don't use them, so I can't technically recommend using either "Bukkit" or "Craftbukkit".
Spigot, on the other hand, is created by a group that has taken precautions against the copyright bullshit that the other author pulled on Bukkit, so I expect it will be around and updated properly for a very long time.  I'm also running Spigot on my 1.11.2 server, so I can say it works properly.
The choice of server wrapper (which is what "Bukkit", "Craftbukkit", "Spigot", and others are called) is entirely up to you...

Could I use the same Permissions jar file and permissions file that I already have if I switch to Spigot? Or would I have to rewrite them?

You can keep those if you use Spigot.

Ok thanks! Gonna go ahead and close the thread now (and switch to Spigot)

You will want to make sure any plugins you're using are compatible with Spigot.  (The EssentialsX I linked to you is too, of course.)
You're welcome.  Have fun!

You can find all the Spigot-specific plugins right here.


Windows otel

Purpose of this pull request
This pull request (PR) ...
Issue number:

Select the type of change:

[ ] Minor Changes - Typos, formatting, slight revisions
[ ] Update Content - Revisions and updating sections
[x] New Content - New features, sections, pages, tutorials
[ ] Site and Tools - Updates, maintenance, and new packages for the site, Gatsby, React, etc

Thanks John. I have incorporated your comments.


[Bug] copies only '-' in clipboard when trying to copy a JWT

Overview

Insomnia Version: 5.7.11
Operating System:  Win 7
Summary:

I am getting a JSON containing a JWT from a POST, a try to copy a part of it into the clipboard. When trying to paste into some editor, all I get is one character '-'. However, when I switch to RAW, then I can copy successfully. And, in Preview or Source, when I doubleclick on some string part´, and some part gets selected, it also works fine. Just when I select with my mouse by pressing, holding, moving and letting go - it dows not work.
How To Reproduce
I try to get a token from keycloak, but I suppose this behaviour is not dependent on keycloak at all.

Create new request to keycloak or something that gives a JSON with an JWT in it.
In my case its a POST to http://server/auth/realms/MyRealm/protocol/openid-connect/token
Perform a request which returns a valid JSON
try to copy a access_token data to clipboard
paste it in any editor

This is a duplicate of #430

@SergejKern will try to deploy the fix for this today.


Luxonis filesystem

First implementation of LuxonisFilesystem which abstract how we deal with paths (local and remote)

Added option to load pretrained (model or backbone) weights from local, s3 path or existing mlflow project
Callbacks:

ExportOnFinish - automatically start export when training is finished, if override_upload_directory is set and MLFlow run active then use that for upload (Note: only if upload is active in Exporter block)
UploadCheckpointOnFinish - Uploads best checkpoint to sepcified remote storage (local, s3, existing MLFlow run or current MLFlow run if active)

Exporter can upload files to remote storage by setting upload.upload_directory to S3 or existing MLFlow run

Note: Should update luxonis-ml version again after this PR is merged so we depend mainly on dev/main versions (not from version on other branches)

Just a quick explanation: s3fs dependency comes from fsspec when using s3 protocol and it is not directly imported anywhere, fsspec uses it in the background.

@conorsim Yeah I think making this work for more general cases and moving it to luxonis-ml is a good idea as it could also nicely abstract functions in s3_utils.py. But  currently it is a bit "finetuned" to models usecase, especially because of how we need to handle mlflow live vs existing runs. So it would need a bit of brainstorming and refactoring before it is ready for luxonis-ml

Separated forward() and forward_deploy() where applicable
Added callback that checks if all required annotations are present at the beginning of train, val and test loop


add missing connection() method to doc-block

Thanks!

Thanks!

Thanks for fixing and merging this fast! 🚀

Thanks for fixing and merging this fast! 🚀


Removes android applinks related vm services and updates gradle task to dump file instead

Since applink validation tool is going to be a static tool, It won't have access to vmservices.
flutter.dev/go/static-tooling-in-devtools
I remove the vm services and also update the deeplink task to also include path pattern and custom scheme
http://go/android-applink-apis (internal only)
Pre-launch Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I read the Tree Hygiene wiki page, which explains my responsibilities.
[ ] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[ ] I signed the CLA.
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is test-exempt.
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Hi @christopherfujino Can you take a look first before I add test for analyzer?


2 prefixes

Hello, I would like to know how I can put 2 rank prefix as "[A]" and Modetateur "[Moderator]" I try Essential Chat but its not work, I use Chatex but its function has one day and when a player speaks the other player does not see it as the example image:  Clic here

ChatEx isn't supported by PEX— none of the 'ChatManager' clones and offshoots are —so you'd need a different chat management plugin to handle what you're after.  EssentialsChat and EssentialsXChat won't do it either since they're both setup to use one prefix, as far as I've ever seen.  Beyond that, you're on your own, unfortunately.


Actually delete configmaps and secrets

Bug in https://github.com/kubernetes/perf-tests/pull/1822, the step that is supposed to delete configmaps and secrets in fact no-op patches them.
/assign @marseel

/lgtm

/lgtm


add knip

chore: remove dependency-cruiser
chore: add knip
chore: fix prepare script

#222
#221  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


How to Contact

Hello, I would like to get in touch with you, do you have a discord or telegram?
Thanks

Hey you can add me on discord:
ع˖⁺ ☁ 𝐉𝐮𝐧𝐚𝐢#0622

Junai#622

You are missing a number    Junai#622 doesn't exist

Junai# 0622, idk why github is deleting the 0


Alert manager goes from Firing->Resolved->Firing

What did you do?
Started the prometheus followed by the alert manger.
What did you expect to see?
Expect to see alerts go off once everyday unless they are resolved for some time and then became firing again.
What did you see instead? Under which circumstances?
I only use alert manager(for now) to monitor if machine is down/up and if any disk locations I monitor goes above threshold . At first I only had disk usage being alerted. At which point, I was getting notifications all the time during the day, my disk space issue is resolved , but then couple of minutes later, it became firing again. I thought this is because the usage was very close to the threshold level.  And it might have resolved for some time. But then I started monitoring machine up/down status as well, I started getting alerts saying machines being down resolved. But these are machines that does not even have the prometheus exporter running. So they were never up/resolved.
So the problem is alert manager goes from  Firing->Resolved->Firing often. I think it has to do with alert manager itself.
Environment

System information:
insert output of uname -srm here: Linux 4.15.0-20-generic x86_64

Alertmanager version:

alertmanager, version 0.15.2 (branch: HEAD, revision: d19fae3bae451940b8470abb680cfdd59bfa7cfa)
  build user:       root@3101e5b68a55
  build date:       20180814-10:53:39
  go version:       go1.10.3

Prometheus version:

prometheus, version 2.2.1 (branch: HEAD, revision: bc6058c81272a8d938c05e75607371284236aadc)
  build user:       root@149e5b3f0829
  build date:       20180314-14:15:45
  go version:       go1.10

Alertmanager configuration file:

global:
  slack_api_url: 'https://hooks.slack.com/services/notTheRealDealBoi'
templates:
- '/etc/alertmanager/template/*.tmpl'
- './slack_title.tmpl' # This is the custom template we wrote

# The root route on which each incoming alert enters.
route:
  # The labels by which incoming alerts are grouped together. For example,
  # multiple alerts coming in for cluster=A and alertname=LatencyHigh would
  # be batched into a single group.
  group_by: ['instance', 'alertname']

  # When a new group of alerts is created by an incoming alert, wait at
  # least 'group_wait' to send the initial notification.
  # This way ensures that you get multiple alerts for the same group that start
  # firing shortly after another are batched together on the first
  # notification.
  #group_wait: 30s

  # When the first notification was sent, wait 'group_interval' to send a batch
  # of new alerts that started firing for that group.
  group_interval: 1m

  # If an alert has successfully been sent, wait 'repeat_interval' to
  # resend them.
  repeat_interval: 24h

  receiver: machine-status-slack-notifications # Default receiver

  routes:
  - match:
      alertname: gsa-fs-threshold
    receiver: gsa-disk-usage-slack-notifications
  - match:
      alertname: fs-threshold
    receiver: disk-usage-slack-notifications
  - match:
      alertname: machine-down-in-canlab
    receiver: machine-status-slack-notifications
  - match:
      alertname: machine-down-not-in-canlab
    receiver: machine-status-slack-notifications

receivers:
- name: 'disk-usage-slack-notifications'
  slack_configs:
   - channel: '#prometheus_alerts'
     title: '{{ template "slack.mytitle.disk.text" . }}'
     title_link: 'http://foo.different.comcom:3000/dashboard/db/machine-stats-single-page-build-disk-test?var-machine={{ .GroupLabels.instance }}'
     text: '{{ template "slack.desc.disk.text" . }}'
     send_resolved: true
- name: 'gsa-disk-usage-slack-notifications'
  slack_configs:
   - channel: '#prometheus_alerts'
     title: '{{ template "slack.mytitle.gsa.text" . }}'
     title_link: 'http://foo.different.comcom:3000/dashboard/db/machine-stats-single-page-build-disk-test?var-machine={{ .GroupLabels.instance }}'
     text: '{{ template "slack.desc.gsa.text" . }}'
     send_resolved: true
- name: 'machine-status-slack-notifications'
  slack_configs:
   - channel: '#prometheus_alerts'
     title: '{{ template "slack.mytitle.text" . }}'
     title_link: 'http://foo.different.com:3000/dashboard/db/machine-stats-single-page-build-disk-test?var-machine={{ .GroupLabels.instance }}'
     text: '{{ template "slack.desc.text" . }}'
     send_resolved: true

# Inhibition rules allow to mute a set of alerts given that another alert is
# firing.
# We use this to mute any warning-level notifications if the same alert is
# already critical.
#inhibit_rules:
#- source_match:
#    severity: 'critical'
#  target_match:
#    severity: 'warning'
  # Apply inhibition if the alertname is the same.
  #  equal: ['alertname']

Prometheus configuration file:

i# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 5m # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - localhost:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  - "alerts.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  #

  # metrics_path defaults to '/metrics'
  # scheme defaults to 'http'.

  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'general'
    static_configs:
      - targets: ['lorem.ipsum.com:1337']
      - targets: ['bar.foo.bar:1337']
      - targets: ['foo.bar.com:1337']
      - targets: ['localhost:1337']

Logs:

Alertmanager logs.

level=info ts=2018-09-07T20:22:14.013605369Z caller=main.go:174 msg="Starting Alertmanager" version="(version=0.15.2, branch=HEAD, revision=d19fae3bae451940b8470abb680cfdd59bfa7cfa)"
level=info ts=2018-09-07T20:22:14.013710082Z caller=main.go:175 build_context="(go=go1.10.3, user=root@3101e5b68a55, date=20180814-10:53:39)"
level=info ts=2018-09-07T20:22:14.047249055Z caller=cluster.go:155 component=cluster msg="setting advertise address explicitly" addr=<IP_ADDRESS> port=9094
level=info ts=2018-09-07T20:22:14.051230665Z caller=cluster.go:570 component=cluster msg="Waiting for gossip to settle..." interval=2s
level=info ts=2018-09-07T20:22:14.051244997Z caller=main.go:322 msg="Loading configuration file" file=simple_new.yml
level=info ts=2018-09-07T20:22:14.059479976Z caller=main.go:398 msg=Listening address=:9093
level=info ts=2018-09-07T20:22:16.053277255Z caller=cluster.go:595 component=cluster msg="gossip not settled" polls=0 before=0 now=1 elapsed=2.00019006s
level=info ts=2018-09-07T20:22:24.058948881Z caller=cluster.go:587 component=cluster msg="gossip settled; proceeding" elapsed=10.005876805s

Ok, sorry for the late reply, I will try that today.

Totally forgot to get back, this solved the problem evaluation_interval: 1m helped.

This has been frustrating, How can a simple thing like this be broken. My configs have not changed other than the config evaluation_interval: 5m -> evaluation_interval: 1m . But the issue came back after couple of days. It is still giving out false alerts and then going back to Firing. Since you mentioned above whatever issue was fixed on the latest prometheus . I have updated both prometheus and alert-manager. But the issue is still there.
I have never mentioned my alerts config may be that's relevant too ?
groups:
    - name: test
      rules:
          - alert: fs-threshold
            expr: ceil(fs_used_p) > fs_thresh
            for: 10m
            labels:
                severity: critical
                slack: "{{ range printf `avg_over_time(notif_info{instance=\"%s\"}[10m])` $labels.instance | query }}{{.Labels.slack}}{{ end }}"
                mount: "{{ $labels.mount }}"
                used_percentage: '{{$value}}' # This is the fs_used_p value
          - alert: main_mount-fs-threshold
            expr: ceil((main_mount_used/main_mount_total)*100) > main_mount_thresh*100
            for: 10m
            labels:
                severity: critical
                email: '{{$labels.email}}'
                slack: '{{$labels.slack}}'
                used_percentage: '{{$value}}' # This is the main_mount_used/main_mount_total eval

          - alert: machine-down-in-lab
            expr: avg_over_time(up{instance=~".*lab.*"}[15m]) < 0.5
            for: 10m
            labels:
                severity: critical
                slack: "{{ range printf `avg_over_time(notif_info{instance=\"%s\"}[10m])` $labels.instance | query }}{{.Labels.slack}}{{ end }}"
            annotations:
                summary: "Machine went down please fix {{$labels.instance}}"
          - alert: machine-down-not-in-lab
            expr: avg_over_time(up{instance!~".*lab.*"}[20m]) < 0.2
            for: 10m
            labels:
                severity: critical
                slack: "{{ range printf `avg_over_time(notif_info{instance=\"%s\"}[10m])` $labels.instance | query }}{{.Labels.slack}}{{ end }}"
            annotations:
                summary: "Machine went down please fix {{$labels.instance}}"

It is still giving out false alerts and then going back to Firing.

I don't get it. Can you give more details about what's going on?
I see that the slack label values in the alerts use a Prometheus query. If the value of this label changes over time then it would explain why you get flapping alerts as the identify of an alert is defined by its label names/values.

The problem is still the same old problem

I only use alert manager(for now) to monitor if machine is down/up and if any disk locations I monitor goes above threshold . At first I only had disk usage being alerted. At which point, I was getting notifications all the time during the day, my disk space issue is resolved , but then couple of minutes later, it became firing again. I thought this is because the usage was very close to the threshold level. And it might have resolved for some time. But then I started monitoring machine up/down status as well, I started getting alerts saying machines being down resolved. But these are machines that does not even have the prometheus exporter running. So they were never up/resolved.

I will experiment with slack query today to see if that helps

@simonpasquier Those slack query slack: "{{ range printf avg_over_time(notif_info{instance="%s"}[10m]) $labels.instance | query }}{{.Labels.slack}}{{ end }}" ends up being the slack handle of the person who is being pinged. This never changes on the custom exporter data. So I don't think its that.

I have updated that to 20 mins to see if that fixes anything

Didn't help

I have updated that to 20 mins to see if that fixes anything

Didn't help

Just an idea. Try checking time on all of your cluster nodes. I have a suspicion that not having NTP installed may be causing similar behaviour for me.
KUBE01 | SUCCESS | rc=0 >>
16:56:21 up 6 days,  5:31,  1 user,  load average: 0.31, 0.35, 0.46
KUBE02 | SUCCESS | rc=0 >>
16:55:20 up 21 days,  4:51,  1 user,  load average: 0.67, 0.84, 1.32
KUBE03 | SUCCESS | rc=0 >>
16:57:37 up 80 days, 23:52,  1 user,  load average: 0.69, 0.45, 0.41

Check the time and then what ? I gotta make the time exactly the same on every machine ?

This has turned into support rather than a feature request/bug report, it would be best if this was continued on the mailing list<EMAIL_ADDRESS>to reach a wider audience that may have similar issues.

Check the time and then what ? I gotta make the time exactly the same on every machine ?
Yes, that's what NTP is for.

You could get by by deploying prometheus-server and alertmanager on same node, but that's a dirty solution.
If time is the issue here, then I think this issue can be closed?

I'm having this issue too.  I have an alert based on the probe_ssl_earliest_cert_expiry metric from the blackbox exporter.  It is supposed to let us know when an ssl certificate is within 30 days of expiring.

The above grafana graph shows the alert going from:

Firing
Both firing and pending
Just pending (triggering a resolve)
Firing again (triggering a notification).

I don't understand how the same alert can be both pending and firing, nor why the alert would resolve while there is a value within the alert threshold.  AlertManager and Prometheus aren't guaranteed to be on the same computer, but they are using ntp so the clocks should be very close to each other.  The alert originally was based on the raw blackbox exporter metric and time() ( probe_ssl_earliest_cert_expiry{job="blackbox"} - time()  < 86400 * 30 ), but I thought maybe the math and magic time() timeseries might be causing evaluation issues, so I created a recording rule and changed the alert to be based off the recorded metric and that didn't fix it.
The relevant portions of our prometheus configuration
prometheus.yml
---
global:
  scrape_interval:     15s # By default, scrape targets every 15 seconds.
  evaluation_interval: 15s # By default, scrape targets every 15 seconds.

rule_files:
  - "/etc/prometheus/rules.d/*.rules"

scrape_configs:
  - job_name: 'blackbox'
    scrape_interval: 15s
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - URL_REDACTED

rules.d/recording.rules:
---
  - name: ssl_cert_expiration_calculations
    rules:
    - record: instance:probe_ssl_earliest_cert_expiry:delta
      expr: probe_ssl_earliest_cert_expiry{job="blackbox"} - time()

rules.d/platform.rules:
groups:
  - name: Platform
    rules:
      - alert: SSLCertExpiringSoon
        expr: instance:probe_ssl_earliest_cert_expiry:delta < 86400 * 30
        for: 10m
        labels:
          alert_slack_channel: "platform-alerts"
        annotations:
          summary: "[[ deploy_env ]]: {{ $labels.instance }} has an SSL cert expiring soon."
          description: "[[ deploy_env ]]: {{ $labels.instance }} has an SSL cert expiring within 30 days."

I've updated the alert expr to be min_over_time(instance:probe_ssl_earliest_cert_expiry:delta[10m]) < 86400 * 30 and moved alertmanager to the same machine as prometheus and I'm still getting the above alert behavior.

@cconstantine commenting on an old issue isn't the most efficient way. Please send a message with all details to our user mailing list. I'll follow up there.

I've replied here because the issue is still open, and I believe this is a bug in prometheus/alertmanager.
I'll send a message to the mailing list, but if this behavior isn't considered a bug, could this issue be closed?

+1

I suddenly started seeing the same problem in our setup and get flooded with Firing-Resolve-Firing-... notifications for some periods of time, even though the metrics on the Prometheus server are not changing over that timeframe.
In our case the rhythm of the notifications is one every 5 minutes (e.g. a cycle of Firing-Resolve takes 10 minutes). When looking at Alertmanager, the start time of the alert remains static, the end time is set and cleared though, like that:
04:11 UTC: Firing Start 04:10 UTC, End none
04:16 UTC: Resolve Start 04:10 UTC, End 04:15 UTC
04:21 UTC: Firing Start 04:10 UTC, End none
04:25 UTC: Resolve Start 04:10 UTC, End 04:25 UTC

For this specific flooding occurrence, it stopped after a last (correct) firing message:
09:51 UTC: Resolve Start 04:10 UTC, End 09:51 UTC
09:56 UTC: Firing Start 04:10 UTC, End none

This has happened with different alerts so far so it does not seem to be tied to a specific alert. Also, I have not observed this until recently and so far only with V0.20.0 (but we skipped some versions). Unfortunately I don't have logs right now but I could try to produce some if required.
The setup is pretty simple; one server with both Prometheus and Alertmanager (not clustered), therefore this should not be related to time issues. Also the fact that the alert start time does not shift points more towards a problem in the notifications part.
Config (without global, receivers and templates):
route:
  receiver: 2FEV8TB5
  group_by:
  - alertname
  - host
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h

Version information:
Revision: f74be0400a6243d10bb53812d6fa408ad71ff32d
Version: 0.20.0

@avonwyss the 5 minutes interval comes from group_interval. I suspect that it is Prometheus generating firing/resolved alerts. One way to troubleshoot is to look at the ALERTS timeseries at the time when the problem happens.

@simonpasquier Thank you for the hint, I'll have a look the next time it occurs. However, if it was Prometheus, shouldn't the start time be reset? This made me think it was in the Alertmanager.

I'm having the issue too...

I'm having the issue too...

There can be multiple reasons for this. If you have evidence that this is actually the same issue, then I suggest providing some more information (e.g. details of the ALERTS series, your configs). Otherwise I suggest posting to the mailing list to work out the details and see if there is some configuration issue (such as a bad HA configuration, dynamically changing labels or flapping expressions).

@hoffie - certainly. I setup deadmanswitch to test it
Here's the output in Slack -

prometheusAPP 22:54
ERROR : Prometheus AlertManager E2E dead man switch (instance )
Prometheus DeadManSwitch is an always-firing alert. It's used as an end-to-end test of Prometheus through the Alertmanager.
VALUE = 1
LABELS: map[]
Details:
• alertname: PrometheusAlertmanagerE2eDeadManSwitch
prometheusAPP 22:53
ERROR : Prometheus AlertManager E2E dead man switch (instance )
Prometheus DeadManSwitch is an always-firing alert. It's used as an end-to-end test of Prometheus through the Alertmanager.
VALUE = 1
LABELS: map[]
Details:
• alertname: PrometheusAlertmanagerE2eDeadManSwitch
prometheusAPP 22:48
RESOLVED : Prometheus AlertManager E2E dead man switch (instance )
Prometheus DeadManSwitch is an always-firing alert. It's used as an end-to-end test of Prometheus through the Alertmanager.
VALUE = 1
LABELS: map[]
Details:
• alertname: PrometheusAlertmanagerE2eDeadManSwitch
prometheusAPP 22:31
ERROR : Prometheus AlertManager E2E dead man switch (instance )
Prometheus DeadManSwitch is an always-firing alert. It's used as an end-to-end test of Prometheus through the Alertmanager.
VALUE = 1
LABELS: map[]
Details:
• alertname: PrometheusAlertmanagerE2eDeadManSwitch

Here's the alertmanager config -
route:
  receiver: 'THE-notify'
  group_by: ['instance', 'alertname', 'product', 'cluster']
  group_wait: 30s
  group_interval: 1m
  repeat_interval: 3h

  routes:
  - match_re:
      service: (?i)(ssl-expire|service-down|prometheus)\S+
    receiver: THE-notify
    group_by: [instance, alertname, cluster, product]
    routes:
    - match:
        severity: error
      receiver: THE-pager
    - match:
        severity: critical
      receiver: THE-pager

I believe it's coming in over the fallback route, since it doesn't match anything else.
Here's the prometheus alert rule -
      - alert: PrometheusAlertmanagerE2eDeadManSwitch
        expr: vector(1)
        for: 5m
        labels:
          severity: error
        annotations:
          summary: "Prometheus AlertManager E2E dead man switch (instance {{ $labels.instance }})"
          description: "Prometheus DeadManSwitch is an always-firing alert. It's used as an end-to-end test of Prometheus through the Alertmanager.\n  VALUE = {{ $value }}\n  LABELS: {{ $labels }}"

What other information would you like?
I'm nearly positive that this is a mis-configuration on my part (semi-new to prometheus), but I cannot find it for the life of me.

I have multiple areas where this appears to be happening, but I figured the best way to test it was to setup an alert that would always fire, and then see if I received notifications more often than every 3hrs, or if I received any Resolved messages... I did (shown above)

@nirgilboa You experienced a different issue. In the setups where all is on the same machine (Prometheus and Alertmanager) there cannot be a time issue, and the rhythm of the firing/resolve is not random when the issue occurs. So yes time needs to be in sync for alerts to be reliable, but there is still a bug around which causes these incorrect resolve and re-alert to happen.

I'm experiencing the exact same thing using blackbox. How is this still an issue?

I'm experiencing the exact same thing using blackbox. How is this still an issue?

I suspect two things:

This Github issue's title describes a symptom which can be caused by lots of things. Unsynchronized time in clustered setups, staleness due to too long scrape or evaluation times (>2m), changes in alert labels, etc.
Lots of people seem to be running Prometheus/Alertmanager without this issue, therefore, most people would not know how to reproduce/fix this.

@shadow9911 and anybody else still seeing this issue: Can you post to the prometheus-users mailing list and provide the following information?

Prometheus version
Alertmanager version
The result of the Prometheus query ALERTS[1h] (maybe limited to the alertname= you are looking at)
Alertmanager logs (debug level, if possible)
A description of alertmanager behavior (e.g. example firing/resolve messages)
Prometheus config, including the relevant alert rules and scrape configs
Alertmanager config
The best thing would be if someone managed to come up with some self-contained example which demonstrated the issue. I understand that this is often not possible, sadly.

Same problem and same bug : firing, resolved, firing.
I search an entire long day, and decide to downgrade prometheus.
And boum, its working again !
I have downgrade to 2.4.2
Same configuration, same files.
So it's clearly a bug.


Video conferencing integrations

Automatically add Zoom, Google Meet, Microsoft Teams, etc. meeting links when a user finalises the meeting time.

Please prioritize Free/Libre/Open tools, not just include but put them first and label them as being FLO so that people can see the distinction between those and proprietary options. meet.jit.si being the dominant one to suggest at this time.

Good point, thanks!

Closing since we want to keep Kukkee as simple as possible.


cmd-ref: document dvc cache migrate --dvc-files

You may disregard these recommendations if you used the Edit on GitHub button from dvc.org to improve a doc in place.

❗ Please read the guidelines in the Contributing to the Documentation list if you make any substantial changes to the documentation or JS engine.
🐛 Please make sure to mention Fix #issue (if applicable) in the description of the PR. This causes GitHub to close it automatically when the PR is merged.
Please choose to allow us to edit your branch when creating the PR.
Thank you for the contribution - we'll try to review it as soon as possible. 🙏
Docs PR for https://github.com/iterative/dvc/pull/10007

Looks good. Can we also add a section in the upgrade guide about it?


Document precisely how lists (flattening, different types of them) work in Perl 6

The problem
Currently we have mixed bunch of solutions to specific things users want to do and bits of information and some flavor text.
We need clear reference documentation on how things work.
Suggestions
We need clear and precise detailed documentation of how exactly things work.
The cookbook part would preferably be separate.

Thanks a lot for raising this issue.
Can you please clarify? We have this tutorial, as well as the reference. Do you mean that the tutorial leaves some parts unexplained?


Show current replica count when using kubectl get scaledobject

Show current replica count when using kubectl get scaledobject.
Use-Case
This allows operators to easily learn what the current count is for scaled objects.

We would need to poke HPA every time to check so not worth the resources


Implement endpoint to run experiment files.

Also it's most likely my fault that it's in there in the first place but we should delete elephant_vending_machine/static/experiments/empty.py , it was just used for manual testing and I missed it with the .gitignore


populate repeats id's in query

I turned on debug on mongoose and noticed that a find query with multiple results which does populate will send a populate query to mongo with many repeating ids.
It would be better to first make the list unique before sending out, and then use the same referenced document for populating the referring doc path. This would also be correct from the "sql-join" perspective as the referenced document is the same one.
details:
this is with mongoose version 3.8.22.
my schema is using a simple ref, something like in the populate example but with ObjectId:
var mongoose = require('mongoose')
  , Schema = mongoose.Schema

var personSchema = Schema({
  name    : String,
});

var storySchema = Schema({
  genre    : String,
  creator : { type: Schema.Types.ObjectId, ref: 'Person' },
});

var Person = mongoose.model('Person', personSchema);
var Story  = mongoose.model('Story', storySchema);

The query is returning multiple Stories and populates their creator:
Story.find({genre: /fantasy/}).populate('creator')

and the sample from debug log is (in the above example J.R.R Tolkien's id will repeat several times)
Mongoose: persons.find({ _id: { '$in': [ ObjectId("54d8be49b60318713e92f014"), ObjectId("54d8be49b60318713e92f010"), ObjectId("54d8be49b60318713e92f011"), ObjectId("54d8be49b60318713e92f012"), ObjectId("54d8be49b60318713e92f013"), ObjectId("54d8be49b60318713e92f014"), ObjectId("54d8be49b60318713e92f014"), ObjectId("54d8be49b60318713e92f012"), ObjectId("54d8be49b60318713e92f013"), ObjectId("54d8be49b60318713e92f010"), ObjectId("54d8be49b60318713e92f011"), ObjectId("54d8be49b60318713e92f014"), ObjectId("54d8be49b60318713e92f012"), ObjectId("54d8be49b60318713e92f013"), ObjectId("54d8be49b60318713e92f010"), ObjectId("54d8be49b60318713e92f011"), ObjectId("54d8be49b60318713e92f014"), ObjectId("54d8be49b60318713e92f012"), ObjectId("54d8be49b60318713e92f013"), ObjectId("54d8be49b60318713e92f010"), ObjectId("54d8be49b60318713e92f011"), ObjectId("54d8be49b60318713e92f014"), ObjectId("54d8be49b60318713e92f012"), ObjectId("54d8be49b60318713e92f013"), ObjectId("54d8be49b60318713e92f010"), ObjectId("54d8be49b60318713e92f011"), ObjectId("54d8be49b60318713e92f014"), ... ] } }) { fields: undefined }

I don't necessarily think the same referenced document is a good approach, but I do agree that making the list unique is a good idea.

@vkarpov15 Great! Your comment made me realize that it might be confusing to link to the same referenced document unless explicitly desired by the application.
In many of my case this is actually making a lot of sense because I only want the populated document to fetch query data, and not to use as a real fully-featured document.
Can this case be opt-in with a populate option? maybe something like "dedupDocs"?

I'm not sure I understand your use case. Can you tell me more about what you're trying to do?

sure, in one case I have a file-system-like structures with files and folders as mongo documents.
a file refers to its parent folder (also folders do so).
when I query the files I populate the parent to get it's name and other attributes to return to my front-end.
this case is repeating in more relations.
in this case it would be great to just get a folder document once per all the files that have the same parent in the query.
makes sense?

:+1:

Fair warning, will only work for ObjectIds, strings, and numbers for now. Won't bother with deep equality checks for objects unless somebody really wants it, so you will still get dups if your _id is an object. On the other hand, there are probably other bugs inherent to having object _ids in mongoose, so probably not a big concern :)


Generic And and Or verification steps

Current dependencies on/for this PR:

main

PR #1

PR #2   👈

This comment was auto-generated by Graphite.

@jcape my next go at the And and Or logic is up now with https://github.com/mobilecoinfoundation/attestation/pull/2/commits/1507cc14399a4144a97875e4c9a43bdf3f2593e6

@awygle bumped you for a review since this had changed significantly since when you reviewed it


JSR 339 3.2 and Enums

Support for #59 and #50
There is a failing test ProjectAnalyzerTest that has arisen but I'm not sure why it's suddenly appearing.
Appears related to the mocked JobRegistry in SubResourceLocatorMethodContentAnalyzerTest not getting cleaned up properly.

ping @sdaschner

Sorry for being unresponsive, I'm having a look and'll merge it this weekend the latest. Thanks once again for your efforts!

Update: So I've already merged the PR in my working copy, but I have to adapt a few things. I found out after thinking about it that we want to decouple the logic of the enum values from the backend to the analysis time. So I'm currently changing the MethodParameter to include more information about the type (not only the String type) -- which can then be used in all backends. But this changes a lot more internally (tests etc.). I'm planning to push that in the next days.
However, stay tuned :-)

No problems =) i'll just keep poking until results arrive :P

Finally ;-)


[1.16] Black Hole Unit Destroyed My Soul

Hello,
The Supreme Black Unit rolls over to -2.14 billion when full and the Void when full option is enabled.
Industrial Foregoing Version:
industrial-foregoing-1.16.5-3.2.11-55cb112
Titanium Version:
titanium-1.16.5-<IP_ADDRESS>
Crashlog If Applicable (Upload to pastebin/gist):

https://clips.twitch.tv/HandsomeLachrymoseLionOhMyDog-PvzYMoXjdkrzbLqq
https://clips.twitch.tv/IntelligentHumbleEggnogStrawBeary-tkCYaZHvYfWQV2BW

On a more serious note, this issue seems to be related to the Void when full option/button in the GUI. If voiding items is disabled, the Supreme Black Hole Unit will not roll over to -2.14billion. It seems the simplest solution is to remove the Void button and set the black hole unit to not void by default.
For any players who happen to see this issue, when placing a Supreme Black Hole Unit disable the Void when full option in the GUI.

Pretty sure the error is here. inserted is not bounds checked after the assignment.
https://github.com/InnovativeOnlineIndustries/Industrial-Foregoing/blame/073b88205eb7b41a8dac23dab94312f3bf9f080e/src/main/java/com/buuz135/industrial/capability/BLHBlockItemHandlerItemStack.java#L61


ECS reformat support for Tomcat

Makes Tomcat logging (which relies on java.util.logging) work with ECS reformatting.
Checklist

[x] This is an enhancement of existing features, or a new feature in existing plugins

[ ] I have updated CHANGELOG.asciidoc
[x] I have added tests that prove my fix is effective or that my feature works
[ ] Added an API method or config option? Document in which version this will be introduced
[x] I have made corresponding changes to the documentation

:grey_exclamation: Build Aborted

There is a new build on-going so the previous on-going builds have been aborted.

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-10-10T13:17:12.485+0000

Duration: 17 min 12 sec

:robot: GitHub comments
Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.

run benchmark tests : Run the benchmark tests.

run jdk compatibility tests : Run the JDK Compatibility tests.

run integration tests : Run the Agent Integration tests.

run end-to-end tests : Run the APM-ITs.

run windows tests : Build & tests on windows.

run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)


merge package template from arlac77/npm-package-template

Updated standard to latest version

Coverage decreased (-0.8%) to 80.429% when pulling 56e30e76800a49773c0997530a7e300a5a944700 on template-sync-1 into 695fedb0043b5564821039c00dbc2222bb32c147 on master.

Codecov Report

Merging #90 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #90   +/-   ##
=======================================
  Coverage   81.25%   81.25%
=======================================
  Files          14       14
  Lines          96       96
=======================================
  Hits           78       78
  Misses         18       18

Continue to review full report at Codecov.

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