master's websocket::stream::async_read() gets confused when handlers with similar signatures are available

Using Boost 1.69 this example compiles. But using Boost b2e37d03b4aa23f8add2ce3dd37d3041c19591d2 it fails with:
/include/boost/beast/core/async_base.hpp:351:13: error: call of ‘(echo_op<boost::beast::websocket::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp> >, main(int, char**)::<lambda(boost::beast::error_code)> >) (boost::asio::error::basic_errors, int)’ is ambiguous
             h_(std::forward<Args>(args)...);
             ^~
echo_op.cpp:199:6: note: candidate: ‘void echo_op<AsyncStream, Handler>::operator()(boost::beast::error_code, std::size_t) [with AsyncStream = boost::beast::websocket::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp> >; Handler = main(int, char**)::<lambda(boost::beast::error_code)>; boost::beast::error_code = boost::system::error_code; std::size_t = long unsigned int]’
 void echo_op<AsyncStream, Handler>::
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
echo_op.cpp:188:10: note: candidate: ‘void echo_op<AsyncStream, Handler>::operator()(boost::beast::error_code, bool) [with AsyncStream = boost::beast::websocket::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp> >; Handler = main(int, char**)::<lambda(boost::beast::error_code)>; boost::beast::error_code = boost::system::error_code]’
     void operator()(boost::beast::error_code ec, bool test)

Diff from echo_op example from Boost 1.69
@@ -8,6 +8,7 @@
 //

 #include <boost/beast/core.hpp>
+#include <boost/beast/websocket/stream.hpp>
 #include <boost/asio.hpp>
 #include <cstddef>
 #include <iostream>
@@ -184,6 +185,7 @@
     // as our intermediate operations complete. Definition below.
     //
     void operator()(boost::beast::error_code ec, std::size_t bytes_transferred);
+    void operator()(boost::beast::error_code ec, bool test);
 };

 //]
@@ -209,15 +211,16 @@
         case 0:
             // read up to the first newline
             p.step = 1;
-            return boost::asio::async_read_until(p.stream, p.buffer, "\r", std::move(*this));
+            return p.stream.async_read(p.buffer, std::move(*this));
+            //return boost::asio::async_read_until(p.stream, p.buffer, "\r", std::move(*this));

         case 1:
             // write everything back
             p.step = 2;
             // async_read_until could have read past the newline,
             // use buffers_prefix to make sure we only send one line
-            return boost::asio::async_write(p.stream,
-                boost::beast::buffers_prefix(bytes_transferred, p.buffer.data()), std::move(*this));
+            //return boost::asio::async_write(p.stream,
+            //    boost::beast::buffers_prefix(bytes_transferred, p.buffer.data()), std::move(*this));

         case 2:
             p.buffer.consume(bytes_transferred);
@@ -257,8 +260,8 @@
     // Make sure stream meets the requirements. We use static_assert
     // to cause a friendly message instead of an error novel.
     //
-    static_assert(boost::beast::is_async_stream<AsyncStream>::value,
-        "AsyncStream requirements not met");
+    //static_assert(boost::beast::is_async_stream<AsyncStream>::value,
+    //    "AsyncStream requirements not met");

     // This helper manages some of the handler's lifetime and
     // uses the result and handler specializations associated with
@@ -277,7 +280,7 @@
         BOOST_ASIO_HANDLER_TYPE(
             CompletionToken, void(boost::beast::error_code))>{
                 stream,
-                init.completion_handler}(boost::beast::error_code{}, 0);
+                init.completion_handler}(boost::beast::error_code{}, std::size_t {0});

     // This hook lets the caller see a return value when appropriate.
     // For example this might return std::future<error_code> if
@@ -304,7 +307,10 @@
     acceptor.bind(ep);
     acceptor.listen();
     acceptor.accept(sock);
-    async_echo(sock,
+
+    boost::beast::websocket::stream<socket_type> ws(ioc);
+
+    async_echo(ws,
         [&](boost::beast::error_code ec)
         {
             if(ec)

Full failing example
//
// Copyright (c) 2016-2017 Vinnie Falco (vinnie dot falco at gmail dot com)
//
// Distributed under the Boost Software License, Version 1.0. (See accompanying
// file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
//
// Official repository: https://github.com/boostorg/beast
//

#include <boost/beast/core.hpp>
#include <boost/beast/websocket/stream.hpp>
#include <boost/asio.hpp>
#include <cstddef>
#include <iostream>
#include <memory>
#include <utility>

//[example_core_echo_op_1

template<
    class AsyncStream,
    class CompletionToken>
auto
async_echo(AsyncStream& stream, CompletionToken&& token)

//]
    -> BOOST_ASIO_INITFN_RESULT_TYPE(CompletionToken, void(boost::beast::error_code));

//[example_core_echo_op_2

/** Asynchronously read a line and echo it back.

    This function is used to asynchronously read a line ending
    in a carriage-return ("CR") from the stream, and then write
    it back. The function call always returns immediately. The
    asynchronous operation will continue until one of the
    following conditions is true:

    @li A line was read in and sent back on the stream

    @li An error occurs.

    This operation is implemented in terms of one or more calls to
    the stream's `async_read_some` and `async_write_some` functions,
    and is known as a composed operation. The program must
    ensure that the stream performs no other operations until this
    operation completes. The implementation may read additional octets
    that lie past the end of the line being read. These octets are
    silently discarded.

    @param The stream to operate on. The type must meet the
    requirements of @b AsyncReadStream and @AsyncWriteStream

    @param token The completion token to use. If this is a
    completion handler, copies will be made as required.
    The equivalent signature of the handler must be:
    @code
    void handler(
        error_code ec       // result of operation
    );
    @endcode
    Regardless of whether the asynchronous operation completes
    immediately or not, the handler will not be invoked from within
    this function. Invocation of the handler will be performed in a
    manner equivalent to using `boost::asio::io_context::post`.
*/
template<
    class AsyncStream,
    class CompletionToken>
BOOST_ASIO_INITFN_RESULT_TYPE(          /*< `BOOST_ASIO_INITFN_RESULT_TYPE` customizes the return value based on the completion token >*/
    CompletionToken,
    void(boost::beast::error_code))     /*< This is the signature for the completion handler >*/
async_echo(
    AsyncStream& stream,
    CompletionToken&& token);

//]

//[example_core_echo_op_4

// This composed operation reads a line of input and echoes it back.
//
template<class AsyncStream, class Handler>
class echo_op
{
    // This holds all of the state information required by the operation.
    struct state
    {
        // The stream to read and write to
        AsyncStream& stream;

        // Boost.Asio and the Networking TS require an object of
        // type executor_work_guard<T>, where T is the type of
        // executor returned by the stream's get_executor function,
        // to persist for the duration of the asynchronous operation.
        boost::asio::executor_work_guard<
            decltype(std::declval<AsyncStream&>().get_executor())> work;

        // Indicates what step in the operation's state machine
        // to perform next, starting from zero.
        int step = 0;

        // The buffer used to hold the input and output data.
        //
        // We use a custom allocator for performance, this allows
        // the implementation of the io_context to make efficient
        // re-use of memory allocated by composed operations during
        // a continuation.
        //
        boost::asio::basic_streambuf<typename std::allocator_traits<
            boost::asio::associated_allocator_t<Handler> >::
                template rebind_alloc<char> > buffer;

        // handler_ptr requires that the first parameter to the
        // contained object constructor is a reference to the
        // managed final completion handler.
        //
        explicit state(Handler const& handler, AsyncStream& stream_)
            : stream(stream_)
            , work(stream.get_executor())
            , buffer((std::numeric_limits<std::size_t>::max)(),
                boost::asio::get_associated_allocator(handler))
        {
        }
    };

    // The operation's data is kept in a cheap-to-copy smart
    // pointer container called `handler_ptr`. This efficiently
    // satisfies the CopyConstructible requirements of completion
    // handlers with expensive-to-copy state.
    //
    // `handler_ptr` uses the allocator associated with the final
    // completion handler, in order to allocate the storage for `state`.
    //
    boost::beast::handler_ptr<state, Handler> p_;

public:
    // Boost.Asio requires that handlers are CopyConstructible.
    // In some cases, it takes advantage of handlers that are
    // MoveConstructible. This operation supports both.
    //
    echo_op(echo_op&&) = default;
    echo_op(echo_op const&) = default;

    // The constructor simply creates our state variables in
    // the smart pointer container.
    //
    template<class DeducedHandler, class... Args>
    echo_op(AsyncStream& stream, DeducedHandler&& handler)
        : p_(std::forward<DeducedHandler>(handler), stream)
    {
    }

    // Associated allocator support. This is Asio's system for
    // allowing the final completion handler to customize the
    // memory allocation strategy used for composed operation
    // states. A composed operation should use the same allocator
    // as the final handler. These declarations achieve that.

    using allocator_type =
        boost::asio::associated_allocator_t<Handler>;

    allocator_type
    get_allocator() const noexcept
    {
        return (boost::asio::get_associated_allocator)(p_.handler());
    }

    // Executor hook. This is Asio's system for customizing the
    // manner in which asynchronous completion handlers are invoked.
    // A composed operation needs to use the same executor to invoke
    // intermediate completion handlers as that used to invoke the
    // final handler.

    using executor_type = boost::asio::associated_executor_t<
        Handler, decltype(std::declval<AsyncStream&>().get_executor())>;

    executor_type get_executor() const noexcept
    {
        return (boost::asio::get_associated_executor)(
            p_.handler(), p_->stream.get_executor());
    }

    // The entry point for this handler. This will get called
    // as our intermediate operations complete. Definition below.
    //
    void operator()(boost::beast::error_code ec, std::size_t bytes_transferred);
    void operator()(boost::beast::error_code ec, bool test);
};

//]

//[example_core_echo_op_5

// echo_op is callable with the signature void(error_code, bytes_transferred),
// allowing `*this` to be used as both a ReadHandler and a WriteHandler.
//
template<class AsyncStream, class Handler>
void echo_op<AsyncStream, Handler>::
operator()(boost::beast::error_code ec, std::size_t bytes_transferred)
{
    // Store a reference to our state. The address of the state won't
    // change, and this solves the problem where dereferencing the
    // data member is undefined after a move.
    auto& p = *p_;

    // Now perform the next step in the state machine
    switch(ec ? 2 : p.step)
    {
        // initial entry
        case 0:
            // read up to the first newline
            p.step = 1;
            return p.stream.async_read(p.buffer, std::move(*this));
            //return boost::asio::async_read_until(p.stream, p.buffer, "\r", std::move(*this));

        case 1:
            // write everything back
            p.step = 2;
            // async_read_until could have read past the newline,
            // use buffers_prefix to make sure we only send one line
            //return boost::asio::async_write(p.stream,
            //    boost::beast::buffers_prefix(bytes_transferred, p.buffer.data()), std::move(*this));

        case 2:
            p.buffer.consume(bytes_transferred);
            break;
    }
    // Invoke the final handler. The implementation of `handler_ptr`
    // will deallocate the storage for the state before the handler
    // is invoked. This is necessary to provide the
    // destroy-before-invocation guarantee on handler memory
    // customizations.
    //
    // If we wanted to pass any arguments to the handler which come
    // from the `state`, they would have to be moved to the stack
    // first or else undefined behavior results.
    //
    // The work guard is moved to the stack first, otherwise it would
    // be destroyed before the handler is invoked.
    //
    auto work = std::move(p.work);
    p_.invoke(ec);
    return;
}

//]

//[example_core_echo_op_3

template<class AsyncStream, class Handler>
class echo_op;

// Read a line and echo it back
//
template<class AsyncStream, class CompletionToken>
BOOST_ASIO_INITFN_RESULT_TYPE(CompletionToken, void(boost::beast::error_code))
async_echo(AsyncStream& stream, CompletionToken&& token)
{
    // Make sure stream meets the requirements. We use static_assert
    // to cause a friendly message instead of an error novel.
    //
    //static_assert(boost::beast::is_async_stream<AsyncStream>::value,
    //    "AsyncStream requirements not met");

    // This helper manages some of the handler's lifetime and
    // uses the result and handler specializations associated with
    // the completion token to help customize the return value.
    //
    boost::asio::async_completion<CompletionToken, void(boost::beast::error_code)> init{token};

    // Create the composed operation and launch it. This is a constructor
    // call followed by invocation of operator(). We use BOOST_ASIO_HANDLER_TYPE
    // to convert the completion token into the correct handler type,
    // allowing user-defined specializations of the async_result template
    // to be used.
    //
    echo_op<
        AsyncStream,
        BOOST_ASIO_HANDLER_TYPE(
            CompletionToken, void(boost::beast::error_code))>{
                stream,
                init.completion_handler}(boost::beast::error_code{}, std::size_t {0});

    // This hook lets the caller see a return value when appropriate.
    // For example this might return std::future<error_code> if
    // CompletionToken is boost::asio::use_future, or this might
    // return an error code if CompletionToken specifies a coroutine.
    //
    return init.result.get();
}

//]

int main(int, char** argv)
{
    using socket_type = boost::asio::ip::tcp::socket;
    using endpoint_type = boost::asio::ip::tcp::endpoint;

    // Create a listening socket, accept a connection, perform
    // the echo, and then shut everything down and exit.
    boost::asio::io_context ioc;
    socket_type sock{ioc};
    boost::asio::ip::tcp::acceptor acceptor{ioc};
    endpoint_type ep{boost::asio::ip::make_address("<IP_ADDRESS>"), 0};
    acceptor.open(ep.protocol());
    acceptor.bind(ep);
    acceptor.listen();
    acceptor.accept(sock);

    boost::beast::websocket::stream<socket_type> ws(ioc);

    async_echo(ws,
        [&](boost::beast::error_code ec)
        {
            if(ec)
                std::cerr << argv[0] << ": " << ec.message() << std::endl;
        });
    ioc.run();
    return 0;
}

Should be fixed in develop.

Please confirm this is fixed in develop and then close the issue, thanks!

It does fix the issue.


Question: Uncertainty Types

Hey @nikitadurasov! 👋
When using the Masksembles method, I want to make a distinction between the different types of uncertainty (model/epistemic, label/aleatoric, and distributional/dataset shift). I noticed it wasn't explicitly stated what kind/s of uncertainty were being estimated through this method, but since the experiments focus on OOD detection, would it be fair to say this is mostly for dataset shift?

Hey @ayeshans!
Yes, primarily we're benchmarkzing against dataset shift, image corruptions and aleatoric uncertainty. Though we aren't providing any clean way to distinguish different types of uncertainties (eg epistemic and data shift), our model still works rather good with standard methods to approach that: 1) for aleatoric classification uncertainty, we can use entropy of mean distribution 2) for epistemic, we calculate Mutual Information as described in the paper.
Hope that helps! :)
Nikita


⚠ Auth API Endpoint has degraded performance

In 23e2145, Auth API Endpoint (https://auth.roblox.com) experienced degraded performance:

HTTP code: 503
Response time: 10572 ms

Resolved: Auth API Endpoint performance has improved in 1fd6893.


where can i get the  "signingKeySecret": ""

where can i get the  "signingKeySecret": ""

It's being shown when you're creating new API key. And you supposed to store it somewhere.
In case it lost, you need to obtain new API key from Twilio website.


Click function in sublime text not functioning properly

System: Linux Ubuntu 12.04 LTS Precise Pangolin
Application: Sublime Text 3
After installing jdebug via package controller in sublime text 3; the application doesn't respond normally to single left clicks inside open files. Double left clicks seems to work fine.

The issue fixed in most recent version


updated DropZone to allow FILE types - types.ts, DropZone.tsx, FileIt…

…em.tsx

This issue has been fixed in another PR. Closing this one,


Change some Alluxio log messages to be debug

fixes https://github.com/NVIDIA/spark-rapids/issues/6277
The logging is nice to have at info but it gets very noisy on a running cluster using alluxio, change some to debug.  They should really only be needed on initial bring up or if something goes wrong.
Signed-off-by: Thomas Graves<EMAIL_ADDRESS>

build


seems like it stops every few seconds

Perhaps this happens because it is changing to a different scene?
My specs:
MacBook Pro OSX 10.11.6
HD: 1TB
Processor: 3 GHz Intel Core i7
Memory: 16 GB 1600 MHz DDR3
Thanks for your support.

Closing as duplicate of #278


add frontend-sonar.yml public src

Drift Video-https://video.drift.com/v/abPtCJuz0Eb4eqLQymgdQ0joHa9uZoyF0ifen9p5iiL0w/
Screenshots:

Metric
Value

alert_status
:white_check_mark: OK

bugs
3

code_smells
3

reliability_rating
D (at least 1 Critical Bug)Note: A being best, E being worst

security_rating
A (0 Vulnerabilities)Note: A being best, E being worst

vulnerabilities
0


Mac OS 13.4 M2 Pro with latest code build error 'opencv2/opencv.hpp' file not found

LocalAI version:
git commit: commit 0780be022cb709d531acb055ac8a858f032d3e19 (HEAD -> master, origin/master, origin/HEAD)
Environment, CPU architecture, OS, and Version:
Mac OS 13.4 M2 Pro
Describe the bug
compile error with BUILD_TYPE=metal build GO_TAGS=stablediffusion,tts
(base) block@192 LocalAI % make BUILD_TYPE=metal build
(base) block@192 LocalAI % export GO_TAGS=stablediffusion,tts

cp -rf overrides/* stable-diffusion/x86/vs2019_opencv-mobile_ncnn-dll_demo/vs2019_opencv-mobile_ncnn-dll_demo/
c++ -I./ncnn -I./ncnn/src -I./ncnn/build/src/ -I. -I./stable-diffusion/x86/vs2019_opencv-mobile_ncnn-dll_demo/vs2019_opencv-mobile_ncnn-dll_demo  -O3 -DNDEBUG -std=c++17 -fPIC -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function stablediffusion.cpp -o stablediffusion.o -c
In file included from stablediffusion.cpp:9:
In file included from ./ncnn/src/net.h:18:
In file included from ./ncnn/src/blob.h:18:
./ncnn/src/mat.h:1164:9: warning: '_Atomic' is a C11 extension [-Wc11-extensions]
        NCNN_XADD(m.refcount, 1);
        ^
./ncnn/src/allocator.h:125:56: note: expanded from macro 'NCNN_XADD'
#define NCNN_XADD(addr, delta) __c11_atomic_fetch_add((_Atomic(int)*)(addr), delta, __ATOMIC_ACQ_REL)
                                                       ^
In file included from stablediffusion.cpp:9:
In file included from ./ncnn/src/net.h:18:
In file included from ./ncnn/src/blob.h:18:
./ncnn/src/mat.h:1188:9: warning: '_Atomic' is a C11 extension [-Wc11-extensions]
        NCNN_XADD(refcount, 1);
        ^
./ncnn/src/allocator.h:125:56: note: expanded from macro 'NCNN_XADD'
#define NCNN_XADD(addr, delta) __c11_atomic_fetch_add((_Atomic(int)*)(addr), delta, __ATOMIC_ACQ_REL)
                                                       ^
In file included from stablediffusion.cpp:9:
In file included from ./ncnn/src/net.h:18:
In file included from ./ncnn/src/blob.h:18:
./ncnn/src/mat.h:1193:21: warning: '_Atomic' is a C11 extension [-Wc11-extensions]
    if (refcount && NCNN_XADD(refcount, -1) == 1)
                    ^
./ncnn/src/allocator.h:125:56: note: expanded from macro 'NCNN_XADD'
#define NCNN_XADD(addr, delta) __c11_atomic_fetch_add((_Atomic(int)*)(addr), delta, __ATOMIC_ACQ_REL)
                                                       ^
In file included from stablediffusion.cpp:11:
./stable-diffusion/x86/vs2019_opencv-mobile_ncnn-dll_demo/vs2019_opencv-mobile_ncnn-dll_demo/decoder_slover.h:11:10: fatal error: 'opencv2/opencv.hpp' file not found
#include <opencv2/opencv.hpp>
         ^~~~~~~~~~~~~~~~~~~~
3 warnings and 1 error generated.
make[1]: *** [stablediffusion.o] Error 1
make: *** [go-stable-diffusion/libstablediffusion.a] Error 2

To Reproduce
make BUILD_TYPE=metal build
Expected behavior
build local-ai
Logs
as bug describes
Additional context
v1.19.2 compile normal

you seem to miss opencv2 header files. you can either drop stablediffusion from your GO_TAGS or install opencv2.

unset GO_TAGS; exec " make build" still compile error:
d531acb055ac8a858f032d3e19"" -tags "" -o local-ai ./
# github.com/go-skynet/LocalAI/pkg/whisper
pkg/whisper/whisper.go:76:34: not enough arguments in call to context.Process
        have ([]float32, nil)
        want ([]float32, "github.com/ggerganov/whisper.cpp/bindings/go/pkg/whisper".SegmentCallback, "github.com/ggerganov/whisper.cpp/bindings/go/pkg/whisper".ProgressCallback)
# github.com/go-skynet/go-bert.cpp
In file included from gobert.cpp:6:
go-bert/bert.cpp/bert.cpp:693:74: warning: format specifies type 'int' but the argument has type 'unsigned long' [-Wformat]
# github.com/go-skynet/go-llama.cpp
binding.cpp:634:15: warning: 'llama_init_from_file' is deprecated: please use llama_load_model_from_file combined with llama_new_context_with_model instead [-Wdeprecated-declarations]
go-llama/llama.cpp/llama.h:162:15: note: 'llama_init_from_file' has been explicitly marked deprecated here
go-llama/llama.cpp/llama.h:30:56: note: expanded from macro 'DEPRECATED'
# github.com/go-skynet/go-ggml-transformers.cpp
replit.cpp:65:50: warning: format specifies type 'int' but the argument has type 'std::vector<unsigned long>::value_type' (aka 'unsigned long') [-Wformat]
make: *** [build] Error 1

seems you are using master, that was just fixed in https://github.com/go-skynet/LocalAI/pull/702.
run git pull again

you seem to miss opencv2 header files. you can either drop stablediffusion from your GO_TAGS or install opencv2.
opencv@2      has been disabled

(base) block@192 LocalAI % brew install opencv@2
Warning: No remote 'origin' in /opt/homebrew/Library/Taps/homebrew/homebrew-services, skipping update!
Running brew update --auto-update...
Error: opencv@2 has been disabled because it is not supported upstream!

seems you are using master, that was just fixed in #702.
run git pull again

it's OK now without GO_TAGS

I had the same issue and resolved it by:

Installing OpenCV following the instructions here
Navigate into the go-stable-diffusion directory and create a soft link to the opencv2 folder, ex:

cd go-stable-diffusion
ln -s /usr/include/opencv4/opencv2 opencv2

It may be worth noting that I did this on a linux box and not on MacOS, though it seemed to solve the same problem.

I got the same error


Cannot toggle fullscreen from key callback function

The intended result of calling glfwSetWindowMonitor() is correct outside of the callback function, but not inside of it. It can switch fullscreen to windowed, but not the other way around.
#include <iostream>
#include <GLFW/glfw3.h>

int main() {
  if(!glfwInit()) exit(1);
  glfwSetErrorCallback([](const int error, const char *desc) {
    std::cerr << error << ": " << desc << '\n';
  });
  glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);
  //GLFWwindow *window = glfwCreateWindow(640, 480, "Hello World", nullptr, nullptr);
  GLFWwindow *window = glfwCreateWindow(640, 480, "Hello World", glfwGetPrimaryMonitor(), nullptr);
  glfwMakeContextCurrent(window);
  glfwSetKeyCallback(window, [](GLFWwindow *window, int key, int, int action, int) {
      if(key == GLFW_KEY_F12 && action == GLFW_PRESS)
        glfwSetWindowMonitor(window, glfwGetWindowMonitor(window), 0, 0, 640, 480, 60);
    });
  //glfwSetWindowMonitor(window, glfwGetPrimaryMonitor(), 0, 0, 640, 480, 60);
  glfwSetWindowMonitor(window, nullptr, 0, 0, 640, 480, 60);
  while(!glfwWindowShouldClose(window)) {
    glfwPollEvents();
    glClear(GL_COLOR_BUFFER_BIT);
    glfwSwapBuffers(window);
  }
  glfwDestroyWindow(window);
  glfwTerminate();
}

You create a full screen window (monitor = primary) and then immediately change it to windowed mode (monitor = nullptr). Why not simply create a windowed mode window?
Your key callback sets the monitor (if any) that the window already has, so it shouldn't ever switch between windowed and full screen. Here is an example of a key callback toggling between windowed and full screen modes.

I still don't understand how the call to glfwSetWindowMonitor does exactly what I want in main but not in the key callback.
From the documentation of glfwSetWindowMonitor:

This function sets the monitor that the window uses for full screen mode or, if the monitor is NULL, makes it windowed mode.

If I understand this correctly, the function changes the window to full screen when given a monitor, otherwise it changes to windowed mode. This is the behavior that the function exhibits when being called from main, but not from the key callback.
Using the code you linked, the window moves to the 0, 0 position of the monitor that it is currently in, but is windowed, even when given a monitor. This is regardless of whether the window was created full screen or windowed. Creating the window full screen works perfectly, however I still haven't been able to switch to full screen after the window has been created.
I also noticed this error, although I'm not sure what caused it and I don't know how to reproduce it:

65544: X11: Iconification of full screen windows requires a WM that supports EWMH full screen

I tested to see if it was my desktop environment causing the problem. I noticed that I can get toggling to work in Unity by using glfwGetPrimaryMonitor, but it doesn't work in DWM. This is odd because creating the window as full screen and changing it to fullscreen in main both work in DWM.

If I understand this correctly, the function changes the window to full screen when given a monitor, otherwise it changes to windowed mode. This is the behavior that the function exhibits when being called from main, but not from the key callback.

Because in the key callback you set the monitor to the current monitor (if any) of the window as returned by glfwGetWindowMonitor, so if it's in windowed mode then you set it to windowed mode and if it's full screen on a monitor you make it full screen on that monitor.

noticed that I can get toggling to work in Unity by using glfwGetPrimaryMonitor, but it doesn't work in DWM. This is odd because creating the window as full screen and changing it to fullscreen in main both work in DWM.

As a tiled window manager, DWM has some unusual ideas about window placement. What version of DWM are you using?

I also noticed this error, although I'm not sure what caused it and I don't know how to reproduce it:
65544: X11: Iconification of full screen windows requires a WM that supports EWMH full screen

What is the output of xprop -root?

I decided to remove glfwSetKeyCallback and use glfwGetKey instead to see if it would work.
This is the code in my main loop:
glfwSetWindowMonitor(window, glfwGetPrimaryMonitor(), 0, 0, 640, 480, 60); // Works
Alternatively:
if(glfwGetKey(window, GLFW_KEY_F12) == GLFW_PRESS)
  glfwSetWindowMonitor(window, glfwGetPrimaryMonitor(), 0, 0, 640, 480, 60); // Fails

The first example works every time. The second fails. I'm positive that the code is executed since debug statements work inside of the conditional.
I think the same problem as with the callback function is happening here.
I did some more testing:
if(true)
  glfwSetWindowMonitor(window, glfwGetPrimaryMonitor(), 0, 0, 640, 480, 60); // Works

if(time == 50) // Number of iterations of main loop
  glfwSetWindowMonitor(window, glfwGetPrimaryMonitor(), 0, 0, 640, 480, 60); // Fails

It seems that glfwSetWindowMonitor only sometimes works if it is in an if conditional. I am sure the expression is true in these examples.

I decided to get back to this. It still confuses me how glfwSetWindowMonitor works alone, but when in an if statement, even if the condition is true, it doesn't.
If the window is started windowed and glfwSetWindowMonitor(glfwGetPrimaryMonitor(), 0, 0, 640, 480, 60) is called, the window is set to fullscreen, but only after the second time. The first time the key is pressed, it changes the resolution, but parts of the desktop are still visible. If the window moved away from the top left of the monitor, it may not be visible. After the second time, it becomes fullscreen with nothing but the window visible.
If the window is started fullscreen, a similar behavior occurs. It takes a call to glfwSetWindowMonitor to make it really fullscreen. Otherwise the desktop is still visible.
I decided to look at the source code of GLFW to see if I could find anything. In x11_window.c, in _glfwPlatformSetWindowMonitor, there is a bit of code:
if (waitForVisibilityNotify(window))
  acquireMonitor(window);

If
if (waitForVisibilityNotify(window))
is commended out, the behavior changes.
Now toggling to fullscreen works from a key but it still takes 2 calls to do it. In other words, it takes either switching to it twice or creating the window fullscreen and switching to it again. Switching to windowed takes only one call.

Fullscreen switching/toggling during runtime won't work on dwm v6.1 without any patches. It simply forces it back into windowed mode. Also, if you toggle the bar of dwm and the window has been started in fullscreen mode, dwm forces it into windowed mode also. So glfwSetWindowMonitor simply won't work on dwm.


fix!: params issue in executeSql

This is PR is Address to encode the params as it does in database.run using encodeParams function, but it breaks the existing code.
Fixes #845

Thanks for the fix @laljikanjareeya. Could you please also add a unit test to make sure that this is fixed?

Added Unit Test as well as system test.

While this change would make the specific example work, the real problem in this case is that the user is using the generated gapic client. When doing so, the user must also take care to specify the parameters in encoded form in the ExecuteSqlRequest. See also my comment in the related issue.

@olavloite correct me if I'm wrong but I think this means we don't need this PR at all since we don't want to modify generated code? I asked the folks dealing with the customer issue to forward your suggestion from the issue.

@olavloite correct me if I'm wrong but I think this means we don't need this PR at all since we don't want to modify generated code? I asked the folks dealing with the customer issue to forward your suggestion from the issue.

Correct, so closing this PR.


two words trigger

In vim, I can set
let g:ycm_semantic_triggers =  {                 \ 'c,cpp,python,java,go,erlang,perl': ['re!\w{2}'],                 \ 'cs,lua,javascript': ['re!\w{2}'],                 \ }
two worlds will trigger. for example pr->printf. can emacs-ycmd set?

I'm not sure, but I think this is a question for company-mode. I'm going to close this, but if it turns out to be an issue for emacs-ycmd, please re-open it.


Recursive equals improvements for unordered sets comparison

Check List:

Fixes #841
Unit tests : YES
Javadoc with a code example (API only) : NA

Many thanks @fiery-phoenix, DeepDifference is complex code !

You are welcome :)


Dockerfile: use image digests for better determinism

Signed-off-by: Akihiro Suda<EMAIL_ADDRESS>

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks @AkihiroSuda
/cc @iamxy

LGTM

LGTM


Using "Microsoft.VisualStudio.Azure.Containers.Tools.Targets" doesn't work with Aspire

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
Issue
Visual Studio Containers - AKA where your build from Windows is transferred into a Linux container, doesn't work with Aspire.
You get this:

System.AggregateException: 'One or more errors occurred. (The Aspire orchestration component is not installed at "C:\Program Files\dotnet\packs\Aspire.Hosting.Orchestration.win-x64\8.0.0\tools\dcp.exe". The application cannot be run without it.)'

And in the Linux Debug container:

I think it's because of how the assembly metadata is used by Aspire to figure out the dcp path.
I have dcp installed in the Linux container:
# ------------------------------------------------------------------------------
# DEBUG CONTAINER:
# Running against Visual Studio where local build is transferred to container
# ------------------------------------------------------------------------------
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS base

USER root
RUN apt-get update && \
	apt-get install -y \
	wget \
	curl \
	libsecret-1-dev
RUN curl -sL https://aka.ms/InstallAzureCLIDeb | bash
RUN dotnet workload install aspire

USER app
WORKDIR /app

But the issue is, Aspire is looking at the Windows path, because that's where Visual Studio Containers builds things.

Repro
I couldn't find anyone that has tried this, so I gave it a go.
launchSettings.json
  "profiles": {
    "Docker Container Development": {
      "commandName": "Docker",
      "launchBrowser": true,
      "launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}",
      "environmentVariables": {
        "ASPIRE_ALLOW_UNSECURED_TRANSPORT": "true",
        "ASPNETCORE_URLS": "http://localhost:17145",
        "ASPNETCORE_ENVIRONMENT": "Development",
        "DOTNET_DASHBOARD_OTLP_ENDPOINT_URL": "http://localhost:21146"
      },
      "publishAllPorts": true,
      "useSSL": false
    },

My csproj (using Aspire 8.1.0):
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <IsAspireHost>true</IsAspireHost>
    <Nullable>enable</Nullable>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>
  <!-- ==== Debugging right inside a docker container ==== -->
  <PropertyGroup>
    <DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
    <DockerfileContext>..\..\..\..\..</DockerfileContext>
    <DockerfileFile>..\..\..\..\docker\Dockerfile.csharp.dev</DockerfileFile>
    <DockerfileRunArguments>-p 17145:17145</DockerfileRunArguments>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" />
    <PackageReference Include="Aspire.Hosting.AppHost" />
  </ItemGroup>
</Project>

Going through the Aspire code for 8.1.0, it looks like passing args for CLIPath and DashboardPath isn't actually used in DCPOptions:
https://github.com/dotnet/aspire/blob/d304c5f6f15bcd4f34f1841b33870cfab88e6937/src/Aspire.Hosting/Dcp/DcpOptions.cs#L115

I tried to add a hack to my CSPROJ, to override the assembly values:
  <ItemGroup>
    <AssemblyAttribute Include="System.Reflection.AssemblyMetadata">
      <_Parameter1>DcpCliPath</_Parameter1>
      <_Parameter2>/usr/share/dotnet/packs/Aspire.Hosting.Orchestration.linux-x64/8.1.0/tools/dcp</_Parameter2>
    </AssemblyAttribute>
    <AssemblyAttribute Include="System.Reflection.AssemblyMetadata">
      <_Parameter1>aspiredashboardpath</_Parameter1>
      <_Parameter2>/usr/share/dotnet/packs/Aspire.Dashboard.Sdk.linux-x64/8.1.0/tools/Aspire.Dashboard.dll</_Parameter2>
    </AssemblyAttribute>
  </ItemGroup>

But that didn't work either.
It looks like this PR:
https://github.com/dotnet/aspire/pull/5082
From @mitchdenny adds the Dashboard Path as an args.
But this isn't available as a Nuget release yet.
Expected Behavior
Visual Studio Containers, an awesome extension for debugging your code in a Docker Container, doesn't work with Aspire.
Steps To Reproduce
Please try to create a simple project with Visual Studio Containers and try to make it work with the latest Aspire Nuget package. You should hit what I hit.
Exceptions (if any)
2024-08-18 20:52:51 info: Aspire.Hosting.DistributedApplication[0]
2024-08-18 20:52:51       Aspire version: 8.1.0+d304c5f6f15bcd4f34f1841b33870cfab88e6937
2024-08-18 20:52:51 info: Aspire.Hosting.DistributedApplication[0]
2024-08-18 20:52:51       Distributed application starting.
2024-08-18 20:52:51 info: Aspire.Hosting.DistributedApplication[0]
2024-08-18 20:52:51       Application host directory is: C:\Users\mdrrahman\Documents\GitHub\AdsHybrid\src\Microsoft.Universal.Aspire.AppHost\Dataplane.EventProcessing\Dataplane.EventProcessing.AppHost
2024-08-18 20:52:51 warn: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[60]
2024-08-18 20:52:51       Storing keys in a directory '/home/app/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed. For more information go to https://aka.ms/aspnet/dataprotectionwarning
2024-08-18 20:52:51 warn: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]
2024-08-18 20:52:51       No XML encryptor configured. Key {b1ec4679-3680-44a7-9e5b-12aab1d11744} may be persisted to storage in unencrypted form.
2024-08-18 20:52:51 fail: Microsoft.Extensions.Hosting.Internal.Host[11]
2024-08-18 20:52:51       Hosting failed to start
2024-08-18 20:52:51       System.IO.FileNotFoundException: The Aspire orchestration component is not installed at "C:\Program Files\dotnet\packs\Aspire.Hosting.Orchestration.win-x64\8.0.0\tools\dcp.exe". The application cannot be run without it.
2024-08-18 20:52:51       File name: 'C:\Program Files\dotnet\packs\Aspire.Hosting.Orchestration.win-x64\8.0.0\tools\dcp.exe'
2024-08-18 20:52:51          at Aspire.Hosting.Dcp.DcpDependencyCheck.GetDcpInfoAsync(CancellationToken cancellationToken) in /_/src/Aspire.Hosting/Dcp/DcpDependencyCheck.cs:line 50
2024-08-18 20:52:51          at Aspire.Hosting.Dcp.DcpHostService.StartAsync(CancellationToken cancellationToken) in /_/src/Aspire.Hosting/Dcp/DcpHostService.cs:line 67
2024-08-18 20:52:51          at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>b__15_1(IHostedService service, CancellationToken token)
2024-08-18 20:52:51          at Microsoft.Extensions.Hosting.Internal.Host.ForeachService[T](IEnumerable`1 services, CancellationToken token, Boolean concurrent, Boolean abortOnFirstException, List`1 exceptions, Func`3 operation)

.NET Version info
This is inside my Docker container:

dotnet workload list

Installed Workload Id      Manifest Version      Installation Source
--------------------------------------------------------------------
aspire                     8.1.0/8.0.100         SDK 8.0.400

$ dotnet --info
.NET SDK:
 Version:           8.0.401
 Commit:            811edcc344
 Workload version:  8.0.400-manifests.56cd0383
 MSBuild version:   17.11.4+37eb419ad

Runtime Environment:
 OS Name:     debian
 OS Version:  12
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/8.0.401/

.NET workloads installed:
Configured to use loose manifests when installing new manifests.
 [aspire]
   Installation Source: SDK 8.0.400
   Manifest Version:    8.1.0/8.0.100
   Manifest Path:       /usr/share/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.1.0/WorkloadManifest.json
   Install Type:        FileBased

Host:
  Version:      8.0.8
  Architecture: x64
  Commit:       08338fcaa5

.NET SDKs installed:
  8.0.401 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Anything else?
No response

If the maintainers of Aspire are not familiar with Visual Studio Containers, and would like me to create a simple hello-world repro app, please let me know, I can create something and link it here.
Else, if you're familiar, you should be able to repro this in 5 minutes, after adding the Visual Studio Containers project into the Aspire Weather Web App Sample

I'm seeing exactly the same problem on Windows.

cc @danegsta

Don't run the apphost inside of a container, it's unclear how that is beneficial as that is essentially tooling code that orchestrates your application.


Consider moving to KonvaJS

Consider moving over to https://github.com/konvajs/konva which is based on KineticJS.

Konva 0.9.5 seems to work quite well. Dragging looks to be a lot faster.
Three problems I'm noticing in LZ:

scaling doesn't work (hairkeeper)
speech bubble has a stray line in upper left corner
an image of the inventory item stays in inventory while dragging

Pushed to https://github.com/evktalo/kiigame/tree/konva
Speech bubble bug seems to be a bug in Konva. Not seeing other problems, so jumping ahead with this is likely.

This is a problem: https://github.com/lavrton/kineticjs-tips-and-tools#caching - dragging an item over a scaled object (e.g. tactic board wiper) resets their scaling.

Merged.


Bump the version of K8s clients and knative/pkg

knative/pkg already bumped things, so this keeps our downstream test passing, so we know if/when we break pipelines.
/kind cleanup
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[ ] Docs included if any changes are user facing
[ ] Tests included if any functionality added or changed
[ ] Follows the commit message standard
[ ] Meets the Tekton contributor standards (including
functionality, content, code)
[ ] Release notes block below has been filled in or deleted (only if no user facing changes)

Release Notes
NONE

/test check-pr-has-kind-label

/lgtm


Getting statistics through the api is always 0

This is my background data

But the data kept returning 0 when accessed through the api(/api/websites/{id}/stats),
url:http://<IP_ADDRESS>:3000/api/websites/1/stats?start_at=1350679719687&end_at=1990039038644
header={
    "Access-Control-Allow-Origin": '*',
    "Accept": "application/json",
    "Authorization": "Bearer xxxx"
}

reuturn value
{"pageviews":{"value":0,"change":0},"uniques":{"value":0,"change":0},"bounces":{"value":0,"change":0},"totaltime":{"value":0,"change":0}}

please help !

Try using the website UUID instead of the PK.
We haven't updated the documentation to reflect those changes accordingly.  We plan on updating after  releasing v2.

尝试使用网站 UUID 而不是 PK。
我们尚未更新文档以相应地反映这些更改。我们计划在发布 v2 后进行更新。
Thanks for your reply, but  What does pk mean, Can you give an example? In addition, when can the new document be released

Try using the website UUID instead of the PK.
We haven't updated the documentation to reflect those changes accordingly. We plan on updating after releasing v2.

Thanks for your reply, but  What does pk mean, Can you give an example? In addition, when can the new document be released


typeResolver setting example

Hi,
Can you please provide an example for using typeResolver? (Typescript please)
Thanks

Hi, @mustafaekim
This is not yet in TypedJSON, as it is currently undergoing a complete rewrite. Once implemented though, the setting will require a callback function accepting the source Object being deserialized, the Map of known-type constructors, as well as the constructor of the expected type. It will be expected to return one of the elements from the Map of known-types, or any other constructor that is deemed the correct one.

OK thanks for the support. I changed the variable name to __type and I move on

There is an example here now : https://github.com/JohnWeisz/TypedJSON/issues/88#issuecomment-454334197


WIP: A Step by Step Getting Started Guide

WIP
Tasks:

[ ] Native Speaker review
[ ] Follow style guide (80 columns wrap as per comment)

From my perspective, the improvements made here are going to give us a solid foundation to build off of going forward. I'm not aware of any blockers for merging into Crossplane, but if we're uncertain, we could merge into the Upbound docs site while we collect feedback (bit of a blank slate).
@negz @hasheddan I suggest you both meet with @luebken to go over some of these changes later today or tomorrow before he leaves on vacation. I'd love to see these merged into the main docs, or at least put into a state where we can release them with the next Crossplane release.


'gbk' codec can't decode byte 0xa7 in position 2608: illegal multibyte sequence

When I install silk and enable it in my Django project, I saw this when I see a profiling.
the request page and sql page is ok.

This is mostly due to your own code files not being encoded in UTF-8. Anyway this exception should be caught and a proper error message shown.

This should have been fixed by @0650fab8


date / daterange "stepper"

Acceptance Criteria

[ ] Implement stepper for date-range input
[ ] Steps should be configurable (day, month, year)
[ ] Should be showcased and documented in storybook
[ ] Change of "step" overrides existing input and uses a current day, week, month etc.
[ ] If input becomes "dirty", stepper should be disabled, can be enabled by clicking on one of the "steps" again.

Tech notes
Should it be an existing date-range component with steps=true or it's own component?

@renehossle @PernilleChristiansen is this component used in the near future?

@frontend-specialisten Not that I know of - I think @renehossle knows


MQTT Port is not saved

Perform all steps below and tick them with [x]

[X] Check the related part of the Documentation
[X] Update openHASP to the latest version
[X] Reproduce the issue and describe all steps

Describe the bug
MQTT Port is not saved in openHASP 0.7.0-dev (265f9c4) for WT32-SC01 Plus
To Reproduce

Change the MQTT Port and Save Settings. Then reopen the MQTT Settings.
Expected behavior

Screenshots or video

Thanks for reporting! It is fixed in the latest dev build (Actions tab).