[WIP] KCL configuration files watch system design

Overview
The KCL dependency watch system is a component designed to monitor and manage dependencies within KCL projects. It is inspired by the efficiency and user-friendliness of tools like Cargo for Rust, aiming to provide a seamless development experience by handling real-time dependency updates and integration with the KCL language server.
Note: This issue serves as a work-in-progress outline for the design and implementation of the watch system.
Previous issues and discussions

#998
#1118
#1212

Design Goals

Real-time Feedback: Provide immediate updates on dependency changes.
Automation: Automatically handle dependency installation, updates, and removal based on configuration changes.
Integration: Seamlessly integrate with the KCL language server for a cohesive development environment.
User Experience: Mimic the ease of use and reliability of existing tools like Cargo.

Core Components
1. Watcher

Utilize a file system notification library (notify, to be specific) to monitor changes in the project directory.

cargo-watch is built upon the notify library (see here)

Operate asynchronously for responsiveness.

2. File Type and Change Detector

Analyze file extensions to determine file types, and map them to corresponding handlers.

3. Handler Registry

Manage operations for different tasks.

Resolve the information contained in the edited configuration files, compare it with the dependencies in current environment, and check if further operations are needed.
Trigger installation event, and run kcl mod add command.
Trigger update event, and run kcl mod update command.

The handlers can be extended to more general usage for other .json and .yaml files in the future.

4. Configuration Manager (optional for users, in order to lower the cost of releases)

Manage settings for the watch system, allowing customization through configuration files.
Possible configurations:

Decide the types of watching files (.mod, .k, .json, .yaml, etc.), and the logic for different configuration files.
Decide the paths of watching configuration files.

Example Workflow: Dependency Update on Configuration Change

KCL Language Server main loop starts and initializes the watcher. The watcher automatically detect the kcl.mod file in the project, and start monitoring for changes.
Developer modifies kcl.mod to add/update a dependency.
Watcher detects file change and triggers an event.
File Type Detector identifies type of the changed configuration file, and start the handlers.
Handler Registry calls for an handler to resolve the kcl.mod file and compare it with the packages in working environment, which turned out that the dependency has not been installed yet. It then triggers another add/update event, and runs kcl mod add/update xxx command.
CLI runs the right command, and the task is finished.

Challenges

Efficient Dependency Management: Ensuring that dependencies are only updated when necessary, without redundant operations.
Configuration File Parsing: Accurately interpreting kcl.mod to manage dependencies effectively.
Error Handling: Providing clear, actionable feedback for configuration errors or dependency conflicts.

Proposed Solutions

Implement incremental compilation checks to avoid unnecessary compiling.
Develop/Utilize a robust parser for kcl.mod to ensure accurate dependency management.
Integrate with the IDE to provide real-time error detection and resolution suggestions.

Manage operations for different tasks.
Resolve the information contained in the edited configuration files, compare it with the dependencies in current environment, and check if further operations are needed.

Trigger installation event, and run kcl mod add command.
Trigger update event, and run kcl mod update command.

what means of installation and update event? add or update dependencies in kcl.mod? If so, kcl mod update would be more appropriate

Hi @changsun20 😄
You can also add some design details, including:

API design: Watch System should be called to KCL LSP as a tripartite library, giving an API or abstract interface.

The contents of the Watch System should be divided into some subtasks, and the corresponding time point should be clearly defined. If it cannot be divided, the time point of the overall task can be given.

The Watch System and the integration of kpm and IDE are all the work, and the integration should be considered together with the watch system when planning the time schedule.

what means of installation and update event? It is user action of add/update dependencies in kcl.mod, or event in language server state? If so, kcl mod update would be more appropriate

Well, I think my initial thought was user action of add/update. So yes you are write, the language here is not precise enough.

1. API design: Watch System should be called to KCL LSP as a tripartite library, giving an API or abstract interface.

2. The contents of the Watch System should be divided into some subtasks, and the corresponding time point should be clearly defined. If it cannot be divided, the time point of the overall task can be given.

3. The Watch System and the integration of kpm and IDE are all the work, and the integration should be considered together with the watch system when planning the time schedule.

Sure, I'll handle these updates ASAP.


Could not read DB: Unknown Error: error decoding response body: missing field label

First, thank you for this code!   I just set it up and am trying to get it to work with my Google calendar.  I am getting the following error when using sui (and a similar when I use saturn).  I am quite familiar with Google APIs and code/cli in general, but a complete novice when it comes to rust and the cargo ecosystem.
thread 'tokio-runtime-worker' panicked at 'Could not read DB: Unknown Error: error decoding response body: missing field `label` at line 350 column 6', /home/evan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/saturn-cli-0.3.6/src/ui/state.rs:147:14

I installed using a simple cargo install saturn-cli and set up OAuth on my Google Workspace account (emphasis due to it possibly being relevant), and set the client id and secret.  I ran get-token and set the db-type to google.  Any query such as saturn l --all or saturn l -r fails, however I did set an event for today and it works fine with just saturn l
This points to an issue with an event I have in my calendar in the next 30 days, I believe.  Is there a way I could constrain the dates queried or otherwise dump more helpful information for debugging purposes?
(As a side query, and I'll connect it to this issue at the end: is there a option to dump a formatted output that can be parsed and used as input to another script?  JSON or YAML or shell or something?  I was thinking I could just dump it from the CBOR database, but it doesn't look to be stored in .saturn.db.  Perhaps that is related to this bug?)

ok. I think what happened here is that you need to rm -f $HOME/.saturn.db and run saturn list which will re-populate the db.
That said, this is less than desirable by any measure and I'm sorry you're going through this. I'll chip at it tonight and see if I can figure out a solution. Please report back if my workaround worked for you, it will help me write the patch.
Thanks!
------- Original Message -------
On Wednesday, September 20th, 2023 at 10:54 AM, Evan Edwards @.***> wrote:

First, thank you for this code! I just set it up and am trying to get it to work with my Google calendar. I am getting the following error when using sui (and a similar when I use saturn). I am quite familiar with Google APIs and code/cli in general, but a complete novice when it comes to rust and the cargo ecosystem.
thread 'tokio-runtime-worker' panicked at 'Could not read DB: Unknown Error: error decoding response body: missing field label at line 350 column 6', /home/evan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/saturn-cli-0.3.6/src/ui/state.rs:147:14
I installed using a simple cargo install saturn-cli and set up OAuth on my Google Workspace account (emphasis due to it possibly being relevant), and set the client id and secret. I ran get-token and set the db-type to google. Any query such as saturn l --all or saturn l -r fails, however I did set an event for today and it works fine with just saturn l
This points to an issue with an event I have in my calendar in the next 30 days, I believe. Is there a way I could constrain the dates queried or otherwise dump more helpful information for debugging purposes?
(As a side query, and I'll connect it to this issue at the end: is there a option to dump a formatted output that can be parsed and used as input to another script? JSON or YAML or shell or something? I was thinking I could just dump it from the CBOR database, but it doesn't look to be stored in .saturn.db. Perhaps that is related to this bug?)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

Regarding the need for a dump command; I avoided this initially because saturn can't back up your google calendar reliably, nor is it the goal of saturn to do so.
That said, I'm not opposed to the idea for limited uses, as long as everyone understands it won't contain everything google calendar does; I'm not even going to try and shave that yak.
Please put in a separate ticket for this request and I will address it.
------- Original Message -------
On Wednesday, September 20th, 2023 at 10:54 AM, Evan Edwards @.***> wrote:

First, thank you for this code! I just set it up and am trying to get it to work with my Google calendar. I am getting the following error when using sui (and a similar when I use saturn). I am quite familiar with Google APIs and code/cli in general, but a complete novice when it comes to rust and the cargo ecosystem.
thread 'tokio-runtime-worker' panicked at 'Could not read DB: Unknown Error: error decoding response body: missing field label at line 350 column 6', /home/evan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/saturn-cli-0.3.6/src/ui/state.rs:147:14
I installed using a simple cargo install saturn-cli and set up OAuth on my Google Workspace account (emphasis due to it possibly being relevant), and set the client id and secret. I ran get-token and set the db-type to google. Any query such as saturn l --all or saturn l -r fails, however I did set an event for today and it works fine with just saturn l
This points to an issue with an event I have in my calendar in the next 30 days, I believe. Is there a way I could constrain the dates queried or otherwise dump more helpful information for debugging purposes?
(As a side query, and I'll connect it to this issue at the end: is there a option to dump a formatted output that can be parsed and used as input to another script? JSON or YAML or shell or something? I was thinking I could just dump it from the CBOR database, but it doesn't look to be stored in .saturn.db. Perhaps that is related to this bug?)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

Regarding time windows for querying: please put in another ticket for this feature, I'm happy to do that as well.
------- Original Message -------
On Wednesday, September 20th, 2023 at 10:54 AM, Evan Edwards @.***> wrote:

First, thank you for this code! I just set it up and am trying to get it to work with my Google calendar. I am getting the following error when using sui (and a similar when I use saturn). I am quite familiar with Google APIs and code/cli in general, but a complete novice when it comes to rust and the cargo ecosystem.
thread 'tokio-runtime-worker' panicked at 'Could not read DB: Unknown Error: error decoding response body: missing field label at line 350 column 6', /home/evan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/saturn-cli-0.3.6/src/ui/state.rs:147:14
I installed using a simple cargo install saturn-cli and set up OAuth on my Google Workspace account (emphasis due to it possibly being relevant), and set the client id and secret. I ran get-token and set the db-type to google. Any query such as saturn l --all or saturn l -r fails, however I did set an event for today and it works fine with just saturn l
This points to an issue with an event I have in my calendar in the next 30 days, I believe. Is there a way I could constrain the dates queried or otherwise dump more helpful information for debugging purposes?
(As a side query, and I'll connect it to this issue at the end: is there a option to dump a formatted output that can be parsed and used as input to another script? JSON or YAML or shell or something? I was thinking I could just dump it from the CBOR database, but it doesn't look to be stored in .saturn.db. Perhaps that is related to this bug?)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

I put in several issues related to this ticket. #32, #33, #34.

can you try latest main branch and see if that fixes the DB reading bug? Alternatively, since this was actually in the https://github.com/erikh/gcal dependency, just re-installing saturn-cli from crates.io should pick it up and you can try that way; other bugs are fixed in main as well.

 This metadata may optionally contain a label, but in my google calendar API library I had accidentally made it required. I hope that helps you understand what is happening.

OK I'm pretty sure the core issue here was resolved; I'm closing this ticket. Please see the other issues to track your other concerns.

Sorry to have filed and run -- I had a series of minor emergencies on my end.  Thank you for the fast response; I will take a look in the next few days.  I understand completely what you meant by location having an optional part of the data structure and the code failing when it was not present.


Check the number is prime or not in Java

Information about Algorithm
I want to add an optimized solution to check whether the number is prime or not.
Inside -> algorithms/Java/Maths
Have you read the Contributing.md and Code of conduct

[x] Yes
[ ] No

Other context

Hey @ming-tsai @sourabhkumar47  I would like to contribute to this issue under the HACKTOBERFEST 2022.
Can you assign it to me?

I want to work on this kindly assign me this work!!

Hey @ming-tsai and @sourabhkumar47  Hope you are doing well, I would love to work on this issue can you please assign it me.

Hi @sourabhkumar47,
Are you going to working this issue?


Istio Envoy Proxy affects data plane of all deployed Services on AuthorizationPolicy change

We are experiencing a data plane interruption of all our Services deployed to Istio during the deployment of an AuthorizationPolicy to a specific namespace.

Each Service is in an independent namespace with its own set of Authorization Policies.
The data plane interruption causes an EOF to all active data plane traffic connections.
This causes all Services in the istio mesh to restart.

Where is this documented that this is by design?
The only solution we can find is an Istio-Agent env var: EXIT_ON_ZERO_ACTIVE_CONNECTION
Kubernetes: 1.28
Istio: 1.22.0

Think this is a bug.


Saperated CSS file from HTML

Going to style all the documentation.
Keeping the CSS rules away from html is good idea now, because CSS rules gonna grow.

Let's leave this as-is, makes it a bit easier to see everything when it's in one file. If the CSS grows beyond the current scope we can revisit.


layer sorting is incorrect

Particle Editor 1.4
Build date: Jun 15 2008
"v1.4:	Fixed a bug with particle system orientation. Orientation is now consistent with the Alo Viewer	(2008/06/15)"
Particle system orientation is still not consistent with the Alo Viewer or the game. It's reversed. Tested on Windows 7-10 systems (DX11+).

@MikeLankamp Do you still have the fixed code lying around? Apparently, the particle editor uploaded is an older version.

@Shimrra, why do you think it's an older version? This is the latest source code as I have it.

@MikeLankamp towards @Megabalta there are a couple of things in the current compiled version, that are fixed towards the changelog on modtools, e.g.

v1.4:	Fixed a bug with particle system orientation. Orientation is now consistent with the Alo Viewer

Haven't confirmed myself though.

I've just tested the above problem both on the old /v1.4 Build date: Jun 15 2008/ and the new /v1.5 (I could only test the 32 bit version, the 64 bit version won't star at all on win10 somehow, not even with compatibility troubleshooting) Build date: Jun 17 2017/ versions.
The problem is sadly still there (never mind the lack of textures, the new build won't reckognize the game directory, although I gave it in, game is GOG version btw.)

I just fixed the missing icons (I noticed that as well). Unfortunately I can't see your emitter settings. Can you please specify exactly how you create your emitters, or even better, zip up the saved particle file and attach it to this issue?
The 64-bit version starts for me (I'm on Windows 10 as well); I did get a warning about running a downloaded executable, but there's usually a way to click "continue" or similar. If it really doesn't work for you, can you please create a new issue for that with all the information (i.e. what does happen)?

You'll find the particle file (PE_AWINGENGINES.alo) and the model file (Rv_awing.alo) in the zip.
Open particle file in the particle editor, open model file in the alo viewer, look at the particles cyan and red emitters, which one is in the front. This is a mere visual problem in the particle editors playback window, it plays the particles emitter layout in reverse, which makes creating particles really hard, due to the need to always use the alo viewer/map editor to see how the particle looks like in the game.
test_particle.zip
I don't think the child emitter issue #3 is the same problem as this, since that's occuring ingame, thus is not a visual problem of the particle editors playback window. I'll create a separate an issue for that.
(I won't create an issue for the 64-bit version, since sadly I can't tell more: I press start on the 64-bit version, press continue in the windows warning, mouse cursor changes to loading cursor, then reverts back to normal cursor, nothing happens, I'm sorry I can't help with that any further)


iOS Crash at beginning of user session with EXC_BAD_ACCESS KERN_INVALID_ADDRESS

Description
2% of iOS users are experiencing crashes in our app. In firebase, we see "100% of crash events for this issue happened in the first 5 seconds of a user's session". Crashes started happening after introducing react native into both native apps. This is the first release with react native, so it is unknown which packages/versions might be causing the issue. All js code is currently behind a feature flag and the feature flag is not enabled for users experiencing the crash, so no js code should be called.
Crash Stack Trace:
Crashed: com.facebook.react.JavaScript
0  App                  0x4d22fc facebook::react::Instance::callJSFunction(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&&, folly::dynamic&&) + 177 (Instance.cpp:177)
1  App                  0x432280 __53-[RCTCxxBridge enqueueJSCall:method:args:completion:]_block_invoke + 365 (dynamic-inl.h:365)
2  App                  0x431e1c __30-[RCTCxxBridge _runAfterLoad:]_block_invoke + 1354 (RCTCxxBridge.mm:1354)
3  App                  0x436fe4 facebook::react::tryAndReturnError(std::__1::function<void ()> const&) + 505 (function.h:505)
4  App                  0x42d304 -[RCTCxxBridge _tryAndHandleError:] + 344 (RCTCxxBridge.mm:344)
5  Foundation                     0x3b000 __NSThreadPerformPerform + 264
6  CoreFoundation                 0xd622c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
7  CoreFoundation                 0xe2614 __CFRunLoopDoSource0 + 176
8  CoreFoundation                 0x6651c __CFRunLoopDoSources0 + 244
9  CoreFoundation                 0x7beb8 __CFRunLoopRun + 836
10 CoreFoundation                 0x811e4 CFRunLoopRunSpecific + 612
11 App                  0x42d23c +[RCTCxxBridge runRunLoop] + 335 (RCTCxxBridge.mm:335)
12 Foundation                     0x5ace8 __NSThread__start__ + 716
13 libsystem_pthread.dylib        0x16cc _pthread_start + 148
14 libsystem_pthread.dylib        0xba4 thread_start + 8

Version
0.70.5
Output of npx react-native info
System:
OS: macOS 12.6
CPU: (10) x64 Apple M1 Max
Memory: 7.21 GB / 64.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 14.17.6 - ~/.nvm/versions/node/v14.17.6/bin/node
Yarn: 1.22.19 - /usr/local/bin/yarn
npm: 6.14.15 - ~/.nvm/versions/node/v14.17.6/bin/npm
Watchman: Not Found
Managers:
CocoaPods: 1.11.3 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 22.1, iOS 16.1, macOS 13.0, tvOS 16.1, watchOS 9.1
Android SDK:
API Levels: 28, 29, 30, 31, 32, 33
Build Tools: 30.0.2, 30.0.3, 31.0.0, 32.0.0, 32.1.0, 33.0.0
System Images: android-30 | Google APIs ARM 64 v8a, android-32 | Google APIs ARM 64 v8a
Android NDK: Not Found
IDEs:
Android Studio: 2021.3 AI-213.7172.25.2113.9123335
Xcode: 14.1/14B47b - /usr/bin/xcodebuild
Languages:
Java: 11.0.15 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 18.1.0 => 18.1.0
react-native: 0.70.5 => 0.70.5
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Steps to reproduce
We are unable to reproduce the issue. We are relying on Firebase. Only 2% of users are affected.
Snack, code example, screenshot, or link to a repository
App Delegate Snippet:
class AppDelegate : UIResponder, UIApplicationDelegate, RCTBridgeDelegate {
    func sourceURL(for bridge: RCTBridge!) -> URL! {
        return RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
    }

    var window: UIWindow?
    let pushRegistration = PushRegistration()

    private let pushMessageHandler = PushMessageHandler()
    private let notificationDataModel = NotificationDataModel.sharedInstance
    private var loadDashFileHelper = LoadDashboardSettingsAlertHelper()
    private var networkServicesManager: NetworkServicesManager?
    private var appStateManager: AppStateManager?
    private let networkMonitor = NetworkMonitor()

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
        setupDependencies()
        setupRootView()
        setupBackgroundAppRefresh()
        setupAppleHealthMicroFeature()
        setupRefresh()
        setupCloudKeyValueStore()
        setupServices(withLaunchOptions: launchOptions)
        setupSingletonDependencies()

        networkServicesManager = NetworkServicesManager()
        appStateManager = AppStateManager()

        DeepLinkOperator.pause()

        var jsCodeLocation: URL!
        jsCodeLocation = RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")

        _ = RCTRootView(
            bundleURL: jsCodeLocation!,
            moduleName: "",
            initialProperties: nil,
            launchOptions: launchOptions)

        notificationDataModel.start()

        if UITestUtility.isUITest {
            logoutUser()
        }

        return true
    }

Bridge used to insert RN into Native sections of the app.
import Foundation
import React

class ReactNativeBridge: UIResponder, RCTBridgeDelegate {
    static let sharedInstance = ReactNativeBridge()
    var bridge: RCTBridge?

    func createBridgeIfNeeded() -> RCTBridge {
        if bridge == nil {
            bridge = RCTBridge(delegate: self, launchOptions: nil)
        }
        return bridge!
    }

    func viewForModule(_ moduleName: String, initialProperties: [String : Any]?) -> RCTRootView {
        let viewBridge = createBridgeIfNeeded()
        let rootView = RCTRootView(bridge: viewBridge, moduleName: moduleName, initialProperties: initialProperties)

        return rootView
    }

    func sourceURL(for bridge: RCTBridge!) -> URL! {
        return RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
    }
}

imports added to Bridging Header:
#import <React/RCTBridgeModule.h>
#import <React/RCTBridge.h>
#import <React/RCTEventDispatcher.h>
#import <React/RCTRootView.h>
#import <React/RCTUtils.h>
#import <React/RCTConvert.h>
#import <React/RCTBundleURLProvider.h>
#import <React/RCTBridgeDelegate.h>

List of Dependencies:
 "@react-native-async-storage/async-storage": "^1.17.11",
        "@react-native-community/blur": "^4.2.0",
        "@react-native-community/cli-platform-android": "^9.1.0",
        "@react-navigation/native": "^6.0.13",
        "@react-navigation/native-stack": "^6.9.0",
        "@segment/analytics-react-native": "^2.9.1",
        "@segment/sovran-react-native": "^0.4.5",
        "@testing-library/react-native": "^11.1.0",
        "d3": "^7.6.1",
        "d3-array": "^3.2.0",
        "d3-path": "^1.0.5",
        "d3-scale": "^4.0.2",
        "d3-selection": "^1.1.0",
        "d3-shape": "^1.2.0",
        "eslint-plugin-promise": "^6.1.0",
        "jest": "^29.0.3",
        "jest-fetch-mock": "^3.0.3",
        "moment": "^2.29.4",
        "patch-package": "^6.4.7",
        "react": "18.1.0",
        "react-native": "0.70.5",
        "react-native-gesture-handler": "^2.8.0",
        "react-native-linear-gradient": "^2.6.2",
        "react-native-reanimated": "^2.11.0",
        "react-native-redash": "^18.0.0",
        "react-native-safe-area-context": "^4.4.1",
        "react-native-screens": "^3.18.0",
        "react-native-svg": "^13.4.0",
        "react-native-vector-icons": "^9.2.0",
        "react-test-renderer": "18.1.0"

@avenable8 was this resolved?

This is resolved and was programmer error. We were initializing the js bundle in the app delegate, but we weren't assigning it to anything, and then we were also initializing it in the data bridge... so we deleted it from the app delegate.

@shaverda, Thanks for updating. Can you please share the code snippet of app delegate which is currently working. Thanks in advance.

@avenable8 did you finally find any solution for this?


CPU is constant high using discovery on proxmox and hassos

After using the script and changing the ip to static ip as instructed, hassio started fine (awesome job). But CPU is running high (constant 80-90) even now after one hour. I am running this on a 32 Gig memory, I3 256G ssd. My hassio install on a debian vm runs at 1-3% cpu. Efter testing some stuff i removed the discovery component and the CPU issue was gone! Anyone seeing this?

I have a Celeron J3455 with 2 Gigs (allocated), 240 gig HDD ( 32gig allocated) and I have a secnd implementation (identical) -- Im showing 5-10% CPU usage for each VM, it does peak to 50 or 60 at times for a second or two (I have 3 cameras running- so I think that is the explanation).
Not sure why you are seeing this. This script sure made it easy for me to get this up and running, completely new to Linux.
Good luck!

I found out what it was. It was the yeelight discovery that was causing the problems. If I disabled the yeelight discovery it worked. @SirRedZ ..


runtime: use of AddVectoredExceptionHandler on windows is ill-advised

What version of Go are you using (go version)?

> go version
go version go1.19 windows/arm64

Does this issue reproduce with the latest release?
Yes, with the latest major version (1.19).
What operating system and processor architecture are you using (go env)?
go env Output
> go env
set GO111MODULE=
set GOARCH=arm64
set GOBIN=
set GOCACHE=C:\Users\billziss\AppData\Local\go-build
set GOENV=C:\Users\billziss\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=arm64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\billziss\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\billziss\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_arm64
set GOVCS=
set GOVERSION=go1.19
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-mthreads -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\billziss\AppData\Local\Temp\go-build481145130=/tmp/go-build -gno-record-gcc-switches

What did you do?

I ran a Golang program that uses a DLL that raises a benign Windows exception in a non-Golang thread. This results in a call to runtime.badsignal2.
What did you expect to see?
I expected the program to run without any problems as the Windows API can handle the benign exception internally.
What did you see instead?
On windows/arm64 I saw a crash because of related problem #56080.
Problem and solution
The initExceptionHandler uses AddVectoredExceptionHandler to add a Vectored Exception Handler. This use looks ill-advised. Windows components (and some third party applications and DLLs) regularly use Structured Exception Handling to report benign errrors, such as "Access Denied". Vectored Exception Handlers run prior to the regular Structured Exception Handlers in Windows. This means that the Golang runtime preempts the regular processing of benign errors and mistakenly thinks that an unrecoverable error has happened.
A likely fix is not to call AddVectoredExceptionHandler.
See also
#56080
https://github.com/rclone/rclone/issues/5828#issuecomment-1269934140

This use looks ill-advised. Windows components (and some third party applications and DLLs) regularly use Structured Exception Handling to report benign errrors, such as "Access Denied". Vectored Exception Handlers run prior to the regular Structured Exception Handlers in Windows

SEH exceptions from non-Go DLLs should be ignored by firstcontinuehandler. The firstcontinuehandler calls isgoexception function to determine if exception is raised by Go, and if not, then passes exception handling back to non-Go DLL by returning EXCEPTION_CONTINUE_SEARCH.
I suspect the problem that you encountered is that you are having exception on non-Go thread. I don't believe that is supported by Go runtime.
If my memory does not fail me Go introduced use of 2 handlers with AddVectoredExceptionHandler to solve problems that you just described - see #8006 for details.
I am pretty sure we tried to implement SEH handlers on amd64 but failed. Windows amd64 binaries that support SEH handling require complete stack information present in the exe. We could not find enough details to implement that.
Alex

The problem with vectored exception handlers is that they see every exception regardless of whether the exception is one that was going to be handled or not. You are correct that in the original issue that prompted this one, the problem likely happens because we have a Windows exception in a non-Go thread.
However even if this was a Windows exception in a Go thread it is not clear to me why the Go runtime should see the exception. A lot of Windows API's use exceptions to implement complicated control flow and injecting Go code execution in that flow seems wrong.
I propose instead an alternative policy for unhandled exception handling that ensures that no Go code runs unless the exception is genuinely not going to be handled. (Please note that I have a limited understanding of the Go runtime and my proposal may in fact be misguided.)
The following C code illustrates:
static VOID UnhandledException(PEXCEPTION_POINTERS ExceptionInfo)
{
    // ... additional code goes here
    ExitProcess(ExceptionInfo->ExceptionRecord->ExceptionCode);
}

static LONG WINAPI UnhandledHandler(PEXCEPTION_POINTERS ExceptionInfo)
{
    UnhandledException(ExceptionInfo);
    return EXCEPTION_CONTINUE_EXECUTION;
}

static LONG NTAPI ContinueHandler(PEXCEPTION_POINTERS ExceptionInfo)
{
    UnhandledException(ExceptionInfo);
    return EXCEPTION_EXECUTE_HANDLER;
}

VOID InitializeExceptionHandling(VOID)
{
    SetUnhandledExceptionFilter(UnhandledHandler);
    AddVectoredContinueHandler(0, ContinueHandler);
}

This works by setting an "unhandled exception filter" and a "vectored continue handler". There are two cases to consider:

Not running under a debugger. In this case UnhandledHandler will be called and we can do our unhandled processing here and terminate the process.

Running under a debugger. In this case UnhandledHandler will not be called. However ContinueHandler will be called and we can do our unhandled processing here and terminate the process.

Notice that we have eliminated the need for AddVectoredExceptionHandler but we can still process unhandled exceptions in all cases, whether being debugged or not. This technique handles all kinds of exceptions, including Access Violations, RaiseException and C++ throw.
I close with a brief description of the Windows exception dispatching mechanism. It proceeds in three phases:

Vectored exception handlers.

If any of these handlers returns EXCEPTION_CONTINUE_EXECUTION subsequent vectored exception handlers and structured exception handlers are not invoked; however vectored continue handlers are invoked.

Structured exceptions handlers.

If any of these handlers returns EXCEPTION_CONTINUE_EXECUTION subsequent structured exception handlers are not invoked; however vectored continue handlers are invoked.
The system wraps every thread with a catch-all exception handler called UnhandledExceptionFilter. This catch-all handler is only used if no other handler handles the exception. This handler is also responsible for calling the handler set by the SetUnhandledExceptionFilter API, unless a debugger is active in which case it returns EXCEPTION_CONTINUE_EXECUTION (and vectored continue handlers will be invoked).

Vectored continue handlers.

These handlers are only invoked if execution is being continued.

I propose instead an alternative policy for unhandled exception handling that ensures that no Go code runs unless the exception is genuinely not going to be handled.

Thank you @billziss-gh for your detailed explanation.
Unfortunately I don't have time and knowledge to even consider your proposal. So leaving it to others.
CC @qmuntal in case you are interested
@qmuntal perhaps you also might be interested to be part of @golang/windows group.
Alex

Thanks for the detailed context @billziss-gh, this thread contains good info, I'll need time to process it.
Setting aside the vectored vs structured exception handling discussion, I'm still not convinced that the current approach precludes other DLLs to handle exceptions raised in non-Go threads. runtime.badsignal2 does abort the process without escape hatch, but, if I'm not wrong, windows/amd64 does not call runtime.badsignal2 when there is an exception in a non-Go thread. There might be a bug in windows/arm64 which causes runtime.badsignal2 to be called when it shouldn't.
@billziss-gh could you provide a minimal program that demonstrates the issue, so I want better understand what you need? Something like this: https://github.com/golang/go/tree/master/src/runtime/testdata/testwinlib.

@qmuntal
I have created throw-away repo golang-veh which allows for some experimentation with the following scenarios:

RaiseExcept: Raise and catch an exception in a Go thread.
RaiseNoExcept: Raise but do not catch an exception in a Go thread.
ThreadRaiseExcept: Raise and catch an exception in a non-Go thread.
ThreadRaiseNoExcept: Raise but do not catch an exception in a non-Go thread.

I then tried these scenarios against stock Go 1.19 with and without the debugger (WinDbg Preview) on x64 and arm64.
Results for Go threads were good (with or without the debugger):

RaiseExcept: Raising and catching an exception in a Go thread works as expected, although I confirmed under WinDbg that sigtramp is called unnecessarily, because of Golang's use of vectored exception handlers.

RaiseNoExcept: Raising and not catching the exception in a Go thread also works as expected, in that the Golang runtime catches the exception and prints a reasonable stack trace.

Results for non-Go threads were not good:

ThreadRaiseExcept:

x64: Raising and catching an exception in a non-Go thread works as expected in x64 (with or without the debugger). Again I confirmed however that sigtramp is called unnecessarily.
ARM64: Raising and catching an exception in a non-Go thread does not work on ARM64.

Without the debugger: The program crashed in badsignal2 (#56080)
With the debugger: The program should have crashed in badsignal2, but by chance the R3 register is initialized to 0, which allows the program to print runtime: signal received on thread not created by Go endlessly. (The endless printing is because the exception handling mechanism is reentered because of how runtime.abort tries to abort the process by causing another exception.)

ThreadRaiseNoExcept:

x64: Behavior differs with and without the debugger:

Without the debugger: Program simply dies without any diagnostic, no error dialogs or WER, etc.
With the debugger: Program returns from ThreadRaiseNoExcept. It should not since we raised an exception that is not being caught. (This is likely because the debugger is able to continue exceptions.)

ARM64: This never executes under ARM64, because we have already bailed when running the previous test ThreadRaiseExcept.

Overall it looks to me that the exception handling code for Windows needs some TLC.

Thanks for the sample repo. It helped me understand the problem and (hopefully) come up with a solution for arm64, see CL 442896.
I still don't know what you would expect from ThreadRaiseNoExcept. AMD64, and soon ARM64, ignores the exception and dies with exit status 42 (being 42 the error code in RaiseException.
How could we do a better job? We could print stack traces, but IMO they would be meaningless as the exception would have happened in a non-Go thread which we have little information. Handling the exception at the end of the chain with SetUnhandledExceptionFilter wouldn't make it much better. At most we could print (if possible) something like: unhandled exception 42.

@qmuntal I appreciate your work on this and it looks like it fixes the important problem with ThreadRaiseExcept on ARM64.

I still don't know what you would expect from ThreadRaiseNoExcept... How could we do a better job?

My primary point when I opened this issue was that the Go runtime should not inject code in the control flow of non-Go code (e.g. a Windows API) that experiences an exception that is going to be handled. This is not just pedantic: the issue with ThreadRaiseExcept would not have happened if the Go runtime had a different exception policy.
There were some additional issues that came up during subsequent experimentation. For example, ThreadRaiseNoExcept has inconsistent behavior with and without the debugger.

We could print stack traces, but IMO they would be meaningless as the exception would have happened in a non-Go thread which we have little information.

I agree, but this is also why I ask the question: why does the Go runtime catch these exceptions?

In any case I do not have a strong opinion on this matter as I am only an interested user and not a stakeholder of this project. I am happy to close this issue if you do not believe that any further changes are warranted.

why does the Go runtime catch these exceptions?

@billziss-gh as I understand it, there are 2 things that Go exception is trying to achieve.
Go needs to be able to recover from CPU exceptions raised in Go code - like division by 0 or reading or writing memory pointed by nil pointer. See https://github.com/golang/go/blob/61f0409c31cad8729d7982425d353d7b2ea80534/src/runtime/signal_windows.go#L65-L89
And any go program crash should end with stack trace printed. The stack trace is not printed if go program is running under debugger, but otherwise, stack trace must always be displayed. As far as I remember, #8006 (that I mentioned above) is about stack trace was missing in some situations.
If you can still meet these 2 requirements with new exception handler code, I think it should be good enough.
CC @aarzilli in case this discussion affects Delve
Alex

In any case I do not have a strong opinion on this matter as I am only an interested user and not a stakeholder of this project. I am happy to close this issue if you do not believe that any further changes are warranted.

Don't get me wrong @billziss-gh, it would be okay for me to switch to SetUnhandledExceptionFilter if by this Go applications are more compatible with other Windows apps, so I would not close this proposal yet. For example, we could avoid doing this hack: 70546f6404c5927a9868a80ccbf4c6c2beaea671.
I've even tried to useSetUnhandledExceptionFilter instead of AddVectoredExceptionHandler, but without much luck for now.


Pose-apriltag T265 example not working in different platforms

Specifications
Version / Model

Camera Model
T265

Firmware Version
<IP_ADDRESS>00

Operating System & Version
Linux (Ubuntu 16.04)

Kernel Version (Linux Only)
4.15.0-50-generic

Platform
Intel NUC 5i7RYH

SDK Version
librealsense  2.25.0

Language
C++

Issue Description
Hi I'm running the librealsense example pose-apriltag in the Intel NUC with the previous specifications and it works fine, but if I run the same code in the Samsung Artik 530 with the following specifications it does not work, it gives me the following error: Frame didn't arrived within 15000.
The code enables both streams, the pose and the fisheye as it show in the following code:
cfg.enable_stream(RS2_STREAM_POSE, RS2_FORMAT_6DOF);
// Enable both image streams
cfg.enable_stream(RS2_STREAM_FISHEYE, 1, RS2_FORMAT_Y8);
cfg.enable_stream(RS2_STREAM_FISHEYE, 2, RS2_FORMAT_Y8);
and it gives me the previous error, but if I only enable one stream pose or both fisheye images, it does not gives me any problem.
I tried:
- enabling the pose stream after certain number of image frames
- enabling the fisheye images after certain number of pose frames
- enabling and disabling image stream after certain number of image frames
- enabling and disabling pose stream after certain number of pose frames
- enabling and disabling image stream after certain number of pose frames
- enabling and disabling pose stream after certain number of image frames
and all of the previous tries give me the same error: Frame didn't arrived within 15000.
Do you have any idea what could be causing this?

Specifications
Version / Model

Camera Model
T265

Firmware Version
<IP_ADDRESS>00

Operating System & Version
Linux (Ubuntu 16.04)

Kernel Version (Linux Only)
4.4.71-0530GC0F-44U-01Q1

Platform
Artik 530

SDK Version
librealsense  2.25.0

Language
C++

Hi, just my 2 cents: does the new platform have USB3.0 and if yes, are you using it to interface with the T265? For image streams, you would need USB3.0, as described here.

Hi @AnthonyKyung11
Were you able to verify the USB3 connection on the Samsung platform you outline?
Thanks

Yes, that was the issue, we were trying to see the image using USB 2.0. Thank you very much.


Send mail to applicant

Targets #3083
Description
New applicant is added to the Code Trek an email triggered to notify the applicant about their successful register.
Checklist:

[x] I have performed a self-review of my own code.

@Akshiteshnaithani Here is the Mail template.
Hello |*applicant_name*|,

We hope this email finds you well. On behalf of the entire team at ColoredCow, We wanted to take a moment to congratulate you on the commencement of your internship. We are thrilled to have you on board and excited to see the valuable contributions you will bring to our organization.

Once again, congratulations on starting your internship! We believe you have the potential to achieve great things, and we look forward to witnessing your growth and accomplishments over the course of your internship.

Wishing you a successful and fulfilling internship journey!

Best regards,
ColoredCow

@Akshiteshnaithani Here is the Mail template.
Hello |*applicant_name*|,

We hope this email finds you well. On behalf of the entire team at ColoredCow, We wanted to take a moment to congratulate you on the commencement of your internship. We are thrilled to have you on board and excited to see the valuable contributions you will bring to our organization.

Once again, congratulations on starting your internship! We believe you have the potential to achieve great things, and we look forward to witnessing your growth and accomplishments over the course of your internship.

Wishing you a successful and fulfilling internship journey!

Best regards,
ColoredCow

@GauravGusain98  Also please take a look at this mail. And let me know if there are any changes needed in this mail template.

@Akshiteshnaithani Here is the Mail template.
Hello |*applicant_name*|,

We hope this email finds you well. On behalf of the entire team at ColoredCow, We wanted to take a moment to congratulate you on the commencement of your CodeTrek internship. We are thrilled to have you on board and excited to see the valuable contributions you will bring to our organization.

Once again, congratulations on starting your CodeTrek internship! You have the potential to achieve great things, and we look forward to witnessing your growth and accomplishments over the course of your internship.

Wishing you a successful and fulfilling CodeTrek internship journey!

Best regards,
ColoredCow

@GauravGusain98  You also please take a look at this mail. And let me know if there are any changes needed in this mail template.

After adding the applicant to Codetrek

The mail has been send to the applicant which is added to Codetrek


New project target incompatible with mono

When I use "forge new project", then generated project targets .Net v4.6.2.
I get compiler warnings that it is incompatible with mono.
warning : TargetFrameworkVersion 'v4.6.2' not supported by this toolset (ToolsVersion: 14.0)
If I change the target to v4.5, I stop getting the warnings.
I am working on El Capitan, mono is v4.8.0, forge v1.3.3

Similar problem here.  OS X 10.11.6, Mono 4.8.0, Forge 1.4.1.
Repro:
mkdir testproj
cd testproj
forge new project --name testproj --dir . --template console
...
./build.sh

The build will fail with the following error:
/Library/Frameworks/Mono.framework/Versions/4.8.0/lib/mono/msbuild/15.0/bin/Microsoft.Common.CurrentVersion.targets(1127,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.6.2" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

If I manually change TargetFrameworkVersion in testproj/testproj.fsproj to v4.5, the build will succeed.

I believe 4.6.2 should be supported in latest mono version.


Makes fully compatible with Python 3

The plugin is calling exec_command() from Ansible's SSH connection plugin, which returns b'' strings. I was getting a TypeError when sshjail tried to split the byte string with a native string in Python 3. That's fixed by the first commit.
The second commit ensures that values used later in a native string context are converted to native strings using Ansible's Python 2- and 3-friendly to_text() method.

I've been running this well in production for a few months. Any chance of merging? Thanks!

LGTM - thanks!

Argh, sorry I've let this languish. This looks good to me, thanks for doing this!


Add workflow to run uv lock

Description
Build on top of https://github.com/cookiecutter/cookiecutter-django/pull/5356 to add a uv lock workflow
Checklist:

[ ] I've made sure that tests are updated accordingly (especially if adding or updating a template option)
[ ] I've updated the documentation or confirm that my change doesn't require any updates

Rationale

Adding a dependency through uv add also updates  uv.lock. So the lock file is kept in sync.
If we commit 'uv.lock', is a workflow like this then required?

This workflow is mainly for dependabot PRs, which AFAIK doesn't support uv.lock yet. Since it does support deps in pyproject.toml, as it's an earlier standard, PRs would leave the lock file out of date.

Clever!

Ok, let's try this


Documentation is incomplete

Hi,
The documentation for this is incomplete.
What is Heroku going to charge for this?
Why is CORS blocking these requests and how do I overcome this?
Am I meant to call this via the backend or via AJAX?
How does it know that I'm making a legitimate request - what's preventing other people from making requests? If that's what the private key is for then how am I making this request?

Hi,
Thank you for your feedback,

You can check Heroku website for the prices but a couple of deployments are free,
The issue was fixed, thank you for raising this
You get the token by making an AJAX call
The server was created as a starter project that is meant to be forked and adapted. The owner is responsible for implementing the authentication.


Collapse Simulator button overlaps with scroll bar

Describe the bug
When the scroll bar for the simulator view in shown, it overlaps with the collapse simulator view button.
To Reproduce
Steps to reproduce the behavior:
The scroll bar only appears when the height of the window is shrunk to be shorter than the DOM (e.g. when a file in is the downloads bar on the bottom) or when there is more content to display (e.g. the file explorer is open)
Screenshots

We have the same behavior with the side docs view. IMO, it's ok.

Yeah, I'm closing this one. If users complain I will reopen


On Ubuntu 16 "Unrecognized Content-Security-Policy directive" reported from some tests

I chose to use Ubuntu 16 (not 14) as my newest base, since I expect we'll be moving there, and I get a lot of warnings during testing ("rails test").  I believe they're all from test/feature testing, where Capybara is in use.  The warnings all look like this (in real output there are a lot of them):
Unrecognized Content-Security-Policy directive 'base-uri'.
Unrecognized Content-Security-Policy directive 'block-all-mixed-content'.
Unrecognized Content-Security-Policy directive 'form-action'.
Unrecognized Content-Security-Policy directive 'frame-ancestors'.

The following test does not create these reports:

rails test test/features/access_home_test.rb:10

But the following test does create these reports:

rails test test/features/access_home_test.rb:15

These two tests do almost exactly the same thing, but the second one sets "js: true" as follows:

scenario 'New Project link', js: true do

So the problem ones are the ones where capybara is invoking the JavaScript driver.  At that point, Capybara.current_driver is :poltergeist.
As a test, I switched the JavaScript driver to Chrome (I already had Chrome installed), and that worked perfectly:

DRIVER=chrome rails test test/features/access_home_test.rb

However, using Chrome directly is much slower - I don't really want to do that during testing if we don't need to.
I didn't find any immediate hints by Googling.

Here's a few notes on our tech stack:
Capybara provides the basic infrastructure for browser-level tests. When we set js: true (to test with JavaScript processing enabled), we call our default javascript_driver, which is poltergeist. Poltergeist is "a driver for Capybara. It allows you to run your Capybara tests on a headless WebKit browser, provided by PhantomJS."
A serious issue is that PhantomJS development has been suspended as of March 3 this year - here are more details.
That suggests to me that we should consider an alternative Capybara driver for JavaScript.  The alternatives are selenium and capybara-webkit.  Selenium requires Firefox to be installed, and is slower because it actually invokes the real Firefox browser.   In contrast, "capybara-webkit driver is for true headless testing. It uses QtWebKit to start a rendering engine process.  It can execute JavaScript as well. It is significantly faster than drivers like Selenium since it does not load an entire browser."
I intend to investigate switching to capybara-webkit further.  If it fixes the problem, and is maintained, that'd be a win-win.

I think we should use Capybara with Headless Chrome.
https://robots.thoughtbot.com/headless-feature-specs-with-chrome
--
Dan Kohn<EMAIL_ADDRESS>Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com
On Thu, Jul 12, 2018 at 7:32 PM, David A. Wheeler<EMAIL_ADDRESS>wrote:

Here's a few notes on our tech stack:
Capybara
https://github.com/teamcapybara/capybara#using-capybara-with-minitest
provides the basic infrastructure for browser-level tests. When we set js:
true (to test with JavaScript processing enabled), we call our default
javascript_driver, which is poltergeist. Poltergeist
https://github.com/teampoltergeist/poltergeist is "a driver for
Capybara. It allows you to run your Capybara tests on a headless WebKit
browser, provided by PhantomJS."
A serious issue is that PhantomJS development has been suspended
http://phantomjs.org/ as of March 3 this year - here are more details
https://github.com/ariya/phantomjs/issues/15344.
That suggests to me that we should consider an alternative Capybara driver
for JavaScript. The alternatives are selenium and capybara-webkit. Selenium
requires Firefox to be installed, and is slower because it actually invokes
the real Firefox browser. In contrast, "capybara-webkit driver is for true
headless testing. It uses QtWebKit to start a rendering engine process. It
can execute JavaScript as well. It is significantly faster than drivers
like Selenium since it does not load an entire browser."
I intend to investigate switching to capybara-webkit further. If it fixes
the problem, and is maintained, that'd be a win-win.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/coreinfrastructure/best-practices-badge/issues/1194#issuecomment-404682019,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC8MBnn5tiKmND4sEOmT_TzH7mdLGg1Mks5uF9x9gaJpZM4VOBsD
.

Thanks for the idea for using ChromeDriver! I was going to complain that Chrome is not open source software, though chromium is, and then we have some serious discussions to have. but it turns out this is from the chromium project. They could do with better documentation, but it looks like they are installing chromium, which therefore has no issue at all. This appears to be a selenium driver, so we would select selenium and then configure selenium to call this. Quite a deep tech stack to do something straight forward... but if it works, it's a good thing.
The trade-offs appear as follows:
Capybara-WebKit runs test slightly faster than Chrome driver. However, ChromeDriver is much easier to install on macOS, and more accurately reflects what happens to real users in their browsers. I can accept slightly longer test times for those reasons. In practice the longer time probably won't be noticeable, since many of our tests don't require JavaScript anyway.


Add support for maven site structure

Maven uses some gothic structure to organize the content which seems optimized to not work with anything.
it structures the files as
src - site -+- markdown
               + ...
               + resources-+- css
                           + js
                           + images

Then when doing mvn site it does it's dark voodoo and everything ends up on another location so the the images folder is now in the site root together with the
docs.
My top gripe is that the images are somewhere far away and there is no decent way
to preview them without corrupting the url's so they won't work on the generated site.
So ti would be nice that the previewer would also look starting from the resources
folder if it does not find a resource in the folder it needs. Or add the resources somewhere the previewer can find them.
I guess that JS and CSS will then automagically work too, but it are the images
which would be the biggest win.

Notice: This plugin is no more maintained and it has been removed from Jetbrains plugins repository. There is a Markdown plugin officially supported by Jetbrains.


High cpu usage

Hi,
I am using Kapacitor 0.10.1 (nightly version from one week ago) with 950 stream tasks that split to two kinds:

Filter by two tags and check the values and trigger alert to based on them

Filter by two tags, create value delta (using window, and two mapReduce for first and last) and trigger alert based on the value delta.

Those alerts send to log file (for start, in the future they will post to some http service).
I have started to ingest events 200,000 events (every 10 second) and I see that kapacitor takes 100% cpu on: 2 cores, 4gb virtual machine.

I you are using the nightly you should be able to see which node in a task is slowest. Can you share the show output of one of the tasks so we can begin to understand the performance profile?

I am using:

0.11.0~n1455782624 (git: master f741d460c4f1b77647efc93ad6718252f051e3c0)

So I don't the throuput metrics yet, tomorrow (Israel time) I will upgrade to the latest nightly.
By the way, some info that I forgot to mention:

I am using Ethernet
I am calling write directly to kapacitor without using influxdb

Hi @nathanielc,
I have installed the latest nightly and now I see that the throughput is between 750 to 820 points per second.
I have upgraded to 4 cores and the cpu is still 100%

Could you post the complete show output from two of your tasks?

Yes, btw - I see that we have high cpu usage while inserting and I changed the alerts to post to http service instead of log file.

@nathanielc any ideas?
I reproducing this high cpu usage on my dev computer and I am seeing something weird:
On the production vm I saw there was 5-6 processes of kapacitor (I saw in htop in tree mode) and In my local computer I see only one process.
On the prod I have 950 tasks and in my local computer I have 4 tasks

@yosiat Kapacitor is single processed but multi-threaded, htop will show threads by default http://unix.stackexchange.com/questions/10362/why-does-htop-show-more-process-than-ps
As for the high cpu, what is your expectation of cpu usage for your ingestion rate? Based on the info I see you are pushing approx  950*4000 = 3,800,000 metrics per second. If that is the case then 100% cpu on 4 cores is really efficient.
Could you get me some more data? First that 3.8 million number is a complete guess and seems really high, what is your real total throughput? Kapacitor reports its total throughput as the TASK_MASTER task. You can use a task like this one to save those metrics in InfluxDB
stream
    .from()
    .influxDBOut()
        .precision('s')

Then query your total throughput like this:
select non_negative_derivative(collected) from edges where task = 'TASK_MASTER' and parent = 'write_points' and time > now() - 1m

That should give us more insight into the total amount of work Kapacitor is doing.
Second capturing a cpu and memory profile from Kapacitor would also help to expose bottle necks. If you start kapacitord with the args  -cpuprofile path/to/cpu.prof -memprofile path/to-mem.prof  then let Kapacitor run for a few minutes at least and shut it down the files will contain profiles I can use to further investigate any bottle necks in the code.

@nathanielc I will send the data as soon as possible!
But before that I don't understand your calculation of 3.8 million metrics per second.
I am ingesting to Kapacitor 4500 metrics per second, If Kapacitor replicates those metrics it would be in-efficient, why not route the metrics to specific tasks instead of ingesting to all tasks?
For example:

Read from the point it's measurement,db and rp
Find the relevant tasks (by building index of (measurement,db,rp) to task)
Insert point to task stream

Kapacitor does duplicate the metric for each task so that each task can manipulate the data. I have already profiled the duplication overhead and it is not significant. The reason I multiplied by the tasks was because I assumed each task was getting a unique set of data, obviously a wrong assumption. The throughput value that the query will return is the number of points Kapacitor has received not the duplicated count so it will give a good idea of how much data is being shared/duplicated across tasks.
Another question: How similar are the 950 tasks? In my experience it is easy to write a single task to handle a large scope problem. Could you show me a few example TICKscripts for your tasks? If not could you explain some of the differences between each of the tasks?
Thanks for working with me through all of this :)

Thank you for helping me out with Kapacitor :)
My tasks falls to two structures (which I posted above as Alert1 and Alert2) they vary by their measurement and thresholds.

@nathanielc I have ran this query:
select non_negative_derivative(collected) from edges where task = 'TASK_MASTER' and parent = 'write_points' and time > now() - 1m

and got between 480 to 485

@nathanielc
I have upgraded the machine to 8 cores and Kapacitor got faster and 70% cpu.
I think I can make performance improvements, right know I write all the data toל Kapacitor and rely on it to filter the measurements, I am thinking to do this on my side and it will take the pressure down on Kapacitor.
What do you think?
BTW - Do you have any benchmark result on Kapacitor? how many tasks & points per second it can handle?

@nathanielc  I upgraded to nightly and thanks to #360 we dropped from 70% steady to 0.1% with little peaks of 9% cpu.
Next week we will run hermeticity test to make sure we are processing 100% of the data, until then I will close this issue.


implement replay binary

TITLE
Description
Description of the pull request changes and motivation.
Checklist

[ ] Linked to Github Issue
[ ] Unit tests added
[ ] Integration tests added.
[ ] This change requires new documentation.

[ ] Documentation has been added/updated.

Codecov Report

Merging #1075 (b978dd4) into main (bf81e72) will decrease coverage by 0.20%.
Report is 1 commits behind head on main.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1075      +/-   ##
==========================================
- Coverage   89.55%   89.36%   -0.20%
==========================================
  Files          50       50
  Lines       13404    13404
==========================================
- Hits        12004    11978      -26
- Misses       1400     1426      +26

see 2 files with indirect coverage changes


Testing "Block User" Functionality

Testing "Block User" Functionality
Description
When blocking a user from their profile, the conversation remains in the conversation list initially. However, the conversation is removed from the list only after the app is killed and reopened.
Steps to Reproduce

Open the app and go to the conversation list.
Select a user and navigate to their profile.
Block the user.
Observe that the conversation with the blocked user remains in the conversation list.
Kill the app and reopen it.
Observe that the conversation with the blocked user is now removed from the conversation list.

Expected Behavior
• The conversation should be removed from the conversation list immediately after blocking the user, without needing to kill and reopen the app.
Actual Behavior
• The conversation remains in the conversation list until the app is killed and reopened.
Slack Message

Fixed with https://github.com/ephemeraHQ/converse-app/pull/539


Arm Ethos-U Core Driver

Origin
Arm Ethos-U Core Driver
https://git.mlplatform.org/ml/ethos-u/ethos-u-core-driver.git
Purpose
Driver for the Arm Ethos-U NPU.
Mode of integration
Module.
The driver is actively maintained upstream, and it would make most sense to keep the differences between the upstream repository and the fork at a minimum.
Suggested name: https://github.com/zephyrproject-rtos/ethos-u-core-driver
Pull Request
No pull request exists.
Description
The Ethos-U Core Driver is a small platform agnostic device driver for the Arm Ethos-U NPU. It provides an interface that frameworks like Tensorflow Lite Micro or uTVM can use to execute command streams on the hardware accelerator.
With this module the Tensorflow Lite Micro framework can be updated to include the Ethos-U kernel (<tflite-micro>/tensorflow/lite/micro/kernels/ethos_u/ethosu.cc), which allows networks optimized by the Vela compiler [1] to be run on TFLu.
[1] https://git.mlplatform.org/ml/ethos-u/ethos-u-vela.git
Dependencies
This module depends on CMSIS Core.
For boards that are built with support for Ethos-U, the tflite-micro module (zephyr/modules/tflite-micro/CMakeLists.txt) will be updated to include the Ethos-U kernel (<tflite-micro>/tensorflow/lite/micro/kernels/ethos_u/ethosu.cc), which creates a dependency on this module.
Revision
https://git.mlplatform.org/ml/ethos-u/ethos-u-core-driver.git
Revision: a0e4d31c5531b55a638d1efa0a43e1f296a2f2d9
License
Apache-2.0
https://spdx.org/licenses/Apache-2.0.html

TSC meeting: No objections to creating the repo and adding the module.

We may want to see about moving zephyr/init.c into the zephyr tree itself to easy maintainership of that glue code.
I assume we'll see updates on the zephyr side for device tree binding, updating dts for an547, some kinda of sample or test.

@carlescufi my Github ID.

We may want to see about moving zephyr/init.c into the zephyr tree itself to easy maintainership of that glue code.

Agreed, let's do that @freddan80 and @kristofer-jonsson-arm. This belongs in the main tree, in modules/.
Speaking of, we need to choose whether we want an isolated repo for this, or a new hal_arm repository that covers all future HALs or drivers that come from Arm. This would be a repo of repos, which has the disadvantage of not being able to track upstream history since updates are done by copying files and not by merging in commits.

I think we can follow the example of tflite-micro and create <zephyr>/modules/ethos-u-core-driver and place the CMakeLists.txt, Kconfig and init.c there.
We will be making minor updates to the an547 board files, adding DTS entries describing the Ethos-U NPU.
We will also need to make a minor adjustment to modules/tflite-micro/CMakeLists.txt, selecting a different version of ethos-u.cc if CONFIG_ARM_ETHOS_U is set.

@carlescufi I can see benefit to both approaches, but looking at TF-M we started with this mono repo approach and it became enough of a support burden to keep the three repos up to date that we broke them out individually. I also think losing the history is non a trivial side effect here.
Would you object with starting with this repo as a direct fork with the history, and when we get to a situation where there are multiple Arm libraries to deal with we can reconsider moving them into a single repo with some sort of update strategy or script defined for that?
I don't have strong feelings here, I'm just aware of the update burden from TF-M with this approach and the messy history situation.

I can see a few advantages of keeping the driver as a standalone repository. Upmerges from the parent repository will be easier. We will hopefully be able to preserve the git history. And ownership of the repo will be clearer, as a hal_arm repo would need to be shared across different teams at Arm.

@carlescufi I can see benefit to both approaches, but looking at TF-M we started with this mono repo approach and it became enough of a support burden to keep the three repos up to date that we broke them out individually. I also think losing the history is non a trivial side effect here.

Yes, I saw that and was actually supportive of the change, but that is a much bigger project. This project is quite small, so I was trying to coalesce it together with other future drivers.  But we can do that later too, let's start simple. Since this is effectively a "HAL", I will create a new hal_ethos_u_core repo.

Thanks, much appreciated.
Talked to Fredrik and we believe hal_ethos_u_core_driver would better reflect the connection to the upstream repository at MLPlatform.

Thanks, much appreciated.
Talked to Fredrik and we believe hal_ethos_u_core_driver would better reflect the connection to the upstream repository at MLPlatform.

Right, but that is a bit of a RAS syndrome, since the hal_ prefix is intended to cover the _driver part.

Thanks, much appreciated.
Talked to Fredrik and we believe hal_ethos_u_core_driver would better reflect the connection to the upstream repository at MLPlatform.

Right, but that is a bit of a RAS syndrome, since the hal_ prefix is intended to cover the _driver part.

@kristofer-jonsson-arm @freddan80 ping on this. Are you ok with hal_ethos_u_core? Will this driver ever contain sources for additional Ethos producs? Should it be hal_ethos_npu instead?

I see what you mean. The repo will not contain any other Ethos-U products, so I would suggest to name the repo hal_ethos_u.

https://github.com/zephyrproject-rtos/hal_ethos_u

Thx @carlescufi


A JavaScript error occurred in the main process

[Window Title]
Error

[Main Instruction]
A JavaScript error occurred in the main process

[Content]
Uncaught Exception:
Error: Cannot find module 'C:\Users\Timo\AppData\Local\Discord\app-0.0.283\resources\app\app\index.js'
    at Function.Module._resolveFilename (module.js:336:15)
    at Function.Module._load (module.js:286:25)
    at Object.<anonymous> (C:\Users\Timo\AppData\Local\Discord\app-0.0.283\resources\atom.asar\browser\lib\init.js:123:10)
    at Object.<anonymous> (C:\Users\Timo\AppData\Local\Discord\app-0.0.283\resources\atom.asar\browser\lib\init.js:125:4)
    at Module._compile (module.js:434:26)
    at Object.Module._extensions..js (module.js:452:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:475:10)
    at startup (node.js:129:18)

[OK]

Looks like you're missing some files.
Run the installer again.

Yeah. The installer was crashing all the time so i debugged with VS and found out the line
Directory.Move(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) + "\\BetterDiscord\\temp\\BetterDiscordApp-stable", GetParent().DiscordPath + "\\resources\\node_modules\\BetterDiscord");

was causing the issues. So i commented it out and it worked :+1

Interesting, did it fail to download the release? Anyhow good to hear you got it working :)


Update Makefile: use XcodeGen instead of SPM to create .xcodeproj

In #18 I forgot to update the Makefile, so that running make xcodeproj would still use SPM to generate the Xcode project file. Not what we want.

Ah, thanks so much for the catch!

Ah yup, test-linux should definitely not depend on xcodeproj. Wanna delete that and I can merge?

Awesome, thanks for fixing this!


chore(blockifier): remove duplicacy tip() and resource_bounds() in AccountTransaction

This change is

#2102
#2101  👈 (View in Graphite)
main

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

crates/starknet_api/src/executable_transaction.rs line 113 at r1 (raw file):
Previously, Yoni-Starkware (Yoni) wrote…
What does it mean?

in both funcs above we're making sure that the field 'tx' of the enum AccountTransaction is of version v3.
This 'tx' is either
starknet_api::transaction::InvokeTransaction  or
starknet_api::transaction::DeployAccountTransaction or
starknet_api::transaction::DeclareTransaction
However, for each of those, there is a func resource_bounds() which implements the above macro, and thus panicking if version != v3
there was a duplication, as the blockifier's AccountTransaction implementation didn't actually use the api's AccountTransaction's implementation of those funcs, but rather accessed 'directly' the implementation of  the starknet_api::transaction.
With that said, the key difference between the 2 implementations I see are: the use of panic vs except (w Option) and clone() vs passing a ref.
Perhaps better to leave things as they were?

crates/blockifier/src/transaction/account_transaction.rs line 113 at r1 (raw file):
Previously, Yoni-Starkware (Yoni) wrote…
Is this still needed?

Yes as all the below funcs are not implemented by 'Transaction' (= starknet_api::executable_transaction::AccountTransaction)
Code snippet:
        (signature, TransactionSignature),
        (nonce, Nonce),
        (nonce_data_availability_mode, DataAvailabilityMode),
        (fee_data_availability_mode, DataAvailabilityMode),
        (paymaster_data, PaymasterData)

crates/blockifier/src/transaction/account_transaction.rs line 113 at r1 (raw file):
Previously, Yoni-Starkware (Yoni) wrote…
(Should have been part of this PR)

I see, will know for the next :)


[ DRAFT ] [ HGEMM ] Draft of kernel-based hgemm

Previously, hgemm was implemented without taking packing / kernel into consideration.
Here I would like to introduce kernel-based hgemm.
It consists of:

packing A / B matrix for 4 / 8 divisible case
4x4, 8x8 hgemm kernel for full-fp16 case.

Note that this is just a draft PR to get review w.r.t. file structure from other reviewers

Self evaluation:

Build test:	 [X]Passed [ ]Failed [ ]Skipped
Run test:	 [X]Passed [ ]Failed [ ]Skipped

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #2527. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

:octocat: cibot: @skykongkong8, nntrainer/tensor/hgemm/hgemm_util.h does not include Doxygen tags such as @file @brief @author @bug. You must include the Doxygen tags in the source code. Please refer to a Doxygen manual at http://github.com/nnstreamer/TAOS-CI/blob/main/ci/doc/doxygen-documentation.md


I want to get the ability to inject hbase

From the component level, not the application level

On a single machine, not K8S

I have already understood your needs. We have also recently planned fault injection capabilities related to hbase, which will support k8s and chaosmetad stand-alone execution mode. Of course, welcome to submit PR to build ChaosMeta together.


Napari UI widgets demo plugin

Story
As a UX designer, I want code examples of all available UI widgets so that I can produce a UI design that is compatible and looks good in Napari
A/C
I know this is done when...

I can view an example of all available UI widgets in a single Napari plugin window
We have selected the underlying UI library that will be used

Details

Goal is to showcase the available standard UI widgets in a single plugin window so that Thao can 1) review the look and feel of all of them and 2) build her own UI prototypes using python code instead of Powerpoint. This will allow to design a more precise and accurate UI and will result in less development work.
As part of this work, we should identify whether we want to use QT or magicgui (whichever seems easier to use and/or prettier). If there is no obvious choice right at the beginning, consider building 2 versions of this demo - one for each library.
See https://allencellscience.slack.com/archives/C01L7L5M29H/p1613777279189500

List of possible widgets to include (non-exhaustive):

Textbox
Drop down list
Slide bar
Checkbox
Button
Progress bar
Labels
Fieldset / Form group

Came across some insight on using Qt vs MagicGUI on Zulip:
https://napari.zulipchat.com/#narrow/stream/212875-general/topic/magicgui.20customization.3F
TL;DR summary:

If you want to do things like subtle positioning adjustment, coloration, size tweaking, you should probably just use Qt. You can probably get a little of this done by directly modify the native widget in magicgui (like widget.native.setStyleSheet() or widget.native.setMaximumWidth(), etc...) but you may well be better of just building your own Qt layout.
yeah, magicgui is still young, and the focus is on functionality over form for the moment. It is also being developed in a backend agnostic way (such that these widgets could eventually be put in a browser notebook for example), so the intention is not to have complete parity with the Qt styling abilities. You will always have the greatest flexibility if you just use Qt directly.

So I guess it depends on how much styling/customization we want. We could also mix and match Qt and MagicGUI.

Goal is to showcase the available standard UI widgets in a single plugin window

You might find running our qt_theme_sample helpful
python -m napari._qt.widgets.qt_theme_sample

It produces the following output

using standard qt widgets.

So I guess it depends on how much styling/customization we want. We could also mix and match Qt and MagicGUI.

Indeed. The magic of magicGui is the autogenerated transition from function signatures to widgets, but it comes at the cost of customization. We can also think about providing more widget types either through napari or magicgui if there are some you are missing (say you want a combined slider and edit box) and improving some of our defaults.
Happy to talk about these tradeoffs anytime. It's very exciting to see this issue!!

@sofroniewn Wow that is super helpful, thanks!
We would absolutely love a combined slider and text edit box option. Actually, at a meeting this morning (@Aerendel I did a 5-min show and tell of the plugin progress at our Animated Cell meeting) we were talking about how we need either a combined slider and text edit box or a combined slider and spinbox. The other issue is that the Qt slider by default doesn't seem to support float values. We can code all of these in but would be really nice to not have to do it :)

@Aerendel There are dozens of available widgets in Qt and most of them are not relevant (for example, font picker, date/time picker, etc.) Can the A/C be adjusted to something like "I can view an example of all relevant UI widgets in a single Napari plugin window"?

@schoinh Yes, just use best judgement for this. If we need to experiment with more widgets in the future as the UX evolves we can do that later.

Actually, at a meeting this morning (@Aerendel I did a 5-min show and tell of the plugin progress at our Animated Cell meeting) we were talking about how we need either a combined slider and text edit box or a combined slider and spinbox. The other issue is that the Qt slider by default doesn't seem to support float values. We can code all of these in but would be really nice to not have to do it :)

Yes @liaprins-czi is starting to think about this now too. We might end up with some more standard widgets that people can reuse. We're currently exploring also adding the widgets in https://github.com/agoose77/qt-jsonschema-form as part of our own usage in https://github.com/napari/napari/pull/2212 cc @goanpeca @ppwadhwa, and might be able to add some more to magicGUI too cc @tlambert03

@schoinh add demo of a expand/collapse layout/form group

@Aerendel It seems there's no built-in Qt widget/layout for a collapsible section. Can we skip this until we know for sure we're gonna need one of these?

Discussed objectives with @thao-do and @Aerendel and decided the work done to date is sufficient. We have decided to use Qt over MagicGUI. Qt demo plugin is on branch feature/demo-qt-widgets.


feat: add SyncSwap pool adapter

Adding SyncSwap finance pool adapter

Hey,
Awesome thanks for the PR, we will review it and get it merged early next week.
Thanks,
JP

I have merged. We will soon be adding support for USD prices to Linea, which will fix the profits results.


Tap and hold to 2x speed

Describe your suggested feature
Can you guys add tap and hold to 2x speed just like YouTube
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is a request regarding an extension, I should be opening an issue in the extension's repository.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I will fill out all of the requested information in this form.

Duplicate of #1660

So When will be this feature implemented

Whenever someone feels like implementing it, there's no ETA.


Creditor implementation

Thank you for this PR, it looks good. Could you write tests for this service please?


Add support for deploying pods with containers

Add support for deploying a pod with containers as a single unit by defining containers as part of the pod using a hash parameter on the pod resource. Systemd service units will be automatically created for both the pod and its containers. If there are any changes to the containers or flags hashes, the entire pod will be redeployed. If an individual container image is updated in the registry, then only the individual container will be redeployed (but the entire pod is restarted).
Note that the service units for the containers within a pod will be prefixed with the default "container-" instead of "podman-" due to how the service units are generated for the entire pod rather than for each container individually.

Unfortunately, when I updated the REFERENCE.md, it resulted in quite a few differences for reasons I do not understand.

Closing due to bugs found. I will resubmit.


chore(main): release 1.2.0

:robot: I have created a release beep boop
1.2.0 (2024-08-16)
Bug Fixes

auth: Fix all auth (f178cac)
auth: Fix all auth issues outstanding (40ecc28)
booking-id: Return booking id on room get (599f2b7)
checkstyle-issues: Add to readme (c83b2b6)
checkstyle-issues: Fix formatting issues after checkstyle failed (5cde2c3)

Other

main: release 1.1.1-SNAPSHOT (e895b4a)

Build

deps: Bump com.nimbusds:nimbus-jose-jwt from 9.30.1 to 9.40 (f02bc86)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.2.0
:sunflower:


docker-edge: 17.04 to 17.05

Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>Motivation for this change
Updating docker-edge to 17.05 now it's released.
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[x] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Any reason we would want to keep 17.04 around?

@NeQuissimus not sure 😝

Taking a look at #24619, I don't think we need 17.04 for anything. It is being directly replaced by 17.05.

@NeQuissimus updated it but not sure why travis failed..

LGTM, works for me locally


PoE config file

Hello, on start script, got error - Cannot read the PoE config-file. Try fresh install, run as administrator.

Did the script ask you to locate the PoE-config file the first time you started it, or did the error message show immediately?
The script tries to read the PoE-config to know if the client is running in windowed mode or not. If it can't find it, it asks the user to locate it.

I have implemented a potential fix: https://github.com/Lailloken/Lailloken-UI/archive/refs/heads/dev.zip. Please report back if that works for you.

The first installation, when trying to run, an error appears  (no regular error, only window with message) and then the script crashes. If try dev zip

I missed something before, should be fixed now. Re-download the dev.zip

Now got this. I play all time in windoved fullscreen.

indoved fullscreen.

Its on me side. I run script as diferent user. Now work well. Thanks for help.

You're welcome, and thanks for reporting this issue. Have fun with the tool.


Mutation errors are local and cannot be shared to other SWR hooks

Bug report
Mutation errors are local and cannot be shared with other SWR hooks
Description / Observed Behavior
I have a case where I would like every component that uses a key to be updated with an unsuccessful mutation result.
For example, I have a modal window that has a form. When filling form values I want the update request to be sent and the modal to be closed. Other page components should indicate to the user, that the operation was unsuccessful.
Expected Behavior
I want mutation results to be shared between other SWR hooks with the same key
Repro Steps / Code Example
https://codesandbox.io/p/sandbox/goofy-feather-g69xrg
Additional Context
I understand that I can work around this issue with the use of some other global state solution, but I think SWR should allow for such a pretty common use case
SWR version. (2+)
Add any other context about the problem here.

It is currently by design.


Files with \xfa (ú) in the filename don't end up in request.files

Expected Behavior
request.files['file'] should contain the file. It doesn't. File contents are visible in request.stream.read().
Raw request in attachment (request.stream.read()):
request.bin.zip
This only occurs with funky characters in the filename. Such as Ofslútdyk.jpg. Same file without special character works as expected.
@app.route(f"/images", methods=['GET', 'POST', 'PUT'])
def images_endpoint(project, group):
    user = get_user(request.headers)

    if request.method in ['PUT', 'POST']:
        file = request.files['file'] # Returns 400 to client.

No errors in console.
Actual Behavior
Flask returning 400 to client.
Environment

Python version: 3.6.9
Flask version: 1.1.1
Werkzeug version: 0.16.0

I think a snippet to reproduce it would be very useful here (one small flask app showing the error, and a script using e.g. requests to send the file)

@ThiefMaster Just added

Hi, just test with your code, everything seems to be in order:
@app.route("/images", methods=['GET', 'POST', 'PUT'])
def images_endpoint():

    if request.method in ['PUT', 'POST']:
        file = request.files['file']  # Returns 400 to client.
        print(file)

    return '''<form method="post" enctype="multipart/form-data">
                <input type="file" name="file">
                <input type="submit">
            </form>'''

Output:
<IP_ADDRESS> - - [21/Dec/2019 22:23:30] "GET /images HTTP/1.1" 200 -
<FileStorage: 'hs_err_pid1770.log' ('text/x-log')>
<IP_ADDRESS> - - [21/Dec/2019 22:23:36] "POST /images HTTP/1.1" 200 -
<FileStorage: 'Ofslútdyk.jpg' ('image/jpeg')>
<IP_ADDRESS> - - [21/Dec/2019 22:25:05] "POST /images HTTP/1.1" 200 -

You may need to enable debug mode (export FLASK_ENV=development), then find the specific exception behind 400 error.


feat: allow builder only proposal flow for benefit of DVT protocols

DVT protocols block proposal may depend on sourcing block for proposal only through relayer so that the distributed validators are signing off on same block for proposal.
This PR allows for the same via --builder.selection=builderonly option

:tada: This PR is included in v1.9.2 :tada:


Parse and ignore postfix ! and ? on type annotations in analyzer

This is part of the experimental implementation of non-nullable types. See the main tracking bug (#23766) for more details.

See: https://github.com/dart-lang/sdk/issues/23766#issuecomment-267703699


bencher.with_inputs() affects benchmark timing

While trying Divan I noticed when I added a bench with a heavier input the timing was quite a bit high.
Since I had only used basic benches prior I thought it was my function in bench_values(), yet when I removed it there was still notable overhead.
After removing the mock data function call for input, that overhead was gone.

The docs for with_inputs() imply this should not contribute to timing?:

Generate inputs for the benchmarked function.
Time spent generating inputs does not affect benchmark timing.

$ cargo bench

Timer precision: 10 ns
example                fastest       │ slowest       │ median        │ mean          │ samples │ iters
├─ with_dynamic_input  660.7 ns      │ 1.312 µs      │ 670.7 ns      │ 718.5 ns      │ 100     │ 200
╰─ with_static_input   0.004 ns      │ 0.008 ns      │ 0.004 ns      │ 0.004 ns      │ 100     │ 819200

// benches/example.rs
use divan::{black_box, Bencher};
use std::collections::HashMap;

fn main() {
  divan::main();
}

#[divan::bench]
fn with_dynamic_input(b: Bencher) {
    b.with_inputs(|| {
        mock_data()
    }).bench_values(|_| {
        black_box(42);
    });
}

#[divan::bench]
fn with_static_input(b: Bencher) {
    b.with_inputs(|| {
        42
    }).bench_values(|_| {
        black_box(42);
    });
}

// Something to generate a larger input:
// Actual method randomized fixed length strings

fn mock_data() -> Vec<String> {
    (0..128).map(|_| {
      "divan".to_string()
    }).collect()
}

I've tried to look through the current docs and announcement blogpost, but it's not clear to me why this is happening?
If I instead swap the mock data generator function for one that just sleeps instead of allocates:
use std::{thread, time};

fn wait_a_bit() {
  let delay = time::Duration::from_nanos(500);
  thread::sleep(delay);
}

It will take longer to complete, but does not affect the timing:
Timer precision: 10 ns
example                fastest       │ slowest       │ median        │ mean          │ samples │ iters
├─ with_dynamic_input  0.002 ns      │ 1.747 ns      │ 0.018 ns      │ 0.093 ns      │ 100     │ 409600
╰─ with_static_input   0 ns          │ 0.002 ns      │ 0 ns          │ 0.001 ns      │ 100     │ 819200

It only affects timing when I return the mocked data and the impact scales with the size of the input. I assume it's related to the example description of Drop behaviour here, but I'm not sure how to exclude that overhead.

I just noticed that compared to the strings example, I was using bench_values() instead of bench_refs(). The latter avoids the overhead.
I assume that you should still be able to bench a method by value without the timing overhead from the input.

I was using bench_values() instead of bench_refs(). The latter avoids the overhead.

It appears what's happening is you're dropping Vec<String> in every run of your benchmarked function. The timing taking longer is expected in this case. You would need to forward it back to Divan by returning it. Or use bench_refs(), which does semantically the same.

You would need to forward it back to Divan by returning it.

That was it, cheers!

Is that related to the Drop example in docs? It only mentioned a memory cost, with a later example of not needing to return a value.
The benched function would take a hashmap as input and return a string. That value was also implicitly returned in the bench_values() closure, but I didn't expect an unused input to introduce timing overhead when not used.
// Slow without return
#[divan::bench]
fn with_dynamic_input(b: Bencher) {
    b.with_inputs(|| {
        mock_data()
    }).bench_values(|_| {
        black_box(42);
    });
}

// Slow with return
#[divan::bench]
fn with_dynamic_input(b: Bencher) {
    b.with_inputs(|| {
        mock_data()
    }).bench_values(|_| {
        // without black_box, also still slow
        black_box(42)
    });
}

// Fast, no notable timing overhead issues
#[divan::bench]
fn with_dynamic_input(b: Bencher) {
    b.with_inputs(|| {
        mock_data()
    }).bench_values(|x| {
        x
    });
}

Might be worth clarifying that in with_inputs() to mention timing will be affected if the input does not defer drop?
Or I guess this issue is sufficient itself for troubleshooting the cause 👍

but I didn't expect an unused input to introduce timing overhead when not used.

Rust was doing what you were telling it to. You just weren't telling it what you wanted it to do 😉. I was hoping the name "values" would help make the move semantics obvious but it seems to still be subtle.

Rust was doing what you were telling it to. You just weren't telling it what you wanted it to do 😉. I was hoping the name "values" would help make the move semantics obvious but it seems to still be subtle.

I thought from the black_box() docs on compiler optimizations, an unused parameter wouldn't have that sort of impact.
I'm familiar with value vs ref and thought I understood them well enough 😅 Just to be clear my confusion with this issue was:

My benched function did take the input value and use it.
I was curious and replaced my function to just return a simple value, expecting it to be quick like my earlier benches which didn't use with_inputs().
I did not expect divan to report time unrelated to what was going outside of the benched function, especially when the input was changed to _ and not used 🤷♂ This was my first time trying benching with Rust, so it was perhaps the wrong expectation.

#[divan::bench]
fn with_dynamic_input(b: Bencher) {
    b.with_inputs(|| {
        mock_data()
    }).bench_values(|x| {
        // If operation doesn't use input, or input is not returned as it was
        // Timing Overhead, regardless of operation
        do_stuff(x)

        // <1ns if instead returning input as-is
        x
    });
}

// <1ns, no overhead
fn do_stuff(s: Vec<String>) -> Vec<String> {
    s
}

// 700ns, returning modified input
fn do_stuff(mut s: Vec<String>) -> Vec<String> {
    s.truncate(1);
    s
}

// 1.4µs, returning different type from input
fn do_stuff(mut s: Vec<String>) -> String {
    s.concat()
}

// 700ns, returning a different type, ignoring input
fn do_stuff(s: Vec<String>) -> u8 {
    42
}

// 700ns, not returning anything
fn do_stuff(s: Vec<String>) {
    42;
}

When the timing is <1ns my understanding is it's been optimized out.
Everything else that is taking a minimum of 700ns is unrelated to the function, and more to do with the input itself adding overhead? 🤷♂
This behaviour was odd to me. Not that I'd avoid using the input in the benched function call, I just didn't expect it to be intentionally contributing to the measured timing like that, since I wanted to compare multiple approaches with the same sized input, without overhead noise.

@polarathene Please submit a PR to improve the docs here! I'm sure you would have good phrasing for it.

I'm happy to submit a PR if another user chimes in with the same confusion, except given the above I still don't quite follow why divan should be including that 700ns 🤔
In my last comment, I thought I just had to consume the input and/or return something, thinking the timing was due to my function logic alone after all, but it seems there is still overhead from the input size regardless of what happens in do_stuff() (at least when passing by value).


d3.interval isn't in main d3 4.1.1

Yet d3.timer is. I'm confused.
Thank you for this library!
Best,
Clive

d3.interval is very much included both in d3-timer and the default build of d3.
https://github.com/d3/d3-timer/blob/v1.0.1/index.js#L12
https://github.com/d3/d3/blob/v4.1.1/index.js#L227


Document Level Addin

How to Set Custom Action Explain in this https://docs.microsoft.com/en-us/visualstudio/vsto/deploying-an-office-solution-by-using-windows-installer?view=vs-2017#to-add-a-custom-action-that-runs-your-program Section using visual studio Installer

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 283a3669-9f0e-c872-028d-9eac66fc221b
Version Independent ID: bdfea87a-3b7d-80ef-51f2-ceadb1ba26bb
Content: Deploy an Office solution by using Windows Installer - Visual Studio
Content Source: docs/vsto/deploying-an-office-solution-by-using-windows-installer.md
Product: visual-studio-dev15
GitHub Login: @TerryGLee
Microsoft Alias: tglee

@VivekKPatel Thanks for letting us know; this content set is in our backlog to update. @John-Hart, FYI.

Please see the updated document: https://docs.microsoft.com/en-us/visualstudio/vsto/deploying-a-vsto-solution-by-using-windows-installer?view=vs-2019


Renaming argument of Retry that has been deprecated with urllib3  [v2.0.0]

Renaming argument of Retry that has been deprecated with urllib3  v2.0.0
Fixes #3

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

+1 Working with GPT-NeoX and this PR would be very helpful in resolving requirements errors

@MarkusSpanring thank you for opening this PR! Please sign the CLA and we’ll go ahead and merge it.

@StellaAthena, sure. I have signed the CLA. Ready to merge.


xlim (and ylim) break my plots

I find that xlim() (and ylim()) break my plots (though only inline in iPython notebooks). For instance, calling the following
ggplot(aes(x='time', y='OD555', color='conc_GLY'), data=tpm_lim) +\
    geom_point() +\
    geom_line() +\
    xlim(0.115 , 0.140)

yields
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-266-64369a019002> in <module>()
----> 1 ggplot(aes(x='time', y='OD555', color='conc_GLY'), data=tpm_lim) +    geom_point() +    geom_line() +    ylab('OD$_{555}$') +    xlab('time (min)') +    xlim(0.115 , 0.140)

TypeError: unsupported operand type(s) for +: 'ggplot' and 'tuple'

although this seems to be the same as the usage in a docs example (which also breaks for me):
ggplot(diamonds, aes(x='carat', y='price')) +\
    geom_point() +\
    ylim(2,3)

I'm running ggplot (0.6.5), and matplotlib (1.4.3).

@joshmaxsilverman , you are mixing ggplot and matplotlib interfaces. The correct ggplot way
ggplot(aes(x='time', y='OD555', color='conc_GLY'), data=tpm_lim) +\
    geom_point() +\
    geom_line() +\
    scale_x_continuous(limits=[0.115 , 0.140])

Thanks! All fixed now.
I'm still a bit confused, it seems in the docs example, xlim is used as part of the ggplot interface: http://ggplot.yhathq.com/docs/xlim.html
Do you know why this is?

They are upkeep issues, some parts of the code base changed and the unit-tests didn't pick it up. It should clear up in the near future.

fixed in 0.9.3