What cameras has highest chance to be working with Yi-Hack in 2024?

I would like to buy camera that can run Yi-Hack, but I can not check their serial number because I will order them online.
What camera has highest chance to be working with Yi-Hack in 2024?
I hate cloud based cameras, I only want IP wireless camera, that's why I would like to have Yi-Hack on camera.

ive had extraordinary luck with the dome guards, i have 31 with allwinnerv2 and two yi home pro 2k. only had a problem on 2 dome guards, first one was drunken user created problems, second tbd.


Fix resolving environment/system variables for annotations

Fix resolving environment/system variables for annotations
Fix sample syntax

Codecov Report

Merging #265 into next-release will not change coverage.
The diff coverage is 0%.

@@               Coverage Diff               @@
##             next-release     #265   +/-   ##
===============================================
  Coverage           61.28%   61.28%
  Complexity            117      117
===============================================
  Files                  13       13
  Lines                 607      607
  Branches               61       63    +2
===============================================
  Hits                  372      372
  Misses                203      203
  Partials               32       32

Impacted Files
Coverage Δ
Complexity Δ

...org/ballerinax/docker/utils/DockerPluginUtils.java
37.14% <0%> (ø)
5 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

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


Question: Starting width on a docked auto-hidden window

I have some tool/work windows that the user can open (from menu or tool bar). The tool window then adds as auto hide on the left or right side depening on the type of window. When the users hovers over the button the tool windows opens and the user can work in it.
My problem is that I want to set the starting width on each opened window seperatly since some have to be smaller and some larger than the default size. How can I do that? As of now the user have to manually resize it after opening it to get the correct size.
A related question is if it is possible to start with the window opened? And that it hides first after the user entered the window and then leaves it (with the mouse pointer)? It would also be helpful in some cases.

You might go through previous discussions. I think yours have already been discussed.
https://github.com/dockpanelsuite/dockpanelsuite/search?q=auto+hide&type=Issues&utf8=✓


Receive Data

LoRaWan communications.
How to receive data instead of send?
In the examples folder there are examples about how to send data from a device to a server. But how to handle data received from a server? In particular I’m sending data through the helium console “downlink” tool.

Hi,
In the LoRaWAN examples you receive the data in the callbacks for RX, e.g. in the LoRaWAN_OTAA_ABP example it is in
void lorawan_rx_handler(lmh_app_data_t *app_data)
{
  Serial.printf("LoRa Packet received on port %d, size:%d, rssi:%d, snr:%d, data:%s\n",
          app_data->port, app_data->buffsize, app_data->rssi, app_data->snr, app_data->buffer);
}

In LoRaWAN are three node classes:

Class A (lowest power consumption) - the node receives downlink packets from the Helium Console only after he has sent an uplink packet to the Helium Console
Class B - not supported
Class C - (highest power consumption) - the node is always in RX mode and the downlink packets from the Helium Console are received immediately

But Class C is not supported by the Helium Console (at least I cannot find how to set it).
So you receive a downlink packet from Helium Console only after the the RAK4631 node has sent an uplink packet.
You set the node class in the lmh_init(&g_lora_callbacks, g_lora_param_init, doOTAA, g_CurrentClass, g_CurrentRegion); call. The forth parameter g_CurrentClass sets the node class. Default is Class A. If you want to change to Class C, you have to do on both the node and in the Helium Console

Hi @beegee-tokyo thank you so much for the fast response! :smile:
If it's possible I have another question for you. I put it here but let me know if it would be better to open a new Issue.
I'm using this example to implement a GPS Tracker but without using the 3AXIS sensor. Everything works fine but I have two problems:

When I upload a new version of the code to the RAK4631 it takes too much time to localize itself. Sometimes 1 hour, sometimes 3 hours, sometime 6 hours. Is it normal? Can you explain me why it takes so long or how to fix it?
The RAK4632, when localized, send a packet every 20 seconds. However when I move the RAK (e.g driving around the city) the position is updated rarely (like every minute). What i mean is that for 1 minute sends always the same [LAT,LONG] coordinates.

Thanks again for your time. Really appreciate your work!

@Famosi
Where are you testing the GPS tracker example code? I am getting a location fix within 12 to 30 seconds when outside of the building. Inside the house I never get a location fix when the device is on my table. Moving it to a (not tinted) window, I can get a location fix within ~40 seconds.
Sending every 20 seconds, when moving is too fast in my opinion.
 The antenna has a white sticker on one side. This side should be oriented towards the sky to get a fast location fix.

I was testing it on my table (indoor).... that's should be the reason! :smiling_face_with_tear:
Now outside the window it takes about 1 min. I didn't test it cause I didn't have a 3V battery to move it outside.
I think you can close this issue, hope it helps someone else.
Thank you for your time!

Will close this now.
If you have more questions, you can open a new issue here or (better, because more people can support) open it on our Forum


[AUTOPATCHER] Patches CVE-2021-3631 for libvirt

        Patches CVE-2021-3631 for libvirt.
        This patch and PR was automatically generated and needs human verification before merging.

Duplicate of #2526


[C++] Create fragment scanners for csv/parquet/orc/ipc

Once we have the basic scan node ready (with an initial implementation based on in-memory fragments) then we can add over the file-format versions.  We may also want to consider adding JSON support for datasets at this time.
Reporter: Weston Pace / @westonpace
Assignee: Weston Pace / @westonpace
PRs and other links:

GitHub Pull Request #14663

Note: This issue was originally created as ARROW-17288. Please see the migration documentation for further details.

@westonpace was this PR closing this ticket? https://github.com/apache/arrow/pull/14663, can we create any follow ups on a different ticket so I can assign this to the 11.0.0 milestone?

No.  The ticket is for all the formats.  The PR only added support for one of them so I didn't close the ticket.  Perhaps unorthadox but I didn't want to split the JIRA issue into 4 similar issues.


Chain not unlinked from singly linked list

It seems that a chain never gets unlinked from its parent body singly linked list on destruction:
https://github.com/erincatto/box2c/blob/main/src/body.c#L675
BTW, I really like this way of dealing with chains (just a bunch of smooth segment shapes). Do you plan to change this?

Thanks for the report! Fixed in #82.


Modeller input for allocation

What should the input look like from the modeler to specify allocation? E.g. how are subnetworks, sources etc. specified?

Subnetworks have an ID and 1 or more sources where source is an edge. Nodes have an optional reference to a subnetwork ID. We reserve groups for different purposes.
We call this allocation sub-network

Priority of sources is at the level of a sub-network.

add optional column to node table called: allocationnetwork_id (long integer)
add optional column to edge table: allocationnetwork_id (long integer)


Syntax expires in DRM-GBM backend conf/local.conf

Follow the tutorial in the README file to add conf/locale.conf line, An error has occurred:
ERROR: Variable DISTRO_FEATURES_append file: /root/build/conf/local.conf line: 278 contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake.
After changing to DISTRO_FEATURES:append = " systemd", WORK!
Related links：
https://low-level.wiki/yocto/honister-upgrade.html

Thank you for reporting the issue.


[e2e]: generic workflow_dispatch branch1 default slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/8422586208
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.workflow_dispatch.branch1.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.workflow_dispatch.branch1.default.slsa3.yml
Trigger: workflow_dispatch
Branch: main
Date: Mon Mar 25 15:33:03 UTC 2024

Repo: https://github.com/slsa-framework/example-package/tree/branch1
Run: https://github.com/slsa-framework/example-package/actions/runs/8430176851
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.generic.workflow_dispatch.branch1.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.generic.workflow_dispatch.branch1.default.slsa3.yml
Trigger: workflow_dispatch
Branch: branch1
Date: Tue Mar 26 03:08:00 UTC 2024
Tests are passing now. Closing this issue.


Vue's mjs type error

Vue version
3.3.1
Link to minimal reproduction
https://github.com/xiaoxiangmoe/issue-vue-3-mjs-type-error
Steps to reproduce
yarn install
yarn tsc # it throw no type error
node src/vue3-default-import.mjs # it throw runtime error

What is expected?
It SHOULD throw type error
What is actually happening?
it throw NO type error
System Info
No response
Any additional comments?
in vue's package.json. it write
  "exports": {
    ".": {
      "types": "./dist/vue.d.ts",
      "import": {
        "node": "./index.mjs",
        "default": "./dist/vue.runtime.esm-bundler.js"
      },
      "require": "./index.js"
    }

Both esm and cjs is provided in same file ./dist/vue.d.ts.
Maybe we should provide seperate .d.cts and .d.mts
For example, in my repo, if run
cat node_modules/vue/dist/vue.d.ts | sed "s?../jsx?./jsx?g" > node_modules/vue/index.d.ts
cat node_modules/vue/dist/vue.d.ts | sed "s?../jsx?./jsx?g" > node_modules/vue/index.d.mts
# copy /dist/vue.d.ts to index.d.ts and index.d.mts

cp node_modules/vue/package.json node_modules/vue/package.json.bak
sed '/"types": ".\/dist\/vue.d.ts"/d' node_modules/vue/package.json.bak > node_modules/vue/package.json
# change remove types field

Then run tsc. it will throw type error.
src/vue3-default-import.mjs:2:8 - error TS1192: Module '"/Users/me/issue-vue-3-mjs-type-error/node_modules/vue/index"' has no default export.

2 import vueDefaultImport from 'vue'
         ~~~~~~~~~~~~~~~~

Found 1 error in src/vue3-default-import.mjs:2

error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

This is work as intended.

Shouldn't this be considered a TypeScript bug?

https://github.com/arethetypeswrong/arethetypeswrong.github.io#:~:text=Types are CJS%2C but implementation is ESM
It falls into this category: "Types are CJS, but implementation is ESM".
Not a big deal because Vue 3 never supported default export, but still an improvement if we can error on the type level.

closed via d621d4c6


Gradle task not found

Component: sqldelight-gradle-plugin
Version: both 1.1.0-SNAPSHOT and 1.2.0-SNAPSHOT
Configuration:
build.gradle.kts (common)
plugins {
    kotlin("multiplatform")
    id("com.squareup.sqldelight")
}
apply(from = File("sqldelight.gradle"))
// ...

sqldelight.gradle (common)
sqldelight {
    TodoSqlDelightDatabase {
        packageName = "com.sample.todo.data.sqldelight"
        sourceFolders = ["sqldelight"]
        schemaOutputDirectory = file("src/main/sqldelight/migrations")
    }
}

Step to reproduce:
gradlew common:tasks
// ...
Sqldelight tasks
----------------
generateAndroidMainTodoSqlDelightDatabaseInterface - Generate androidMain Kotlin interface for TodoSqlDelightDatabase
generateAndroidMainTodoSqlDelightDatabaseSchema - Generate a .db file containing the current TodoSqlDelightDatabase schema for androidMain.
generateMetadataMainTodoSqlDelightDatabaseInterface - Generate metadataMain Kotlin interface for TodoSqlDelightDatabase
generateMetadataMainTodoSqlDelightDatabaseSchema - Generate a .db file containing the current TodoSqlDelightDatabase schema for metadataMain.
verifyAndroidMainTodoSqlDelightDatabaseMigration - Verify androidMain TodoSqlDelightDatabase migrations and CREATE statements match.
verifyMetadataMainTodoSqlDelightDatabaseMigration - Verify metadataMain TodoSqlDelightDatabase migrations and CREATE statements match.
// ...

gradlew common:generateMetadataMainTodoSqlDelightDatabaseInterface
Configuration on demand is an incubating feature.

> Configure project :common
Kotlin Multiplatform Projects are an experimental feature.
Configuring compileKotlinAndroid in project common...
Configuring compileTestKotlinAndroid in project common...

FAILURE: Build failed with an exception.

* What went wrong:
Task 'generateMetadataMainTodoSqlDelightDatabaseInterface' not found in project ':common'.

* Try:
Run gradlew tasks to get a list of available tasks. Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to g
et full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 2s

do the generateAndroidMain... tasks work fine?

Just tried out all 6 tasks listed, all report task not found

thats....really confusing. Maybe related to kotlin gradle script stuff. Have you tried running the task from IDE instead of command line? Curious if that says anything different

Tasks are all listed in the Gradle panel (Android Studio)
Run tasks from IDE produce the same result,
I suspect the same thing.
Since I do not know how to configure this through Gradle Kotlin DSL so I just apply from a regular one. The fact that tasks name contain my database class name prove that the sqldelight.gradle applied successful

yea and their appearance in the list should mean the tasks are actually working...
what version of gradle are you using?

Just migrated backed to a groovy script, same issue
build.gradle (:common)
plugins {
    id 'org.jetbrains.kotlin.multiplatform'
    id 'com.squareup.sqldelight'
}

sqldelight {
    TodoSqlDelightDatabase {
        packageName = "com.sample.todo.data.sqldelight"
        sourceFolders = ["sqldelight"]
        schemaOutputDirectory = file("src/main/sqldelight/migrations")
    }
}

kotlin {
    sourceSets {
        commonMain {
            dependencies {
                implementation("com.squareup.sqldelight:runtime")
                implementation("org.jetbrains.kotlin:kotlin-stdlib")
            }
        }
        commonTest {
            dependencies {
                implementation("org.jetbrains.kotlin:kotlin-test-common")
                implementation("org.jetbrains.kotlin:kotlin-test-annotations-common")
            }
        }
        jvm("android").compilations["main"].defaultSourceSet {
            dependencies {
                api("com.squareup.sqldelight:runtime")
            }
        }
        jvm("android").compilations["test"].defaultSourceSet {
            dependencies {
                implementation("org.jetbrains.kotlin:kotlin-test")
                implementation("org.jetbrains.kotlin:kotlin-test-junit")
            }
        }
    }
}

My gradle version is 5.2.1

it might be a gradle compatibility issue. I'll try upgrading our test suite to 5.2.1 and see what happens

I'll try to downgrade to 4.10.2, good luck

^
Done
Gradle 4.10.2 + Android Gradle Plugin 3.3.0 + normal Groovy script produce the same issue
Here is the stack trace in case it help
gradlew common:generateMetadataMainTodoSqlDelightDatabaseInterface --stacktrace
Parallel execution is an incubating feature.
Parallel execution with configuration on demand is an incubating feature.

> Configure project :common
Kotlin Multiplatform Projects are an experimental feature.
Configuring compileKotlinAndroid in project common...
Configuring compileTestKotlinAndroid in project common...

FAILURE: Build failed with an exception.

* What went wrong:
Task 'generateMetadataMainTodoSqlDelightDatabaseInterface' not found in project ':common'.

* Try:
Run gradlew tasks to get a list of available tasks. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.execution.TaskSelectionException: Task 'generateMetadataMainTodoSqlDelightDatabaseInterface' not found in project ':common'.
        at org.gradle.execution.TaskSelector.getSelection(TaskSelector.java:116)
        at org.gradle.execution.TaskSelector.getSelection(TaskSelector.java:81)
        at org.gradle.execution.commandline.CommandLineTaskParser.parseTasks(CommandLineTaskParser.java:42)
        at org.gradle.execution.TaskNameResolvingBuildConfigurationAction.configure(TaskNameResolvingBuildConfigurationAction.java:44)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:48)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.access$000(DefaultBuildConfigurationActionExecuter.java:25)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter$1.proceed(DefaultBuildConfigurationActionExecuter.java:54)
        at org.gradle.execution.DefaultTasksBuildExecutionAction.configure(DefaultTasksBuildExecutionAction.java:44)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:48)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.access$000(DefaultBuildConfigurationActionExecuter.java:25)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter$1.proceed(DefaultBuildConfigurationActionExecuter.java:54)
        at org.gradle.execution.ExcludedTaskFilteringBuildConfigurationAction.configure(ExcludedTaskFilteringBuildConfigurationAction.java:47)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:48)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.select(DefaultBuildConfigurationActionExecuter.java:36)
        at org.gradle.initialization.DefaultGradleLauncher$CalculateTaskGraph.run(DefaultGradleLauncher.java:305)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:300)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:292)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:174)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.initialization.DefaultGradleLauncher.constructTaskGraph(DefaultGradleLauncher.java:190)
        at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:145)
        at org.gradle.initialization.DefaultGradleLauncher.executeTasks(DefaultGradleLauncher.java:124)
        at org.gradle.internal.invocation.GradleBuildController$1.call(GradleBuildController.java:77)
        at org.gradle.internal.invocation.GradleBuildController$1.call(GradleBuildController.java:74)
        at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:154)
        at org.gradle.internal.work.StopShieldingWorkerLeaseService.withLocks(StopShieldingWorkerLeaseService.java:38)
        at org.gradle.internal.invocation.GradleBuildController.doBuild(GradleBuildController.java:96)
        at org.gradle.internal.invocation.GradleBuildController.run(GradleBuildController.java:74)
        at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
        at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
        at org.gradle.tooling.internal.provider.ValidatingBuildActionRunner.run(ValidatingBuildActionRunner.java:32)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.run(RunAsBuildOperationBuildActionRunner.java:50)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:300)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:292)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:174)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:45)
        at org.gradle.tooling.internal.provider.SubscribableBuildActionRunner.run(SubscribableBuildActionRunner.java:51)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:47)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:44)
        at org.gradle.composite.internal.DefaultRootBuildState.run(DefaultRootBuildState.java:79)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:44)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:39)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:25)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:80)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:53)
        at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:62)
        at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:34)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:36)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:25)
        at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:43)
        at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:29)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:59)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:31)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:59)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:44)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:46)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:30)
        at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:67)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:122)
        at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:37)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:122)
        at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:26)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:122)
        at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:34)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:122)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:74)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:72)
        at org.gradle.util.Swapper.swap(Swapper.java:38)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:72)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:122)
        at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:122)
        at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:62)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:122)
        at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:81)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:122)
        at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:50)
        at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:295)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)

* Get more help at https://help.gradle.org

BUILD FAILED in 2s

In case you need the current project that produces this issue, I thought it would be helpful
https://github.com/nlgtuankiet/todo-sample
My local development has more few commits ahead with the master brand, but you can pretty much start from there.

thanks for linking the project, will be easier to debug from that

do you mind pushing a branch with everything in groovy/gradle4.10.2? will be a bit easier from my end

Done, haven't thought of that, thank for the suggestion

yup i see it too. Very weird bug. The only thing I can think of is that it still has to do with the gradle kotlin dsl since the root project uses it. We'll have to setup a test case in repo for the kotlin dsl to make sure it works

Same issue here, reverted to 1.0.3 fttb.

I believe this is due to enabling configure on demand in Gradle which someone breaks the SQLDelight plugin.

@ansman did the latest release fix this?

Hi,
info on when this issue will be fixed?
Thanks

its caused be enabling configure on demand

did you mean this?
org.gradle.configureondemand=false

Any known solutions?
org.gradle.configureondemand=false doesn't work, tried in terminal and in gradle.properties

@ATizik make sure you don’t have it in ~/.gradle/gradle.properties. It counter intuitively overrides whatever you have in your project config.
Perhaps SQLDelight should throw an error when CoD is detected until it’s been fixed.

@ansman
Tried on OSX and Linux: explicitly added org.gradle.configureondemand=false to ~/.gradle/gradle.properties, still the same missing task
Basically adding sqldelight 1.1.3 to https://github.com/JetBrains/kotlin-mpp-example breaks it.
1.0.3 works fine

@ATizik Just had the same problem. I was trying to run the gradleTask via IntelliJ. I had to go into the IntelliJ Preferences -> Build, Execution, Deployment -> Gradle-Android Compiler and disable Configure On Demand.

@kgonyon
There is no such option in Intellij 2019.1 or Appcode 2019.1, and executing from terminal gives the same missing task

turns out this is actually preventing us from upgrading the sample to 1.1.3 because we use configure on demand for CI, so this is pretty high priority
I'm going to need to rethink the sqldelight gradle lifecycle more. It's too late to rework things right now but here's what I think needs to be done:
Right now we rely on projectsEvaluated to add the sqldelight tasks and dependencies to the task graph, this doesnt work for configuration on demand. It's not super clear why, I'm assuming the time which that callback gets invoked is different with COD and its too late to set task dependencies.
That's pretty hacky regardless, so probably what we need to do is use task creation callbacks instead of project evaluation callbacks. The original problem was that kotlin multiplatform adds the android compilation tasks late in gradles lifecycle, and projectsEvaluated always invoked after that. Instead we should probably use tasks.whenTaskAdded to add sqldelight task dependencies when the kotlin compilation tasks are added.
There's also some implications for multi-module here, since module properties are initialized during afterEvaluate blocks, we were assuming they're set up when creating tasks in projectsEvaluated, but if we switch to task creation that probably won't hold, so we'll also need to make sure the downstream sqldelight module is configured, which probably requires more understanding of how gradle implements configure on demand.

Hi all,
Are there good news?
Thanks

org.gradle.configureondemand=false wfm

@AlecStrong was this fixed? I'm having a similar issue in my project (although I'm not using SqlDelight), can you let me know how you fixed this? Cheers.

It's fixed on master, but theres a bug I'm trying to work through before
doing a release. You can try using the snapshot version
On Sat., Jul. 6, 2019, 5:18 a.m. Franco Sabadini<EMAIL_ADDRESS>wrote:

@AlecStrong https://github.com/AlecStrong was this fixed? I'm having a
similar issue in my project (although I'm not using SqlDelight), can you
let me know how you fixed this? Cheers.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/square/sqldelight/issues/1243?email_source=notifications&email_token=AAMZBQACZYDW67FOGKFNFQDP6BPNTA5CNFSM4G2W5W3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKV2EY#issuecomment-508910867,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMZBQFSDLAHOD54WR5SXSDP6BPNTANCNFSM4G2W5W3A
.

The fix was to not rely on the gradle.projectsEvaluated api
On Sat., Jul. 6, 2019, 9:06 a.m. Alec Strong<EMAIL_ADDRESS>wrote:

It's fixed on master, but theres a bug I'm trying to work through before
doing a release. You can try using the snapshot version
On Sat., Jul. 6, 2019, 5:18 a.m. Franco Sabadini, <
<EMAIL_ADDRESS>wrote:

@AlecStrong https://github.com/AlecStrong was this fixed? I'm having a
similar issue in my project (although I'm not using SqlDelight), can you
let me know how you fixed this? Cheers.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/square/sqldelight/issues/1243?email_source=notifications&email_token=AAMZBQACZYDW67FOGKFNFQDP6BPNTA5CNFSM4G2W5W3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKV2EY#issuecomment-508910867,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMZBQFSDLAHOD54WR5SXSDP6BPNTANCNFSM4G2W5W3A
.


Fixed and simplified the assertion handling logic: even with flatten …

…and forceinline allover pure debug codegen is still larger for the entupling-delayed-streaming approach compared to inline streaming operator calls.

So, what does this PR fix ?
I see kumi fixes but you end up not using tuple anymore ?
What shoudl we do with this ?
Could the kumi changes be PR'ed over at kumi ?

So, what does this PR fix ?

'Source location' parameters were incorrectly propagated (e.g. the location would always be the assert helper function 🙈 😊)

I see kumi fixes but you end up not using tuple anymore ? What shoudl we do with this ?

The other issue was the bloated code generated by my previous changes - the kumi changes (forceinlines and all that) were attempts to workaround that - however it wasn't enough - so I gutted the 'entuplment' shenanigans alltogether - but left the kumi changes for you to choose if perhaps you want them anyway...

Could the kumi changes be PR'ed over at kumi ?

As you like, I can remove them from the PR alltogether.

OK, I'm for :

you remove the kumi fixes and make a kumi PR or issur for them
we merge the rest
?

Are you OK now with the gen code btw ?

kumi PR or issur for them

pr on the separate repo for kumi library or on this repo just a separate pr for that file alone?

Last thing too. Can't BOOST_ENABLE_ASSERT_HANDLER be KWK_ENABLE_ASSERT_HANDLER ? Then we ifdef BOOST_ENABLE_ASSERT_HANDLER to set the other macro up ?

not sure what you mean - i use BOOST_ENABLE_ASSERT_HANDLER to detect if the user is using Boost.Assert machinery - i.e. has potentially setup a custom assertion handler (boost::assertion_failed_msg) and then respect that by delegating the final handling of the assertion failure to that handler

Are you OK now with the gen code btw ?

never(tm) 😅  ... but enough that i'm not going to spend more time on it (ideally the macro invocations would all have to be changed which, i suppose, is not worth the effort)

not sure what you mean - i use BOOST_ENABLE_ASSERT_HANDLER to detect if the user is using Boost.Assert machinery - i.e. has potentially setup a custom assertion handler (boost::assertion_failed_msg) and then respect that by delegating the final handling of the assertion failure to that handler

I mean we don't depends on BOOST so requriign user to overload BOOST_ENABLE_ASSERT_HANDLER is strange. We can keep the same internal mecanism but ties up to a KWK_ macro.

AAAAH no wait I see what is going on. So, no that's OK.


Add Service Bus Event Handler preview to Event Handlers list in Overv…

…iew page of EventGrid

@vplauzon : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks great, thanks for the catch @vplauzon #sign-off


Fix some ansible_vars to make them generic

ctlplane uses a var ctlplane_subnet_cidr where as other networks just use <network_name>_cidr ex. storage_cidr.
As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running

/approve
This patch is a Depends-On for https://github.com/openstack-k8s-operators/dataplane-operator/pull/614 - though we'll have to sync properly in order to merge them both. Once 614 is green, we should be able to merge this one, and get 614 in as well. Correct, @rabi ?

@cjeanner can we force merge this please as the other PR got merged?

recheck


create-turbo - aborting installation in ubuntu 20.4 with all 3 package managers

What version of Turborepo are you using?
latest
What package manager are you using / does the bug impact?
npm, pnpm, Yarn v1
What operating system are you using?
Linux
Describe the Bug
I followed the instructions for initial installation.
ubuntu 20.4.
npm 8.19.1
yarn 1.22.19
pnpm 7.11.0
I run
npx create-turbo@latest
then I select directory and a package manager, and I get this error:
>>> TURBOREPO

>>> Welcome to Turborepo! Let's get you set up with a new codebase.

? Where would you like to create your turborepo? portfolio
? Which package manager do you want to use? npm

Aborting installation.
Unexpected error. Please report it as a bug:
TypeError: import_fs.default.cpSync is not a function
    at run (/home/me/.npm/_npx/e8c68b66aeb1424f/node_modules/create-turbo/dist/index.js:319:21)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)

I tried updating npm, restarting, but no idea what this error message means. I tried googling it but can't find anything similar enough for me to understand. Help please!
Expected Behavior
successful installation
To Reproduce
no idea.

Got this error too

I also got the same error in macOS Monterey version 12.5.1.

I also got the same error in macOS Monterey version 12.5.1.

This should be fixed on node 16 (similar issue: https://github.com/vercel/turborepo/issues/1856)

updated to node v18 and worked perfectly. Thank you tk!

This issue is present for me on Macos, with node 16 - i had to upgrade to node 18 to resolve it

I've also just hit this issue. So Turborepo requires Node 18? Is that the solution here?

I had the same issue in macOS Monterey 12.6, I was using Node version 14.18.0, I upgraded to 16.18.0 and the issue is gone.


Docs: add note about AKS kube-apiserver entity

Adds a note to the docs that kube-apiserver
entity is not available in AKS.

Looks good, thanks!
Is there an easy way to check whether the entity is available for a specific distribution?

No that I'm aware of. I will do some tests on EKS and GKE next week.

Could you clarify what you mean by "unavailable"? As far as I understand it, kube-apiserver works fine for egress traffic, even on AKS. But it won't work for ingress traffic (because of NAT) (ref #31711 (comment))

You're absolutely right; the note should mention that only ingress statements with `fromEntities: kube-apiserver affected.

Could you clarify what you mean by "unavailable"? As far as I understand it, kube-apiserver works fine for egress traffic, even on AKS. But it won't work for ingress traffic (because of NAT) (ref #31711 (comment))

I tested against AKS, EKS and GKE and the behaviour is the same. kube-apiserver doesn't work for ingress traffic, but for egress traffic. Should be ready to be merged.

/test


Custom Report - Data returned is missing and can't be exported.

When I go onto the production platform and the custom report area under reports, I run a report for the working preferences section, but the data returned states value/blank for some candidates. The users need to provide this data to our stakeholders are currently having to do this manually from each application and be able to show their information ranked.

We currently have 3 exercises that need this information:
066 - Circa 216 candidates - https://admin.judicialappointments.digital/exercise/Yt04PxbBde5nfZxNgFWx/details/overview
070 - Circa 400 candidates - https://admin.judicialappointments.digital/exercise/Yt04PxbBde5nfZxNgFWx/details/overview
077 - Circa 069 candidates - https://admin.judicialappointments.digital/exercise/Yt04PxbBde5nfZxNgFWx/details/overview
For 066 - We need all candidates at the recommended stage and need their Jurisdiction and Location Preferences in rank order

For 070 - We need all candidates at the selected stage. We need their answers to the jusdication question and all additional preferences questions. The If you are applying for the First-tier Tribunal, please rank your choice of chambers. As business requirements may change throughout the exercise for appointment in the First-tier Tribunal you are required to rank all chambers in order of preference on your application; one being your most preferred choice and seven being your least preferred. (Ranked choice) question should be returned as ranked in the data.

For 077 - We need all candidates at the selected stage nd need their Jurisdiction and Location Preferences. The location preferences should be ranked in the data return.

All data needs to be exported via a button on the platform - this is currently missing.

Hey @andrew-isaac I have exported the data for the three exercises so the immediate requirements are satisfied. I haven't amended the custom report so have moved this ticket to the backlog to be implemented in the future.

@tomlovesgithub  - Is there any update on when this can be released? I have more teams requesting this type of data now from me for a large exercise.


Rohita lal

Issue 466

There are only 4 questions in physics quiz section.

Fixes: #466
Added 11 more questions
I've added 11 new questions in physics quiz section from different topics.
Screenshots

@rohitalal why have u added 5000+ files. Send only the questions file in the PR

@rohitalal why did u delete the entire package.json?


Add wal backpressure performance tests

Resolves #1889.
This PR adds new tests to measure the WAL backpressure's performance under different workloads.
Changes

add new performance tests in test_wal_backpressure.py
allow safekeeper's fsync to be configurable when running tests

Preliminary results:

run_duratitrue
read_latency_max
read_latency_avg
read_latency_stdev

heavy_write[vanilla]
8.438
0.114
0.046
0.029

heavy_write[netrue, fsync=false]
34.892
2.047
1.137
0.564

heavy_write[netrue, fsync=on]
60.459
3.562
1.951
0.851

pgbench_simple_update[vanilla]
2.488
0.404
0.236
0.238

pgbench_simple_update[netrue, fsync=false]
6.158
0.578
0.528
0.039

pgbench_simple_update[netrue, fsync=on]
48.186
11.407
1.465
2.826

other_table[vanilla]
21.407
0.036
0.012
0.006

other_table[netrue, fsync=false]
46.768
0.479
0.135
0.130

other_table[netrue, fsync=on]
105.960
20.600
0.630
2.589

There is a noticeable performance drop when fsync is enabled in the safekeeper config (disabled by default for tests). For example, I cannot reproduce the issue in #1763 if fsync is disabled. My best guess is that fsync is the bottleneck here.

Seconds I saw three warnings:
 Command '['/home/knizhnik/zenith/tmp_install/bin/pgbench', '-s1000', '-i', 'host=localhost port=5432 dbname=postgres options=-cstatement_timeout=120s']' returned non-zero exit status 1.

I wonder if it indicates some error...

I saw that too. It's because a query's timeout is set to be 120s. That's one reason why I don't increase the workload too much.

May be we should increase write workload (produce more WAL) or adjust default parameters for this test.

Yeah we should adjust the default parameters to make the throttling happen more often

I never saw "backpressure throttling" backend status (but I have to say that throttling sometime happen, because once I have added correspondent trace, I saw such messages in the log).

Can you share the modifications you make? It's helpful for me to use that for reference when making changes

My best guess is that fsync is the bottleneck here.

It could be. Where do you run these tests? I suggest trying to run some benchmarks to understand how fast is your disk. pg_test_fsync should be enough to get basic fsync performance, but you can also run fio and look at https://github.com/neondatabase/perftest-sk/blob/master/common/disk-perf.md for examples.

It could be. Where do you run these tests?

I run locally on my M1 air using release build.

At my laptop test is not completed in 20 minutes.
Also printing avg/stddev of read request delay seems to be not enough. It will be much more interesting to see histogram or at least maximal value.

My best guess is that fsync is the bottleneck here.

I do not think so.
First of all in case of bulk load (copy, i.e. pgbench -i) all changes are inserted inside one transaction. fsync is rarely performed.
Performance is limited by disk write speed.
With large number of small update transaction (pgbehch -N) situation is quite different. Please notice that to commit transaction compute node should want until it is synced by all safekeepers.  But there should not be a big replication lag. Assume that you run pgbench -c 10 -N. In this case there can be up to ten concurrently executed transactions. The LSN lag between compute node and safekeeper should not be arge than 10*transaction_size, in where transaction size i this case is very small ~100 bytes.
Actually to trigger backpressure we should make safekeepers to work faster and pageserver - slower. It cn be achienved by setting fsync=off for safekeeper (disabling fsyncs at page server is not currently supported, them are always performed).
In this case transaction will be committed faster and appended to the safekeeper log, but pageserver can not consume them with the same rate).
But if safekeeper and pageserver are working at the same node (as in case of local tests), then fsyncs performed by safeleeper may significantly afect total system performance At my laptop intensive disk writes may cause several seconds delay for disk operations (reads and writers). At Mac OS/X  fsync is very expensive. So here the picture can be even more complicated and obscure.

Can you share the modifications you make? It's helpful for me to use that for reference when making changes

I just added corresponding logging to handling replication lag in ProcessInterrupts. This messages are printed to pg.log. It is not so convenient to monitor them from tests. May be we should just periodically chek backends status (pg_stat_activity) for backpressure throttling and also output current replication lag usig backpressure_lsns() and `pg_current_wal_flush_lsn ()' functions.

Size of foo table is ~3Mb. With shared_buffers=1MB (default value) it doesn't fir in ompute shared memory and so select count(*_ from foo cause fetching pages fro pageserver. But with large value of shared buffers (i.e. 128Mb used at staging and production), this query may not cause access to page server at all. So our test will not notice delay caused by replication lag.

At my laptop test is not completed in 20 minutes.
Also printing avg/stddev of read request delay seems to be not enough. It will be much more interesting to see histogram or at least maximal value.

Look like you're running the old version of the tests. Can you update the branch and try again? I have removed the vacuum step when doing pgbench -s100 -i. Without that, it will run for a really long time (> 5min in my laptop). Not sure why it's that slow compared to vanilla, 4x slower read time doesn't seem to justify the scale, maybe there are other things, idk.
I also added the maximum latency read as a report value. Agree that it would be much better to have some kind of visualization.

But if safekeeper and pageserver are working at the same node (as in case of local tests), then fsyncs performed by safeleeper may significantly afect total system performance At my laptop intensive disk writes may cause several seconds delay for disk operations (reads and writers). At Mac OS/X fsync is very expensive. So here the picture can be even more complicated and obscure.

That makes sense and also explain the performance difference when running with fsync on/off. I'll revert the changes and do some other experiments.

I also noticed significant difference fsync on/off for pgbench -i
Looks like I was wrong: looks like  128kb (maximal size of wal sender message) is not large enough to eliminate overhead of  fsyncing. As far as copy is done inside one transaction, sync replication wait can not slowdown walsender.
 So in this case bottleneck causing replication lag is safekeeper, not pageserver.

Yeah, look like the only place where there is a significant difference between fsync=true and fsync=false is in test_pgbench_intensive_init_workload. In the other two, the performance with fsync on is worse than fsync off, but not too much.

Important notes: the new tests in this PR (with default parameters) will make benchmark workflow 1.5 times slower from ~20min to ~30min.

Really interesting results. This is why I said that such performance tests should run at server hardware, not at local laptops.
But still is not quite clear to me how to interpret this results.

As we can see replication lag is not so large (< 20Mb). Most likely it is result of backpressure (max_replication_write-lag is 15Mb). It will be interesting to change it to 500Mb and check maximal lag and delays in this case.
For some reasons I do not see much difference at my local laptop.

Even with 20Mb max lag, average delay is small (<1sec) but maximal delay is still  very large: ~1min.
Please notice that measuring time of "select count(*) from foo" we get not just max wail_lsn time, but time of execution of about 300 get_page_at_lsn calls. I tried to replace select count(*) from foo with select count(*) from pg_class but results are basically the same. I will be very useful to understand whats happening with pageserver (or with safekeepers/compute) when such large latency takes place. Unfortunately it is not clear how to achieve it. Locally at my computer I inserted message wrapping compaction, materialization checkpointing and other page server activity. And then I try to find correlation of this evens with drop downs in pgbench  TPS (reported each second). Looks like in my case delays are mostly caused by flushing and are more or less random: sometimes flushing frozen layers cause long delay, sometimes flushing of image layer. Looks like it is specific of my local SSD behavior and Linux driver. It is not clear how to make the same experiment at CI server.

max lag is almost the same for test_pgbench_intensive_init_workload with fsync=on and fsync=off, But max read latency is much higher for fsync=on. And test run time (i.e. time of database initialization) is smaller for fsync=on. It seems to be strange.

In neon_fixtures .py default value is overwritten with 15Mb

I played around with the test_measure_read_latency_heavy_write_workload test bit. I found it really hard to actually hit the backpressure with this test. There are a few reasons for this:

Every iteration in start_heavy_write_workload runs an UPDATE that scans the whole table. When it scans the whole table, it needs to read pages from the page server, which forces the backend to wait for the pageserver to catch up. That will drain any lag that has accumulated
With this workload, postgres will call smgrexists() on the FSM fork repeatedly, whenever it needs to extend the index. That again causes the backend to wait for the pageserver to catch up, draining any lag. (I noticed this by looking at pg_stat_activity, saw the backends blocked on the "Extension" wait event, and then I connected to the backend process with 'gdb' to see what exactly it was doing)
A single backend doing INSERTs isn't quite enough to saturate the page server.
The SELECT count(*) query that's used to measure the latency is quite slow, because it needs to scan the whole table. That hides much of the latency. Would be better to perform a very short query that nevertheless needs to read a single page, and hence needs to wait for the pageserver to catch up.

So the key to reproducing the issue is to make sure that the workload that's generating the WAL doesn't itself need to read anything from the pageserver, because whenever it needs to read, it blocks until the pageserver catches up. We want to reproduce the situation where the pageserver has trouble keeping up with the WAL being generated.
I made a few changes to the test and to the compute's relsize caching to fix those things, and now the test hits the max_replication_write_lag limit and backpressure throttling very quickly. I pushed those fixes to this branch. It needs some cleanup (I don't wait for all the threads to finish, for example), but I hope it's useful. The changes to vendor/postgres are in https://github.com/neondatabase/postgres/pull/175.
With these changes, the read latency in the test is pretty horrible, which is great :-):
------------------------------------------------------------------------------------- Benchmark results --------------------------------------------------------------------------------------
test_measure_read_latency_heavy_write_workload[neon-1].run_duration: 180.383 s
test_measure_read_latency_heavy_write_workload[neon-1].read_latency_avg: 64.833 s
test_measure_read_latency_heavy_write_workload[neon-1].read_latency_stdev: 19.573 s

This is all on my laptop, I didn't follow the discussions on fsyncs closely.
PS. There is a very useful tool for watching the lag from the Postgres side, in the 'neon' extension. For example:
postgres=# create extension neon;
CREATE EXTENSION
postgres=# SELECT x.pg_current_wal_flush_lsn - received_lsn, x.* FROM (select pg_current_wal_insert_lsn(), pg_current_wal_flush_lsn(), received_lsn, disk_consistent_lsn from backpressure_lsns()) x;
 ?column? | pg_current_wal_insert_lsn | pg_current_wal_flush_lsn | received_lsn | disk_consistent_lsn
----------+---------------------------+--------------------------+--------------+---------------------
     8272 | 0/211B510                 | 0/211B510                | 0/21194C0    | 0/1698CC0
(1 row)

The first column is the observed replication lag. When that reached max_replication_lag, the backpressure throttling kicks in. I kept an eye on that manually while I was running the tests, connecting to the postgres instance directly with psql. It would be handy to watch that as part of the python test itself.

I played around with the test_measure_read_latency_heavy_write_workload test bit. I found it really hard to actually hit the backpressure with this test. There are a few reasons for this:

Every iteration in start_heavy_write_workload runs an UPDATE that scans the whole table. When it scans the whole table, it needs to read pages from the page server, which forces the backend to wait for the pageserver to catch up. That will drain any lag that has accumulated
With this workload, postgres will call smgrexists() on the FSM fork repeatedly, whenever it needs to extend the index. That again causes the backend to wait for the pageserver to catch up, draining any lag. (I noticed this by looking at pg_stat_activity, saw the backends blocked on the "Extension" wait event, and then I connected to the backend process with 'gdb' to see what exactly it was doing)
A single backend doing INSERTs isn't quite enough to saturate the page server.
The SELECT count(*) query that's used to measure the latency is quite slow, because it needs to scan the whole table. That hides much of the latency. Would be better to perform a very short query that nevertheless needs to read a single page, and hence needs to wait for the pageserver to catch up.

So the key to reproducing the issue is to make sure that the workload that's generating the WAL doesn't itself need to read anything from the pageserver, because whenever it needs to read, it blocks until the pageserver catches up. We want to reproduce the situation where the pageserver has trouble keeping up with the WAL being generated.
I made a few changes to the test and to the compute's relsize caching to fix those things, and now the test hits the max_replication_write_lag limit and backpressure throttling very quickly. I pushed those fixes to this branch. It needs some cleanup (I don't wait for all the threads to finish, for example), but I hope it's useful. The changes to vendor/postgres are in neondatabase/postgres#175.
With these changes, the read latency in the test is pretty horrible, which is great :-):
------------------------------------------------------------------------------------- Benchmark results --------------------------------------------------------------------------------------
test_measure_read_latency_heavy_write_workload[neon-1].run_duration: 180.383 s
test_measure_read_latency_heavy_write_workload[neon-1].read_latency_avg: 64.833 s
test_measure_read_latency_heavy_write_workload[neon-1].read_latency_stdev: 19.573 s

This is all on my laptop, I didn't follow the discussions on fsyncs closely.
PS. There is a very useful tool for watching the lag from the Postgres side, in the 'neon' extension. For example:
postgres=# create extension neon;
CREATE EXTENSION
postgres=# SELECT x.pg_current_wal_flush_lsn - received_lsn, x.* FROM (select pg_current_wal_insert_lsn(), pg_current_wal_flush_lsn(), received_lsn, disk_consistent_lsn from backpressure_lsns()) x;
 ?column? | pg_current_wal_insert_lsn | pg_current_wal_flush_lsn | received_lsn | disk_consistent_lsn
----------+---------------------------+--------------------------+--------------+---------------------
     8272 | 0/211B510                 | 0/211B510                | 0/21194C0    | 0/1698CC0
(1 row)

The first column is the observed replication lag. When that reached max_replication_lag, the backpressure throttling kicks in. I kept an eye on that manually while I was running the tests, connecting to the postgres instance directly with psql. It would be handy to watch that as part of the python test itself.

Thanks for looking into this. Agree with most of the points you mentioned above. I've created another branch (#1919) to do some more experiments modifying the test's behaviour.
Also, look like you're experimenting with the old version of the tests. Regarding test_measure_read_latency_heavy_write_workload I have removed the update transaction to only do insert, and also add a function to record LSN write lag using the backpressure_lsns() function.
With that added, the test's result should contain lines like this:
....lsn_write_lag_max: 3771 kB
...lsn_write_lag_avg: 1730 kB
....lsn_write_lag_stdev: 759 kB

With these changes, the read latency in the test is pretty horrible, which is great :-):
------------------------------------------------------------------------------------- Benchmark results --------------------------------------------------------------------------------------
test_measure_read_latency_heavy_write_workload[neon-1].run_duration: 180.383 s
test_measure_read_latency_heavy_write_workload[neon-1].read_latency_avg: 64.833 s
test_measure_read_latency_heavy_write_workload[neon-1].read_latency_stdev: 19.573 s

This is all on my laptop, I didn't follow the discussions on fsyncs closely.

Just realized that this was with a debug build. With release build it looks much less horrible. Still, I think all the points hold.

@hlinnaka I tried your test with required relcache improvements at my laptop. Its execution takes so long time (so it is actually based on old version of test_wal_bckpressure) but latency is not so horrible, although >10 seconds delay seems to be not acceptable.
FAILED test_runner/performance/test_wal_backpressure.py::test_pgbench_simple_update_workload[neon_on_500MB-10000-10] - psycopg2.DatabaseError: no commit timestamps...

I wonder whether find_lsn_for_timestamp should bail if it doesn't find any timestamp (may because database is empty)?

The last version of test_wal_backpressure from thang/add-wal-backpressure-tests branch do not shows large read delays, but 2 tests are failed with error:
FAILED test_runner/performance/test_wal_backpressure.py::test_pgbench_simple_update_workload[neon_off_500MB-10000-10] - psycopg2.DatabaseError: no commit timestamp...
FAILED test_runner/performance/test_wal_backpressure.py::test_pgbench_simple_update_workload[neon_on_500MB-10000-10] - psycopg2.DatabaseError: no commit timestamps...

I wonder whether find_lsn_for_timestamp should bail if it doesn't find any timestamp (may because database is empty)?

In this PR, I tuned down the parameters a bit and only made some structural changes.
Now, most of the changes about the tests' behaviour will be in #1919. I've changed CI workflows in that branch to have a better feedback loop. Also, I have added Heikki's suggestions based and observed the write lag to approach the limit quickly. The tests in that branch are quite broken now, so will need to look into them first.

@knizhnik I think tests work well now on #1919. You can try run them on that branch.
 So, the big read latency in some tests is probably because of the write lag.

test_wal_backpressure on #1919 branch now consumes ore than 200Gb of disk space so I can't run it locally.
So we have now a lot of tests for backpressure. But what's next?
This tests proves well known fact that 500Mb write lag is too much and may cause long delays (minutes).
With 15Mb write lag delays are much smaller except this:
test_pgbench_simple_update_workload[neon_on_15MB-45-100].read_latency_max: 49.567 s

But it is hard to say whether such delay is actually caused by wait_lsn and what pageserver is doing during this 50 seconds.
May be node was just overloaded with work.
My original assumption was that small (10Mb) max_write_relication_lag allows to eliminate huge delays (>10 sec).
It's a pity if it is not true.
The next problem which makes me to look for replacement of current stop-and-wait throttling algorithm was that with max_replication_write_lag write speed was about 3 times slower.
This tests do not prove it: only in one case there is noticeable difference:
test_pgbench_simple_update_workload[neon_on_15MB-45-100].run_duration: 183.948 s
test_pgbench_simple_update_workload[neon_on_500MB-45-100].run_duration: 156.513 s

But even in this case it is not large enough. So based on the results of this tests there is o strong need in replacement of current simple stop-and-wait throttling algorithm.
What else we should try is cache for last written LSN (https://github.com/neondatabase/postgres/pull/167).
It is alternative way (to backpressure) to fix problem with read latency.

PR (https://github.com/neondatabase/postgres/pull/167) can not help to reduce read latency in test_pgbench_simple_update_workload just because reader access updated table.

So look like lag value limit itself is not enough warranty of small latency. At least at my laptop.

I understand the reasons of large read latency in  test_pgbench_simple_update_workload and other tests and why backpresser doesn;t help much;

By default wal_log_hints=on, to them are inserted into WAL without XID (by vacuum or select). Backpressure is not performed for backends having not XID, so it is not jelping in this case.
This test performes "SELECT * from pgbench_accounts where aid = 1" query in separate thread  but this query is also executed BEFORE index is constructed, so it required sequential scan. This is why read_latency_max is high.

With wal_log_hits=on
test_pgbench_simple_update_workload[neon_on_15MB-45-100].read_latency_avg: 50.435 s

wal_log_hints=off
test_pgbench_simple_update_workload[neon_on_15MB-45-100].read_latency_avg: 2.340 s

By default wal_log_hints=on, to them are inserted into WAL without XID (by vacuum or select). Backpressure is not performed for backends having not XID, so it is not jelping in this case.

Is wal_log_hints=on enabled in prod? Should we disable wal_log_hints for the wal backpressure task?

This test performes "SELECT * from pgbench_accounts where aid = 1" query in separate thread  but this query is also executed BEFORE index is constructed, so it required sequential scan. This is why read_latency_max is high.

Good catch! I have updated the tests. in #1919, the max read latency is reduced significantly on my local.

So we have now a lot of tests for backpressure. But what's next?
This tests proves well known fact that 500Mb write lag is too much and may cause long delays (minutes).

I'm not so sure. In fact, with only that lot of tests, the total test runtime is increased by ~40min, which is extremely slow. It can probably be helped with parallelism.

Is wal_log_hints=on enabled in prod?

Yes

In fact, with only new wal backpressure tests, the total test runtime is increased by ~40min, which is extremely slow.

I do not think that we should perform tests with 500Mb max_replication_write_lag.

However, given the fact that 500MB is the default setting in prod, we should probably wait.

IMHO we should change prod settings ASAP.

Hmm, I'm not sure I'm ready to jump to that conclusion. What is the speed that the pageserver can process the incoming WAL?

It greatly depends on workload (i.e. FPI from COPY vs. individual insert records, especially updating indexes)
and disk IO speed. But looks like 10Mb/sec is good estimation of write consumption speed.

So why are are we seeing read latency > 10 seconds for some queries?

10 MB/sec we get if there is no other activity.
If we there are active:

autovacuum
checkpointing (writing frozen lyers)
flushing layers
compaction

then speed can be decreased several times.
I tried to find out which of the activities above have the most impact on performance.
But looks like t my laptop the main showstopper is SSD itself: in case of intensive writes sometimes IO operations (fsyncs, writes and even reads) are sometimes blocked for dozen of seconds. At server hardware such effect is less noticeable.

Is the pageserver getting stuck on a lock sometimes, so that it pauses processing any WAL for 5-10 seconds? Or does the query need to wait for multiple pages, so that the overall response time is > 10 seconds, even though the wait on each page is only 1.5 s. Or what's going on?

I didn't ever see that pageserver is blocked on some locks.  Most frequently I see threads blocks in write/fsync.
Also please notice, that originally I say the huge delay problem with new client connection and first execution of some query.
In both cases client has to read much more than just one page: actually it reads substantial part of system catalog. It is hadren or may be even thousands of  pages. This is why total time can be much larger than 1 second. But with 10Mb max_replication_write_lag or with cached lst written LSN patch I rarely see delays larger than few seconds.

It would be useful to print out the current last_received_lsn once as second during the test. You could then see the speed that the pageserver is processing the WAL. Is it constant, or is there some pauses?

Backpressure tests are printing lag now,  adding it to current flush LSN we can monitor speed of consuming WAL by pageserver.

In fact, with only new wal backpressure tests, the total test runtime is increased by ~40min, which is extremely slow.

I do not think that we should perform tests with 500Mb max_replication_write_lag.

However, given the fact that 500MB is the default setting in prod, we should probably wait.

IMHO we should change prod settings ASAP.

Got it. Will disable it later.

It would be useful to print out the current last_received_lsn once as second during the test. You could then see the speed that the pageserver is processing the WAL. Is it constant, or is there some pauses?

Backpressure tests are printing lag now,  adding it to current flush LSN we can monitor speed of consuming WAL by pageserver.

I have added the code to print lsn_process_speed and lsn_produce_speed in #1919. I also disable wal_log_hints in the latest commit to see if that makes any difference.

If we assume conservatively that it's actually 10 MB/s, then a 15 MB max_replication_write_lag should give a max 1.5 seconds delay. So why are are we seeing read latency > 10 seconds for some queries?

This is only true if the difference between produce speed and process speed is consistently 10MB/s. IIUC, as a read request requires the latest LSN, theoretically, there can be a situation when produce speed = process speed and the lag is consistently at 14 MB/s. If that happens, the read request'll never finish because the page server keeps failing behind.

IIUC, as a read request requires the latest LSN, theoretically, there can be a situation when produce speed = process speed and the lag is 14 MB. If that happens, the read request'll never finish because the page server keeps failing behind.

Read request may require latest LSN. But latest at the moment of issuing this request. If soe WAL is produced after it, we should not wait for it. So the situation you have described is never possible. Achilles won't overtake the tortoise: walreceiver may never catch-up wih walsender without some kind of synchronization. But we are solving different problem: read_page_at_lsn doesn't need to catch-up. It just waits for the particular LSN. And even if request has "latest" flag, we still wait for last_record_lsn at the moment of receiving this requests.

IIUC, as a read request requires the latest LSN, theoretically, there can be a situation when produce speed = process speed and the lag is 14 MB. If that happens, the read request'll never finish because the page server keeps failing behind.

Read request may require latest LSN. But latest at the moment of issuing this request. If soe WAL is produced after it, we should not wait for it. So the situation you have described is never possible. Achilles won't overtake the tortoise: walreceiver may never catch-up wih walsender without some kind of synchronization. But we are solving different problem: read_page_at_lsn doesn't need to catch-up. It just waits for the particular LSN. And even if request has "latest" flag, we still wait for last_record_lsn at the moment of receiving this requests.

Yeah, you're right. The requested page stream only waits for at most req.lsn (the LSN at the time making the read request) LSN. And the time delay for waiting once the page service receives such page request is not big. What I don't understand is that for big read latency request, there is a delay between the time client makes the request and the time the page service receives the corresponding page stream.

@knizhnik I think I quite get the problem now. It's true that a single get_page_at_lsn request is fast, but when the page service receives multiple get_page_at_lsn requests, the total runtime is slow because the page service handles them sequentially and needs to wait for the latest LSN specified by each request. During the wait, the latest LSN for the next request is incremented as the page server processes more WALs. For example, assume 10MB/s WAL processing -> 15/10 = 1.5s maximum wait time for each request. A select count(*) from t with 100_000 involves around 375 blocks. So, in the worst cases, the total wait time is (375 * 1.5)s. Please correct me if I misunderstand something here.
In case of test_heavy_write_workload, SELECT * from t0 where key = 0 should involve one single get_page_at_lsn request, the reason for large latency (~4-5s) is because after we establishing a new connection, handling a read request requires PG to also read other relations. Looking into the logs, they seem to include pg_* tables such as pg_authid_rolname_index, pg_authid_oid_index, etc. This scales up the number of get_page_at_lsn requests for each read-latency record. I have tried to address this problem by reusing a PG cursor when recording read latencies in https://github.com/neondatabase/neon/pull/1919/commits/041dced18fa21ed12650a8ac86effaf140458ae6.
Compared to the previous commit, the read latency average for this test is reduced by 10x. However, the read latency and runtime for the test_pgbench_intensive_init_workload test are increased significantly. I'll need to look into a bit deeper into the reason. My quick investigation for the slow read latency is because select count(*) from t request involves reading multiple blocks (mentioned above), hence require requesting multiple get_page_at_lsn requests. But it's not clear to me why it's much slower now.

Please correct me if I misunderstand something here.
Yes, you understanding is correct.
PR #1919 address this problem, because updated relation dot not increase last written lsn for all other tables, so we can access catalog relation with old lsn and do not wait each time for page server to catch-up. In this PR cache is very small (just 4), so if many tables (and their indexes) are updated, then this cache will not help.  As alternative we can think about much larger cache, may be not for the whole relation but  for some relation chunk (i.e. 1Mb) or even individual pages. But such large cache shoudl be shared and so requires synchronized access. And it can become bottleneck.

However, the read latency and runtime for the test_pgbench_intensive_init_workload test are increased significantly.

Actually, after reruning the test, there is not much of a difference between the two runs. I guess the previous anomaly happens because CircleCI is under a heavy load.
@knizhnik if the tests' behaviours defined in #1919 look good to you, I can merge it back to this branch and we can start working on merging the changes to main.

Or we can rebase #1919 and start from there

@knizhnik if the tests' behaviours defined in https://github.com/neondatabase/neon/pull/1919 look good to you, I can merge it back to this branch and we can start working on reviewing this PR and merging it into main.

May be we should better merge #1919 in main?

Close in favour of #1919


Fix list style on cdcp-apply page

[Task name](Replace with a link to your task)
Fix list styling on cdcp-apply page
Before:

After:

Test Instructions

Navigate to cdcp-apply page
See list is formatted properly (20px font-size, indented)

Check out a preview of your pull request here: https://app-servicecanadalabs-dev-pr-preview-0.azurewebsites.net


Add ATmega4809

SUMMARY
Add ATmmega4809 device
OPEN QUESTIONS / UNRESOLVED ISSUES

CHECKLIST

[X] I have read and followed the library conventions.
[X] For packages, I followed IPC7351C (see details in library conventions).
[X] I'm the copyright owner of the added content (i.e. the changes are made by myself, not copied/imported from somewhere else).
[X] I agree to publish all my changes under the CC0 Public Domain License, allowing everyone to use and modify the content without any restrictions.

Do not remember this change.
What should be rights ? All files and folders to 644 ? Only files ?

Files should probably have 644 as permission. Folders need 755, but they aren't tracked by git, so it doesn't matter.

Done !

Hi @dbrgn  can you check this ?
I need to update this lib today and as I am not comfortable with git, I think it will be easier if you merge this pull request before.

Hi @dbrgn  can you check this ?
I need to update this lib today and as I am not comfortable with git, I think it will be easier if you merge this pull request before.

I'll try to take a look at this in the coming week, if I find time.

I'll try to take a look at this in the coming week, if I find time.


I want emails but not alerts

If I want to subscribe to a thread I click on the button "Receive emails and alerts" here:

However I just want an email, not an alert. That is not shown as an option, which is confusing.
Also, if I subscribe to a thread, to which I have not made a post, the "subscribed" icon (which looks like a pair of spectacles in the listing of threads) does not appear.
Also see: https://github.com/arduino/forum-issues/issues/170

This should be in place, please verify!

When I click on "Receive Emails" the box above does indeed change to "Receive Emails". However if I exit that page and reload it, the box now reads "Receive Emails and Alerts". I'm not sure what I will receive, but the change doesn't seem to "stick".

However the "subscribe" icon (spectacles) does appear in the main listing.


Add a GetSubName to consumer backend

Will place in https://github.com/cloudchacho/hedwig-firehose/pull/22


Migrate Telemetry Reporting to Amplitude

Which area/kind this issue is related to?

/area telemetry
Issue Description
We need to set up new charts and reports in Amplitude now that reflect the ones we had in Woopra
Target Date:
March 31, 2023

Charts and report created


Creating  blog page and some minor view and config fixes [wip]

Pending the creation of diferent default posts. @leomp12 , please take a look at post item view


Addsite.rb script finally here!

Big thanks to @ilyakatz for the making of this script and @psgs who assisted us. You're awesome guys :heart:
So this ruby script adds new sites and providers to the yaml files. Hopefully this will help people not make yaml errors.
The script will also put all the sites/providers in an alphabetic order which is a solution to #837.
We feel like the script is done so I'm now making this merge request of the script branch.
If you can't tell already, I'm super excited about this :smile:

Comments incoming.

Comments incoming.

It's New Years eve josh, enjoy Seattle and not GitHub for a moment 😋 :fireworks:

It's New Years eve josh, enjoy Seattle and not GitHub for a moment 😋 :fireworks:

:+1:

:+1:

Not sure where to put this, but since it's a ruby script:
https://travis-ci.org/jdavis/twofactorauth/builds/46014958#L196
I noticed the verify.rb script outputs an error if it finds a tab character, but it says

found a tab character that violate intendation

I'm pretty sure that's spelled wrong. I would've opened a PR, but I couldn't find intendation in verify.rb :confused:
Not that it's a big deal :stuck_out_tongue:

hey folks, i will take a look at all the comments in the next few days. @Walkman100 the intendation is somewhere deep in the yaml library code :)

Ah okay. As I said, not a big deal, so never mind then

Uhm so is this ready to be merged?

As @ilyakatz mentioned, we are going to address the things I brought up and then it should be ready to merge.

Hey guys, I'm finding it hard to find spare time to do open source work. Is there anyone who would be willing and able to help me finish this stuff off, if it's still relevant.

What about this branch then?

Let me clone it tomorrow morning and then I can remove it


Fix app manager releases list

fix provided by through https://github.com/PhilippLgh/electron-app-manager/commit/787d708893a8b38743840e766c7dfd777ac19982


MicroProfile Interoperable JWT RBAC 1.2 Compatible Certification Request - Payara Community 5.2021.10

[x] Organization Name ("Organization") and, if applicable, URL:
Payara Services Ltd.

[x] Product Name, Version and download URL (if applicable):
Payara Platform Community 5.2021.10 Release

[x] Specification Name, Version and download URL:
MicroProfile Interoperable JWT RBAC 1.2

[x] Public URL of TCK Results Summary:
MicroProfile TCK Results

[x] Any Additional Specification Certification Requirements:
No

[x] Java runtime used to run the implementation:

zulu 8

[x] Summary of the information for the certification environment, operating system, cloud, ...:

AWS, Ubuntu 20.04

[x] By checking this box I acknowledge that the Organization I represent accepts the terms of the EFTL.
[x] By checking this box I attest that all TCK requirements have been met, including any compatibility rules.

Thanks for opening this request, my understanding these requests have to be created once to support a given release, for example, for 1.2 it was #227, for 2.0 - #269.

What you mentioned is the minimum requirement for releasing a spec. This issue is to certify a runtime after the release.
It is okay for a runtime to submit a CCR here to certify the support of a particular release of the corresponding spec. However, it will save time to just raise a CCR to cover all of MP 4.1 specs on the eclipse/microprofile repo. At the moment, we are standardising the TCK certification process here. Once MP WG agrees, we will publicise the process so that everyone can follow. Hopefully, we will settle this soon. You can leave this issue for now.

I believe we can close this issue now, IMHO the list of open issues should be about fixing something in the MP JWT spec


Vuejs render api calls with ssr

What problem does this feature solve?
I was unable to render with vue ssr api call with javascript turned off. The documentation also does not explain how to do it.
What does the proposed API look like?
If you can do document it if there is no possibility to create it.

Hi, thanks for your interest but Github issues are for bug reports and feature requests only. You can ask questions on the forum, the Discord server, gitter or StackOverflow.

This doc may help you: https://ssr.vuejs.org/


Unable to resolve your shell environment: Unexpected number in JSON at position 35

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

VS Code Version: 1.66.2
OS Version: Ubuntu Studio Xfce4 Linux x64 5.13.0-19-lowlatensy

Steps to Reproduce:

Add to ~/.bashrc next line:
trap 'printf "\033]0;%s\007" "${BASH_COMMAND//[^[:print:]]/}"' DEBUG
Launch VS Code from the Applications Menu or double click the associated file
Get error message:

Unable to resolve your shell environment: Unexpected number in JSON at position 35

Upd: If I comment this line VS Code runs without error.

Do you see any errors in you ~settings.json` for User and Workspace?

@IllusionMH, no, I don't see any error in my settings.json.

What are you trying to do with that line?

@meganrogge, this line changes the title of my terminal window to the currently running command, so that I can see in the taskbar which command currently running in each terminal window.
but it shouldn't matter to vscode. and a few versions ago it was. I have been using this line since very beginning of using Linux. and vscode didn't throw this error until recently.

I added that line to my .bashrc and I don't have a problem
when VS Code launches, we source a "dev environment" by running your default shell. When this fails we show the error message that your shell returned. You have some issue in your shell init files that's causing that error, you need to investigate on your end as it's a problem with your environment, not with VS Code.
See here for what we do before showing this error:
https://github.com/microsoft/vscode/blob/87b365f433427f0b936b02382b177abebc7c6369/src/vs/platform/environment/node/shellEnv.ts#L126-L151

I'd disagree with this being an environment problem and I'm not sure if should be closed.

Unable to resolve your shell environment: Unexpected number in JSON at position 35

I'm seeing the exact same problem as the OP in 1.68.0 (can't say when it started, skipped a few versions) and it's triggering over a custom git prompt in bash on Ubuntu that I've been using fine in all sorts of environments since forever.
Happy to provide more info to debug this if that helps and if you'd provide some guidance what to do.
Also: if there is an issue in a user's shell configuration, wouldn't it be useful to make the error message a bit more user friendly? As a suggestion, it'd be good if it explained that and maybe render the actual command VS Code tried to run and that failed? Or some more information in VS Code logs?


None of your accounts are a member of 'TNVENL2JX3' error

Hi,
Could you set "team" to none inside the General/Signing section of the settings in the AudioPlayerSwift.xcodeproj you ship ?
I need to do it manually after updating carthage, otherwise when trying to build my project, i'm getting this error:
"None of your accounts are a member of 'TNVENL2JX3':  An unexpected error occurred. Xcode cannot find a team matching 'TNVENL2JX3'."

Just pushed to master, can you give it a second try?

@tbaranes Thanks Tom, it is fixed.
BTW did you try to test the fadein/out in the unit tests ? I tried to add some tests but it seems the Timer.scheduledTimer thing doesn't work there.

There's no tests in AudioPlayerSwift, that's definitely missing. If you write some, don't hesitate to send a PR 👯
Not sure about your question, what is not working? The timer or the fade?

Testing the fadings is failing for me (I guess because of the timers), audio don't even get considered as stopped.

Not sure why that's happening, I don't have time to investigate right now, but you can open another issue until we find a solution.
I'm gonna close this one it's fixed.


Add tips for overwriting configuration in tests

Related issue: #1172

I'm ok with the message, but I'd rather add it to a new page about testing as part of #1171.

OK, closing it now. Maybe we won't need this if we can support recreating the engine.


Sudoers should be managed in /etc/sudoers.d

According to sudo's recommendation, you should add a file or individual files in the /etc/sudoers.d directory.
Also, currently, when I remove a user, it lingers on the /etc/sudoers file. It should be removed, IMHO.
If the first recommendation is implemented by using individual files, the second should be easy to do.
Sorry for the two issues in one ;)

The latest GitHub release contains the new Linux guest environment which manages sudo access with a sudoers group.


feat(wayland): popup window

While we can use muda to create context menu, it requires GTK as dependency.
We want to go with more native approach so I'm researching smithay-client-toolkit at the moment.
According to wayland protocol, we need to get window's wl_surface and obtain xdg_surface for it.
This means we also needs to get the xdg_wm_base global, but smithay_client_toolkit doesn't seem to have anywhere to explain how to get this.
The rests steps are almost from the method of xdg_wm_base  as well.
If we could get the wl_surface of the popup window, we can think about how to add it into our Window type. Hence, it will be able to become a webview and render the menu we want to display.

See also: https://github.com/Smithay/client-toolkit/issues/471

Currently I can create an xdg_popup from smithay-client-toolkit
https://github.com/pewsheen/client-toolkit/commit/373e63732b9aee07267460499b86ecce7ba6fe2f
But I'm unsure if I'm using it correctly, and it needs delegated seats to handle input as well.
I think the next step will be using it with Winit. But it seems that Winit has not re-exposed those Wayland states; we will figure it out in the following days.

Okay! I made a workable version that modified from Winit example
https://github.com/pewsheen/winit/commit/73fad21b6cb30699c24315bc6b1ba00c7dc53acf
Unfortunately, it requires implementing some traits to the WinitState in the Winit crate. Hence, we may not be able to create the popup at the moment, or maybe someone else has ideas 🙏


auto_complete does not work with conditional compilation

source

cargo.toml
[package]
name = "auto_complete"
version = "0.1.0"
authors = ["seanybaggins<EMAIL_ADDRESS>edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[features]
foo = []

[dependencies]

This is exacted, foo feature is not default and is not enabled. You can set rust-analyzer.cargo.allFeatures: true to enable it.


Multiple input updates

Summary of changes:

maps Q to radial menu / menu accept
maps E to menu cancel / use
maps xbox Y/B to forward / back weapons
maps xbox B to menu accept
maps xbox A to menu cancel / use

Addresses these issues:

#31
#40
#41

I found an issue w/ this PR:

mp forward / back is broken

moving to draft for now

I found an issue w/ this PR:
~FIXED mp forward / back is broken~
moving to draft for now

Fixed up the controller binds & tested w/ camspy.

Slayer controls feel okay with these button mappings.

I found a regression w/ not being able to release grabbables unless you swing them around like mario64 and let go. moving to draft.

maps xbox B to menu accept
maps xbox A to menu cancel / use
Wait, what? Can Menu Cancel / Use not be split into distinct inputs?

maps xbox B to menu accept
maps xbox A to menu cancel / use

Wait, what? Can 'Menu Cancel' and 'Use' not be split into distinct inputs?

in 1964 / N64: we expect the use button (e-keyboard or b-n64) to use and to cancel menus
in xbla we expect the use button to accept menus, and weapon back to go back in menus
when using a switch controller (especially if used to playing 1964 on the steam deck) you'd expect B to use / go back, and A to switch back / cancel menus (I realize now I need to implement this.)
I just realized when I was writing this that I should include a config option to treat the controller with xbla-style bindings or switch-style bindings.
Okay here's the things I need to fix:

[ ] config option, per player, to treat as A/B buttons as switch vs xbla-style
[ ] Readme updates detailing the changes, layouts, and rationale
[ ] Fix the grabbable issue, but take video first b/c it's kind of fun

I would say the XBLA/Switch option isn't really necessary if we're going to have rebindable buttons in the future. If you still think it is necessary, maybe hold off on that until there's an extended options menu or something, I feel like it'd be a bit awkward reading those flags for each individual player from the config.

I would say the XBLA/Switch option isn't really necessary if we're going to have rebindable buttons in the future. If you still think it is necessary, maybe hold off on that until there's an extended options menu or something, I feel like it'd be a bit awkward reading those flags for each individual player from the config.

Agreed. The ability to map use / accept / cancel separately would make that not needed directly.  Also, what's considered "A and B" for the purposes of mine detonation. For now I'll take out the abstraction layer that's only for switch / xbla handfeel and it can be handled more elegantly.

So the current default is for menus to go against the standard layout for PC controllers?


push improvements

rename push to insert and change value to Into

https://github.com/Kinetus/vk_method/commit/45b501d96ca4efd02478b802e5546ccae3b3c668


Oauth callback to configure in google dev

http://<IP_ADDRESS>:9000/youtube/callback uri worked for me. This might be good to add in the documentation as this is a requirement for using the app.

I'd like to give default credentials in production, but everybody should be able to set its own to avoid quota issues.


Flush batched entries timer

Please make sure these boxes are checked, before submitting a new PR.

[x] You ran the local CI checker with ./check.sh with no errors
[x] You reference which issue is being closed in the PR text (if applicable)
[x] You updated the OmniPaxos book (if applicable)

Issues
Fix #127. Omnipaxos::tick() now also flushes batched log entries every flush_batch_tick_timeout ticks. This stops entries from being stuck in the batch buffer when there are no incoming proposals.
Breaking Changes

Adds new field flush_batch_tick_timeout to ServerConfig.

Looks good to me. I just want to confirm with you that we don't need to check that we're in the accept phase to flush these entries? Because they get buffered up in memory only in the accept phase.

Yes exactly the entries will get flushed on entering the Prepare phase and will only start batching up in the Accept phase. But to be safe its probably better to only flush in the accept phase to prevent future bugs. I'll make that change now.


Pulls inconsistently failing

I've been pulling a large number of Miami addresses through location.get_detail using the rate_limiter option in the package initialization. On test batches of addresses (5-10K), I find that a significant number (~20%) will return as invalid IDs in the CSV file. The weird things are...

On spot checks, I can pull any of these failed addresses just fine either through the API one-by-one or looking them up on the Flood Factor website
To test whether this was something with the ordering or the rate limit, I tried changing the ordering and going slower, but the same properties returned as invalid IDs.
However, when I then selected only these invalid IDs and ran them through again, about 80% of them returned as valid! I ran through the remaining 20% invalid again, and 80% came back valid

At the bottom you will find my code snippet. Happy to pass along a sample of addresses to see if you get the same behavior (it looks like I can't attached CSVs here). I'm running Python 3.7.9 on Jupyter Notebook, Windows 10. I just updated to the latest API access this afternoon (i.e. pip install --upgrade fsf_api_access_python)
I appreciate any help you can offer. Thank you!
Snippet:
import shapely.geometry
import nest_asyncio
nest_asyncio.apply()
import numpy as np
import pandas as pd
import requests
import json
import os
import csv
from csv import DictReader
import firststreet
fs = firststreet.FirstStreet("api_key",rate_limit=4000,rate_period=62)
pull_address = "filename.csv"
fs.location.get_detail(pull_address,'property',csv=True)

Hey @mulderphilip,
That definitely sounds weird and I can take a look for you. Are you able to drop the sample addresses into a google drive?
(Also please make sure to keep the API key secure!)

Rookie mistake, sorry! Happy to share the files, let me know

@mulderphilip, I've open up a temporary google drive folder, if you could throw the file in there
https://drive.google.com/drive/u/1/folders/1Ygd3fRxXY-UlcAVrJ211Q6G1aA6xmPfA

Got it, should be uploaded. Thank you!

Hey @mulderphilip ,
I've taken a look and it might take a bit longer to identify the root issue. It looks like when too many consecutive address calls are made, the server returns an error (leading to the invalid IDs since the response is an error)
Some temporary solutions while we investigate this:

I have not noticed the issue for FSIDs or lat/lngs, so those two input types may work better if you have them instead of addresses

Slow down your rate_period while keeping the same ratio. ie: Instead of rate rate_limit=4000, rate_period=62, try rate rate_limit=65, rate_period=1, connection_limit=10. The issue is too many consecutive calls, so slowing down the rate to smaller chunks may alleviate the issues. This will be a bit slower than running the original ratio with a larger connection_limit, but from my test it seems to be the most stable (using the second configuration I only got 1 invalid fsid out of 4968 addresses). Feel free to try adjusting the parameters

We'll let you know if we get any updates on the investigation

@Lyetenth , thanks so much! I'll try those fixes, I'm sure they'll work for the data I need.

Hey @mulderphilip ,
We've identified the issue being the service we use to convert and identify addresses in the API's backend. Unfortunately at the moment, the service limits us to 1000 calls per minute. I'm told there are plans on changing this some time in the future, but for now the two temporary solutions above will have to do.
ie:

Using an FSID or lat/lngs instead of an address since those two methods don't use this service
Slowing down the rate to rate_limit=1000, rate_period=60. (Different configurations may still unexpectedly work)

Sorry for no concrete fix, we'll notify the Flood Lab members with API version updates. Thanks for helping us identify the issue!

Hey @mulderphilip,
We made some changes to the address matching and the problem should be fixed. Feel free to test it again and re-open this issue if the issue persists

Hey @mulderphilip,
We made some changes to the address matching and the problem should be fixed. Feel free to test it again and re-open this issue if the issue persists