LXDE - MPV failed to open rockchip

I'm using the bionic-lxde-rock64-0.9.14-1159-armhf image. When I try to open a video with MPV, I get these errors:
libGL error: MESA-LOADER: failed to open rockchip (search paths /usr/lib/arm-linux-gnueabihf/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: rockchip
libGL error: MESA-LOADER: failed to open rockchip (search paths /usr/lib/arm-linux-gnueabihf/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: rockchip

Do I need to install something else to get hardware support?

Oops. It seems there is rkmkv installed and that has acceleration.


Test consumers without RabbitMQ running

Hi @lucacorti, first of all thanks for the library. Appreciate it a lot open-sourcing the library.
I am wondering how I can test consumer modules without having to run Rabbit MQ in my test environment.
Given I have a module like this one below, I'd like to verify the behavior when receiving the message with routing key foo.bar.
defmodule MyProducer do
  use Lapin.Connection

  def handle_deliver(_channel, %Lapin.Message{
        meta: %{routing_key: "foo.bar"},
        payload: payload
      }) do
  # here be dragons
  end

  def handle_deliver(_channel, _message) do
    :ok
  end
end

Calling the function in a test context with a struct created manually for channel and message fails with an argument error.
Thanks in advance!

Hey @nTraum, thanks for the feedback, can you share how you are calling MyProducer.handle_deliver/2 in your test?

Well, I think this was a classic case of rubberduck-debugging! I just tried to reproduce it in a example repo for you and now it works!
For completeness sake, here is me just faking the message and channel as observable by inspecting a real one and using it for a test
defmodule MyLapinTestTest.WorkerTest do
  use ExUnit.Case

  test "greets the world" do
    message = %Lapin.Message{meta: %{app_id: :undefined, cluster_id: :undefined, consumer_tag: "amq.ctag-NXAA7seVhNmaXiFYFIJz2A", content_encoding: :undefined, content_type: nil, correlation_id: :undefined, delivery_tag: 1, exchange: "some_exchange", expiration: :undefined, headers: [], message_id: :undefined, persistent: true, priority: :undefined, redelivered: false, reply_to: :undefined, routing_key: "test", timestamp: :undefined, type: :undefined, user_id: :undefined}, payload: "hi"}

    channel = %Lapin.Consumer{ channel: %AMQP.Channel{ conn: %AMQP.Connection{}, custom_consumer: {AMQP.SelectiveConsumer}}, config: [queue: "some_queue"], consumer_tag: "amq.ctag-NXAA7seVhNmaXiFYFIJz2A", pattern: Lapin.Consumer.Config, queue: "some_queue"}

    MyLapinTest.Worker.handle_deliver(channel, message)
  end
end

I'm not sure how much of it is actually needed, but I'll find out soon! Thanks anyway and sorry for bothering you unnecessarily! :fearful:

@nTraum aha, great! Let me know if you encounter any other issues.


Fix both lists of "Supported .NET Framework Libraries" (re: SQLCLR)

This fixes #4614
On the Designing Assemblies page:

Added:

System.Deployment.dll  (added in SP1 for SQL Server 2005)
System.Core.dll  (added in SQL Server 2008)
System.Xml.Linq.dll  (added in SQL Server 2008)

Rearranged list of assemblies to be in their proper (expected) order.
Fixed incorrect casing for several library names.

On the Supported .NET Framework Libraries page:

Moved System.Core to the proper/expected position.
Removed ".dll" extension from System.Core and System.Xml.Linq to match the rest of the list.
Removed extraneous newline between each library that made the list harder to read as you had to scroll to see all of the items.
Added HTML comment below the "Supported Libraries" list indicating the other page containing the same list (i.e. the "Designing Assemblies" page that hasn't been updated since SQL Server 2005 went RTM) so that hopefully it will be easier to maintain consistency across future updates.

Take care,
Solomon...
https://SqlQuantumLift.com/
https://SqlQuantumLeap.com/
https://SQLsharp.com/

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

@srutzky This is really great work. Thank you! #sign-off


⚠ Bofrost.de has degraded performance

In 5bea0f8, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1238 ms

Resolved: Bofrost.de performance has improved in 6dd092e after 10 minutes.


Update bug with library font-awesome

Hi thanks for the PR. As far as I can see the PR is missing the name changes for the classes in this file.
Also please prefix the classes with leaflet-pm. So icon-polygon becomes leaflet-pm-icon-polygon.
👍 good catch, will get merged when the changes are made.

Hi Friend. Added update leaflet-pm-icon-*
Archives changed:
- src/js/Toolbar/L.PM.Toolbar.js
- dist/leaflet.pm.css
- dist/leaflet.pm.min.js


chore: Update dependency golang.org/x/net to fix CVE-2022-41717

What this PR does / why we need it:
The golang.org/x/net dependency in use is affected by https://nvd.nist.gov/vuln/detail/CVE-2022-41717, this updates the dependency to the latest version so this binary is not affected

/assign @nckturner

/hold

This was supposed to be fixed in https://github.com/kubernetes/kubernetes/commit/afe5378db9d17b1e16ea0028ecfab432475f8e25, which is included in our current dependency version.  Either that was a patched version of 0.3 (vulnerability database said > 0.4), or @liggitt made a mistake and updated to a version that didn't contain the fix.
Considering this dependency version included due to code-generator and sample-controller, I don't think its high risk and we can wait until we get the fix from upstream in the if the version didn't include the fix.

Actually let me look at our usage of sample-controller, that might be an issue.

This was supposed to be fixed in https://github.com/kubernetes/kubernetes/commit/afe5378db9d17b1e16ea0028ecfab432475f8e25, which is included in our current dependency version. Either that was a patched version of 0.3 (vulnerability database said > 0.4), or @liggitt made a mistake and updated to a version that didn't contain the fix.

It is fixed in that version, https://github.com/golang/net/commit/1e63c2f08a10a150fa02c50ece89b340ae64efe4 is exactly the content/commit tagged as v0.4.0 (https://github.com/golang/net/commits/v0.4.0), that tag just didn't exist at the time we bumped, so go generated a prerelease pseudo-version of "v0.3.1-0.20221206200815-1e63c2f08a10"

Thanks, closing.
/close


Boilerplate example doesn't connect to Sauce Labs

After cloning this boilerplate example, I add my Sauce Labs user and API key to wdio.sauce.conf.ts file. When I run npm run test, the tests fail (they do pass locally).
If I check the logs, wdio.log shows:
2021-06-17T16:26:10.773Z DEBUG @wdio/utils:initialiseServices: initialise service "sauce" as NPM package
2021-06-17T16:26:11.037Z INFO @wdio/cli:launcher: Run onPrepare hook
2021-06-17T16:26:11.037Z DEBUG @wdio/cli:utils: Finished to run "onPrepare" hook in 0ms
2021-06-17T16:26:11.041Z INFO @wdio/cli:launcher: Run onWorkerStart hook
2021-06-17T16:26:11.042Z INFO @wdio/cli:launcher: Run onWorkerStart hook
2021-06-17T16:26:11.042Z INFO @wdio/cli:launcher: Run onWorkerStart hook
2021-06-17T16:26:11.042Z DEBUG @wdio/cli:utils: Finished to run "onWorkerStart" hook in 0ms
2021-06-17T16:26:11.042Z DEBUG @wdio/cli:utils: Finished to run "onWorkerStart" hook in 0ms
2021-06-17T16:26:11.042Z DEBUG @wdio/cli:utils: Finished to run "onWorkerStart" hook in 0ms
2021-06-17T16:26:11.052Z INFO @wdio/local-runner: Start worker 0-0 with arg: run,wdio.sauce.conf.ts
2021-06-17T16:26:11.151Z INFO @wdio/local-runner: Start worker 0-1 with arg: run,wdio.sauce.conf.ts
2021-06-17T16:26:11.246Z INFO @wdio/local-runner: Start worker 0-2 with arg: run,wdio.sauce.conf.ts
2021-06-17T16:26:17.861Z DEBUG @wdio/local-runner: Runner 0-0 finished with exit code 1
2021-06-17T16:26:18.012Z DEBUG @wdio/local-runner: Runner 0-1 finished with exit code 1
2021-06-17T16:26:18.163Z DEBUG @wdio/local-runner: Runner 0-2 finished with exit code 1
2021-06-17T16:26:18.164Z INFO @wdio/cli:launcher: Run onComplete hook
2021-06-17T16:26:18.165Z DEBUG @wdio/cli:utils: Finished to run "onComplete" hook in 0ms
2021-06-17T16:26:18.197Z INFO @wdio/local-runner: Shutting down spawned worker
2021-06-17T16:26:18.448Z INFO @wdio/local-runner: Waiting for 0 to shut down gracefully

If I check the logs, wdio-0-0.log:
2021-06-17T16:26:14.545Z INFO @wdio/local-runner: Run worker command: run
2021-06-17T16:26:15.465Z DEBUG @wdio/config:utils: Found 'ts-node' package, auto-compiling TypeScript files
2021-06-17T16:26:15.725Z DEBUG @wdio/local-runner:utils: init remote session
2021-06-17T16:26:15.750Z DEBUG @wdio/utils:initialiseServices: initialise service "sauce" as NPM package
2021-06-17T16:26:16.149Z DEBUG @wdio/sync: Finished to run "beforeSession" hook in 0ms
2021-06-17T16:26:16.599Z DEBUG @wdio/local-runner:utils: init remote session
2021-06-17T16:26:16.602Z INFO webdriver: Initiate new session using the WebDriver protocol
2021-06-17T16:26:16.605Z INFO webdriver: [POST] https://hub.testingbot.com/wd/hub/session
2021-06-17T16:26:16.605Z INFO webdriver: DATA {
  capabilities: {
    alwaysMatch: {
      browserName: 'chrome',
      browserVersion: 'latest',
      platformName: 'Windows 10',
      'sauce:options': [Object]
    },
    firstMatch: [ {} ]
  },
  desiredCapabilities: {
    browserName: 'chrome',
    browserVersion: 'latest',
    platformName: 'Windows 10',
    'sauce:options': { build: 'Build<PHONE_NUMBER>' }
  }
}
2021-06-17T16:26:17.304Z WARN webdriver: Request failed with status 401 due to The key (username) and secret (apikey) you used to authenticate are incorrect TestingBot credentials
2021-06-17T16:26:17.305Z INFO webdriver: Retrying 1/3
2021-06-17T16:26:17.305Z INFO webdriver: [POST] https://hub.testingbot.com/wd/hub/session
2021-06-17T16:26:17.305Z INFO webdriver: DATA {
  capabilities: {
    alwaysMatch: {
      browserName: 'chrome',
      browserVersion: 'latest',
      platformName: 'Windows 10',
      'sauce:options': [Object]
    },
    firstMatch: [ {} ]
  },
  desiredCapabilities: {
    browserName: 'chrome',
    browserVersion: 'latest',
    platformName: 'Windows 10',
    'sauce:options': { build: 'Build<PHONE_NUMBER>' }
  }
}

2021-06-17T16:26:17.752Z ERROR webdriver: Request failed with status 401 due to Error: The key username) and secret (apikey) you used to authenticate are incorrect TestingBot credentials
2021-06-17T16:26:17.752Z ERROR webdriver: Error: The key username) and secret (apikey) you used to authenticate are incorrect TestingBot credentials

So, why is this trying to connect to TestingBot when it should be connecting to Sauce Labs?

https://hub.testingbot.com/wd/hub/session

It seems that your credentials indicate a Testingbot or your hostname is set this way.

@christian-bromann I don't see how. I'm using my SauceLabs username and API key, so not sure how that would pertain to testingbot. I don't have a testingbot account. As for hostname, I've checked both Windows 10 and Ubuntu hosts files and there's nothing there for testingbot...just pain default files.
Ultimately, I'm trying to find a solution to this: https://github.com/webdriverio/webdriverio/issues/6075 and was trying your boilerplate to see if that worked for me. It didn't due to the testingbot error.
Any other advice?

@leejensen no, can you provide a reproducible example?

Closing due to inactivity.


Locking out metaproperties

By using the syntax class.<prop>, we effectively lock out the ability to add metaproperties for exposing things about classes that should be kept private.
For example in the decorators proposal I've mentioned the possibility of accessing the decorated and undecorated class using metaproperties (here). But one could imagine other cases such as private constructors, getting a list of applied decorators or other similar usages.
As such I think it would be better if instead of blocking the entire class. namespace, to instead use a single metaproperty hanging off class, e.g. class.current/class.original/etc

One thing I do like about having just class on it's own (while I do see the downside of blocking the whole namespace), is that it is only one character longer than this.
class WithALongName {
  static #f = 1;
  static method() {
    this.#f; // unsafe to use `this` as could be called by static subclass
    class.#f; // safer with similar effort to read/write

    class.current.#f; // safe but same length as reading/writing:
    WithALongName.#f; // safe but verbose
  }
}


Add watermark interrupt strobe functionality

Add enable bit to make watermark interrupt behave like a "data ready" signal when the interrupt is triggered.
When the bit is set, instead of keeping watermark interrupt signal constantly high, the signal will toggle at ~10KHz. This will allow a master device (specifically the EVAL-ADIS-FX3) to trigger reads on data ready, ensuring that the buffer outputs are only read/logged when buffered data is available. When the watermark interrupt is not triggered the selected line will return to 0.

Done.


Add predefined preprocessors: replacer

Create Replacer PreProcessor, which will be instantiated with a dictionary {Object} and it replaces all occurance of all keys (in token format, e.g. [key]) of dictionary to correspondant values.
It should replace keys with value in

name and description of a Feature
name and description of a Scenario-like item (Backround, Scenario, ScenarioOutline)
text of a Step
value of a Tag
name of an Examples
value of a TableCell
content of a DocString

@judit-nahaj you can start to implement this issue.


Make Task.future public

When trying to implement the README example for streaming, there were a few compile warnings.

HTTPResponseDelegate has been renamed to HTTPClientResponseDelegate
The protocol functions now have a task parameter
HTTPRequest has been renamed HTTPClient.Request
httpClient.execute(request:, delegate:).future is inaccessible since future is internal.

This pull requests fixes these issues in the Readme example.
This includes making Task.future public. Since future is now public, I removed wait and cascade since they are now available on the future. This would be a breaking change and existing code in the project has been updated to reflect the change.
I have two remaining questions, was there a reason why Task.future was originally made internal and is the README example for accessing the streaming result correct?

Thank you for the PR. We improved this in #47 - please have a look at current master and see what you think.


Replace raised and flat buttons with elevated buttons for examples an…

…d README.md
Description
Replacing the examples that were failing due to using raised_button and flat_button which need to be replaced by elevated_button.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[ x] I read the Code Style Guide and followed the process outlined there for submitting PRs.
[ x] All existing and new tests are passing.
[ x] I updated/added relevant documentation (doc comments with ///).
[ x] The analyzer (flutter analyze or dart analyze) does not report any problems on my PR.
[ x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[ ] I updated CHANGELOG.md to add a description of the change.
[ x] I am authorized to release this code under the MIT License and agree to do so

UI Change
Does your PR affect any UI screens?

[ ] Yes, the relevant screens are included below.
[ x] No, there are no UI impacts with this PR other than making them work properly without error.

Thanks!


Failed experiment: Use poolstl to sort randstrobes in parallel

This documents a change that I would not like to merge.
See https://github.com/alugowski/poolSTL
Sorting the randstrobes is currently a bottleneck in index generation as it does not run in parallel. This is an attempt to parallelize it.
poolstl’s sort uses regular std::sort under the hood. We currently use pdqsort_branchless, which is about twice as fast as std::sort, so parallel sorting breaks even with pdqsort_branchless at about 2-3 threads. It gets faster with more threads, but not as much as one would perhaps expect. Here are the sorting runtimes for CHM13:

31 s with pdqsort_branchless
59 s with std::sort
34 s with parallel sort, 2 threads
24 s with parallel sort, 4 threads
23 s with parallel sort, 8 threads

Another issue is that sorting is no longer in place, so memory usage goes up by a couple of gigabytes, which is another reason for not making this change.

I see. Good to test alternative approaches nevertheless.

For reference: The code for doing this is not super complicated (although I don’t understand everything, yet): https://github.com/alugowski/poolSTL/blob/89fde73f0a8b818df45082ebdfca5abee1ec02c4/include/poolstl/internal/ttp_impl.hpp#L132 So maybe we could adjust it to use pdqsort.
Also, we already create the randstrobes for each chromosome in parallel, so we could also sort each chromosome in parallel. Then the only remaining thing to do serially would be to merge the chromosomes into one sorted vector. I’m not sure how to do this without using extra memory, though.

poolSTL author here. Thanks for giving it a try @marcelm!

For reference: The code for doing this is not super complicated (although I don’t understand everything, yet): https://github.com/alugowski/poolSTL/blob/89fde73f0a8b818df45082ebdfca5abee1ec02c4/include/poolstl/internal/ttp_impl.hpp#L132

The algorithm is simple: for p threads split the input range into p chunks. In parallel, run the sequential sort function on each chunk. Finish with a tree merge of the chunks, in parallel as much as possible.

So maybe we could adjust it to use pdqsort.

I just added a pluggable_sort() that makes this easy:
poolstl::pluggable_sort(poolstl::par.on(pool), randstrobes.begin(), randstrobes.end(), pdqsort_branchless);

Cool, thanks! I opened #385 to track this. We’ll let you know how it goes.


Unable to resolve sbt-core-next with RC10

I tried upgrading to RC10 but got the following error while loading the project:
coursier.ResolutionException: Encountered 1 error(s) in dependency resolution:
    org.scala-sbt:sbt-core-next;sbtVersion=0.13;scalaVersion=2.10:0.1.1:
        not found:
            /home/martynas/.ivy2/local/org.scala-sbt/sbt-core-next/scala_2.10/sbt_0.13/0.1.1/ivys/ivy.xml
            https://repo1.maven.org/maven2/org/scala-sbt/sbt-core-next_2.10_0.13/0.1.1/sbt-core-next-0.1.1.pom
            https://repo.typesafe.com/typesafe/ivy-releases/org.scala-sbt/sbt-core-next/0.1.1/ivys/ivy.xml
            https://repo.scala-sbt.org/scalasbt/ivy-snapshots/org.scala-sbt/sbt-core-next/0.1.1/ivys/ivy.xml
            https://repo.scala-sbt.org/scalasbt/maven-snapshots/org/scala-sbt/sbt-core-next_2.10_0.13/0.1.1/sbt-core-next-0.1.1.pom
            https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/org.scala-sbt/sbt-core-next/scala_2.10/sbt_0.13/0.1.1/ivys/ivy.xml

Tried with sbt 0.13.15 and 0.13.16

(Btw what depends on sbt-core-next?)

Possibly an error (independent of sbt-coursier) at the definition of the ivy-releases repository used here. The url from it that should be checked should be https://dl.bintray.com/typesafe/ivy-releases/org.scala-sbt/sbt-core-next/scala_2.10/sbt_0.13/0.1.1/ivys/ivy.xml instead of https://repo.typesafe.com/typesafe/ivy-releases/org.scala-sbt/sbt-core-next/0.1.1/ivys/ivy.xml (scala_2.10/sbt_0.13 parts missing).

Like in https://github.com/coursier/coursier/issues/632, I'm not 100% sure of where this repo is defined, this might here.

As for more context, I noticed this error when trying to load alpakka's master build with RC10. I am not sure what depends  sbt-core-next. I tried loading the project with RC8 and then running dependencyBrowseGraph after reload plugins but there was no sbt-core-next.

I am having this issue too and unable to run coursier as a result of it. Is there any information I can provide to help iron it out?
coursier.ResolutionException: Encountered 1 error(s) in dependency resolution:
    org.scala-sbt:sbt-core-next;sbtVersion=0.13;scalaVersion=2.10:0.1.1:
        not found:
            C:\Users\rpiaggio\.ivy2\local\org.scala-sbt\sbt-core-next\scala_2.10\sbt_0.13\0.1.1\ivys\ivy.xml
            C:\Users\rpiaggio\.sbt\preloaded\org.scala-sbt\sbt-core-next\0.1.1\ivys\ivy.xml
            C:\Users\rpiaggio\.sbt\preloaded\org\scala-sbt\sbt-core-next_2.10_0.13\0.1.1\sbt-core-next-0.1.1.pom
            https://repo1.maven.org/maven2/org/scala-sbt/sbt-core-next_2.10_0.13/0.1.1/sbt-core-next-0.1.1.pom
            https://repo.typesafe.com/typesafe/ivy-releases/org.scala-sbt/sbt-core-next/0.1.1/ivys/ivy.xml
            https://repo.scala-sbt.org/scalasbt/ivy-snapshots/org.scala-sbt/sbt-core-next/0.1.1/ivys/ivy.xml
            https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/org.scala-sbt/sbt-core-next/scala_2.10/sbt_0.13/0.1.1/ivys/ivy.xml

BTW, our Scala version in build.sbt is 2.11.11, not sure why 2.10 libraries are being downloaded.

The current master of alpakka seems to work fine with sbt-coursier 1.0.0-RC12 (update, updateClassifiers, and updateSbtClassifiers are ok).

Closing this. Re-open if ever that's not fixed for you.

Yes. It works great. Thanks!


multicam live reconstruction

Required Info

Camera Model
D435

Operating System & Version
Win 10

Platform
PC

Language
C++

Hello,
I am using two cameras at the same time with the multicam feature. I would like to make a live reconstruction, and not display two views of each camera but display only one view with a reconstruction of what both camera detect. I could transmit the angle difference between the two cameras to falicitate the reconstruction.
Has someone already implemented that kind of feature?
Best regards,
Emmanuel

In January 2018 at the Sundance festival, Intel demonstrated 'volumetric capture' 180 degree scanning of the human body with four hardware-synced D435s.
According to an Intel blog article about the demo, they took point cloud scans from four separate PCs (one for each camera) and used a 5th PC to sync it all together.
https://realsense.intel.com/intel-realsense-volumetric-capture/
My transcript of Intel's recent webinar about multiple cameras has suggestions about how to approach combining point clouds into a single one - by using the software Vicalib, or by doing an Affine Transform operation to rotate the clouds so they can be appended together into a single cloud.
https://communities.intel.com/message/566337#566337

Also please take a look at #2531. I know this issue is Windows and ROS is (mostly) Ubuntu, but this can give you some direction (and perhaps you could even make it work with newly announced ROS for Windows (#2465)

[Realsense Customer Engineering Team Comment]
Closing this now.
Feel free to reopen if your issue or problem was not addressed.


Update convert-user-mailbox-to-shared-mailbox.md

Removing the note about the new admin portal, because the steps are the same in the old and new M365 admin portal. Adding a step about password reset and also adding a note as to why this is important.

@ninobb can you please make the suggested changes to your edit and resubmit? thanks!

@ninobb The changes I suggested need to be made to the file before I can approve the PR. Thanks.


fixed datepicker issue on Lollipop

Fixed the datepicker scrolling issue on Lollipop.

Thanks for the fix. I added it in dev branch.


🧪 add upload of coverage to code coverage

Follow #27, add the upload of the tests coverage to Codecov (was missing).

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


Display multi window in case multi request

Description of the bug
Display multi-window in case multi request
To reproduce the bug
Actual: Display multi-window in case multi request

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./upgrade-ui-pr-1252-build-1.0.2-1-2023-04-20T04-16-33UTC.zip
Validation passed


kubernetes-client readiness check is not able to check services.

The k8s-client can not check readiness of kind service: https://github.com/fabric8io/kubernetes-client/blob/master/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/internal/readiness/Readiness.java#L79
This PR is switching to waitUntilReady. Notice: this ignores the comment // Workaround: waitUntilReady appears to be buggy.. I have tested it with waitUntilReady on my local k8s-cluster and it works as expected.
containerproxy must use Kubernetes as backend and must not be running inside the cluster (proxy.kubernetes.internal-networking: false) in order to reach the affected code.

Hi @cleemansen
Thank you for your contribution!
We noticed the same issue and included a similar fix in the latest release (https://github.com/openanalytics/containerproxy/commit/fe16bc8c508bd39f6e26574f2509fdd037266868)
Thanks again.


Fix #3107: Make Closeable extend AutoCloseable.

Because AutoCloseable does not exist on JDK6, we have to move the definition of java.lang.AutoCloseable from the javalanglib to the javalib. It so happens that no class or trait in the javalanglib needs to extend AutoCloseable, so we're fine.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/4232/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5647/
Test PASSed.


Add support for eslint-plugin-prettier

Does this actually make sense? The link has no dynamic capabilities, and where it is linking to only tells the user how to configure the plugin. Does this plugin even report messages?


K8SPG-204 Enable Openshift detection by default

Explicitly stated option does not let operator to manage
pod FSgroup flawlessly

Test name
Status

demand-backup
passed

init-deploy
passed

upgrade
passed

scaling
passed

recreate
passed

affinity
passed

scheduled-backup
passed

smart-update
passed

monitoring
passed

version-service
passed

self-healing
passed

operator-self-healing
passed

clone-cluster
passed

tls-check
passed

users
passed

ns-mode
passed

We run 16 out of 16

commit: https://github.com/percona/percona-postgresql-operator/pull/265/commits/bdf96cc9a1b3378a0e9a3a682c85da16352ac868
image: perconalab/percona-postgresql-operator:PR-265-bdf96cc9-pgo-apiserver
image: perconalab/percona-postgresql-operator:PR-265-bdf96cc9-pgo-event
image: perconalab/percona-postgresql-operator:PR-265-bdf96cc9-pgo-rmdata
image: perconalab/percona-postgresql-operator:PR-265-bdf96cc9-pgo-scheduler
image: perconalab/percona-postgresql-operator:PR-265-bdf96cc9-postgres-operator
image: perconalab/percona-postgresql-operator:PR-265-bdf96cc9-pgo-deployer


Extract stacktraces from errors of the pkg/errors package

Note: this is an initial implementation for #37. Please don't merge it yet.
Errors created by pkg/errors capture the stacktrace of the place when
the errors are created. It makes debugging much more easier if
developers can see the real origin of the errors.
This commit introduces the special handling of errors from the
pkg/errors package.
Fixes #37
Signed-off-by: Tibor Benke<EMAIL_ADDRESS>

Looks nice! Can you please move all stack related code to util.go (probably also renaming it to stack.go)? Also having at least one test would be nice.

Thanks. I will merge and make few edits.

Thanks!

Release v3.2.0. Thanks again for your contribution.

You're welcome.


Weekly Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Validate ManagedPolicy Description

cfn-lint version: (cfn-lint --version) 0.7.1
Description of issue.
A recent deployment of a template with an IAM policy failed because a newline was accidentally included in the description, and IAM doesn't like that. Got this error:

AWS::IAM::ManagedPolicy MyPolicy CREATE_FAILED: ... 'description' failed to satisfy constraint: Member must satisfy regular expression pattern: [\p{L}\p{M}\p{Z}\p{S}\p{N}\p{P}]* ...

This also isn't documented on CloudFormation or in the IAM API.

I'm trying to convert this regex into something we could use.  Looks like \p{Z} is for whitespace.  What I can't tell if that also includes new lines as it looks to be a subset of this one.

@cmmeyer looks like to make this easier on ourselves we should convert to the regex package.  https://pypi.org/project/regex/  it comes with easy unicode character matching and makes writing this rule a lot easier.  It looks like it can drop in replace the current 're' but it would be a new dependency.


mkl: fix expectation of MKLROOT being set in pkg-config files

Motivation for this change
The Intel MKL pkg-config files did not work, because they expect that
the MKLROOT environment variable is set. This change replaces
occurences by the actual path of MKL in the Nix store.
Since the pkg-config files seem to break quite frequently after
upgrades, add a post-install check to validate the pkg-config files.
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 87789 1

5 packages built:
- clmagma
- mkl
- python27Packages.mkl-service
- python37Packages.mkl-service
- python38Packages.mkl-service


Is this under development?

Getting a lot of issues using this with NestJS and typescript. Is this library still being built?

Could explain with examples if that is not the case.
Also, are you guys accepting any volunteer help? I will see if I can help.

Same here, I doubt this is production ready.

@jatinhariani Yes we are actively working on this package. Please feel free to share any issues you're facing or make pull requests with suggested changes 👍🏼


Update to zig 0.11.0

Hi there, hope you're doing well!
I was fiddling around with your library, and decided to give it a shot at updating to the latest release.  I'm not sure if any of these patches are welcome, but after my changes started piling up, I decided to post them here.
I think the only thing that remains to get working is the zig build test step, but once that's done, the PR should technically be ready.
Cheers!

Very nice, thanks for the work! I very welcome updates to my libs!

AFAICT, things seem to be working properly:
[psyomn@xaos zig-gemtext]$ zig build test examples
[psyomn@xaos zig-gemtext]$ echo $?
0

[psyomn@xaos bin]$ for cmd in gem2html-zig gem2md-zig gem2html-c gem2md-c; do echo "$cmd"; echo -e "# hello\nthere" | ./$cmd; echo $?; done
gem2html-zig

hello

there

0
gem2md-zig
# hello

there
0
gem2html-c

hello

there

0
gem2md-c
# hello
there
0

Happy to change things, be it from code to commit messages.  Let me know!

Ah you know what? I'm fine with the code!

Hey by the way, I hope I didn't rush you into merging this -- that was
not my intent.
I'm not sure I fully understood what you meant with the resize comment
-- did you mean that an approach could be to first attempt resize, and
on fail, then only try to do a realloc in order to save an alloc?
I'm also looking at the allocator code, but from what I understand it
[1] takes into consideration these optimization cases (though I might be
wrong, as I'm still learning the language).
[1] https://github.com/ziglang/zig/blob/master/lib/std/mem/Allocator.zig#L255
Anyway, I hope I didn't cause too much trouble; just trying to get a
little better at the language!
On Mon, Dec 11, 2023 at 08:54:58AM -0800, Felix Queißner wrote:

Ah you know what? I'm fine with the code!
--
Reply to this email directly or view it on GitHub:
https://github.com/MasterQ32/zig-gemtext/pull/1#issuecomment-1850478367
You are receiving this because you authored the thread.
Message ID: @.***>


修复删除输入框值，显示undefined

inputDisplayValue 类型是 string

Coverage remained the same at 28.092% when pulling d01c8ded00669dcdf9797c9b02a6f03a839fbcf6 on fxxkscript:master into 71e3f9cffb25d75cbf12c17c144ba8cc87e25f8c on react-component:master.


Allow to choose to download results

In some cases, we may not want to download results from the bucket.
There could be an optional parameter allowing us to explicitly say that we do not want to get the raw results.
Example :
lane :test do
  run_tests_firebase_testlab(
    project_id: "your-firebase-project-id",
    model: "Nexus6P",
    version: "27",
    delete_firebase_files: false,
    download_results_from_firebase: false
  )
end

Sounds good for me. I will implement it soon 🙂

As I got some time, I tried to develop something.
Hope it will help you !

Implemented in version 0.2.2!


Async producer can overflow itself at high rate

Versions
Please specify real version numbers or git SHAs, not just "Latest" since that changes fairly regularly.
Sarama Version: b1da1753dedcf77d053613b7eae907b98a2ddad5
Kafka Version: Irrelevant
Go Version: b1da1753dedcf77d053613b7eae907b98a2ddad5
Configuration
What configuration values are you using for Sarama and Kafka?
Sarama async producer:
	conf := sarama.NewConfig()
	conf.Metadata.Retry.Max = 1
	conf.Metadata.Retry.Backoff = 250 * time.Millisecond
	conf.Producer.RequiredAcks = sarama.RequiredAcks(sarama.WaitForLocal)
	conf.Producer.Timeout = 1 * time.Second
	conf.Producer.MaxMessageBytes = 16 << 20 // 16MB
	conf.Producer.Flush.Bytes = 16 << 20 // 16MB
	conf.Producer.Flush.Frequency = time.Minute
	conf.Producer.Compression = sarama.CompressionNone // otherwise Kafka goes nuts
	conf.Producer.Return.Errors = true
	conf.Producer.Partitioner = NewIdentityPartitioner

Logs
Sarama logs:
2017-01-09T23:30:21.504 myhost 2017/01/09 23:30:19 Kafka producer err: kafka: Failed to produce message to topic requests: kafka server: Message was too large, server rejected it to avoid allocation error.

Problem Description
Problem is in this function:

https://github.com/Shopify/sarama/blob/0fb560e5f7fbcaee2f75e3c34174320709f69944/async_producer.go#L583-L648

We produce messages at such rate (100K/s+) so select always picks up processing of new incoming messages over rolling over and flushing existing ones.
I applied to following patch:
diff --git a/vendor/github.com/Shopify/sarama/async_producer.go b/vendor/github.com/Shopify/sarama/async_producer.go
index e7ae8c2..13a888b 100644
--- a/vendor/github.com/Shopify/sarama/async_producer.go
+++ b/vendor/github.com/Shopify/sarama/async_producer.go
@@ -2,6 +2,7 @@ package sarama

 import (
 	"fmt"
+	"log"
 	"sync"
 	"time"

@@ -249,6 +250,7 @@ func (p *asyncProducer) dispatcher() {
 		}

 		if msg.byteSize() > p.conf.Producer.MaxMessageBytes {
+			log.Printf("Got message size bigger than allowed max message bytes %d > %d", msg.byteSize(), p.conf.Producer.MaxMessageBytes)
 			p.returnError(msg, ErrMessageSizeTooLarge)
 			continue
 		}
@@ -577,9 +579,12 @@ func (bp *brokerProducer) run() {
 	var output chan<- *produceSet
 	Logger.Printf("producer/broker/%d starting up\n", bp.broker.ID())

+	wasReadyTimes := 0
+
 	for {
 		select {
 		case msg := <-bp.input:
+			log.Println("INPUT MESSAGE")
 			if msg == nil {
 				bp.shutdown()
 				return
@@ -625,14 +630,23 @@ func (bp *brokerProducer) run() {
 				bp.timer = time.After(bp.parent.conf.Producer.Flush.Frequency)
 			}
 		case <-bp.timer:
+			log.Println("TIMER FIRED")
 			bp.timerFired = true
 		case output <- bp.buffer:
+			wasReadyTimes = 0
+			log.Println("ROLL OVER")
 			bp.rollOver()
 		case response := <-bp.responses:
+			log.Println("HANDLING RESPONSE")
 			bp.handleResponse(response)
 		}

 		if bp.timerFired || bp.buffer.readyToFlush() {
+			log.Println("READY TO FLUSH YAY")
+			wasReadyTimes++
+			if wasReadyTimes > 10 {
+				log.Fatal("We were ready for a long time, but it did not happen. Exiting.")
+			}
 			output = bp.output
 		} else {
 			output = nil
diff --git a/vendor/github.com/Shopify/sarama/produce_set.go b/vendor/github.com/Shopify/sarama/produce_set.go
index 9fe5f79..91a127f 100644
--- a/vendor/github.com/Shopify/sarama/produce_set.go
+++ b/vendor/github.com/Shopify/sarama/produce_set.go
@@ -1,6 +1,9 @@
 package sarama

-import "time"
+import (
+	"log"
+	"time"
+)

 type partitionSet struct {
 	msgs        []*ProducerMessage
@@ -147,6 +150,7 @@ func (ps *produceSet) readyToFlush() bool {
 		return true
 	// If we've passed the byte trigger-point
 	case ps.parent.conf.Producer.Flush.Bytes > 0 && ps.bufferBytes >= ps.parent.conf.Producer.Flush.Bytes:
+		log.Printf("ready to flush because buffer bytes are big enough: %d >= %d", ps.bufferBytes, ps.parent.conf.Producer.Flush.Bytes)
 		return true
 	default:
 		return false

The output looks like this: https://gist.github.com/bobrik/27071d61d5ec98ed15ffd1cb5331f3f4.
Without log.Fatal I've seen buffer sizes go as high as 40MB, which is bigger than message.max.bytes=33554432 in our cluster.
The solution is probably to do rollOver outside of select.

Ok, it looks like sarama.MaxRequestSize is 100MB by default (and it's a global setting), and this was preventing sarama from applying back pressure sooner. Setting it under message.max.bytes solves the issue for us.
Still, this doesn't seem right. Message size back pressure should be controlled by sarama.Config.Producer.MaxMessageBytes, not by sarama.MaxRequestSize.

https://github.com/Shopify/sarama/blob/0fb560e5f7fbcaee2f75e3c34174320709f69944/produce_set.go#L139-L141

sarama.MaxRequestSize and sarama.Config.Producer.MaxMessageBytes are completely different values that control different aspects of Kafka.
sarama.Config.Producer.MaxMessageBytes is equivalent to message.max.bytes on the broker and refers to the maximum size of a kafka message, and has nothing to do with network wire size except in as much that messages get put on the wire in some form.  After that point the value is only used in a few subtle cases to do with the way kafka frames compressed messages.
sarama.MaxRequestSize is equivalent to max.request.size on the broker and refers to the maximum size of the network packet on the wire. Since you can't split a kafka message across network boundaries, this also serves as an indirect cap on the size of a kafka message, though usually it is several orders of magnitude larger and so irrelevant.

sarama.MaxRequestSize and sarama.Config.Producer.MaxMessageBytes are completely different values that control different aspects of Kafka.

There's no doubt in that.

sarama.Config.Producer.MaxMessageBytes is equivalent to message.max.bytes on the broker and refers to the maximum size of a kafka message

Yes, but the constraint of maximum message size gets violated, because no backpressure is applied when message size crosses this boundary. This is exactly the issue. I set sarama.Config.Producer.MaxMessageBytes to 16MB and get 40MB messages rejected by Kafka.

the constraint of maximum message size gets violated, because no backpressure is applied when message size crosses this boundary

When not using compression (your ticket specifies sarama.CompressionNone), produce rate and backpressure has nothing to do with message size at all. I think the confusion here is the over-use of the word "message". We're talking about two different kinds of messages and getting them mixed up:

Kafka is a "message" broker; kafka messages are produced to a partition of a topic, and end up at a specific offset. Kafka messages cannot be larger than sarama.Config.Producer.MaxMessageBytes or message.max.bytes. Batching and backpressure are irrelevant when calculating this size. This is the constraint being violated according to the error you provided.

Network messages containing multiple kafka messages are sent between the producer and the brokers. Network messages cannot be larger than sarama.MaxRequestSize or socket.request.max.bytes. Batching and backpressure are important here; if a large enough request is accumulated we cannot accept more kafka messages until the current network message has been delivered.

I notice that you have the following configuration values:
conf.Producer.MaxMessageBytes = 16 << 20 // on client
message.max.bytes=33554432 // on broker

Since these values are equivalent they are usually set to the same value.

Just getting into investigating here, but I believe what we're trying to say is that because we have such a high rate of production on one topic-partition, the first statement in the select is always being run and the following lines don't have a chance to run:
https://github.com/Shopify/sarama/blob/0fb560e5f7fbcaee2f75e3c34174320709f69944/async_producer.go#L636-L637
Since those don't have a chance to run, we're never rolling over the buffer, and it grows too large.
@bobrik , please correct me if I'm wrong.  Still looking into it more though.
I think the fact that setting sarama.MaxRequestSize under max.message.bytes makes it work is probably just a coincidence, so we'll revert that.
Also, I'm auditing our producers to ensure that they've all got MaxMessageBytes <= message.max.bytes on the broker.  Thanks for that tip @eapache.

If your produce rate is that high, you should still hit a hard block when wouldOverflow triggers (https://github.com/Shopify/sarama/blob/0fb560e5f7fbcaee2f75e3c34174320709f69944/async_producer.go#L619-L624) and the call to waitForSpace will force the rollover to happen.

Thanks.  I'll update our patch to ensure we're hitting that condition and get back.

@eapache what you say sounds good in theory, but it's just now how I see it working in real life.
Consider the following patch:
diff --git a/vendor/github.com/Shopify/sarama/async_producer.go b/vendor/github.com/Shopify/sarama/async_producer.go
index e7ae8c2..27c2f10 100644
--- a/vendor/github.com/Shopify/sarama/async_producer.go
+++ b/vendor/github.com/Shopify/sarama/async_producer.go
@@ -2,6 +2,7 @@ package sarama

 import (
        "fmt"
+       "log"
        "sync"
        "time"

@@ -249,6 +250,7 @@ func (p *asyncProducer) dispatcher() {
                }

                if msg.byteSize() > p.conf.Producer.MaxMessageBytes {
+                       log.Printf("Got message size bigger than allowed max message bytes %d > %d", msg.byteSize(), p.conf.Producer.MaxMessageBytes)
                        p.returnError(msg, ErrMessageSizeTooLarge)
                        continue
                }
@@ -577,6 +579,8 @@ func (bp *brokerProducer) run() {
        var output chan<- *produceSet
        Logger.Printf("producer/broker/%d starting up\n", bp.broker.ID())

+       maxMessageSize := 0
+
        for {
                select {
                case msg := <-bp.input:
@@ -585,6 +589,11 @@ func (bp *brokerProducer) run() {
                                return
                        }

+                       if msg.byteSize() > maxMessageSize {
+                               maxMessageSize = msg.byteSize()
+                               log.Printf("Biggest message seen so far: %d bytes", maxMessageSize)
+                       }
+
                        if msg.flags&syn == syn {
                                Logger.Printf("producer/broker/%d state change to [open] on %s/%d\n",
                                        bp.broker.ID(), msg.Topic, msg.Partition)
@@ -610,6 +619,7 @@ func (bp *brokerProducer) run() {
                        }

                        if bp.buffer.wouldOverflow(msg) {
+                               log.Println("!!! OVERFLOW !!!")
                                if err := bp.waitForSpace(msg); err != nil {
                                        bp.parent.retryMessage(msg, err)
                                        continue
@@ -627,6 +637,7 @@ func (bp *brokerProducer) run() {
                case <-bp.timer:
                        bp.timerFired = true
                case output <- bp.buffer:
+                       log.Printf("Roll over, bufer size: %d", bp.buffer.bufferBytes)
                        bp.rollOver()
                case response := <-bp.responses:
                        bp.handleResponse(response)
@@ -634,6 +645,7 @@ func (bp *brokerProducer) run() {

                if bp.timerFired || bp.buffer.readyToFlush() {
                        output = bp.output
+
                } else {
                        output = nil
                }
diff --git a/vendor/github.com/Shopify/sarama/produce_set.go b/vendor/github.com/Shopify/sarama/produce_set.go
index 9fe5f79..4886032 100644
--- a/vendor/github.com/Shopify/sarama/produce_set.go
+++ b/vendor/github.com/Shopify/sarama/produce_set.go
@@ -147,6 +147,7 @@ func (ps *produceSet) readyToFlush() bool {
                return true
        // If we've passed the byte trigger-point
        case ps.parent.conf.Producer.Flush.Bytes > 0 && ps.bufferBytes >= ps.parent.conf.Producer.Flush.Bytes:
+               // log.Printf("ready to flush because buffer bytes are big enough: %d >= %d", ps.bufferBytes, ps.parent.conf.Producer.Flush.Bytes)
                return true
        default:
                return false

The config looks like this:
	conf.Producer.MaxMessageBytes = 33554432
	conf.Producer.Flush.Bytes = 16 << 20

Let's look at the output:
2017/01/11 21:23:37 Biggest message seen so far: 26 bytes
2017/01/11 21:23:37 Biggest message seen so far: 1174 bytes
2017/01/11 21:23:37 Biggest message seen so far: 1334 bytes
2017/01/11 21:23:37 Biggest message seen so far: 1382 bytes
2017/01/11 21:23:37 Biggest message seen so far: 1510 bytes
2017/01/11 21:23:37 Biggest message seen so far: 1630 bytes
2017/01/11 21:23:37 Biggest message seen so far: 2094 bytes
2017/01/11 21:23:37 Biggest message seen so far: 2430 bytes
2017/01/11 21:23:37 Biggest message seen so far: 4510 bytes
2017/01/11 21:23:37 Biggest message seen so far: 4606 bytes
2017/01/11 21:23:37 Biggest message seen so far: 4990 bytes
2017/01/11 21:23:37 Biggest message seen so far: 5414 bytes
2017/01/11 21:23:37 Biggest message seen so far: 6414 bytes
2017/01/11 21:23:37 Biggest message seen so far: 6814 bytes
2017/01/11 21:23:37 Roll over, bufer size: 16778270
2017/01/11 21:23:37 Biggest message seen so far: 7526 bytes
2017/01/11 21:23:37 Biggest message seen so far: 7718 bytes
2017/01/11 21:23:37 Roll over, bufer size: 46134566
2017/01/11 21:23:37 Biggest message seen so far: 10918 bytes
2017/01/11 21:23:37 Biggest message seen so far: 11854 bytes
2017/01/11 21:23:37 !!! OVERFLOW !!!
2017/01/11 21:23:37 Biggest message seen so far: 20406 bytes
2017/01/11 21:23:37 !!! OVERFLOW !!!
panic: kafka: Failed to produce message to topic requests: kafka server: Message was too large, server rejected it to avoid allocation error.

goroutine 86 [running]:
panic(0x6c4cc0, 0xc423cca4e0)
	/usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/panic.go:500 +0x1a1
code.cfops.it/data/replicator.errLoop(0xc4200a6a20)
	/code/replicator/replicator.go:122 +0x76
created by code.cfops.it/data/replicator.New
	/code/replicator/replicator.go:63 +0x3e2

So my bugger message was around 20kb, but Kafka still complains about too big messages.
Limiting sarama.MaxRequestSize to 30mb (just under message.max.bytes) makes it work.
@abraithwaite select{} running just for incoming messages is in fact fine, there is code for backpressure, it just doesn't engage.

Can you provide the config of the kafka broker please?

Also, to verify, this is all running still with conf.Producer.Compression = sarama.CompressionNone right?

Still running with sarama.CompressionNone.
Broker config:
broker.id.generation.enable=true

zookeeper.connect=zk.foo.bar.com:2181/kafka/http

zookeeper.connection.timeout.ms=30000

advertised.host.name=foo.bar.com
port=9092

controlled.shutdown.enable=true
auto.create.topics.enable=false
default.replication.factor=3
auto.leader.rebalance.enable=True
delete.topic.enable=true
message.max.bytes=33554432
num.io.threads=4
num.network.threads=16
num.partitions=3

log.dirs=/state/kafka/http
log.cleaner.enable=false
log.flush.interval.messages=10000000
log.flush.interval.ms=10000
log.retention.check.interval.ms=60000
log.retention.hours=6
log.segment.bytes=2000000000

num.replica.fetchers=4
replica.fetch.max.bytes=33554432
replica.fetch.wait.max.ms=500
replica.lag.time.max.ms=10000
replica.socket.receive.buffer.bytes=1048576
replica.socket.timeout.ms=30000
replica.fetch.min.bytes=65535

socket.receive.buffer.bytes=1048576
socket.request.max.bytes=104857600
socket.send.buffer.bytes=1048576
log.message.format.version=<IP_ADDRESS>
broker.rack=218

Are any of those config values overridden for the specific topic you're using (https://kafka.apache.org/documentation/#topic-config)?

@eapache we don't have any topic level overrides:
Topic:requests	PartitionCount:84	ReplicationFactor:3	Configs:

I'm going to "think aloud". A few things don't line up:

The largest message we're actually seeing (per your logs) is ~20KB but the maximum message size is configured to be much larger both on the client and the broker.
The broker is returning MESSAGE_TOO_LARGE.
Limiting the maximum request size (not the maximum message size) makes the MESSAGE_TOO_LARGE error go away.

1 is inconsistent with 2, since the broker should only return that error when the message we're sending is larger than the configured maximum.
2 is inconsistent with 3, since the maximum request size and the maximum message size have nothing to do with each other.
Also worth noting: there's nothing unusual about the config here, and while the message rate is high, Sarama has been benchmarked and stress-tested fairly thoroughly without anybody else reporting this issue.

At this point I can't even generate a consistent hypothesis which explains all of the facts. So let's get some more data and see if something pops:

Is there anything interesting in the broker logs when this occurs? A stack trace, or a log indicating the too-large message, or something?
Does anything happen differently if you change producerMessageOverhead from 26 to 34?

Also worth noting in the interest of completeness: the SHA you're running is a fairly old version at this point, but I don't think there have been any changes since that version which would affect this particular issue. Upgrading might be something to try; if nothing else it would give us another data point.

And in the interest of "more data won't hurt", could you provide the standard Sarama logs for one of these issues as well? You've provided some output of your custom logging statements, but the defaults (the ones going to sarama.Logger) have been fairly well-tuned for debugging by this point as well.

We'll work on getting you some more information on this, but I do have one clarification question to ask regarding how the flush timing is handled:
If we check readyToFlush here:
https://github.com/Shopify/sarama/blob/0fb560e5f7fbcaee2f75e3c34174320709f69944/async_producer.go#L642
And we flush here:
https://github.com/Shopify/sarama/blob/0fb560e5f7fbcaee2f75e3c34174320709f69944/async_producer.go#L636-L637
The producer.Flush settings are described as best effort, but this seems a bit extreme.  Why wouldn't we start putting back pressure earlier?
Seems like part of the reason we're seeing issues is because those settings don't do much with high input message throughput.  In my mind, sarama.MaxRequestSize should still do what it does (last resort), producer.Flush.{Bytes,Messages} should take next priority and flush directly after the threshold crossing, and then producer.Flush.Frequency should handle the trickle case, so is really the only one that should be considered best effort.
Gonna investigate how the other clients handle this though.

This is an experimental cluster and I tested compression on brokers at some point. I enabled debug logs on one broker with compression enabled and here's what I found:
2017-01-11T23:43:01.253 36ssds3 DEBUG [KafkaApi-1005] Produce request with correlation id 1 from client  on partition requests-38 failed due to org.apache.kafka.common.errors.RecordTooLargeException (kafka.server.KafkaApis)

Disabling compression.type on broker solves the issue. It's still not clear to me why that happens.

I guess we have this: https://issues.apache.org/jira/browse/KAFKA-1718

The producer.Flush settings are described as best effort, but this seems a bit extreme. Why wouldn't we start putting back pressure earlier?

The specific scenario in question is when:

a produce request is already in flight, so we can't send another (tcp pipelining would be a nice enhancement but is not on my roadmap for the near future)
we have enough new messages/bytes accumulated to trigger a flush condition, but not enough to max out the connection
we receive another message to process

Right now we just accept the message, since we can safely handle it. We could in principle start applying backpressure at this point, but all that would accomplish would be to artificially limit throughput, especially since the flush-trigger and the maximum-supported are usually substantially different.

the Producer.Flush settings don't do much with high input message throughput

Except for Flush.MaxMessages (which is a hard limit), Sarama will happily ignore the flush settings if respecting them would negatively affect throughput.

producer.Flush.{Bytes,Messages} should take next priority and flush directly after the threshold crossing

If they behave this way, Flush.Bytes would be effectively equivalent to sarama.MaxRequestSize and Flush.Messages would be exactly equivalent to Flush.MaxMessages (tangent: yes, I wish I could go back in time and make MaxRequestSize part of the config instead of a global, but the API is pretty much unchangeable now).
Honestly, those two config values (Flush.{Bytes, Messages}) are not usually useful in practice. Sarama's default as-fast-as-possible config is the best choice in almost all circumstances, the harder limits exist for those who need them, and Flush.Frequency exists, as you correctly point out, for the trickle case. If I ever did a v2 with API breaks I'd be half-tempted to remove them just to avoid confusion.

I guess we have this: https://issues.apache.org/jira/browse/KAFKA-1718

Yes, you have a new variant of that issue which seems to be caused by the broker doing compression even when the client sends uncompressed messages. Since the client is not compressing the messages at all, it has no way to even know to work around the issue. It may be worth filing another upstream ticket for the new bug and referencing the old one, since the new one is more problematic and harder to magically work around for the client.
For such high-throughput scenarios you probably want to enable client-side compression anyway, but if that doesn't work for you then setting sarama.MaxRequestSize to message.max.bytes will (as you have already discovered) work around the issue at the cost of slightly reduced maximum throughput.

Closing as this is an upstream bug.
I'm happy to keep discussing flush logic though if there are still questions around that.

Thanks for the thoughtful response.  Although I have one quick follow up question:
How can I identify whether a produce request is in-flight in the code we've highlighted?   I'm assuming that output <- bp.buffer blocks in that case, is that correct?
It'd be nice to try (nonblocking) output <- bp.buffer once after readyToFlush() triggers, and if it's not blocked, go for it.
As @bobrik mentioned, we found our issue after all so I guess this can be closed.
Thanks for all your help!

How can I identify whether a produce request is in-flight in the code we've highlighted? I'm assuming that output <- bp.buffer blocks in that case, is that correct?

Yup. There is a tiny bridge goroutine (https://github.com/Shopify/sarama/blob/0fb560e5f7fbcaee2f75e3c34174320709f69944/async_producer.go#L542-L553) which ranges over output, making one request at a time and dumping the response into responses. A request is effectively in flight from the time you've sent the buffer to output to the time you get a response back on responses, and writing to output will block during that time frame.

It'd be nice to try (nonblocking) output <- bp.buffer once after readyToFlush() triggers, and if it's not blocked, go for it.

This doesn't actually make sense, and I think stems from an earlier misunderstanding. You wrote:

because we have such a high rate of production on one topic-partition, the first statement in the select is always being run and the following lines don't have a chance to run

Which is simply not true. Per https://golang.org/ref/spec#Select_statements if multiple cases are ready one will be chosen at random. The fact that the input case is at the top will not starve the output in high-throughput scenarios.

Ah, that's what I knew the behavior was, but then when I went to the docs:

For all the cases in the statement, the channel operands of receive operations and the channel and right-hand-side expressions of send statements are evaluated exactly once, in source order, upon entering the "select" statement.

And then stopped reading, confusing myself.  Looks like I need to work on my RTFM skills a bit more again.
Thanks again for all the help.


PROD-348/breakpoint-nft-reveal-issues

@marvinmarnold there was a missing relation from ChompResult table to RevealNft table. Currently I set it as one to many relation, but it needs to be one to one. I did that because default value in one to one relation cannot be null, but I will fix that after we run a script called: reveal-nft.ts
That script will connect records from RevealNft table to ChompResult table.

I don't totally understand all the details about the relations between tables. Some questions:

Should this be working in preview or does the script need to be run? When I to reveal on staging with address (ip5UyE6cXhy6cmxuaHWzW2pWmkFAZuDg8mjXCSroeA4), I'm not getting an offer to burn using the NFT that belongs to that wallet.
At a high level, why were so many changes necessary? I thought we previously had support for multiple collections.

This PR has a migration, so it can be tested when it is merge. After it is merged we need to run a script (first localy, then on prod)

They are necessary because we added this peace of code that was missing in claim action:
const tx = await CONNECTION.getTransaction(transactionHash!, {
commitment: "confirmed",
maxSupportedTransactionVersion: 0,
});
if (!tx) return errorToast("Cannot get transaction");

So this peace of code is causing an error. So I saw there is a missing relation from ChompResults table to a RevealNft.


Unknown shout be a generic type

tidr: for lazy type refinement we need a parameterized unknown

A problem: we can't define a expected type for future refinement:
const data: Array<number> | unknown = JSON.parse(some)

function head(list: Array<string> | unknown, fallback: ?string): string | undefined {
  if (list instanceof Array) return list[0]
  return fallback
}

// Expected: Type "Array<number>" is incompatible with type "Array<string>"
// Actual: OK!
const result = head(data)

If we define a head as function thats accept only Array<number> without unknown - we need to provide a type-garanted data for that function, thats may be an overhead for current case (walk of all array elements to refine it type).
I expecting thats unknown type may be a generic: unknown</* meta type: */Array<number>>.
As an option we could review a workaround: unknown union should not lose an other not unknown types. In other words the top ^ example just should work as a expected comment, but I think it is not intuitive because unknown as a part of union, technically, may be used for any refine, thats superfluously (не знаю как слова подобрать - кароч мы должны пресекать возможность передавать параметризированный unknown в функции принимающие простой unknown). May be, as a solution, we should use intersection for expected unknown: MyType & unknown, but I think container type is will be better: $Unknown<MyType>.

As i understood it should be something like this:
const data: $Unknown<Array<number>> = JSON.parse(some)

function head(list: $Unknown<Array<string>>, fallback: string = ''): string {
  if (typeof list == 'number') // Type $Unknown<Array<string>> can't be "number" type
  {
  }
  if (list instanceof Array) {
	  // Expected: unknown
	  const item = list[0]
	  if (typeof item == 'string')
	  {
		return item
	  }

  }
  return fallback
}

// Expected: Type "Array<number>" is incompatible with type "Array<string>"
// Actual: OK!
const result = head(data)

IMO T | unknown is just unknown. So both Array<string> | unknown and Array<number> | unknown are just unknown and therefore they are assignable to each other.

@raveclassic The behavior is needed for the try..catch statement. To show, that in catch may be placed as well unknown and your own defined errors from called functions.

How is that different?
Looking at example from the docs:
function assertIsTrue(arg) {
    if (!arg) {
        throw new TypeError("arg is invalid")
    }
}
try {
    assertIsTrue(false);
} catch (e) {
    // Type of "e" variable is "TypeError | unknown"
}

it's not clear to me how should I work with e in the catch block and what advantages does | unknown provide in the type?
In TS error is usually check with:
if (e instanceof TypeError) {
  // type of e is `TypeError`
} else {
  // e is unknown
}

But it's absolutely the same for e: unknown without that TypeError | part.
Keeping that in mind I would expect the error to be plain e: TypeError without unknown because assertIsTrue only throws TypeError. That would make sense.

The different is in fast understanding of which errors can be catches by the try..catch block.
If you will see only unknown type, it gives you nothing, but, if you see that it will be UserNotFoundError | DataBaseError | unknown you can understand which errors you can catch, and find some problems related to that.
As an example (UserNotFoundError | DataBaseError | unknown), you can understand, that you call method/function which throws low-level error DataBaseError, and you can find it and rethrow DataBaseError as other top-level error.

Seems we're talking about different things. I'm absolutely ok with declaring throwed errors in function signature (this reminds me checked exceptions in Java). What I don't get is:

why is unknown added to the union
even if it's added, then how does declaring error types help at all since you always end with unknown in the most general case.

Seems Hegel encodes unknown in a different way than TypeScript. If so, could you please clarify why is T | unknown not equal to unknown?

I understand your position and also I agree with that.  (Actually unknown | T should be unknown). But I don't know which way is better for informative hints in try..catch block. If you have some advice or interesting solution for the case - I will the first one who change the semantic of union with unknown type :)

That's a very good question. I'm pretty sure I don't see the whole picture but at least I'd suggest not using unknown in unions because it ultimately defeats the purpose of such unions for a person not familiar with these highly specific semantics.
Back to the original issue: if we both agree that adding unknown to a type (not in try/catch case) effectively turns such type to unknown, then I'd suggest using tuples+spreads (I don't know if Hegel supports them ATM):
declare const head: <A>(list: [A, ...unknown[]]) => A

Ok, here another case. You write a library for mom and type an argument of public function. You can't control a user env and don't know which type system they used (or no one at all). So u in same time want to describe a type of argument and what to mark it as unknown for internal contract provement. How to describe it better in code?
May be we need a two kindest type: with two different signature, for publick and internal usage. Because if mark an argument of a function as generic unknown we tell a user of function that they may to provide anything by argument too...
I think we need a more investigation for this...

In TS I'd just declare it as unknown because it's the "smallest" possible type for a function argument, I mean when checking this argument in the body of that function. While also the "widest" type to pass to that function from outside. This reflects how outer-world interop can be encoded.
Even if you add something more specific to the union you can't guarantee that in runtime the argument will adhere the type since Hegel is just a typechecker.

@raveclassic do you really think it is safety??

A type system, with this case, is useless and getting false garanties

I don't get the example. You declare a function which returns any (ehw), and then refine that function. Could you clarify what do you mean?

Here's how I see it:
// this code requires runtime checks to guarantee that calls to `foreign` always return `number`
export declare const foreign: (data: string) => number;
export function process(): number {
	const foo = foreign('foo');
	const bar = foreign('bar');
	return foo + bar; // UNSAFE!
}

export declare const safeForeign: (data: string) => unknown;
export function safeProcess(): number | undefined {
	// note the `| undefined` here
	const foo = safeForeign('foo');
	const bar = safeForeign('bar');
	// return foo + bar; // Error! Object is of type `unknown`
	if (typeof foo === 'number' && typeof bar === 'number') {
		return foo + bar;
	}
	// here, foo and bar are still of type `unknown`
	// the only thing we could do here is to type them as smth like `unknown - number`
	// but there's no such operator
}


The terminal failed to load powershell, there is an error loading cmd

VSCode Version: 1.33.0
OS Version: Windows_NT x64 10.0.17763

extra information：

版本: 1.33.0 (user setup)
提交: 0dd516dd412d42323fc3464531b1c715d51c4c1a
日期: 2019-04-04T15:14:28.026Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

Steps to Reproduce:

Open terminal.
Powershell does not work properly in vscode.
Switch to cmd, the text format in the terminal is incorrect when the script is first input.

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

Can you elaborate on what "Powershell does not work properly in vscode" means and also "the text format in the terminal is incorrect"? Screenshots might help.

cmd text format problem：
When opening the terminal, the following picture:

entering a line command:

The focus position is incorrect and the current path is not displayed.

Powershell cannot be started in the vscode terminal.

Will always be in this state...

English is not good, please forgive me

@ygwoo 显示问题，滚轮上滑可以看到powershell已经启动了，功能也不受影响

@Tyriar That's a render problem, scroll up will see powershell is already run, but a lot of blank has rendered.

@ygwoo 显示问题，滚轮上滑可以看到powershell已经启动了，功能也不受影响

哦 发现了，谢谢，那现在只存在显示格式问题了。

This is a bug in Windows 10 1809, unfortunately we have no way to work around the issue so you will need to wait until you get the next version of Windows 10 (1903).
/duplicate https://github.com/Microsoft/vscode/issues/57803


Fix question page examples

This adds closing divs to two examples on the question page pattern

You can preview this change here:
Built with commit 6bf0ef7254ca4b01655607891f21660c09b7f473
https://deploy-preview-198--govuk-design-system-preview.netlify.com


Inverted section with DataTable doesn't evaluate correctly

When trying to use a DataTable that has zero rows, the inverted tag doesn't evaluate correctly (i.e. not at all). Here's an example of my template:

                Foo

            {{#Data}}

                {{Foo}}

            {{/Data}}
            {{^Data}}

                    No data exists.

            {{/Data}}

I get simply:

                Foo

My call looks like so:
Render.FileToString("path_to_template.html", new {
    <other properties...>,
    Data = dt
});

Hey, thanks for reporting this. It was an oversight on my part when implementing the DataTable interpolation in that it has to have an explicit way to determine if it has values.
I've added code to fix this and added a test using your example (which was well documented, thank you very much for that) and it'll in the next release which should be on Friday by the latest.
Thanks,


Extensive ConfigMap usage a problem in some OpenShift environments

When trying to deploy Funktion to an Openshift environment maintained by my IT department, I hit an issue with ConfigMap quotas. Just installing the platform creates a lot of catalog-* ConfigMap entries and every Function, Flow, and Connector installed adds more. In my case I have a quota of 20 ConfigMaps, which is fairly low, but even a much higher quota could quickly be hit.
Is there a way we could reduce overall ConfigMap usage without sacrificing functionality? Perhaps we could install the catalog-* ConfigMap entries from funktion install platform lazily as-needed instead of eagerly?

I don't see any reason, why we couldn't use a single map that contains all catalogs.
@jstrachan: wdyt?

Iirc there's a 1mb limit on config map size.

Does funktion even need all of those catalog- entries? Or are they just coming in because funktion-platform brings in the fabric8 console? If we removed the console from the platform, that would greatly reduce the ConfigMap burden I believe.

I think there are two problems: the undesirable coupling with the fabric8 app catalog deployment; and also the use of config maps to define possible connectors. It should be easy to remove the installation of fabric8 console but probably need to think more about the use of configmaps for connectors.

Is there a workaround for this?
> funktion install platform
kubectl apply --namespace funktion-system -f https://repo1.maven.org/maven2/io/fabric8/platform/packages/funktion-platform/2.4.24/funktion-platform-2.4.24-kubernetes.yml

bufio.Scanner: token too long
Failed: exit status 1

@ChugR whats the output of
kubectl version

I suspect we need a recent 1.4.x version of kubectl

@jstrachan 1.3

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"3",
GitVersion:"v1.3.0+52492b4", GitCommit:"52492b4",
GitTreeState:"clean", BuildDate:"2016-10-26T13:42:34Z",
GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"3",
GitVersion:"v1.3.0+52492b4", GitCommit:"52492b4",
GitTreeState:"clean", BuildDate:"2016-10-15T23:44:12Z",
GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

@ChugR that's a known issue which can be ignored, it won't prevent funktion from working (see https://github.com/funktionio/funktion/issues/33).

I've removed the fabric8 console and application catalog from the funktion installation which makes things much simpler; so a funktion install is 2 small ConfigMaps (one runtime, one for exposing services) and 1 Deployment/pod so its pretty minimal and can fit inside OpenShift Online free tier now


Advanced color-schema picker and heatmap color schema

Is your feature request related to a problem? Please describe.
Users should be able to select different color schemas and not just the default for each feature. They should also be provided with a color picker which takes up less space and is more clear about the current color choices.
Describe the solution you'd like
Users should see the possible properties which can be used as color schema properties in a dropdown.
Additionally they should be presented with a dropdown / toggle for choosing between different color schemas for a certain color schema property.
Additional context
#5 should be finished first.

Variables that are not categorical / numerical should not be used for node colors.

Was partially implemented in #56


chore(main): release 3.0.0

:robot: I have created a release beep boop
3.0.0 (2023-09-15)
⚠ BREAKING CHANGES

resolve path resolve issues (on windows) and types for virtual modules (#68). As a side effect of this, it is no longer possible to import the schema on the client/vue-side.

🐛 Bug Fixes

hmr schema watcher had an always truthy conditional check (#67) (4104b50)
resolve path resolve issues (on windows) and types for virtual modules (#68) (5256e31)

🧹 Miscellaneous

deps: update actions/checkout action to v4 (#69) (4356e16)
deps: update all non-major dependencies (#62) (c613500)
deps: update devdependency eslint-config-prettier to v9 (#66) (b4591ce)
deps: update devdependency eslint-plugin-unused-imports to v3 (#65) (9211aea)
deps: update typescript-eslint monorepo to v6 (#63) (c718676)
fix badge url in the readme (#73) (cd20c96)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/tobiasdiez/nuxt-graphql-server/releases/tag/v3.0.0 :sunflower:


feathers-authentication branch 0.8 did not work with payload (tested on socket)

This post is a report of my work to allow persist login with token based check with branch 0.8 feathers-authentication
I made some research to get mostly same behavior than feathers-authentication stable release (last)
I found some problem in code of feathers-authentication
----------ISSUE-------------------
'jwt issuer invalid. expected: feathers'
I use REST and socket in server side:
.configure(rest())
.configure(socketio())
socket is used to register and to login,
rest make some test on token in browser refresh
I started my coding from standard example supplied (i kept configuration and middleware order in server side and client side)
The rest check the token issued by login and make some problem when pass
feathers-authentication:token Verifying token

my config feather.json is

"auth": {
"token": {
"secret": "monsecret"
},
"user": {
"idField": "uuid",
"endpoint": "/user"
}
}
my idfield is personnel and generate with uuid.v4
so i have _id and uuid in mongo-table
here different things to make it work

[x] In src/services/local.js:
tokenendpoint is not good
tokenEndpoint: '/auth/local',
change for
tokenEndpoint: '/auth/token',

so need to add idField in services/token.js like it is in services/local.js

[x] around line 196 set
const { passwordField, idField} = authConfig.user;
options = merge(defaults, authConfig.token, options, { passwordField, idField});

[x] around line 130
the last patch should to be omitted else options is not the same than before refresh -> and not good for keeping session logged
// if (!data.iss) {
options.issuer = issuer;
//  }
//  if (!data.sub) {
options.subject = subject;
//   }
//  if (!data.exp) {
options.expiresIn = expiresIn;
//  }
//here it's my hack
if (data.sub) {
data={[this.options.idField]:data[this.options.idField]}
}

if data.sub exist rewrite data without sub , exp properties ... (these are not here when not logged)
because data.sub not exist when user not logged  (there is no jwt.verify pass before to create the payload)
from token jwt.verify  put some properties in payload result (sub , exp ...) then
the payload (data) in jwt.sign are not the same than when i was not logged;;;
the result that after 2 refresh i have 'unauthorized' and i'm not anymore logged

I have a persistant login after the upper changes

Finally in debug i have something good
New JWT issued with payload +0ms { uuid: 'b68a370c-c180-41c8-b573-6de42a8dd723' }
For every refresh my token is different (is it important to change it ???)
after 30sec my login session not work (so it's fine because it's the configuration of 'feathers-jwt' token)
here my Client-side code a simple class to manage login authorization:
//part initialization:
feathers()
.configure(socketio(socket))
.configure(hooks())
.configure(authentication({storage:window.localStorage,cookies: {enable:true}}));
//
class login-auth:
init() {
// get token from localStorage
const token = (process.env.BROWSER)
? window.localStorage.getItem('feathers-jwt')
: null;
// auto-login with jwt
if (token)
this.jwtAuth();
}
@action
updateUser(data = {}) {
//make stuff with user
let av={email:data.email,username:data.username}
this.user = av || {};
}
jwtAuth() {
//auto login
return app()
.authenticate({})
.then((result) => this.updateUser(result.user))
.catch((err) => {
console.error('errorauth')
console.error(err)}
); // eslint-disable-line no-console
}
@action
login({ email, password }) {
return app()
.authenticate({ type: 'local', email, password})
.then((result) => this.updateUser(result.user));
}
@action
register({ email, password, username }) {
return service('user')
.create({ email, password, username });
}
//serverside
app.use(compress())
.configure(rest())
.configure(socketio())
.configure(hooks())
.use(bodyParser.json())
.use(bodyParser.urlencoded({extended: true}))
.configure(authentication({cookies: {enable:true}})).configure(token()).configure(local())
.configure(service) //i have user service connected with mongoose
.use('/', serveStatic(app.get('public')))
.configure(middleware);
hook:
import { hooks as auth } from 'feathers-authentication';
import { setUUID } from '../../hooks/setUUID';
/**
Hook: before
Service: user
*/
export default {
all: [],
find: [ ],
get: [
auth.verifyToken(),
auth.populateUser(),
auth.restrictToAuthenticated(),
auth.restrictToOwner(),
],
create: [
setUUID(),
auth.hashPassword(),
],
update: [
auth.verifyToken(),
auth.populateUser(),
auth.restrictToAuthenticated(),
auth.restrictToOwner(),
],
patch: [
auth.verifyToken(),
auth.populateUser(),
auth.restrictToAuthenticated(),
auth.restrictToOwner(),
],
remove: [
auth.verifyToken(),
auth.populateUser(),
auth.restrictToAuthenticated(),
auth.restrictToOwner(),
],
};

This is no longer valid and we have tests in place for the new 1.0.0-beta version that is in master and slated for release that confirms this works.


Get rid of --network-timeout=300

neuro's global option --network-timeout specifies the timeout between two reads, not the overall timeout. Thus, we allow our commands used in neuro exec (in make setup) to keep silence for 5 minutes! comparing to default 1 minute. This is not what we need, in addition, we overcomplicate commands syntax.
AFAIR, we added --network-timeout=300 as an emergency option right before the first demo. Now we have time to investigate this question more thoroughly and, if needed, increase the default timeout in neuro instead (cc @asvetlov).

AFAIR, this option is no longer valid and should be removed anyway.


[Feature Request]: missing/outdated config for standart 1.16+ preset

Is there an existing issue for this?

[X] I have searched the existing issues

Suggested Feature
OpenTerrainGenerator-1.16.5-0.1.10

incorrect grass color for "Dark Forest (Hills)"
biome "Deep Cold/Lukewarm/Frozen Ocean" and "(Tall) Birch Forest Hills" is not implemented as "IsleBiomes"
outdated "(Deep) Ocean" generation, incorrect "(Deep) Cold/Frozen Ocean" generation
incorrect water and waterfog color for "Swamp (Hills), (Deep) Cold/Lukewarm/Warm/Frozen Ocean"

OpenTerrainGenerator-1.17.1-0.0.23

missing COPPER_ORE,DEEPSLATE generation
missing DEAD_BUSH generation in "swamp" category
unused glow lichen and amethyst geode features

Suggested Implementation

use "GrassColorModifier: DarkForest"
add gravel layer to ocean floor below ~52
add new resources/registry

Anything else?
No response

The suggestions for 1.17+ are appreciated but won't be implemented until we do a full update, which won't happen until we have a more stable release for them. The others should probably be looked at for the next 1.16.5 release

1.17x also includes all 1.16x mismatches...


spanish transcription

hi i need your help with time-coded transcripts, i have a licence of Dragon Naturally Speaking spanish vocabularies, how can continue testing this app with that speech to text engine
stay alert

I'm unfamiliar with Dragon Naturally Speaking.  Are there options to export transcripts in different formats?  If so, what formats?  This app supports importing standard captioning formats

Pls Share me what formats
El jul 22, 2016 10:14 AM, "Brian Foo"<EMAIL_ADDRESS>escribió:

I'm unfamiliar with Dragon Naturally Speaking. Are there options to export
transcripts in different formats? If so, what formats? This app supports
importing standard captioning formats
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/NYPL/transcript-editor/issues/86#issuecomment-234569733,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAaLFIjbnb7fckozBE_s9rahlx6wjGS8ks5qYNzogaJpZM4JSXRM
.

@beefoo pls tell me about formats

It currently supports WebVTT which is based on SRT formats.


BUG: Code-Review missing review markers

Describe the bug
Code-Review misses review indicators used by FreeBSD.
Reproduction steps
Steps to reproduce the behavior:

Inspect Code-Review for freebsd-src https://securityscorecards.dev/viewer/?uri=github.com/freebsd/freebsd-src
Review recent FreeBSD commits https://github.com/freebsd/freebsd-src/commits/main/
Observe Reviewed by: tags and/or Phabricator URLs indicating review took place, e.g. https://github.com/freebsd/freebsd-src/commit/1b7487592987c91020063a311a14dc15b6e58075

Expected behavior

Match Reviewed by: as a synonym for Reviewed-by: as evidence of review
Consider following Phabricator review links and extracting review state

Additional context
I suspect FreeBSD may be one of the more significant remaining open source users of Phabricator, and for us review evidence should be included in the commit message directly (via Reviewed by:). It may or may not be worth the effort to parse Phabricator state for other projects that use Phabricator and do not indicate the review state in the commit message. LLVM used to be an example of such a project, but they use a completely GitHub-based workflow now.

We do try and detect Phabricator review links:
https://github.com/ossf/scorecard/blob/71aed951f99eba4e84737895c1251e295f5b71e5/checks/raw/code_review.go#L95-L105
Where the regex we currently use is:
https://github.com/ossf/scorecard/blob/71aed951f99eba4e84737895c1251e295f5b71e5/checks/raw/code_review.go#L27-L28
I see many commits with content like:
Differential Revision: https://reviews.freebsd.org/D44814
Differential Revision: https://reviews.freebsd.org/D44815

We do get matches on some of the commits, including https://github.com/freebsd/freebsd-src/commit/1b7487592987c91020063a311a14dc15b6e58075
2024/04/30 13:26:54 1b7487592987c91020063a311a14dc15b6e58075 {Phabricator https} Phabricator https

But our regex doesn't handle the link, so all of these changes count as 1 revision ("https"). So unrelated commits are getting grouped as one, leading to an under reporting of freebsd's code review practices.

Phabricator wants the full URL for auto-closing - see e.g. LLVM's (now obsolete) Phabricator documentation: https://releases.llvm.org/14.0.0/docs/Phabricator.html, so the regex should be changed to match any non-space characters.

What do you think about:
Differential Revision:[^\r\n]*(D\d+)

So it matches the D### on the same line as Differential Revision

That RE lgtm, and 16/29 seems plausible for the fraction of recent commits with evidence of review based on a quick look in the repo.

I'm curious how multiple commits with the same phabricator review link are handled, though -- it's possible that the same code review may be shared by multiple commits (e.g., there may be a bugfix and new functionality that are closely related and make sense to review altogether, but the two parts are committed separately).

I'm curious how multiple commits with the same phabricator review link are handled, though -- it's possible that the same code review may be shared by multiple commits (e.g., there may be a bugfix and new functionality that are closely related and make sense to review altogether, but the two parts are committed separately).

Under the hood they get grouped into the same changeset, in this case by Phabricator revision ID
https://github.com/ossf/scorecard/blob/b9c1f3fc7ac7ce91e582cd5b27537171496ec522/checks/raw/code_review.go#L155-L175
So if you have 4 commits, 2 of which come from the same Phabricator review, and 2 commits which don't have reviews.
this will get grouped into 3 groups, (phabricator revision, unreviewed commit 1, unreviewed commit 2), and be considered 1/3 reviewed.

The commit you linked has two linked reviews:
Differential Revision: https://reviews.freebsd.org/D44814
Differential Revision: https://reviews.freebsd.org/D44815

I think the regex would only associate it with D44814, but either way it counts as reviewed


Example Throws TypeError

With a fresh install of cmd2 and cmd2-ext-test, the example from the README will generate a type error.  I actually found this issue a couple weeks ago and never pushed a change back up through here.
I'll get a fix published this weekend.
Also, we're moving this plugin in as part of the main cmd2 git project so it can be unit tested together to prevent this type of thing from happening in the future.

@cpy1 0.1.1 should be release now with the fix.


[docs] Getting started instructions missing cli tool instructions

After going through the "Getting Started" section, when copying a component's code, there are often errors related to ~/lib and ~/components imports. Seems the steps on this page are missing the cli setup.
Also, earlier today there was a CLI section on the docs that seems to have disappeared, guess these parts of the docs are being actively worked on?

@aryzing
Thanks for taking your time to create this issue. I agree that the docs at this point could be a bit more precise.
How ever the step you are missing is part of the getting-started.mdx so I think we can just merge them.

Sure, seems like merging Setup + CLI into one would make sense

The Getting Started page has been revised.


Use a Merkle accumulator for history

Instead of a linear previous-blockhash, a Merkle accumulator (such as a Merkle mountain range) should be used. This allows for proving inclusion of a block in the chain with a logarithmic number of hashes, which is especially in the context of cross-chain relays.

It might be possible to capture all the benefits of an in-protocol history MMR with a history MMR computed entirely client-side (i.e. add a new leaf to a locally-maintained MMR for each new block header).


node index.js not found

Whenever I try to run "node index.js" it states cannot find module and also my package.json has a debug issue at scripts anyone else run into this problem.
I can't seem to figure out what's the problem? (I'm relatively new to coding so any help would be great)

Thanks for the help :)

Thanks for the help :)

Hey there, did you figure it out, im having the same issue, any help would be great:)


Spike: malicious validators only calling a hard-coded list of malicious miners

We potentially could do more research here but it is our understanding that the way to prevent this is to have many validators that we control, all "benevolent".  If this is the case, malicious validators will then be scored poorly b/c they are not following the herd in terms of the weights they set.  We should investigate:

how to weight copy, or even if we should do that, because we can also:
run many independent validators, improving the decentralization of the network

I'm creating these 2 new spikes and closing this issue.


with google analytics visualisation

Hello,
on https://analytics.google.com
this works :
analytics.track("testTrack1");

analytics.track("testTrack2",{ category:"testCategory2" });

this doesn't works, I have got nothing on https://analytics.google.com, any idea ?
analytics.identify('1e810c197e', {
name: 'Bill Lumbergh',
email<EMAIL_ADDRESS>});
analytics.page("home1");

analytics.page("home2",
{
  page:"/yo1",
  name:"s1",
  category:"good1",
  support:"sup1",
  source:"source1",
  title:"tile1",
  location:"loc1",
}
);

thank you

Hey @TroubadourFabiolas,
I just tested the example app and it seems to run fine.
I also pasted your example in the example app and it showed up on https://analytics.google.com .
Do have adblocker on by any chance? If not maybe try you example in the example app to see if it works fine there.

hi @arrygoo thanks for your answer
No, I have not adblocker.
In your example, you use analytics.on('page'and I use analytics.page("home1"); => is it the same ?
Do I need to use "Mixpanel" in settings.json ?
Thank you

Hey @TroubadourFabiolas,
I hope I can help you figure this out. Those two are not the same. In the example analytics.on('page', foo) is an event listener, meaning that  "foo" will run everytime a "page" event is emitted. In our example we log it every time 'page' happens.
On the other hand, analytics.page("home1") is the actual trigger of the action, meaning that it will cause a page view to show up in your google analytics.
Is it possible that you're looking at the wrong place in google analytics? Try going to the real-time tab and see if calling the analytics.page("home1") makes it show up there.
Mixpanel doesn't have to be in settings.json, but make sure you're using the correct trackingId.
If you provide a repo where this is happening we will be able to assist you better.

@arrygoo thank for you answer,

Mixpanel doesn't have to be in settings.json, but make sure you're using the correct trackingId
=> TrackingId is good because I can see all events analytics.track on https://analytics.google.com

Is it possible that you're looking at the wrong place in google analytics? Try going to the real-time tab and see if calling the analytics.page("home1") makes it show up there.
I looked everywhere to find these "event page" but nothing appears

For your information : Meteor <IP_ADDRESS>

@arrygoo I just checked on https://analytics.google.com
Yesterday, I didn't see nothing on the real-time tab,
Today, I just saw a page seems tracked,
so, I continue the test and I'll come back tomorrow ;-)

@arrygoo Hello, here you are my results after my latest tests.
with this code
analytics.page("my_page_testing", { //It works on https://analytics.google.com => Reporting => Behaviour => Overview => Page Title
      title: "my_title_testing", //I don't see this information on https://analytics.google.com
      path: "/my/url/testing"//It works on https://analytics.google.com => Reporting => Behaviour => Overview (here page default)
  });

Note : On real-time tab, I can see some activity like Url from browser like '/' but we can't see more details of activity.
Thank you @arrygoo for your help.


Bot sends message to the same chat

👋
Hi believe I found a problem but I cant understand where the problem is.
The following fode when in a controller will always send all the messages to the first chat.
/** @var TelegraphChat $chats */
$chats = TelegraphChat::all();

foreach ($chats as $chat) {
    $chat->markdown("*Hello!*\n\nI'm here!")->send();
}

strange behaviour,
can you dump the generated request url by calling
dump( $chat->markdown("*Hello!*\n\nI'm here!")->getUrl());

on each chat?

strange behaviour,
can you dump the generated request url by calling
dump( $chat->markdown("*Hello!*\n\nI'm here!")->getUrl());

on each chat?

Yes here you go.
[2022-03-08 17:23:02] local.DEBUG: data::webhook ["https://api.telegram.org/bot5134627221:AAHitxQitwx0Z-rOvKLKYPejauEMZ9qjG2o/sendMessage?text=%2AHello%21%2A%0A%0AI%27m+here%21&chat_id=889306437&parse_mode=markdown"]
[2022-03-08 17:23:02] local.DEBUG: data::webhook ["https://api.telegram.org/bot5134627221:AAHitxQitwx0Z-rOvKLKYPejauEMZ9qjG2o/sendMessage?text=%2AHello%21%2A%0A%0AI%27m+here%21&chat_id=889306437&parse_mode=markdown"]
[2022-03-08 17:23:02] local.DEBUG: data::webhook ["https://api.telegram.org/bot5134627221:AAHitxQitwx0Z-rOvKLKYPejauEMZ9qjG2o/sendMessage?text=%2AHello%21%2A%0A%0AI%27m+here%21&chat_id=889306437&parse_mode=markdown"]
[2022-03-08 17:23:02] local.DEBUG: data::webhook ["https://api.telegram.org/bot5134627221:AAHitxQitwx0Z-rOvKLKYPejauEMZ9qjG2o/sendMessage?text=%2AHello%21%2A%0A%0AI%27m+here%21&chat_id=889306437&parse_mode=markdown"]
[2022-03-08 17:23:02] local.DEBUG: data::webhook ["https://api.telegram.org/bot5134627221:AAHitxQitwx0Z-rOvKLKYPejauEMZ9qjG2o/sendMessage?text=%2AHello%21%2A%0A%0AI%27m+here%21&chat_id=889306437&parse_mode=markdown"]

seems the chat ID overlaps, thanks for pointing this out, will fix on the next release (will be available later today)

any issue is welcome, we are using it in production too, but every application brings his own needs and issues. Again, thanks!

@fabio-ivona yes I have 5 rows in that table with 5 different chat_id values.

and this code dumps you different values?
 /** @var TelegraphChat[] $chats */
    $chats = TelegraphChat::all();

    foreach ($chats as $chat) {
        dump($chat->chat_id);
    }

@nacr never mind, found it
it is tied to a bug that I already fixed a couple of days ago and will be released right now
v1.4.0 will solve it

and this code dumps you different values?
/** @var TelegraphChat[] $chats */
$chats = TelegraphChat::all();

foreach ($chats as $chat) {
    dump($chat->chat_id);
}

Yes that code will dump the correct value.
but if I add this to the foreach
dump($chat->markdown("*Hello!*\n\nI'm here!")->getUrl());

the chat_id value is always the same.

yep, v1.4 has an internal refactor of how telegraph handles chats during requests, so they are not cached anymore, am releasing it right now, could you confirm me that v1.4.0 solves your issue?

Yes it does.
❤ thanks m8


Where is function.json?

Not sure where to post it, but using Azure Functions for VS 2017. When it generates the template, where is the function.json? Is it only generated when I build the project? What if I want to modify the function.json such as adding the  direction for out?

Closing: Found the right repo.  https://github.com/Azure/azure-functions-vs-build-sdk/issues/60


Making corrections to the Kodadot docs

In the first picture, the correct phrase should have been: " we thrive on becoming a non-exclusive..."
In the second, their was a mistake in spelling ecosystem. I hope to see this implemented team, WAGMI!

Done! Thank you :)


fix: relative script dir path

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

v1.47.0
GitHub release

Your semantic-release bot :package::rocket:


Synthesize existing sender research

User Story
As an RS team member, I want to be able to review findings from sender debriefs to understand at a high level what is working well and what could be improved
Background & Context

Flo recently conduct 3 sender debriefs (Genabio, BZD labs, and Intrivo)

There are ongoing efforts to map the sender onboarding process, both for CRM and automation initiatives

Collecting the feedback we have from senders in one place could inform the above

Working Links
CRM mural
Onboarding metrics mural
Acceptance Criteria

[ ] Review interview notes and add high level takeaways for each

[ ] Start a mural board with feedback

[ ] Share with team

[ ] Add insights to above existing murals as appropriate

[ ] Based on patterns found, consider next steps, like updating programmer's guide

Synthesized notes here

Synthesized notes here


Add explaination on how to use PSR-4 autoloading to documentation

Hello,
I had problems to autoload multiple context classes. Here is all explanation how much I had to think till I found the solution. Something like this should be in the documentation for sure:
http://stackoverflow.com/questions/36598315/behat-3-1-multiple-contexts-second-context-class-not-found/36599933#36599933

If Behat is a dev dependency in your composer.json, you don't need to configure anything. Behat by default will use Composer autoloader, meaning every class Composer can find, Behat will be able to find too. Simply configure PSR-4 autoloading in Behat and it should work. I think you're overthinking it.
I'm closing this - please, feel free to reopen if you think there's still major documentation issue.


Unceasing Flame - Make it give a card that gives Flaming, instead of having to be right-clicked (Thanks to Twitch's Aragolt, which forgot to use Unceasing Flame and that probably helped him to die in Act 3)

The relic already calls attention to itself, so this is not needed.


💡[FEATURE]: Finance & Accounting Courses - Udemy (13K+ course)

About Dataset
Context
A compilation of all the development related courses ( 13 thousand courses) which are available on Udemy's website. Under the development category, there are courses from Finance, Accounting, Book Keeping, Compliance, Cryptocurrence, Blockchain, Economics, Investing & Trading, Taxes and much more each having multiple courses under it's domain.
All the details can be found on Udemy's website as well!
Content
Here, I have extracted data related to 10k courses which come under the development category on Udemy's website.
The 17 columns in the dataset can be used to gain insights related to:
id : The course ID of that particular course.
title : Shows the unique names of the courses available under the development category on Udemy.
url: Gives the URL of the course.
is_paid : Returns a boolean value displaying true if the course is paid and false if otherwise.
num_subscribers : Shows the number of people who have subscribed that course.
avg_rating : Shows the average rating of the course.
avg rating recent : Reflects the recent changes in the average rating.
num_reviews : Gives us an idea related to the number of ratings that a course has received.
num_ published_lectures : Shows the number of lectures the course offers.
num_ published_ practice_tests : Gives an idea of the number of practice tests that a course offers.
created : The time of creation of the course.
published_time : Time of publishing the course.
discounted_ price_amount : The discounted price which a certain course is being offered at.
discounted_ price_currency : The currency corresponding to the discounted price which a certain course is being offered at.
price_ detail_amount : The original price of a particular course.
price_ detail_currency : The currency corresponding to the price detail amount for a course.

you should create a new folder for it and the main importance should be given to the financial domain


Write Starsim talk

which starsim talk? i'm giving one tomorrow, will link slides here!

For SciPy! "The launch"

Done