Fidget not starting with ClojureLSP

Based on the ClojureLSP Capabilities site, the $/progress event is already implemented but when starting the LSP in Clojure files figet doesn't show.
Nvim version
NVIM v0.9.1
Build type: Release
LuaJIT 2.1.0-beta3

Lazy setup
return {
  "j-hui/fidget.nvim",
  tag = "legacy",
  event = "LspAttach",
  config = function ()
    require("fidget").setup()
  end
}

@safv12 can you try with the updated implementation and let me know if this is still a problem?
If so, can you please set up test repo for me to reproduce the problem on my end (with setup instructions; I'm not familiar with Clojure development) so that I can debug it? Thanks!

Related: this Wiki page: https://github.com/j-hui/fidget.nvim/wiki/Known-compatible-LSP-servers
It's also worth checking if Fidget progress notifications are working with other language servers.

As far as I understand, fidget progress only pops up when the LSP client attaches to the buffer
I have noticed clojure-lsp not attaching until all the preprocessing is done. That's why fidget progress doesn't show up.
Let me know if you find the same @safv12 .
When you open any clojure file, check the lsp client status using :LspInfo

Closing for now, since @Samy-33 's explanation makes sense to me. Feel free to re-open this issue if Fidget isn't showing progress even after clojure-lsp has attached.

@j-hui, what's the behaviour when the client hasn't attached yet but the server still sends $/progress info?
It should work regardless of client being attached or not. Let me know what you think?

How would the server send $/progress messages if there's no attached client? (I don't actually know, I always assumed the messages could only be sent to attached clients).
In any case, it doesn't matter. Fidget doesn't assume the existence of any LSP client or server; it just uses an event handler for LspProgress and funnels messages to the notifications subsystem.

You can see here, that LSP client sends initialize message on line#3 and server starts sending $/progress before sending back initialized message. So, yes that is possible.
[START][2023-11-24 11:34:08] LSP logging initiated
[INFO][2023-11-24 11:34:08] .../vim/lsp/rpc.lua:662	"Starting RPC client"	{  args = {},  cmd = "/Users/saket/.local/share/nvim/mason/bin/clojure-lsp",  extra = {    cwd = "/Users/saket/Documents/oliv/autosched"  }}
[DEBUG][2023-11-24 11:34:08] .../vim/lsp/rpc.lua:284	"rpc.send"	{  id = 1,  jsonrpc = "2.0",  method = "initialize",  params = {    capabilities = {      textDocument = {        callHierarchy = {          dynamicRegistration = false        },        codeAction = {          codeActionLiteralSupport = {            codeActionKind = {              valueSet = { "", "quickfix", "refactor", "refactor.extract", "refactor.inline", "refactor.rewrite", "source", "source.organizeImports" }            }          },          dataSupport = true,          dynamicRegistration = false,          isPreferredSupport = true,          resolveSupport = {            properties = { "edit" }          }        },        completion = {          completionItem = {            commitCharactersSupport = true,            deprecatedSupport = true,            documentationFormat = { "markdown", "plaintext" },            insertReplaceSupport = true,            insertTextModeSupport = {              valueSet = { 1, 2 }            },            labelDetailsSupport = true,            preselectSupport = true,            resolveSupport = {              properties = { "documentation", "detail", "additionalTextEdits", "sortText", "filterText", "insertText", "textEdit", "insertTextFormat", "insertTextMode" }            },            snippetSupport = true,            tagSupport = {              valueSet = { 1 }            }          },          completionItemKind = {            valueSet = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25 }          },          completionList = {            itemDefaults = { "commitCharacters", "editRange", "insertTextFormat", "insertTextMode", "data" }          },          contextSupport = true,          dynamicRegistration = false,          insertTextMode = 1        },        declaration = {          linkSupport = true        },        definition = {          linkSupport = true        },        documentHighlight = {          dynamicRegistration = false        },        documentSymbol = {          dynamicRegistration = false,          hierarchicalDocumentSymbolSupport = true,          symbolKind = {            valueSet = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26 }          }        },        hover = {          contentFormat = { "markdown", "plaintext" },          dynamicRegistration = false        },        implementation = {          linkSupport = true        },        publishDiagnostics = {          relatedInformation = true,          tagSupport = {            valueSet = { 1, 2 }          }        },        references = {          dynamicRegistration = false        },        rename = {          dynamicRegistration = false,          prepareSupport = true        },        semanticTokens = {          augmentsSyntaxTokens = true,          dynamicRegistration = false,          formats = { "relative" },          multilineTokenSupport = false,          overlappingTokenSupport = true,          requests = {            full = {              delta = true            },            range = false          },          serverCancelSupport = false,          tokenModifiers = { "declaration", "definition", "readonly", "static", "deprecated", "abstract", "async", "modification", "documentation", "defaultLibrary" },          tokenTypes = { "namespace", "type", "class", "enum", "interface", "struct", "typeParameter", "parameter", "variable", "property", "enumMember", "event", "function", "method", "macro", "keyword", "modifier", "comment", "string", "number", "regexp", "operator", "decorator" }        },        signatureHelp = {          dynamicRegistration = false,          signatureInformation = {            activeParameterSupport = true,            documentationFormat = { "markdown", "plaintext" },            parameterInformation = {              labelOffsetSupport = true            }          }        },        synchronization = {          didSave = true,          dynamicRegistration = false,          willSave = true,          willSaveWaitUntil = true        },        typeDefinition = {          linkSupport = true        }      },      window = {        showDocument = {          support = true        },        showMessage = {          messageActionItem = {            additionalPropertiesSupport = false          }        },        workDoneProgress = true      },      workspace = {        applyEdit = true,        configuration = true,        didChangeWatchedFiles = {          dynamicRegistration = false,          relativePatternSupport = true        },        semanticTokens = {          refreshSupport = true        },        symbol = {          dynamicRegistration = false,          hierarchicalWorkspaceSymbolSupport = true,          symbolKind = {            valueSet = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26 }          }        },        workspaceEdit = {          resourceOperations = { "rename", "create", "delete" }        },        workspaceFolders = true      }    },    clientInfo = {      name = "Neovim",      version = "0.9.4"    },    initializationOptions = vim.empty_dict(),    processId = 66843,    rootPath = "/Users/saket/Documents/oliv/autosched",    rootUri = "file:///Users/saket/Documents/oliv/autosched",    trace = "off",    workDoneToken = "work-done-token",    workspaceFolders = { {        name = "/Users/saket/Documents/oliv/autosched",        uri = "file:///Users/saket/Documents/oliv/autosched"      } }  }}
[DEBUG][2023-11-24 11:34:08] .../vim/lsp/rpc.lua:387	"rpc.receive"	{  jsonrpc = "2.0",  method = "$/progress",  params = {    token = "work-done-token",    value = {      kind = "begin",      percentage = 0,      title = "clojure-lsp"    }  }}
[DEBUG][2023-11-24 11:34:08] .../vim/lsp/rpc.lua:387	"rpc.receive"	{  jsonrpc = "2.0",  method = "$/progress",  params = {    token = "work-done-token",    value = {      kind = "report",      message = "Finding kondo config",      percentage = 5    }  }}

According to the specification

Until the server has responded to the initialize request with an InitializeResult, the client must not send any additional requests or notifications to the server. In addition the server is not allowed to send any requests or notifications to the client until it has responded with an InitializeResult, with the exception that during the initialize request the server is allowed to send the notifications window/showMessage, window/logMessage and telemetry/event as well as the window/showMessageRequest request to the client. In case the client sets up a progress token in the initialize params (e.g. property workDoneToken) the server is also allowed to use that token (and only that token) using the $/progress notification sent from the server to the client.

But again, fidget is not showing up even when we receive the $/progress messages from the LSP server.

I don't have a Clojure dev environment set up, so I am unable to reproduce this, but I've been lookin at the code and I have some theories about what might be happening.
First, I'm going to assume that the progress message is successfully received by Neovim's $/progress handler, though it would be great if you could validate this; just override the progress handler with a little logging:
local logger = require("fidget.logger")
local og = vim.lsp.handlers["$/progress"]
local function wrapped(x, result, ctx)
  logger.debug("got message from", ctx.client_id, vim.inspect(result))
  local res = og(x, result, ctx)
  logger.debug("nvim handler returned", res)
end
vim.lsp.handlers["$/progress"] = wrapped

On Fidget side, the LspProgress handler should call my poll_for_messages() function, which iterates through active LSP clients. I just added some extra logging in e732e65d6784ec1c34bb269ee69d635daffc4868; please update Fidget (and configure to INFO level logging) and let me know if it's finding those messages.

Hey John, do active clients mean the attached clients?
If so, it won't return clojure LSP as it's not yet attached ( but still
sending $/progress messages, which is allowed by the spec).
I will try to get more logs following the instructions you mentioned
tomorrow.
On Tue, Nov 28, 2023, 10:45 PM John Hui @.***> wrote:

I don't have a Clojure dev environment set up, so I am unable to reproduce
this, but I've been lookin at the code and I have some theories about what
might be happening.
First, I'm going to assume that the progress message is successfully
received by Neovim's $/progress handler
https://github.com/neovim/neovim/blob/35cec0de4acd351119230330f54b0a45f9823695/runtime/lua/vim/lsp/handlers.lua#L23-L57,
though it would be great if you could validate this; just override the
progress handler with a little logging:
local logger = require("fidget.logger")local og = vim.lsp.handlers["$/progress"]local function wrapped(x, result, ctx)
logger.debug("got message from", ctx.client_id, vim.inspect(result))
local res = og(x, result, ctx)
logger.debug("nvim handler returned", res)end
vim.lsp.handlers["$/progress"] = wrapped
On Fidget side, the LspProgress handler should call my poll_for_messages()
function, which iterates through active LSP clients
https://github.com/j-hui/fidget.nvim/blob/e732e65d6784ec1c34bb269ee69d635daffc4868/lua/fidget/progress/lsp.lua#L55.
I just added some extra logging in e732e65
https://github.com/j-hui/fidget.nvim/commit/e732e65d6784ec1c34bb269ee69d635daffc4868;
please update Fidget (and configure to INFO level logging) and let me
know if it's finding those messages.
—
Reply to this email directly, view it on GitHub
https://github.com/j-hui/fidget.nvim/issues/139#issuecomment-1830328475,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADXTLBPMIFBPZUUUUYSBLZLYGYL4HAVCNFSM6AAAAAA5DKHRYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZQGMZDQNBXGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

In the mean time, if you want to reproduce the issues:

Make sure you have java 8+ JDK installed
Install clojure: https://clojure.org/guides/install_clojure
Install leiningen: https://leiningen.org/#install
Create a project using lein template:
lein new luminus my-app +http-kit +shadow-cljs +reagent
Go inside the project and open a .clj file.

On Tue, Nov 28, 2023, 11:56 PM Saket Patel @.***> wrote:

Hey John, do active clients mean the attached clients?
If so, it won't return clojure LSP as it's not yet attached ( but still
sending $/progress messages, which is allowed by the spec).
I will try to get more logs following the instructions you mentioned
tomorrow.
On Tue, Nov 28, 2023, 10:45 PM John Hui @.***> wrote:

I don't have a Clojure dev environment set up, so I am unable to
reproduce this, but I've been lookin at the code and I have some theories
about what might be happening.
First, I'm going to assume that the progress message is successfully
received by Neovim's $/progress handler
https://github.com/neovim/neovim/blob/35cec0de4acd351119230330f54b0a45f9823695/runtime/lua/vim/lsp/handlers.lua#L23-L57,
though it would be great if you could validate this; just override the
progress handler with a little logging:
local logger = require("fidget.logger")local og = vim.lsp.handlers["$/progress"]local function wrapped(x, result, ctx)
logger.debug("got message from", ctx.client_id, vim.inspect(result))
local res = og(x, result, ctx)
logger.debug("nvim handler returned", res)end
vim.lsp.handlers["$/progress"] = wrapped
On Fidget side, the LspProgress handler should call my
poll_for_messages() function, which iterates through active LSP clients
https://github.com/j-hui/fidget.nvim/blob/e732e65d6784ec1c34bb269ee69d635daffc4868/lua/fidget/progress/lsp.lua#L55.
I just added some extra logging in e732e65
https://github.com/j-hui/fidget.nvim/commit/e732e65d6784ec1c34bb269ee69d635daffc4868;
please update Fidget (and configure to INFO level logging) and let me
know if it's finding those messages.
—
Reply to this email directly, view it on GitHub
https://github.com/j-hui/fidget.nvim/issues/139#issuecomment-1830328475,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADXTLBPMIFBPZUUUUYSBLZLYGYL4HAVCNFSM6AAAAAA5DKHRYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZQGMZDQNBXGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

@j-hui logs with above mentioned logging:
[INFO  Wed Nov 29 12:20:02 2023] /lua/fidget.lua:18: fidget.nvim setup() complete.
[DEBUG Wed Nov 29 12:20:02 2023] /Users/saket/.config/nvim/lua/user/config/lsp.lua:64: got message from  1 {
  token = "work-done-token",
  value = {
    kind = "begin",
    percentage = 0,
    title = "clojure-lsp"
  }
}
[DEBUG Wed Nov 29 12:20:02 2023] ...r/neovim/HEAD-8c6b0a5/share/nvim/runtime/lua/vim/lsp.lua:1152: nvim handler returns
[INFO  Wed Nov 29 12:20:02 2023] /lua/fidget/poll.lua:113: Poller ( progress ) polling once at 0.263s
[INFO  Wed Nov 29 12:20:02 2023] /lua/fidget/progress.lua:173: No LSP messages (that can be displayed)
[DEBUG Wed Nov 29 12:20:02 2023] /Users/saket/.config/nvim/lua/user/config/lsp.lua:64: got message from  1 {
  token = "work-done-token",
  value = {
    kind = "report",
    message = "Finding kondo config",
    percentage = 5
  }
}
[DEBUG Wed Nov 29 12:20:02 2023] ...r/neovim/HEAD-8c6b0a5/share/nvim/runtime/lua/vim/lsp.lua:1152: nvim handler returns
[INFO  Wed Nov 29 12:20:02 2023] /lua/fidget/poll.lua:113: Poller ( progress ) polling once at 0.264s
[INFO  Wed Nov 29 12:20:02 2023] /lua/fidget/progress.lua:173: No LSP messages (that can be displayed)
[DEBUG Wed Nov 29 12:20:02 2023] /Users/saket/.config/nvim/lua/user/config/lsp.lua:64: got message from  1 {
  token = "work-done-token",
  value = {
    kind = "report",
    message = "Finding cache",
    percentage = 10
  }
}
[DEBUG Wed Nov 29 12:20:02 2023] ...r/neovim/HEAD-8c6b0a5/share/nvim/runtime/lua/vim/lsp.lua:1152: nvim handler returns
[INFO  Wed Nov 29 12:20:02 2023] /lua/fidget/poll.lua:113: Poller ( progress ) polling once at 0.264s
[INFO  Wed Nov 29 12:20:02 2023] /lua/fidget/progress.lua:173: No LSP messages (that can be displayed)
[DEBUG Wed Nov 29 12:20:04 2023] /Users/saket/.config/nvim/lua/user/config/lsp.lua:64: got message from  1 {
  token = "work-done-token",
  value = {
    kind = "report",
    message = "Copying kondo configs",
    percentage = 15
  }
}
[DEBUG Wed Nov 29 12:20:04 2023] ...r/neovim/HEAD-8c6b0a5/share/nvim/runtime/lua/vim/lsp.lua:1152: nvim handler returns
[INFO  Wed Nov 29 12:20:04 2023] /lua/fidget/poll.lua:113: Poller ( progress ) polling once at 2.597s
[INFO  Wed Nov 29 12:20:04 2023] /lua/fidget/progress.lua:173: No LSP messages (that can be displayed)


fix: change reference of cni config to scripts dir

Reason for Change:

change reference of cni config to scripts dir
Issue Fixed:

Credit Where Due:
Does this change contain code from or inspired by another project?

[x] No
[ ] Yes

If "Yes," did you notify that project's maintainers and provide attribution?

[ ] No
[ ] Yes

Requirements:

[x] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Notes:

/azp run


Sea Level Predictor - Gitpod boilerplate dependencies issue

Describe the Issue
Error thrown:
AttributeError: module 'numpy.typing' has no attribute 'NDArray'
The issue seems to be with the PIL dependencies and/or NumPy. Not really sure if it is a peer dependency or if PIL is part of the docker image.
Forum post for context https://forum.freecodecamp.org/t/data-analysis-with-python-projects-sea-level-predictor/699393
Affected Page
https://www.freecodecamp.org/learn/data-analysis-with-python/data-analysis-with-python-projects/sea-level-predictor
Your code

Expected behavior
The Gitpod boilerplate not to throw errors.
Screenshots
No response
System

Device: [e.g. iPhone 6, Laptop]
OS: [e.g. iOS 14, Windows 10, Ubuntu 20.04]
Browser: [e.g. Chrome, Safari]
Version: [e.g. 22]

Additional context
No response

I updgraded numpy with pip:
pip install numpy --upgrade

It installed 1.24.4 version. After that scipy was giving errors, and after upgrading it:
pip install scipy --upgrade

To the 1.10.1 version project appears to work fine.
requirements.txt might need updating to these versions.


Allow user to add style sheet to DOCX or HTML

Let the user add their own style sheet to DOCX and HTML output types.  Maybe have options_docx and options_html functions to do it.

No longer necessary due to style objects.


FS disable FS_LARGEFILE by default

Summary
#4193 Introduced LFS support.
However it seems that it's enabled by default as well.
Whereas many applications don't have a need for LFS support i.e. FAT32 is 4GB limited and solutions such as NXFFS, LittleFS and SmartFS run on smaller flash chips.
Therefore I propose to disable this feature by default because it has a big impact on 32bit systems regarding program size and runtime memory size.
If people want to have to large file support on a microcontroller I think it makes sense they have to manually enable this feature.
Impact
CONFIG_FS_LARGEFILE Enabled
   text    data     bss     dec     hex filename
 162996     792   23856  187644   2dcfc nuttx

CONFIG_FS_LARGEFILE Disabled
   text    data     bss     dec     hex filename
 160268     792   23856  184916   2d254 nuttx

Testing

Seems that SPIFS also need to select an option


Enable gt in tools

Looks good to me. Gonna ask Sam about the check failure

This can land since it's not a required check. Following up with another PR to get that services Check passing.


Added: Add sort Functionality for journals

--- This PR is work in Progress ---
This PR closes #264.
It adds sort function with the following specifications:

Users should be able to define their own sort conditions for the journal with the options: Date, Priority and Title.
Users should be able to define more than one condition to sort by the first condition then by the next...
Users should be able to sort the journal ascending and descending

Progress:

[x] Set sort structures definitions and api
[x] Build UI dialog to let the users set their sort definitions
[x] Implement sorting with its own unit tests in the module.
[x] Integrate Sorting in the app with unit tests to check how it works with the filter
[x] Update Readme

@orhun Sorting is implemented here. However the selected option will not be persisted. I've creating another Issue to save the current app state which will solve it. For now if you want a work around for that you can change the Default Implementation for the Sorter struct in the file sorter.rs

Very nice, thanks!


where is the step history of the workflow ?

Originally posted by @yuedefeng in https://github.com/js-ojus/flow/issues/101#issuecomment-441347344

Please see the table wf_docevent_application for the history of document events applied to a given document.


Feed URL
https://www.andrewwalpole.com/feed.xml
More Info
No response

closed by https://github.com/murtuzaalisurti/rssed/commit/5aab921702885ea3008199e12280ab2adbe4df0d


Container resize

Resize the TTY for a container when using Run method

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "container_resize" git@github.com:juliengk/libcompose.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842354043440
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.


Documentation for deployment section is unclear

Environment information

OS: macOS

$ ape --version

0.7.8

What went wrong?
The documentation for deployment section for ape-config.yml is unclear.

How can it be fixed?
Update the documentation to cover

Is this section updated by some tool
Is this section updated manually
Which commands read this section of the configuration file

For clarity, the section is only updated manually, and it can be read when you do project.MyContract.deployments within ape
Agree it needs a lot of work to be useful


Add custom ecdsa implementation support

This PR adds support to allow the platform to define its own custom ecdsa implementation instead of the default one. This change is needed because each platform could use different crypto lib or hardware.
I previously made a PR that added a custom ecdsa tinycrypt implementation that is used in Matter. Because we need to add another ecdsa implementation and making a custom file for each one is not scalable, I opened this PR.
The custom ecdsa implementation will be placed in platform (e.g ot-nxp) and added in makefiles, e.g. here.

Yes, I can take a look. Thanks.

Hello @LuDuda , @jwhui . I've made the API, could you please take a look? Thank you.

Hello @abtink, I updated the API & format.
I had to move otCryptoSha256Hash from openthread/crypto.h to openthread/platform/crypto.h to avoid a circular inclusion. openthread/crypto.h includes openthread/platform/crypto.h but for the ECDSA API I would have to include openthread/crypto.h into openthread/platform/crypto.h which leads to other issues (otCryptoKey).

@andrei-menzopol , some of the CI checks are failing (e.g. ot-test-ecdsa). Can you help fix?

Thank you @abtink , @jwhui. I'll fix the CI tests.

Thank you

@andrei-menzopol , you'll need to increment OPENTHREAD_API_VERSION again.


Fatal Exception: std::__1::system_error recursive_mutex lock failed: Invalid argument

Description
Fatal Exception: std::__1::system_error recursive_mutex lock failed: Invalid argument
Crashed: com.google.firebase.crashlytics.ios.exception
0  FirebaseCrashlytics            0x1eea8 FIRCLSProcessRecordAllThreads + 393 (FIRCLSProcess.c:393)
1  FirebaseCrashlytics            0x1f288 FIRCLSProcessRecordAllThreads + 424 (FIRCLSProcess.c:424)
2  FirebaseCrashlytics            0x164d4 FIRCLSHandler + 34 (FIRCLSHandler.m:34)
3  FirebaseCrashlytics            0x111a8 __FIRCLSExceptionRecord_block_invoke + 232 (FIRCLSException.mm:232)
4  libdispatch.dylib              0x3fdc _dispatch_client_callout + 20
5  libdispatch.dylib              0x13574 _dispatch_lane_barrier_sync_invoke_and_complete + 56
6  FirebaseCrashlytics            0x101b4 FIRCLSExceptionRecord + 234 (FIRCLSException.mm:234)
7  FirebaseCrashlytics            0xfec4 FIRCLSTerminateHandler() + 404 (FIRCLSException.mm:404)
8  libc++abi.dylib                0x10f28 std::__terminate(void (*)()) + 20
9  libc++abi.dylib                0x10ec4 std::terminate() + 56
10 libobjc.A.dylib                0x33bec objc_terminate + 16
11 libdispatch.dylib              0x3ff0 _dispatch_client_callout + 40
12 libdispatch.dylib              0x15b8c _dispatch_root_queue_drain + 684
13 libdispatch.dylib              0x16284 _dispatch_worker_thread2 + 164
14 libsystem_pthread.dylib        0xdbc _pthread_wqthread + 228
15 libsystem_pthread.dylib        0xb98 start_wqthread + 8
Reproducing the issue
Don't know exactly when this crash happened but as per logs the last entry is adding an array of data to a document. See below code.
{
"notes" = "<FSTArrayUnionFieldValue: 0x28089b120>";
}
let noteMap = {} // Json of list of notes
let mapToCache = ["notes": FieldValue.arrayUnion([noteMap!])]
firestore
.collection("user")
.document("123")
.setData(mapToCache, merge: true)
Firebase SDK Version
10.1.0
Xcode Version
14.1
Installation Method
CocoaPods
Firebase Product(s)
Analytics, App Distribution, Crashlytics, Database, Firestore, Messaging, Performance
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

Drive-by comment: The only place in Firestore where we use std::recursive_mutex is in EventListener: https://github.com/firebase/firebase-ios-sdk/blob/43b6e276bf89d899bb3fadcafabd42b81f1ef759/Firestore/core/src/core/event_listener.h#L97. This is almost certainly related to another issue reported by @sspogra: https://github.com/firebase/firebase-ios-sdk/issues/10611. Something is going wrong with listener callbacks, and this issue appears to be another symptom.

After further investigation, this crash almost certainly has the same root cause as the other listener-related crashes that you've reported. I'm going to close this one and use https://github.com/firebase/firebase-ios-sdk/issues/10611 as the canonical issue to track progress. At this time, there is nothing more I can do without a reproducible scenario. Were you ever able to run your app with Address Sanitizer enabled? Can you try reproducing when your app is compiled in Release mode?


update docs

contributing docs need overhaul: instructions for running tests in particular.

To Do:

[ ] add graphviz install note
[ ] add description of command line usage (needs graphviz)
[ ] add non-interactive example to notebook (needs graphviz)
[ ] add an interesting complex example
[ ] update contributing docs
[ ] setup docs build


Use Async calls from AsyncHTTPClient

This was complex. Trying to return back the AsyncSequence from AHC in a generic way until I found AnyAsyncSequence in AHC. This simplified passing the body back from AHC through my own types.

Added AnyAsyncSequence as a generic method for passing AsyncSequences about.
Added ByteBufferAsyncSequence as a way to convert a ByteBuffer into an AsyncSequence of ByteBuffer slices.
Added HTTPBody to hold response payloads. This'll probably be also used in requests but I haven't got to that yet. If so I'll rename back to AWSPayload for some consistency. The HTTPBody no longer defines the type of data it holds (eg xml, json, raw data) this data is got from the serviceProtocol

Streaming requests and response currently don't work, so related code and tests may be commented out

Fixed the tests. There was a weird interaction between the test server which can only receive one request at a time and me not flush the response body when I don't expect one


Feature: Add support for the secure socks proxy

Background
This PR enables support for the secure socks proxy, which is a new feature in Grafana 10. The feature allows datasource connections to be proxied through a socks5 proxy with TLS. This enables Grafana users to connect to datasources that live in different networks than where Grafana is running when they cannot open up ports to the public internet.
Implementation notes

The feature itself no longer sits behind a feature toggle in Grafana OSS, but a feature toggle is being used in all non-core datasources until the datasource can upgrade the frontend dependency@grafana/runtimeto at least 10.0.0. At that point, we can switch this line to look at config.secureSocksDSProxyEnabled, rather than the feature toggle.
If in the future, clickhouse is moved to using the sdk to parse the http client settings, the code around parsing the secure socks proxy settings can be removed. Originally, I had tried to just parse the secure socks proxy settings like this, but that would cause a panic in the tests because tlsAuth is passed in as a string
Dependency updates:

clickhouse-go: need to include this PR to get the http based connection to work. This new version will be released tomorrow, so this PR is in draft until then.
grafana-plugin-sdk-go: Needs to run at least v0.159.0, where the setup functionality was added

Screenshots

Closes https://github.com/grafana/hosted-grafana/issues/3945

Nice! thank you for doing this work


Dependencies are specified with upper bounds, causing problems with resolution

Please unpin your dependencies. Python libraries specifying upper version boundaries or even versions pinned using ~=x.y.z or == cause problems when combined with other libraries: https://iscinumpy.dev/post/bound-version-constraints/
Pinning dependencies is OK if you are a) hacky shim around another library that needs to reach deeply into its guts (like aiobotocore is to botocore) and also b) are able to very quickly react to new releases of your parent library. If either of the two doesn’t apply, don’t specify upper bounds.
That you do manifests in bugs like, #357, #558, and downstream issues that not always reach you like this, this, or one we recently ran into, where botocore and boto3 versions were rendered incompatible due to s3fs.
You can configure your CI to regularly run with newer versions of your dependencies to catch problems with updated dependencies early.

What do you suggest that we do, when it is likely that newer releases of aiobotocore will break older versions of s3fs? The pin with fsspec is essential, they are always released together.

The pin with fsspec is essential, they are always released together.

That’s fine then, you maintain both and if you choose to do that and stick to it, there’s no problem.

What do you suggest that we do, when it is likely that newer releases of aiobotocore will break older versions of s3fs?

Aiobotocore being tied to botocore’s version makes sense. Aiobotocore has to hack deeply into botocore’s internals since it tries to make it do things it wasn’t designed for. That’s a brave endeavor, and limiting breakage by tying versions together here makes sense. It needs very active maintenance to work out though.
S3fs relies on aiobotocore’s abstractions to provide specific functionality. It should be able to only rely on stable APIs in aiobotocore. If it can’t do that, aiobotocore should have been discarded in the evaluation phase. If it can’t be relied on to provide stable APIs, it’s alpha quality software and shouldn’t be used as a dependency yet.

I can't really comment on whether aiobotocore is "alpha" or "beta", but we absolutely need it, as nothing else does what it does. We have indeed found cases where things have changed and broken our usage, but probably somewhat deeper than a typical user. See the code translating a/boto exceptions.

Luckily, https://github.com/fsspec/s3fs/commit/7ff31c5a6a3679acf38f5cffdba75f3d588e97cf implies it has a stable API. You just bumped the version without doing anything else. If you’d depend on aiobotocore>=2.1.0 instead, you wouldn’t have had to act at all and https://github.com/fsspec/s3fs/issues/558 would have never been filed.

We didn't know it would be problem free in this case. Previous version changes were not without problems, and once the package is on PyPI, we cannot change its deps to indicate that it is incompatible with some later version of aiobotocore. We choose to be conservative, and update our pin as soon as we can, and have a rapid release cycle ourselves.

we absolutely need

I think this, combined with the hackiness of botocore’s implementation is what leads to problems here.
Don’t get me wrong, I love Python’s async and there’s other projects that have the same problems (e.g. numba doing its byte code patching), but until aiobotocore is the upstream and botocore wraps it (which could be done non-hackily), there will be problems for anyone depending on it.

While you may well be right, I don't see that there's anything we can do about it in this repo. Indeed, I would love to see aio supported in botocore itself (I am in an issue to this effect on their tracker). Do you have any suggestions?

Since you said you positively need aiobotocore, I have nothing productive at this point.
I think an alternative for them would be to do their own codegen instead of error-prone monkeypatching. Or get talking with botocore people until they agree to collaborate & merge a PR fixing boto/botocore#458


1.14.5 fees UI

Love the humor, question though: how does increasing fee increase confirmation times right now, effectively?

ok. So, checked this out as well and - I like the simplicity and this is what I was aiming for; now, to Patrick's question... that's a good point: If someone were to set a higher fee, would it be mined sooner? With Bitcoin, their blocks are full so there's competition -- ours aren't full. So I think as it stands that slider actually wouldn't affect transaction priority. (Of course some day down the line, which we hope doesn't happen - it could.)  So maybe having the slider there is OK, but perhaps we can add a note that says "This slider will have no effect on speed unless network conditions"... something (i don't know the right phrasing right now..)
Technically, though, the review is a thumbs up...

So, linking fee height to confirmation speed CAN be a thing right now:

If you pay 1 DOGE per kb including rounding up, then you can be positive that ALL nodes relay your tx and that it gets mined quickly.
If you don't then you will only be relayed by 1.14.4+ nodes and only be mined by those miners that have upgraded past 1.14.3

However, I do not see that reflected in the implementation, so I think the speed thing is a bit misleading, at least for the current network.

It doesn't actually change confirmation time currently, I've put different fee values in for now but we could fix the number entirely, remove the slider. This is here because we wanted to have the slider do something, and it moves the discussion forward.

I've updated the placeholder fee values, but would note I don't know if we're targetting four options, so need to decide what the UI options as a precursor to finalizing the numbers.

So let's take a step back. The following situations can occur:

Connected to older peers, lowest fee filter is set at 1 DOGE/kb plus rounding or, say, most miners haven't upgraded yet - this means the maximum fee rate is 5.21 DOGE/kb (as the smallest tx the wallet makes would be 192kb)
Miners do upgrade but don't lower the fees - this would put the fees at 100x recommended fee rate
Miners do upgrade but decide that they only appreciate fees/10, not fees/100 -  this would put the fees at 10x recommended fee rate
Blocks are full, people need increments to get some sort of priority - 2x, 5x would probably do, or alternatively 2x 4x 8x

So the slider would then be:
0.01    0.02    0.05    0.1     1.0   5.21
|--------|-------|-------|-------|-------|

I think I'm inclined to push the slider back to 1.14.6, remove it entirely from 1.14.5 so we have a functioning solution with lower fees soon, and can examine adoption before deciding on this. What do others think?

@rnicoll  I agree.

The network currently is ~22.5% 1.14.4 and adoption is growing very slowly the past week. At 22.5%, this means 77.5%^8 = 13% of shibes will not connect to a 1.14.4 right now so it's too early to release. There is time to get this done and the slider is a user-friendly way of letting people determine their fees. So why not take the time to do it right? I don't see ANY pressure to release other than people wanting to take credit for the release.

@patricklodder That is a fair point. There are still quite a few things left on the dock that are high priority to get done  -- mostly security related stuff including #2459. If by the time we  are done with all those this is taken care of then all is fine. If we finish everything else first, then I would support releasing and delaying this one.

There are still quite a few things left on the dock [..]

Agree, but it's mostly important to prevent another fee disaster, as where last November, about 11% of transactions got stuck in the mempools, it would be a fantastic CF if devs would create the same problem again, by rushing a fee recommendation before the network is ready, and before there are controls in place to allow a resolution for transactions stuck and even more so since the recommendation PR got rushed by a private review deal between "core devs" while I had a review in progress on it, of which the devs that rushed it were aware, and as a result, the current fee logic is not fully consistent yet, and readability from a "reference implementation" point of view is terrifying. So we have time, and we need time: for this UI fix, for a consistent set of fees, and for the network to adapt to have a more reliably lenient mempool.
I was also hoping to get these UI changes in so that we can fixate translations, because that's a real mess, and then maybe we can get some internationalization fixed before release rather than just English and German, both of which are less important than for example Asian translations. I was also hoping to be able to do some build system and dependency upgrades while we still have time, but all this is getting endangered from an artificial release pressure. I understand people have a need for showing the world how awesome their new org is by doing press releases, but not at the cost of another round of transactions getting stuck for no reason other than developer vanity.
PS:

[..] high priority to get done -- mostly security related stuff including #2459.

#2459 cannot be high priority because in the field, 1.14 nodes do not use cmpctblock for announcements and on top, https://github.com/dogecoin/dogecoin/pull/2562#issuecomment-917395863 from today claims that it is broken (?!?) If anything regarding that is high priority it would probably - especially since today's claim - be to re-enable the test and make sure that whenever 1.21 nodes are going to imply they need cmpctblock messages, 1.14 nodes are not going to split the network up. The more 1.14 versions we can get out there that actually are tested to run the protocol they are advertising to support (meaning: cmpctblock by announcing version 70015) is going to help MUCH more than disconnecting a peer in an edge scenario for a protocol that requires leniency on pre-validation announces, which is guaranteed by that same version announcement. So if we want to bring that forward, we have to fix p2p-compactblocks.py first, then assess whether we need to do something with the protocol implementation per the claim in above mentioned issue comment, and only then will we be able to do something real with #2459.

@patricklodder I was referring to enabling enabling testing as you mentioned here, https://github.com/dogecoin/dogecoin/pull/2459#issuecomment-902982023. So, I think we both agree enabling that test and updating it is a priority. The resolution of the issue itself is another matter.

The more 1.14 versions we can get out there that actually are tested to run the protocol they are advertising to support (meaning: cmpctblock by announcing version 70015) is going to help MUCH more than disconnecting a peer in an edge scenario for a protocol that requires leniency on pre-validation announces, which is guaranteed by that same version announcement.

I agree. Given we moved #2459 from the last release, and that it was a quick fix to #2383, I wanted to get feedback on it. The work I did initially suggested fixing the original issue might be a lot of work, https://github.com/dogecoin/dogecoin/issues/2283#issuecomment-900708165. But, as you point out, it is better to get the testing working again and enforce the implementation later after assessing the situation then.

So if we want to bring that forward, we have to fix p2p-compactblocks.py first, then assess whether we need to do something with the protocol implementation per the claim in above mentioned issue comment,

We are in agreement.

Closing this, but keeping the branch in case we want to re-visit.

As said elsewhere - this was a UI mock up, I hadn't expected it to be reviewed for merging, so much as demonstrate what the UI could look like.
If however people do like the slider and it's just a matter of the fee boundaries, happy to re-open this. There are three options for the UI that I am aware of:

Change the slider to provide Dogecoin-friendly fee values (some variation of this).

Conscious that criticising my own PR looks strange, but having made this, I am not sure having values between 1.0 and 0.01 is useful.

Remove the slider entirely, and change the default action to be 0.01 DOGE fees.

Aware there are concerns of reliability, but initial tests suggest low fee transactions are mined consistently within minutes. I'll run more tests on main.

Replace the slider and custom with a pair of radio boxes, with 1.0 and 0.01 fees. Have not yet mocked up this option.

Removes options the user shouldn't be using currently.
More invasive UI change, makes it harder to re-introduce variable fees later.

I'll update this with Patrick's suggested boundaries and re-open it tonight. If we want a mock-up of the last option do let me know.

Today I learned if you force-push a closed branch, it won't let you re-open. I'll make a new PR. Sorry about that.


Inconsistent results of forward (training) and step (inference)

Hi, I did a simple test to verify the difference between forward and step (mode="dense") on a single unidirectional S4 layer. Given a random sequence, there difference, the absolute error is around 1e-2 and the square error is around 1e-4. I suspect these results are wrong. My verification follows test_step() in //src/models/sequence/ss/kernel.py. I'd love to know if you have examples that clearly compares their difference. Thanks:)

I suspect Cauchy kernel results this significant precision issue.

Thanks for the report! To clarify, your test shows that there may be numerical issues, but the code should be correct assuming high precision? Has this resulted in downstream performance issues?

Thanks for the report! To clarify, your test shows that there may be numerical issues, but the code should be correct assuming high precision? Has this resulted in downstream performance issues?

Thanks Albert. It is likely to be a numerical issue; but I am not sure whether it comes from fft/ifft or cauchy kernel, or both; will let you know when I got some updates. For downstream performance, I have no numbers yet, but this level of mismatch is likely to influence the last softmax. Did you use uni-s4 on some task and compare step and forward downstream performance?

Yes, we used the CNN mode (forward) for training and RNN mode (step) for inference in Sashimi. We generated sequences of over 100000 samples in step mode, so it has worked fine in practice. Perhaps the random inputs in your synthetic tests are an edge case.

Yes, we used the CNN mode (forward) for training and RNN mode (step) for inference in Sashimi. We generated sequences of over 100000 samples in step mode, so it has worked fine in practice. Perhaps the random inputs in your synthetic tests are an edge case.

Thanks, Albert. For "it has worked fine in practice", is the test NLL in the paper given by forward or step? The difference of waveforms can be marginal from human evaluation between the two forward schemes.

The test NLL is calculated the same way training is done, with "teacher forcing", so it uses forward. Step only makes sense for autoregressive generation in which case it doesn't make sense to calculate NLL the usual way.

I got the reason about the mismatch. It is a precision issue of the fast cauchy kernel. The symmetric trick you developed causing issues on float32, not float64. A fast way to verify it is, on float32,
Let A=z-w_half, B=z-w_half.conj(),
v_half/A+v_half.conj()/B ≠ v_half*B/A*B+v_half_conj*A/A*B

Just to double check, are you talking about the pykeops kernel or the CUDA extension?

CUDA extension.

Cool, good to know!


Cannot slide between sections. Will Jetpack Compose have some kind of ViewPager?

Is this an issue with any of the samples?


No longer working in PyCharm 2018.1.3?

Save actions does not seem to be working after upgrading to the most recent PyCharm version 2018.1.3.
Am I the only one seeing this?
FWIW
(1) I'm on OSX High Sierra
(2) Don't see anything in PyCharm logs

It should work, I'll try to test it.

For me it started to work again briefly and then went back to not working. Sadly I've become pretty dependent on it so that my current refractor is full of unused imports. obviously I can use the code refactoring tools built into pycharm directly but it's just no longer a knee jerk

Just tested in 2018.2.1 and it work. With plugin version 1.0.0
PyCharm 2018.2.1 (Community Edition)
Build #PC-182.3911.33, built on August 5, 2018
JRE: 1.8.0_152-release-1248-b8 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.8.0-59-generic


[sqllab] Fix sql lab resolution link

This PR makes the error resolution link get passed to the frontend separately in the payload as opposed to preformed html from the backend.
@graceguo-supercat @michellethomas @mistercrunch

Codecov Report

Merging #5216 into master will decrease coverage by <.01%.
The diff coverage is 64.28%.

@@            Coverage Diff             @@
##           master    #5216      +/-   ##
==========================================
- Coverage   63.46%   63.45%   -0.01%
==========================================
  Files         261      261
  Lines       19845    19852       +7
  Branches     1998     2000       +2
==========================================
+ Hits        12594    12598       +4
- Misses       7242     7245       +3
  Partials        9        9

Impacted Files
Coverage Δ

...uperset/assets/src/SqlLab/components/SouthPane.jsx
88.57% <ø> (ø)
:arrow_up:

superset/assets/src/SqlLab/reducers.js
57.98% <0%> (ø)
:arrow_up:

...uperset/assets/src/SqlLab/components/ResultSet.jsx
84.37% <0%> (-0.89%)
:arrow_down:

superset/sql_lab.py
75% <50%> (-0.41%)
:arrow_down:

superset/assets/src/SqlLab/actions.js
72.6% <88.88%> (+0.16%)
:arrow_up:

Continue to review full report at Codecov.

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

@johnbodley @mistercrunch done

PING


Version Android Manifest inserts an empty string instead of zero for version code

Azure DevOps Extension you are using
Version Android Manifest
Where are you running it?
Azure DevOps Service (VSTS)
Version of Extension/Task
2.0.4
Expected behaviour and actual behaviour
When using a version number like 1.0.0 I expect it to use "1.0" in the Version Name Pattern and "0" in the Version Code Pattern. However, when it attempts to build the project I get the error message:

src\JokeGenerator\JokeGenerator.Android\obj\Release\MonoAndroid81\android\manifest\AndroidManifest.xml(3,0): Error APT0000: String types not allowed (at 'versionCode' with value '').

These are the Task settings I am using:

And the build number format is $(date:yyyyMMdd)-1.0.0.$(rev:r).
If I simply change the build number format to $(date:yyyyMMdd)-1.0.1.$(rev:r) then everything works properly.
Steps to reproduce the problem
Use a version number that has a zero for the 3rd part and attempt to build the Android csproj. It will fail because the version code is blank instead of zero.
Additional Info
Here is the output from the Version Android Manifest task:
2018-10-15T05:56:46.9481266Z ##[section]Starting: Version Android Manifest
2018-10-15T05:56:46.9485245Z ==============================================================================
2018-10-15T05:56:46.9485323Z Task         : Version Android Manifest
2018-10-15T05:56:46.9485386Z Description  : Applies a version to an Android Manifest via the versionCode property based on the build number.
2018-10-15T05:56:46.9485433Z Version      : 2.0.4
2018-10-15T05:56:46.9485490Z Author       : Black Marble
2018-10-15T05:56:46.9485536Z Help         : Version: 2.0.4. [More Information](https://github.com/rfennell/vNextBuild/wiki/Version-Assemblies-and-Packages-Tasks/)
2018-10-15T05:56:46.9485585Z ==============================================================================
2018-10-15T05:56:47.2156898Z Source Directory:  D:\a\1\s
2018-10-15T05:56:47.2157418Z Filename Pattern: AndroidManifest.xml
2018-10-15T05:56:47.2157730Z Version Number/Build Number: 20181014-<IP_ADDRESS>
2018-10-15T05:56:47.2157867Z Version Filter to extract build number: \d+\.\d+\.\d+
2018-10-15T05:56:47.2158545Z Version Number Format: {1}.{2}
2018-10-15T05:56:47.2158700Z Version Code Format: {3}
2018-10-15T05:56:47.2158821Z Output: Version Number Parameter Name: OutputedVersion
2018-10-15T05:56:47.2366236Z Found 1 files to update.
2018-10-15T05:56:47.2366568Z Extracted Version: 1.0.0
2018-10-15T05:56:47.2383852Z Version Name will be: 1.0
2018-10-15T05:56:47.2385331Z Version Code will be 0
2018-10-15T05:56:47.2385431Z Will apply versionName: 1.0 and versionCode: 0 to 1 files.
2018-10-15T05:56:47.2392954Z Set the output variable 'OutputedVersion' with the value 1.0.0
2018-10-15T05:56:47.2456458Z ##[section]Finishing: Version Android Manifest

It says:

Version Code will be 0

But it seems that it uses an empty string. Unless zero is simply not a valid version code?
Hopefully you can address this one, even if the problem is that zero is not a valid version code, then just increment it to 1.
Thanks for the great extensions!

After discussion with @rfennell we're going to make it so the task fails if the Version Code would be 0. If we auto increment it to 1 then it'll almost certainly cause problems further down the line, mainly when you increment the minor version number.
I'd suggest making your Version Code {2}{3} or {1}{2}{3} to include the other version numbers into it and increase the chance it is unique.

Released in 2.1.x

Awesome, thanks for the info Chris. I've never created an Android app before so I didn't realize those specifics about the Version Code. I could potentially see the value decreasing accidentally when using {1}{2}{3} (e.g. going from version 1.10.3 to version 2.0.1), so I've opted to instead use $(Build.BuildId) as that should be an ever increasing integer value. We'll see how that goes. Thanks!


[Bug] SM4 encryption function encryption result error

Search before asking

[X] I had searched in the issues and found no similar issues.

Version
1.1.1
What's Wrong?
In the sample results of Doris, the SM4 encryption function returns the encryption content as' aDjwRflBrDjhBZIOFNw3Tg==', but the encryption results of the encryption program written in Java and the test website are both' LjZFimmUHZO4TghQCZ8z4w=='
The test website is: http://lzltool.com/SM4
The test is as shown in the figure

What You Expected?

How to Reproduce?
No response
Anything Else?
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Use unhex to wrap the key like
select to_base64(sm4_encrypt('text', unhex('F3229A0B371ED2D9441B830D21A390C3')));
then you will get the right result.

Use unhex to wrap the key like select to_base64(sm4_encrypt('text', unhex('F3229A0B371ED2D9441B830D21A390C3'))); then you will get the right result.

get√


How to specify config when creating a service

Hi,
I want to speficy a config when creating a service. like this:
docker service create -p 5000:80 --name test --config src=testConfig,target="app/testconfig.txt" myImage
How can I pass the configuration in the following code?
There seems to be no possibility to specify this
            await client.Swarm.CreateServiceAsync(new ServiceCreateParameters()
            {
                Service = new ServiceSpec()
                {
                    TaskTemplate = new TaskSpec
                    {
                        ContainerSpec = new ContainerSpec()
                        {
                            Image = "mirasoftde/test:aspnetapp"
                        }
                    },
                    EndpointSpec = new EndpointSpec()
                    {
                        Ports = new List<PortConfig>()
                        {
                            new PortConfig() { Name = "HTTP", Protocol = "tcp", TargetPort = 80, PublishedPort = 5000, PublishMode = "ingress" }
                        }
                    },
                    Name = name
                }
            });

Unfortunately the version of the Docker API this library supports ATM didn't have this option. It will require a version update but I will add this as a feature request for the next version.

Hi, is there anything blocking/preventing this to be added? And in general, anything that explains why there has been no new feature or release in quite a few months?

Is it now possible to add this?

I am able to create configs in swarm now as of the latest release of Docker.DotNet thanks to recent PR's, however once the config is created, I can't figure out how to then assign the config to a service as described by this issue.

think this can be closed RE https://github.com/dotnet/Docker.DotNet/issues/609


Create New Folder from Editor UI

Godot version
4.0 beta v4.0.alpha6.official [e4f0fc50f]
System information
Windows 10, Ryzen 5900X, RTX 3080, Vulkan
Issue description
Trying to create a folder from the context menu in the FileSystem tab will return the message "Could not create folder. File with that name already exists." This happens no matter the name given. The issue can be worked around by making a folder with the OS file system.
Steps to reproduce
Right click the FileSystem tab area and select New Folder. Give a name. Hit OK. No folder should be created.
Minimal reproduction project
No response

Duplicate of https://github.com/godotengine/godot/issues/59956.


Remove notebook from the examples and integrate with docs

📚 Documentation
Once #99 gets merged we will move the notebook from examples folder into a the docs folder / tutorials folder (? was unclear to me) and then include the lines on how to run napari from a notebook in the docs

We've left one notebook file in the examples, and now added instructions on how to launch napari here getting started tutorial


adds copilot snapshot during cf config setup

cloudfoundry can now dynamically inject route rules
based on data from copilot
during a snapshot, the config monitor will keep its config store in
tact if a connection error occurs while attempting to update itself.

Signed-off-by: Zach LaVallee<EMAIL_ADDRESS>

Hi @aaronshurley. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/assign @geeknoid

/ok-to-test

@aaronshurley: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-simple

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-bookInfo

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-simple

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-bookInfo

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-simple

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test istio-pilot-e2e

prow/e2e-simpleTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-bookInfo

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

ignore the prow test failure for now; they are broken on master/all prs

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-simple

prow/e2e-bookInfoTests.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
c9950dfb9ad7e91ca216709d21d7a590efb15ef7
link
/test istio-pilot-e2e

prow/istio-unit-tests.sh
f42937d2c27ff9c65f6bce04fbee834cf73f7a59
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ZackButcher @costinm could we get a cursory review on this? Should fall in line with the file snapshot pattern for config injection that we refactored into.

@costinm thanks for the review. For more details on how copilot is working you can actually see e2e test that we've constructed here (its got a mocked copilot but it should provide a rough sketch):
https://github.com/istio/istio/blob/master/tests/e2e/tests/pilot/cloudfoundry/copilot_test.go
copilot is meant to pull the relevant data from the Cloudfoundry API and hold it until Pilot / the Service Registry can come through and grab it.

@rshriram yes, thanks for pointing that out.  short answer: we will follow-up with optimizations.   we are still in this POC phase for everything CF+Istio, unfortunately.

@utako please comment here and note you've signed the CLA 👍

@aaronshurley: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
1a8b02771c88c4b9b9fb21d401e02f4128495b5e
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

I've signed the CLA.

@aaronshurley: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
cbb292333fb5c0fec162a372e9f389e515ef29f6
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
cbb292333fb5c0fec162a372e9f389e515ef29f6
link
/test istio-unit-tests

prow/istio-pilot-e2e.sh
26599b34e6349a74159971d96ca169fad6975347
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
26599b34e6349a74159971d96ca169fad6975347
link
/test istio-pilot-e2e

prow/istio-unit-tests.sh
029907db5b2ce005df64ba5ef9c0b8bcd8ced9ff
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
029907db5b2ce005df64ba5ef9c0b8bcd8ced9ff
link
/test istio-unit-tests

prow/istio-pilot-e2e.sh
029907db5b2ce005df64ba5ef9c0b8bcd8ced9ff
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test istio-unit-tests

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
029907db5b2ce005df64ba5ef9c0b8bcd8ced9ff
link
/test istio-pilot-e2e

prow/istio-unit-tests.sh
029907db5b2ce005df64ba5ef9c0b8bcd8ced9ff
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
029907db5b2ce005df64ba5ef9c0b8bcd8ced9ff
link
/test istio-pilot-e2e

prow/istio-unit-tests.sh
44aeeb1526f4094817c42131a0c550acb8565c83
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@aaronshurley: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
44aeeb1526f4094817c42131a0c550acb8565c83
link
/test istio-unit-tests

prow/istio-pilot-e2e.sh
44aeeb1526f4094817c42131a0c550acb8565c83
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

Prow is clear, please manually retest circle (I have no permissions)

/retest


[Bug] select2_multiple inside a tab doesn't render properly unless that tab is selected on page load

Bug report

What I've already tried to fix it
Will have a dig around and submit a PR if I can work it out.
Backpack, Laravel, PHP, DB version
When I run php artisan backpack:version the output is:
### PHP VERSION:
PHP 8.0.15 (cli) (built: Jan 21 2022 04:49:41) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.15, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.15, Copyright (c), by Zend Technologies

### LARAVEL VERSION:
v9.0.2@4c7cd8c4e95d161c0c6ada6efa0a5af4d0d487c9

### BACKPACK VERSION:
5.0.6@2be4ff8407259f528a3541f0569ce156bab63165

Addressed in #4201 !
Thanks again @olipayne 🙏


Add Telemetry Page

This adds a description of what telemetry we collect and when we send it. It also goes into detail about some of the inner workings of the telemetry system and what happens when it is disabled.

mike's suggestion on the first paragraph removed the "fairly minimal" wording, so that part wasn't needed. but I did add the italics for the other parts

Alright--the changes are in if the two of you want to take another look


⚠ ESPN has degraded performance

In bca56bb, ESPN (https://espn.com) experienced degraded performance:

HTTP code: 200
Response time: 1964 ms

Resolved: ESPN performance has improved in b5d204b.


Add Taker Fee Query

Closes: #XXX
What is the purpose of the change
Adds taker fee query and add it to stargate whitelist.
Needed for necessary calculations for all contracts that have dependency on calculation.
Testing and Verifying
This change is a trivial rework / code cleanup without any test coverage.
Documentation and Release Note

[ ] Does this pull request introduce a new feature or user-facing behavior changes?
[ ] Changelog entry added to Unreleased section of CHANGELOG.md?

Where is the change documented?

[ ] Specification (x/{module}/README.md)
[ ] Osmosis documentation site
[ ] Code comments?
[ ] N/A

devbot help

I didn't add CLI on purpose(didn't see any need for it), but on the second thought, why not :)
Added in the most recent commit and comfirmed that it fetches state correctly
./osmosisd q poolmanager trading-pair-taker-fee stake uosmo
taker_fee: "0.100000000000000000"


Feature request: list frequency of import/export arrows per file node

Summary
For context, I'm using skott to help port libraries between frameworks.
But porting a library with a team requires coordination and prioritisation.
I would like to prioritise files that are imported most frequently so less blockers occur.
Details
Could add a config somewhere to show how frequency of imports/exports per file on each node.
I'd imagine implementation is a matter of changing nodeId or some sort of name to display the number of imports and edges.
Or an alternative UX is to sort each row by number of exports.
Standard questions
Would you consider contributing a PR?
YES

Hey @MengLinMaker, thanks again for thinking about enhancing the visualization!

frequency of imports/exports per file on each node

Could you please provide an example of what you meant?

Hey @MengLinMaker, I can imagine relevant use cases where it would be valuable to have the number of times a given node is directly imported, as a file being imported X times means that a lot of nodes directly rely on it. We could even imagine graph clustering based on that kind of information.
About the exports, it seems like a different kind of information, a node having X exports could have a lot of meanings

@antoine-coulon
After giving this some thought, on file selection, the "in/out arrows" should be highlighted in different colours. Then colour coded numbers would quantify number of "in/out arrows" for better clarity as the number of arrows grow and becomes cluttered.
I believe this would improve what could be communicated through the UI.


Add support for GKEStartPodOperator

It would be great to add support for creating pods through GKEStartPodOperator to provide better integration with Google Kubernetes Engine (GKE).
GKEStartPodOperator extends KubernetesPodOperator to provide authorization using Google Cloud credentials. There is no need to manage the kube_config file, as it will be generated automatically. All Kubernetes parameters (except config_file) are also valid for the GKEStartPodOperator.
The chief benefit of using GKEStartPodOperator is to easily create pods in a different cluster than the airflow instance which is less trivial with KubernetesPodOperator.
Happy to have a stab at creating a PR.

I think the right approach may be to do this with https://github.com/astronomer/astronomer-cosmos/issues/427. There's probably a few other operators we'd want to support, so generalizing this makes more sense IMO. Curious to get your thoughts though!

I like the approach of adding the ability to have a custom subclass since that is more generalizable. I had briefly attempted this by monkey-patching the package to drop in a different subclass but that very quickly became unmaintainable.
I'll keep an eye out on https://github.com/astronomer/astronomer-cosmos/issues/427 in the meantime. Let me know if I can assist in any way.

Agree, monkey patching isn't sustainable in the long-term and I'd rather just support this directly in Cosmos 🙂
Opening this issue is super helpful! And if you have any other thoughts/ideas on #427 definitely feel free to drop a comment on that issue

@davidvanrooij #427 is available as part of Cosmos 1.2 - if you have a chance, please give it a try and let us know how it goes.
An alternative approach to run Cosmos in GCP is to wait for the PR #611 to be released and use ExecutionMode.VIRTUALENV (https://astronomer.github.io/astronomer-cosmos/getting_started/execution-modes.html#virtualenv).

@tatiana Awesome, thanks for the update. I'll give that approach a try and get back to you.


Fix field may be null, avoid throwing NullPointerException(#7619)

What is the purpose of the change
Fix field may be null, and NullPointerException will be thrown in FieldUtils
In this issue(#7619 ), this pr is to fix this issue, to avoid throwing NullPointerException in FieldUtils, thanks
Brief changelog
Verifying this change

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #7620 (ed04e00) into master (f8e25ec) will decrease coverage by 0.15%.
The diff coverage is 0.00%.

:exclamation: Current head ed04e00 differs from pull request most recent head 6249f6e.

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


Add THORNode chain info

THORChain is a decentralised liquidity network built with CosmosSDK.
https://gitlab.com/thorchain/thornode

Thanks for this PR!  Much appreciated!
Regarding the RPC endpoints, the field was meant more for the Tendermint rpc endpoints (which are used for broadcasting txs, etc).
It seems these endpoints are more for the nodes of chains connected to i.e. the endpoints of the BTC, ETH, LTC, etc nodes?
Agree it is useful to have these somewhere, but should probably be a new field.  (You can create a custom field in the json, that's not part of the original schema).

Updated as per your request. Indeed those endpoints were not valid tendermint rpc endpoints.
I also created the "sidechains_rpc" key where I added the values for BTC, ETH, LTC and so on.
Hope it has all the required information now.

Thanks!

@marius-avram wait why is the chain name thornode instead of thorchain?


Update Windows os image

updated image tag for windows os image

not sure what this file is but looks like it will not be checked in? seems like some github beta view thing

Looks like the PR has two files, we should remove the two in the "LocalMultiplayerAgentPublishFolder"


group.exile gives 411

i do group.exile([valid user id]) and it gives http 411
but
import json
r = await Client.request.request(url=f"https://groups.roblox.com/v1/groups/{group_id}/users/{user_id}",method="DELETE",data=json.dumps({}),noerror=True)

works fine so its an issue with da api
ples fix
kthx

I'm pretty sure your on the wrong version.

yeah that works, i was using the one off pip
soz


[WIP] Debian 8 shootout 0.3.0

Working to update Debian 8 shootout to version 0.3.0

Alpha -> Beta comments:
Looks like go stub should be updated?
ERROR protection against POODLE attack [reject sslv3.dshield.org:443]
      reason: stub exited with return code 1
      output: Get https://sslv3.dshield.org:443: tls: server selected unsupported protocol version 300
              exit status 1

Java stubs vs "output" on expected exceptions? It looks that more used practice is not to output expected exceptions.

looks good to me


Added files via upload

@vjd @dpastoor
I put PKPDsim through the standard evaluation we discussed.  The vanco/AG sheet attached by @vjd was very similar but less in depth.
What do you guys think?  Am I going about this the right way?
I have the rest of today and most of this week to get this done.

I think this is a good first start, and I think you can now move over to mrgsolve. I encourage you to dig around a bit more, the mrgsolve nonmem syntax will be more daunting than the simple syntax of PKPDsim. Refer back to some of the areas that I mentioned (like 'figuring out' the pow operator) as you enter into mrgsolve land. If you have some experience with C (from your interest in cython?) then you can more easily dig into the source code to look at how features are implemented. For better or worse with a lot of these open source packages, a substantial task in figuring out what a package is 'capable of' is often digging around in the source code. One area that can always be very valuable (though absent in PKPDsim) is look at the tests. This can give you insight to how the authors designed and are thinking about the api's


Update app-shell.md - Remove duplicate title

Remove duplicate title
Fixes: #6041

[ ] This has been reviewed and approved by (NAME)
[ ] I have run gulp test locally and all tests pass.
[ ] I have added the appropriate type-something label.
[ ] I've staged the site and manually verified that my content displays correctly.

CC: @petele

I signed it!

:tada: This has been pushed live to https://developers.google.com/web/


Memory utilization

Steps to reproduce
Link to live example: (required)
Steps:
1.
2.
3.
Current behavior
No response
Expected behavior
No response
Context
We have react js application integrated with MUI. When application is deployed production on Kubernetes, we observed size of MUI packages taking more than 350mb space.
packages taking extra space are @mui, @mui/icons-material
version used :5
Can you please suggest how to reduce bundle size of MUI packages, i referred below link but didn't get much help. Top level imports are used in application e.g. "import { Button, TextField } from '@mui/material';"
https://mui.com/material-ui/guides/minimizing-bundle-size/
Your environment
No response
Search keywords: memory

Are you talking about disk space?

@mui/icons-material with its dependencies takes 18.1MB https://packagephobia.com/result?p=%40mui%2Ficons-material
@mui/material with its dependencies takes 21.8MB https://packagephobia.com/result?p=%40mui%2Fmaterial

When we install node_module docker image for the application on Kubernetes @mui takes 170340 kb and @mui/icons-material takes 132948 kb.

Any solution to mentioned issue?


Renaming the Expression system

Drop the Sty prefix on everything
Rename Expr to Expression

Coverage remained the same at 65.282% when pulling 49331a0bf595ac70b889000cb7135640b9598762 on docs into 008ebe1b8fba9c1421268a2fc4c0cf8b19a09cfd on develop.

Strange that Travis is showing as failed, since the build clearly passed....
https://travis-ci.org/alcarney/stylo/builds/490711702
Merging


ReadConsoleInputStream demo

This is a demo that shows how we can have a stream-oriented view of characters from the console
while also listening to console events like mouse, menu, focus, buffer/viewport(1) resize events.
This has always been tricky to do because ReadConsoleW/A doesn't allow retrieving events.
Only ReadConsoleInputW/A returns events, but isn't stream-oriented. Using both doesn't work because
ReadConsoleW/A flushes the input queue, meaning calls to ReadConsoleInputW/A will wait forever.
I do this by deriving a new Stream class which wraps ReadConsoleInputW and accepts a provider/consumer implementation of BlockingCollection<Kernel32.INPUT_RECORD>. This allows asynchronous monitoring of console events while simultaneously streaming the character input. I also use Mark Gravell's great System.IO.Pipelines utility classes (2) and David Hall's excellent P/Invoke wrappers (3) to make this demo cleaner to read; both are pulled from NuGet.
(1) in versions of windows 10 prior to 1809, the buffer resize event only fires for enlarging
the viewport, as this would cause the buffer to be enlarged too. Now it fires even when
shrinking the viewport, which won't change the buffer size.
(2) https://github.com/mgravell/Pipelines.Sockets.Unofficial
https://www.nuget.org/packages/Pipelines.Sockets.Unofficial
(3) https://github.com/dahall/Vanara
https://www.nuget.org/packages/Vanara.Pinvoke.Kernel32
Oisin Grehan - 2019/4/21
https://twitter.com/oising
https://github.com/oising

The point of this is to make stream oriented work with VT sequences easier to do. This is the basis of my ongoing multiplexer project.

I'm good with this, but I'd like at least one other person to look (we do a 2-other-eyes policy for our code, generally). @DHowett-MSFT, @adiviness, @zadjii-msft, can one of you three give it a look?


Start week on sunday

Hello,
For my project I need for the week to start on sunday opposed to monday, and the documentation of this plugin doesn't say if it's possible.

Is there a possible way to look into modifying the module until the feature is added? I looked at the code, I see on line 2123, the Json string, although when digging into the code elsewhere, I see your calculations are based on Monday. Is there a simple fix that I am missing?

Hi @PauloKlixto, @jessicakennedy1028,
I have released a new version 1.34.0 that allows starting the week on Sunday with this option: start-week-on-sunday please refer to the API section https://antoniandre.github.io/vue-cal/#api.
Hope it helps,
let me know if you notice something unexpected!

Working example: https://codepen.io/antoniandre/pen/OdEgEq

@antoniandre
It worked perfectly!
Thanks for to add this feature.

Hi @PauloKlixto, @jessicakennedy1028,
I have released a new version 1.34.0 that allows starting the week on Sunday with this option: start-week-on-sunday please refer to the API section https://antoniandre.github.io/vue-cal/#api.
@jessicakennedy1028, indeed all my calculations were based on starting on Monday. I did a quick dev to help, I will do more tests tomorrow.
Hope it helps, let me know if you notice something unexpected!

it's 2024, but still it isn't mentioned in an official document of Vuecal, I expect new functions should be noted in the official site

Hey @Taeeon-kim, It's written in the API section. It does not need more because the name of the prop is very descriptive.
I'm currently working on V5 and the prop remains the same. I'll do an interactive example to showcase most of the props in v5.


fix(GATE-7): Call 'ceiling' on DAI bridge instead of 'maxTotalBalance'

Description of the Changes
Please add a detailed description of the change, whether it's an enhancement or a bugfix.
If the PR is related to an open issue please link to it.
Checklist

[ ] Changes have been done against master branch, and PR does not conflict
[ ] New unit / functional tests have been added (whenever applicable)
[ ] Test are passing in local environment
[ ] Docs have been updated
[ ] PR title is follow the Conventional Commits convention: <type>[optional scope]: <description>, e.g: fix: prevent racing of requests

This change is

:tada: This PR is included in version 1.5.0-dev.5 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.5.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


docs(readme): added an example to what

:tada: This PR is included in version 1.3.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Feature Request] Optionally sandbox icon detection to certain folders

[EDIT] Shortly after posting this I realized the vscode icon api wouldn't allow configuration like this. I'll leave it up in case the ideas are useful for the future.
The end goal of this suggestion is to allow users to have a zero-configuration appearance as follows:

This feature could have farther reaching implications (allowing a user to define folder-specific icon associations, for instance), but as far as the "why" of this request, it's really just to make the .vscode folder look a bit cleaner.

Currently, icons are applied regardless of position in the file tree. This allows for very easy configuration (seriously, that config is a work of art to my eyes), but doesn't support things like limiting icon detection to certain folders. For vscode-specific icons in particular this can be tricky because names like launch.json and tasks.json can be safely assumed to be used only for vscode configuration, whereas names like  extensions.json and (definitely) settings.json cannot.
A naive approach for implementing this feature would be to extend IFileExtension to include an optional folder configuration:
export interface IFileExtension extends IExtension {
  filename?: boolean; // set to true if the extension represents the whole file name.
  folders?: string[] // a whitelist of folder names to apply the extension in
  languages?: ILanguage[]; // collection of languages associated to the icon.
}

Note: all names and proposed interface changes are for demonstration purposes here, as more relevant implementations wouldn't be apparent to me
During file schema generation we can apply these folders to the defs field, skipping over matched files during application if their path doesn't match. As this is opt-in functionality, definitions without a folders property would continue to function as before.
Unfortunately, here we run into a snag: As the comment suggests, setting the folders property would immediately prevent icon application for all folders but those listed. For the vscode use case this is problematic, as files like .vscodeignore are expected to be in the root & adding the root to the proposed folders property would defeat the purpose of the sandbox. Expanding the type definition of folders would get messy fast, as we'd have more corners to check before we continue. Instead, we can add one more property to IFileExtension (also added in the defs object and consumed downstream):
export interface IFileExtension extends IExtension {
  filename?: boolean; // set to true if the extension represents the whole file name.
  folders?: string[] // a whitelist of folder names to apply the extension in
  allowInRoot?: string[] // a list of files to allow icon associations in the root directory, regardless of whitelists
  languages?: ILanguage[]; // collection of languages associated to the icon.
}

As the comment says, allowInRoot overrides folders, allowing us to move forward with the whitelist without worrying about files like .vscodeignore. Here is what our hypothetical new configuration for vscode would become:
{
  icon: 'vscode',
  extensions: [
    'launch.json',
    'tasks.json',
    'extensions.json',
    'settings.json',
  ],
  folders: [
    '.vscode',
  ],
  allowInRoot: [
    'vscodeignore.json',
    '.vscodeignore',
  ],
  filename: true,
  format: FileFormat.svg,
},

In the future, this can possibly be expanded to e.g. automatically apply uniform icons to all files within the whitelisted folders (or the aforementioned expansion of a user's ability to customize icons). However, due to the simplicity of the initial motivation & the possibility for scope creep during implementation, providing explicit support for these and other potential "side-effect" features is not included under this proposal.
Thanks for your time in reading my proposal! If a PR is welcome for this I can prepare a proof-of-concept. Have a nice day! :)
Checklist:

[x] I'm sure this issue is not a duplicate

@zackschuster Impressive study. Thanks for your time and input. If and when the vscode API gives such an ability, it's in our highest priority implementing it.

What about setting the icons based on parent icon, instead of the parent folder? Like this ... (I'm duplicating the src icon for example.)
{
   "icon": "src",
   "extensions": [ "custom_src" ],
   "format" : "svg",
   "extends": "src"
},
{
   "icon": "angular",
   "extensions": [ "environments" ],
   "children": true,
   "format" : "svg",
   "parent": "src"
}

So, it would style /custom_src/environments with the angular icon, because the icon of its parent was src

@ciel It's not supported by vscode so we can't do anything without injecting code directly to the app, something we want to avoid at all cost.


Builderror on linux 64 bit gcc

I pasted this code in my terminal while being in the root of RxCpp:
mkdir projects/build
cd projects/build
cmake -G"Unix Makefiles" -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_BUILD_TYPE=RelWithDebInfo -B. ../CMake
make```
I got the following output / error message:

~/dvl/cpp/RxCpp/projects/build$ cmake -G"Unix Makefiles" -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_BUILD_TYPE=RelWithDebInfo -B. ../CMake
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- CMAKE_CXX_COMPILER_ID: GNU
-- using gnu settings
-- RXCPP_DIR: /home/dhaeb/dvl/cpp/RxCpp
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.6")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dhaeb/dvl/cpp/RxCpp/projects/build
~/dvl/cpp/RxCpp/projects/build$ make
Scanning dependencies of target one_test
[  2%] Building CXX object CMakeFiles/one_test.dir/home/dhaeb/dvl/cpp/RxCpp/Rx/v2/test/test.cpp.o
/home/dhaeb/dvl/cpp/RxCpp/Rx/v2/test/test.cpp:11:21: fatal error: catch.hpp: No such file or directory
#include "catch.hpp"
^
compilation terminated.
make[2]: *** [CMakeFiles/one_test.dir/home/dhaeb/dvl/cpp/RxCpp/Rx/v2/test/test.cpp.o] Error 1
make[1]: *** [CMakeFiles/one_test.dir/all] Error 2
make: *** [all] Error 2
Where is the catch.hpp file? A ```find . -name "catch.hpp"``` couldn't find it ether...

catch is a git submodule. the initial clone should use --recursive switch, or use 'git submodule update --init --recursive' in your current clone.

Thanks I don't saw any hint in the readme regarding any git submodules.
Maybe I missed something there - but if not, I suggest it would be great to
inform the users.
Kirk Shoop<EMAIL_ADDRESS>schrieb am So., 10. Mai 2015 21:51:

catch is a git submodule. the initial clone should use --recursive switch,
or use 'git submodule update --init --recursive' in your current clone.
—
Reply to this email directly or view it on GitHub
https://github.com/Reactive-Extensions/RxCpp/issues/125#issuecomment-100688769
.


[Nomination] : JovanCBS

Technical expertise
https://github.com/sora-xor/sora2-network/tree/master/pallets/hermes-governance-platform
Community involvement
No involvement.
Content creation
No contet.
Leadership experience
No experience.
Mentorship experience
Yes
Mentorship details
Ni mentorship.

Thank you for submitting a nomination for Hero status! :sparkles:
A word about the process:
The team reviews nominations four times a year in March, June, September and December.
We commit to responding to every nomination within two weeks after the review process has completed.
How does this work? :eyes:
If you submitted this nomination in February, then it will be reviewed in March. :raised_hands:
if you submitted this nomination in November, then it will be reviewed in December. :raised_hands:
As a reminder, the criteria for review and selection for Hero status is publicly available in this GitHub repository.
You can continue to update your nomination form with new and relevant information up until the point of review.
Have any questions? Please don't hesitate to send us a message! :email:

Hi @JovanCBS, thank you again for submitting your nomination to become a Hero in the Polkadot Developer Heroes program.
We have briefly looked at your self-nomination, but unfortunately we haven't found enough information to make a fair evaluation.
Please note that we have recently updated our criteria to minimise subjectivity as much as possible and ensure fairness and transparency in the Hero selection process. You can look at the new criteria here. If you are still interested in applying to become a Hero, I'd like to encourage you to resubmit your nomination based on the updated guideline.
Thanks a ton for your interest in the Heroes program!

Hi @JovanCBS this is just a gentle reminder about your hero nomination. Please note that if you don't submit an updated nomination in a week, we close this issue. You can of course open a new one any time later in the future.

Closing this ticket now. Feel free to nominate yourself again in the future!


Adds Support for Configurable gRPC Listen Address

Fixes #113
Converts -grpc-port flag from an int to a string representing a host:port, ip:port or port. When port is specified, fnet.NormalizePort is used to generate :port used by the grpc listener. Since grpcClient() uses the -grpc-port flag, the setGRPCDestination function was added to construct the proper grpcping destination.

/cc @ldemailly

let's try to get this in so the readme update can be done too and I can make 0.6.8

@ldemailly I refactored this PR based on your feedback and all tests pass. Let me know if anything is needed to get this merged.


After update to 3.7.0 only 3 of 10 devices show up as local online

As the tille said I did do update through HACS from V3.6.0 to V3.7.0 and now only 3 of 10 devices show up local. Through cloud still 10 of 10 show up
Also it shows in system info 3/3 local devices and not 3/10 (see picture)

I am on H.A. 2024.4.3
EDIT. In the EweLink App the devices still show as LAN connected

https://github.com/AlexxIT/SonoffLAN#issues

4/5 devices is currently unavailable to control using Homeassistant.

I see no warnings/errors in my log
I am unsure how the debug page works
I'm attaching the diagnostic file

I have rebooted the system multiple times.
As I was busy posting this 2 of my devices have devices to come online and is now available. So I'm uploading a 2nd diagnostics file.
config_entry-sonoff-c6892c4c076a46a5b7600b452d683864.json
config_entry-sonoff-c6892c4c076a46a5b7600b452d683864 -2.json

After logging into the ewelink app and manually switching all devices off and back on, they are now available in Homeassistant.

@ianvnza how you mean switch off and back on?  All my devices are already in Off state, or you mean switching the LAN option off and on?

My devices were all in an off, so I just switched them on and the off again. The Lan option was already on and I didn't do anything there.

@ianvnza how you mean switch off and back on? All my devices are already in Off state, or you mean switching the LAN option off and on?

My devices were all in an off state, so I just switched them on and the off again. The Lan option was already on and I didn't do anything there.

@ianvnza unfortunately this not works for me, also did you try what happens if after this you reload the integration or reboot H.A.
@AlexxIT you can tell what you need from us please

@smarthomefamilyverrips after a reboot everything is unavailable in home assistant again and I have to toggle the power on them in the ewelink app again to get them available in homeassitant. So this is only a temporary "fix"

@smarthomefamilyverrips after a reboot everything is unavailable in home assistant again and I have to toggle the power on them in the ewelink app again to get them available in homeassitant. So this is only a temporary "fix"

@ianvnza thanks for testing! 👍 it seems we need to wait for a permanent fix then.

The answer was in the logs. Good thing the problem was on my server as well. Should be fixed in latest master version

The answer was in the debug logs. Good thing the problem was on my server as well. Should be fixed in the latest master version

@AlexxIT Thanks! 👍 Looking forward to the fix being applied.

Master version always available through HACS via manual redownload feature

Master version always available through HACS via manual redownload feature

@AlexxIT I did mean for the fix to be applied in the next regular update V3.X.X

https://github.com/AlexxIT/SonoffLAN/releases/tag/v3.7.1

Thanks @AlexxIT !!! 🥇 all working again after 3.7.1 💯


docs(README): Fix alt text of runkit shield

Coverage remained the same at 100.0% when pulling 2125182d6627f28d4308277e6d302025b6709bad on prtksxna:patch-3 into 6af9236ea8407213b86c750e92b6a52ff728be09 on decisively:master.