mouse movement breaks VRR

Hyprland Version
 System/Version info
Hyprland, built from branch  at commit cdd3de640d7cca766135515e167b26b7bc603ada  (add back nvidia hardware cursor).
Date: Fri May 24 14:42:19 2024
Tag: v0.40.0-121-gcdd3de64, commits: 4727

flags: (if any)

System Information:
System name: Linux
Node name: artix
Release: 6.9.1-273-tkg-bore
Version: #1 SMP PREEMPT_DYNAMIC TKG Tue, 21 May 2024 00:11:39 +0000

GPU information:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3060 Ti] [10de:2486] (rev a1) (prog-if 00 [VGA controller])
11:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] (rev c5) (prog-if 00 [VGA controller])

os-release: NAME="Artix Linux"
PRETTY_NAME="Artix Linux"
ID=artix
BUILD_ID=rolling
ANSI_COLOR="0;36"
HOME_URL="https://www.artixlinux.org/"
DOCUMENTATION_URL="https://wiki.artixlinux.org/"
SUPPORT_URL="https://forum.artixlinux.org/"
BUG_REPORT_URL="https://bugs.artixlinux.org/"
PRIVACY_POLICY_URL="https://terms.artixlinux.org/docs/privacy-policy/"
LOGO=artixlinux-logo

plugins:

Bug or Regression?
Bug
Description
When moving my mouse around in game, my monitors refresh rates jumps to its maximum (155), using Hyprland compiled from Main 4e42107d25dc47ee94da282db233f85f1e4 , I used my monitors OSD to view refresh rate changing. I have not tested on the amd igpu as of yet
nvidia driver version: 555.42.02
Things i have tried:
main branch:
4e42107d25dc47ee94da282db233f85f1e4c6bd0 - no atomic = 1, no hardware cursors = 1 or 0, VRR mouse issue
4e42107d25dc47ee94da282db233f85f1e4c6bd0 - no atomic = 0, no hardware cursors = 1 or 0, broken VRR, stays at monitors max refresh
I have narrowed down the commits where the issue starts > ed411f53bdcf8d455f9e6ca769693aa84dc8372f to fe4737fb9d578400ecfc63dc6ab4d684993362b8
e4e84064f2d07810e0c150bce1369a0a00503e9a Is the last working commit before having VRR issue with mouse.
However compiling from main with both, Fixes the VRR mouse issue:

(#6220)
(#6086)

main + #6086 + #6220:
WLR_DRM_NO_ATOMIC = 1, WLR_NO_HARDWARE_CURSORS = 1, VRR mouse issue
WLR_DRM_NO_ATOMIC = 1, WLR_NO_HARDWARE_CURSORS = 0, working VRR
WLR_DRM_NO_ATOMIC = 0, WLR_NO_HARDWARE_CURSORS = 1, VRR mouse issue
WLR_DRM_NO_ATOMIC = 0, WLR_NO_HARDWARE_CURSORS = 0, working VRR, refresh rate spikes have also mostly disappeared that issue (#5918) is talking about
main + #6220:
WLR_DRM_NO_ATOMIC = 1, WLR_NO_HARDWARE_CURSORS = 1 or 0, working VRR
WLR_DRM_NO_ATOMIC = 0, WLR_NO_HARDWARE_CURSORS = 1 or 0, broken VRR
main + #6086:
WLR_DRM_NO_ATOMIC = 1, WLR_NO_HARDWARE_CURSORS = 1 or 0, VRR mouse issue
WLR_DRM_NO_ATOMIC = 0, WLR_NO_HARDWARE_CURSORS = 1 or 0, VRR mouse issue, refresh rate spikes have also mostly disappeared that issue (#5918) is talking about
How to reproduce
Use the configs listed above with their corresponding branch/PR, use your monitors refresh rate OSD function to see if refresh rate is matching what happens with my test results.
Crash reports, logs, images, videos
No response

FYI, the WLR_NO_HARDWARE_CURSORS env var has been deprecated in favour of the cursor:no_hardware_cursors config since #5902


Suggestion: move Gradient.TypeAnnotation to a separate package

The macro-based implementation of Gradient.TypeAnnotation is great! The only problem with it is that when you use it, Gradient and transitively also Gradualizer become your dependencies for all your environments, not only for dev. It seems a bit silly that the two packages are needed only because of the tiny macro. What do you think about moving it to a different package (e.g. gradient_runtime, gradient_utils) that would be the only one needed in prod and test environments? Gradualizer itself could depend on it as well and use it inside Gradient.TypeAnnotation to provide backward compatibility.

Yes, this seems like a good idea. Thanks for raising this!

I've spent some more time thinking about this and also looking at #148 and ultimately I think we're already doing the right thing. I mean we don't need #148 or a separate gradient_runtime.
@xxdavid

The only problem with it is that when you use it, Gradient and transitively also Gradualizer become your dependencies for all your environments

This is not the case, but you have to be careful about how the dependency is specified in the project you use Gradient with. Specifically, it should be:
      {:gradient, (path: ... or github: ...), only: [:dev, :test], runtime: false}

It's the runtime: false part that's crucial - with that set, the dependency is not going to be a runtime dependency and it won't be bundled in a release. The macros in Gradient.TypeAnnotation are written carefully to make sure that's possible - i.e. there's no code there that actually needs to be shipped with the release, all is taken care of at compile time.
How does one make sure? Let's consider this:
09:44:23 erszcz @ x6 : ~/work/esl/gradient (main *%)
$ cd examples/typed_gen_server
09:44:46 erszcz @ x6 : ~/work/esl/gradient/examples/typed_gen_server (main *)
$ rm -rf _build/dev/rel
09:44:52 erszcz @ x6 : ~/work/esl/gradient/examples/typed_gen_server (main *)
$ mix release
* assembling typed_gen_server-0.1.0 on MIX_ENV=dev
* skipping runtime configuration (config/runtime.exs not found)

Release created at _build/dev/rel/typed_gen_server!

    # To start your system
    _build/dev/rel/typed_gen_server/bin/typed_gen_server start

Once the release is running:

    # To connect to it remotely
    _build/dev/rel/typed_gen_server/bin/typed_gen_server remote

    # To stop it gracefully (you may also send SIGINT/SIGTERM)
    _build/dev/rel/typed_gen_server/bin/typed_gen_server stop

To list all commands:

    _build/dev/rel/typed_gen_server/bin/typed_gen_server

09:44:56 erszcz @ x6 : ~/work/esl/gradient/examples/typed_gen_server (main *)
$ _build/dev/rel/typed_gen_server/bin/typed_gen_server start_iex
Erlang/OTP 25 [erts-13.0.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]

Interactive Elixir (1.13.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(typed_gen_server@x6)1> {:ok, srv} = Server.start_link()
** (UndefinedFunctionError) function Server.start_link/0 is undefined (module Server is not available)
    Server.start_link()
iex(typed_gen_server@x6)1> alias TypedGenServer.Stage2.Server
TypedGenServer.Stage2.Server
iex(typed_gen_server@x6)2> {:ok, srv} = Server.start_link()
{:ok, #PID<0.664.0>}
iex(typed_gen_server@x6)3> Server.echo(srv, "payload")
"payload"
iex(typed_gen_server@x6)4> l(Gradient)
{:error, :nofile}
iex(typed_gen_server@x6)5> l(Gradient.TypeAnnotation)
{:error, :nofile}
iex(typed_gen_server@x6)6>

As we can see above, Gradient is not part of the release. Please note that Server.echo uses the annotation:
  @spec echo(t(), String.t()) :: String.t()
  def echo(pid, message) do
    case annotate_type(GenServer.call(pid, {:echo_req, message}), Contract.Echo.res()) do
      # case call_echo(pid, message) do
      ## Try changing the pattern or the returned response
      {:echo_res, response} -> response
    end
  end

But the annotation gets compiled away on release creation, before the release is run.
@xxdavid are you convinced by this explanation? :)

@xxdavid Specifically, I'm wondering if you have run into any issues caused by runtime: false or by having/not having access to Gradient where you expect it.

Hi @erszcz, I agree that we shouldn't hurry this decision, and it's better to think it over.
So first, let's summarise what the runtime: false does. The Elixir documentation seems quite mysterious to me (taken from mix deps docs):

:runtime - whether the dependency is part of runtime applications. If the :applications key is not provided in def application in your mix.exs file, Mix will automatically include all dependencies as a runtime application, except if runtime: false is given. Defaults to true.

I interpret it as that the application of the dependency will not be automatically started before my app starts. This is in agreement with two Stack Overflow answers on this topic (1, 2).
The dependency is still considered when compiling, though. It is compiled alongside the project. The project can use its macros, and they will be evaluated (is this the right word?) during my app compilation. My app can also make calls to the dep, and it will work when running the app with iex -S mix.
However, as you say, it appears that the dependency is not included in releases built with mix release. I haven't found any mention of it in the docs though. This comment suggests that Destillery does not bundle such dependencies either.
From all of the above, it seems that it is safe to use runtime: false for Gradient, and that we want to do so.

Now let's focus on the meaning of :only in the dependency specification. Here's what the official docs says:

:only - the dependency is made available only in the given environments, useful when declaring dev- or test-only dependencies; by default the dependency will be available in all environments. The value of this option can either be a single environment (like :dev) or a list of environments (like [:dev, :test])

This means that the dependency won't be compiled at all in other environments (like prod), and it even needs not to be downloaded (when using mix deps.get with --only). The fact that it is not considered when compiling implies that if we use macros from the dep, the compilation will fail in environments not in the :only list.
Let's see it in action. In a dummy project I list the dependency with {:gradient, github: "esl/gradient", only: [:dev, :test], runtime: false}.
$ git clone https://github.com/xxdavid/gradient_test_project
$ cd gradient_test_project
$ git checkout dependency_params

~/Development/elixir/gradient_test_project on  dependency_params ⌚ 22:05:36
$ MIX_ENV=prod mix compile
Compiling 1 file (.ex)

== Compilation error in file lib/gradient_test_project.ex ==
** (CompileError) lib/gradient_test_project.ex:2: module Gradient.TypeAnnotation is not loaded and could not be found
    (elixir 1.13.2) expanding macro: Kernel.use/1
    lib/gradient_test_project.ex:2: GradientTestProject (module)

~/Development/elixir/gradient_test_project on  dependency_params ⌚ 22:05:59
$ MIX_ENV=prod mix release
Compiling 1 file (.ex)

== Compilation error in file lib/gradient_test_project.ex ==
** (CompileError) lib/gradient_test_project.ex:2: module Gradient.TypeAnnotation is not loaded and could not be found
    (elixir 1.13.2) expanding macro: Kernel.use/1
    lib/gradient_test_project.ex:2: GradientTestProject (module)

~/Development/elixir/gradient_test_project on  dependency_params ⌚ 22:06:21
$ mix compile
===> Analyzing applications...
===> Compiling gradualizer
==> gradient
Compiling 19 files (.ex)
Generated gradient app
==> gradient_test_project
Compiling 1 file (.ex)
Generated gradient_test_project app

Therefore, I think we cannot use :only with Gradient if we want to use macros from it. This is where the new package, say gradient_runtime (although I don't really believe it is a good name anymore), would be beneficial. We could have deps like this:
  defp deps do
    [
      {:gradient, github: "esl/gradient", only: [:dev, :test], runtime: false}, # or maybe only :dev?
      {:gradient, github: "esl/gradient_runtime", runtime: false}
    ]
  end

This would mean that in production, Gradient and Gradualizer would not be compiled, and thus not needed at all (in prod). It is arguable that it is worth it though. When I created the issue, I thought that :only is what controls whether the dependency is bundled or not (but it is the :runtime option instead). With runtime: false doing what it does, I no longer think it is such an issue.

Thanks for a thorough response, @xxdavid. I see your point with adding Gradient just with only: [:dev, :test] and gradient_runtime with only: [:prod]. Let me check if all that works as expected when put together with what we have in #148.
A simple solution would have been to just drop only: ... altogether, but given @luk-pau-es has already done the work in #148 there's no reason not to use this optimisation.

@erszcz, hmm, just a quick note. I am not sure but I don't think that only: [:prod] would work in dev environment (and others like test). Don't you think?

Indeed, we get quite a clear warning about that. For the context, I did the following - Gradient mix.exs (Gradient requires its runtime all the time):
      {:gradient_runtime, github: "esl/gradient_runtime", runtime: false},

examples/typed_gen_server/mix.exs (a user project requires the runtime only in prod, in the other profile we rely on Gradient pulling it in):
      {:gradient_runtime, github: "esl/gradient_runtime", only: [:prod], runtime: false},

This results in:

Thanks for the idea @xxdavid  and for the PR @luk-pau-es!

I am testing whether everything works now and I am not sure whether gradient should depend on gradient_macros. I think it should not. If it does and you don't specify it directly in your project (declaring only {:gradient, github: "esl/gradient", only: [:dev], runtime: false}), the macros are not used in production compilation:
$ MIX_ENV=prod mix compile
Compiling 1 file (.ex)

== Compilation error in file lib/gradient_test_project.ex ==
** (CompileError) lib/gradient_test_project.ex:2: module Gradient.TypeAnnotation is not loaded and could not be found
    (elixir 1.13.2) expanding macro: Kernel.use/1
    lib/gradient_test_project.ex:2: GradientTestProject (module)

Moreover you get a compilation warning in dev:
$ mix compile
==> gradient_macros
Compiling 2 files (.ex)
Generated gradient_macros app
===> Analyzing applications...
===> Compiling gradualizer
==> gradient
Compiling 18 files (.ex)
Generated gradient app
==> gradient_test_project
Compiling 1 file (.ex)
warning: Gradient.TypeAnnotation.__using__/1 defined in application :gradient_macros is used by the current application but the current application does not depend on :gradient_macr
os. To fix this, you must do one of:

  1. If :gradient_macros is part of Erlang/Elixir, you must include it under :extra_applications inside "def application" in your mix.exs

  2. If :gradient_macros is a dependency, make sure it is listed under "def deps" in your mix.exs

  3. In case you don't want to add a requirement to :gradient_macros, you may optionally skip this warning by adding [xref: [exclude: [Gradient.TypeAnnotation]]] to your "def projec
t" in mix.exs

  lib/gradient_test_project.ex:2: GradientTestProject

warning: Gradient.TypeAnnotation.assert_type/2 defined in application :gradient_macros is used by the current application but the current application does not depend on :gradient_ma
cros. To fix this, you must do one of:

  1. If :gradient_macros is part of Erlang/Elixir, you must include it under :extra_applications inside "def application" in your mix.exs

  2. If :gradient_macros is a dependency, make sure it is listed under "def deps" in your mix.exs

  3. In case you don't want to add a requirement to :gradient_macros, you may optionally skip this warning by adding [xref: [exclude: [Gradient.TypeAnnotation]]] to your "def projec
t" in mix.exs

  lib/gradient_test_project.ex:14: GradientTestProject.my_info/0

On the other hand, if you do declare it in your project like this:
      {:gradient, github: "esl/gradient", only: [:dev], runtime: false},
      {:gradient_macros, github: "esl/gradient_macros", runtime: false}

you get a dependency collision:
$ mix deps.get
* Getting gradient (https://github.com/esl/gradient.git)
remote: Enumerating objects: 3292, done.
remote: Counting objects: 100% (717/717), done.
remote: Compressing objects: 100% (246/246), done.
remote: Total 3292 (delta 491), reused 559 (delta 431), pack-reused 2575
Receiving objects: 100% (3292/3292), 848.70 KiB | 4.96 MiB/s, done.
Resolving deltas: 100% (1876/1876), done.
* Getting gradient_macros (https://github.com/esl/gradient_macros.git)
remote: Enumerating objects: 41, done.
remote: Counting objects: 100% (41/41), done.
remote: Compressing objects: 100% (29/29), done.
remote: Total 41 (delta 14), reused 30 (delta 7), pack-reused 0
origin/HEAD set to main
* Getting gradualizer (https://github.com/josefs/Gradualizer.git - 5567a23)
remote: Enumerating objects: 7555, done.
remote: Counting objects: 100% (573/573), done.
remote: Compressing objects: 100% (209/209), done.
remote: Total 7555 (delta 403), reused 492 (delta 362), pack-reused 6982
Receiving objects: 100% (7555/7555), 4.44 MiB | 8.40 MiB/s, done.
Resolving deltas: 100% (5249/5249), done.
Dependencies have diverged:
* gradient_macros (https://github.com/esl/gradient_macros.git)
  the dependency gradient_macros in mix.exs is overriding a child dependency:

  > In mix.exs:
    {:gradient_macros, [env: :prod, git: "https://github.com/esl/gradient_macros.git", runtime: false]}

  > In deps/gradient/mix.exs:
    {:gradient_macros, [only: [:dev], env: :prod, git: "https://github.com/esl/gradient_macros.git", ref: "bf5a066", runtime: false]}

  Ensure they match or specify one of the above in your deps and set "override: true"
** (Mix) Can't continue due to errors on dependencies

I think that we could solve this issue by gradient not depending on gradient_macros. Projects would have to declare both of the dependencies explicitly but I think this is okay. What do you think?

Hey, @xxdavid!
If we don't make gradient_macros a Gradient dependency, then it'll be quite hard to test the functionality in the package, as it's now moved completely out of Gradient into the package, not duplicated in Gradient and in the package.
To avoid the issue in projects intending to use Gradient the key is to configure Mix envs appropriately:
      {:gradient, github: "esl/gradient_macros", only: [:dev], runtime: false},
      {:gradient_macros, github: "esl/gradient_macros", only: [:test, :prod], runtime: false}

This should address the issue you're describing. Could you check if it works for you?

Hi @erszcz, sorry for a longer response time.

If we don't make gradient_macros a Gradient dependency, then it'll be quite hard to test the functionality in the package, as it's now moved completely out of Gradient into the package, not duplicated in Gradient and in the package.

Sounds reasonable. Making gradient not dependent on gradient_macros is probably not the right way.

To avoid the issue in projects intending to use Gradient the key is to configure Mix envs appropriately:
      {:gradient, github: "esl/gradient_macros", only: [:dev], runtime: false},
      {:gradient_macros, github: "esl/gradient_macros", only: [:test, :prod], runtime: false}

This should address the issue you're describing. Could you check if it works for you?

Unfortunately, this does not work either.
$ mix deps.get
* Getting gradient (https://github.com/esl/gradient.git)
remote: Enumerating objects: 3382, done.
remote: Counting objects: 100% (807/807), done.
remote: Compressing objects: 100% (291/291), done.
remote: Total 3382 (delta 537), reused 627 (delta 470), pack-reused 2575
Receiving objects: 100% (3382/3382), 873.60 KiB | 5.75 MiB/s, done.
Resolving deltas: 100% (1922/1922), done.
* Getting gradient_macros (https://github.com/esl/gradient_macros.git)
remote: Enumerating objects: 41, done.
remote: Counting objects: 100% (41/41), done.
remote: Compressing objects: 100% (29/29), done.
remote: Total 41 (delta 14), reused 30 (delta 7), pack-reused 0
origin/HEAD set to main
* Getting gradualizer (https://github.com/josefs/Gradualizer.git - 5567a23)
remote: Enumerating objects: 7589, done.
remote: Counting objects: 100% (607/607), done.
remote: Compressing objects: 100% (218/218), done.
remote: Total 7589 (delta 428), reused 522 (delta 387), pack-reused 6982
Receiving objects: 100% (7589/7589), 4.48 MiB | 6.09 MiB/s, done.
Resolving deltas: 100% (5268/5268), done.
Dependencies have diverged:
* gradient_macros (https://github.com/esl/gradient_macros.git)
  the dependency gradient_macros in mix.exs is overriding a child dependency:

  > In mix.exs:
    {:gradient_macros, [env: :prod, git: "https://github.com/esl/gradient_macros.git", only: [:prod, :test], runtime: false]}

  > In deps/gradient/mix.exs:
    {:gradient_macros, [only: [:dev], env: :prod, git: "https://github.com/esl/gradient_macros.git", ref: "bf5a066", runtime: false]}

  Ensure they match or specify one of the above in your deps and set "override: true"
** (Mix) Can't continue due to errors on dependencies

However, the following combination works:
      {:gradient, github: "esl/gradient", only: [:dev], runtime: false},
      {:gradient_macros, github: "esl/gradient_macros", runtime: false, override: true}

It doesn't seem very clean though (because of the override: true). But I don't see any other option, unless we wan't to revert the change. What do you think about it?

@erszcz What do you think about this?

I came around this issue again. To summarise, if we want to use assert_type and annotate_type macros in production code, we have two options.
Either we can declare only gradient as a dependency, but for all envs (I previously wrote that this causes compilation warnings but that was probably some cache-related issue):
      {:gradient, github: "esl/gradient", runtime: false},

Or we can use this combination:
      {:gradient, github: "esl/gradient", only: [:dev], runtime: false},
      {:gradient_macros, github: "esl/gradient_macros", runtime: false, override: true}

The first variant has the drawback that both gradient and gradualizer packages are downloaded and compiled on all envs (even when it is not needed). The second one on the other hand has the override: true which is also not very nice. Not sure which option is better. But both of them work and both of them exclude gradient, gradient_macros and gradualizer from releases (with mix release), which is good.


Test Coverage

Reason/Context
We must make sure developers do not waste time manually testing different things while contributing to the project.
Add tests using mocha and node core assertions.
RequestHandler

Checks for createReqHandler() for  mqtt protocol.
Checks for startOperations (id,selectedProtocol)

mqttHandler

Checks for creating new handler instance

cli

Checks if input loop for scenario and asyncapi file is valid.

partially progressed by #39


Update README.md

Fix named parameter 'errorMessage' isn't defined error in  FormBuilderValidators.requiredTrue for FormBuilderCheckBox validator.
The 'errorMessage' parameter is renamed to the correct name 'errorText' instead.

Thanks for your contribution @ephrimlawrence.
You're the best.

Thanks for your contribution @ephrimlawrence.
You're the best.

@danvick  Thank you too. You library has made my work very easy :+1:


support for

either carlo nor puppeteer didn't support <webview> tag, is any method to get it work?

Web Components?

https://developer.chrome.com/apps/tags/webview  tag from chrome apps

Would IFRAME work for you?

nope, I have to interact directly with web page for more control.


Blogpost: Outreach Jan 2024

Thanks a lot for the write-up!

Please reduce the size of the images for faster page load and slimmer Git repo
The images don't show up in my local preview

Should be better now. Main problem is that I had added the "uncompressed" photos.
I also changed from jp2 to jpg, maybe that helps with the rendering.

Thanks! Now one image renders. The other doesn't. Please try to preview it on your side.

Looks like I forgot to git add one of the images

Thanks! And the persons on the photos are OK to be there? If yes, then ready to merge. Thank you again!

Okay from my side.

I've gotten the pictures approved.
I don't have write access so I can't merge

You just got an invite to a team/group. After accepting you can merge.


not creating tables on first run (linux)

Empty database after first run

Hello!
Have you created the database in MySQL first?
When you run command sudo node server.js the system will require to enter database information
If you need help with installation please contact us on<EMAIL_ADDRESS>


Collections disregard Material design spec

At current state, collections are mostly unusable for almost every case a list would be used.

It isn't supposed to have borders

The List spec doesn't even mention the word "border".

It isn't supposed to have full-bleed dividers for every item by default

The Dividers spec clearly states you shouldn't overuse full-bleed dividers:

Collections should not decide anything about dividers, it should be up to the client to create and use them inside lists (pretty much like creating a .divider element inside a collection).

First, Materialize is a great library, kudos to the team who built it.
However, I agree with @13k "collections" doesn't follow the material design spec. In fact, it really should be called Lists, no?

See https://github.com/Dogfalo/materialize/pull/4727

nice! I suppose we can close this one then?

I would keep it open until we have discussed, if want to merge or declined the PR.

Quick Q: Is this refactor going to bring the sidebar's list stuff in line with the rest of materialize? I've been really frustrated lately juggling between collections and sidebar lists that contain the same content but have totally different capabilities. Collections feel so limited, I can't even get links to work with secondary content, whereas the sidebar list just works.

I'm cleaning up my open issues and this one seems like it's stale/fixed. Feel free to reopen if this is a mistake.


option to choose replacement colour

Hi, currently transparency is replaced by black colour, it would be great if there will be an option to change that to other colours (e.g.. white)

agreed.


kitchen test very slow

I'm using the following .kitchen.yml:
---
driver:
  name: docker
  use_sudo: false
  privileged: true

platforms:
  - name: ubuntu-16.10

provisioner:
  name: salt_solo
  salt_install: apt
  salt_bootstrap_url: https://bootstrap.saltstack.com
  formula: honey
  state_top:
    base:
      '*':
        - honey
  pillars:
    top.sls:
      base:
        '*':
          - honey

suites:
  - name: default
    provisioner:
      pillars-from-files:
        honey.sls: pillar.example

verifier:
  name: shell
  remote_exec: false
  command: testinfra -vvv --connection=docker --hosts=root@$KITCHEN_CONTAINER_ID --junit-xml junit-$KITCHEN_INSTANCE.xml test/integration/$KITCHEN_SUITE

However every time I run bundle exec kitchen test it will re-run the salt bootstrap. It takes sooo much time.
Is it possible to cache that operation?
Thanks

kitchen test will run through all the steps (create, converge, verify, destroy). If you are actively working on a formula, just do kitchen converge Or if you just want to check the verifier do a kitchen verify neither of those steps will provision or destroy the VMs that get created. When you are all done, do a kitchen destroy followed by a kitchen test to ensure it passes your CI.

@cmarzullo is absolutely right on breaking down your development to converge and verify.
I use the vagrant driver, and one trick I use is to build my own vagrant boxes using packer. I pre-install the latest version of Salt, Chef, busser, and the busser modules I use—serverspec and bash. I have a Jenkins job setup to do this so whenever a new version of Salt comes out I can easily rebuild the boxes. For packer templates I highly recommend boxcutter project. I use the Ubuntu, macOS, and Windows projects to build my boxes. I don't know if this will help with your docker setup, but for others following this thread it may be a useful technique.

@barkingfoodog Do you have an example json file that you can share for building a machine with packer having salt preinstalled ?
Thanks

@alem0lars-yoroi the boxcutter projects used to offer a CM_TOOL setting that would pre-install Salt, Chef, Puppet, and Ansible. I've forked these to our internal Bitbucket server and use the same technique to install Salt. The current boxcutter projects, except Windows, designate a custom-script.sh you can use to pre-install Salt or do anything else you want. But, you can still go back to those older versions to see how they installed Salt.
The last release for Ubuntu that supported pre-provisioning the box with Salt was 2.0.18. The macOS project doesn't have releases, but it looks like this commit was the last one to support CM_TOOL. The Windows project still supports CM_TOOL to pre-install Salt.
In short this technique adds a provisioner that runs a script to install Salt. It's included with others that install updates, guest additions for the VM provider, and so on. Here's an relevant excerpt of the packer json file from the 2.0.18 release for Ubuntu:
"provisioners": [
    {
      "environment_vars": [
        "CM={{user `cm`}}",
        "CM_VERSION={{user `cm_version`}}",
        ...
        "no_proxy={{user `no_proxy`}}"
      ],
      "execute_command": "echo '{{ user `ssh_password` }}' | {{.Vars}} sudo -E -S bash '{{.Path}}'",
      "scripts": [
        "script/update.sh",
       ...
        "script/cmtool.sh",
       ...
        "script/cleanup.sh"
      ],
      "type": "shell"
    }

On Ubuntu, script/cmtool.sh simply calls the standard bootstrap installer:
wget -O - http://bootstrap.saltstack.org | sudo sh

On macOS, I install homebrew and use that to install Salt. If you need a copy of that script I'm happy to make it available.
The Windows build uses a cmtool.bat script that downloaded the current installer and installs it. You can find a current copy on my boxcutter/windows fork.
I'm a little confused as to what you mean by pre-installing .kitchen.yml. Normally you have .kitchen.yml in your dev environment. Test Kitchen uses the settings in this file to create boxes and provision and test them using different providers, such as SaltStack. But, the .kitchen.yml file isn't needed directly in the test environment.

@barkingfoodog Thanks very much.
Anyways, I'm going to close the issue (false positive)
Thanks everyone!


Proposal: CSS Custom Properties to make styling more accessible

This solution greatly improves clarity and allows beginners to make basic aesthetic changes without having to search for selectors, go into dev tools, etc. I've read the manifesto in the docs, and I think this would be helpful for generating early positive feedback for new users getting their feet wet with programming.
Example:
These is currently how we set the colors:
/* main_old.css */
body {
  color: #aaa;
}
.dimmed {
  color: #666;
}
.normal {
  color: #999;
}
.bright {
  color: #fff;
}

With custom properties, we would set the defaults in main.css
/* main.css */
:root {
    --grid-gap: 2rem;
    --color-text-body: #aaa;
    --color-text-bright: #fff;
    --color-text-normal: #999;
    --color-text-dimmed: #666;
}
body {
 color: var(--color-text-body);
}
.dimmed {
  color: var(--color-text-dimmed);
}
.normal {
  color: var(--color-text-normal);
}
.bright {
  color: var(--color-text-bright);
}

and if a beginner wanted to make adjustments, they could use custom.css.sample (similar to how the sample config is used):
/* custom.css */
:root {
    --grid-gap: 2rem;
    --color-text-body: blue;
    --color-text-bright: #fff;
    --color-text-normal: #999;
    --color-text-dimmed: #666;
}

If it were up to me, I would actually just include a custom.css by default with some comments on how it works, but that's your call.
The custom variable for blue text in custom.css. overrides the defaults (#aaa) set in main.css like so:

So you can see here that all a beginner would need to do was change --color-text-body: to start personalizing their MM. I plan to include add variables for text sizes and fonts to make it easier to tinker with all the stuff you might want to change. I'm already planning on doing some of this for my own benefit but I thought it might be helpful to the community if I shared the work.
Cheers!

I like this idea, especially since I had that planned too (https://github.com/MichMich/MagicMirror/compare/master...rejas:custom_properties) But didnt follow it through with not enough time these days, so I'd be happy to see someone else code it  ;-)
Anyway, I am in favor of this. Like you wrote, it is easier for beginner to change the looks of MM. Plus it would be nice if Module developers would pick it up for their styles too.

but it can't be custom.css or any file owned my MM in the live path   we already went thru overlaying the users custom.css file...
(sample is good, but another file people wont see)

It sounds like a good idea. I'm all in favor of the css changes.
Regarding the custom.css: we had an issue where it was part of the repo which resulted in conflicts when users modified it.
We ended up removing it from the repo and adding it into the .gitignore list.
What could be an option though is adding a check to the startup sequence of the mirror to see if the custom.css file exists. And if not, generate one (which won't be tracked by git).
If someone makes PR's for this my suggestion is to separate these two changes in two separate PR's. We have to test and discuss the second one before and if we want to merge it.

I guess the OP didnt know about the custom.css history ;-)IBut he has made a good propoal:

and if a beginner wanted to make adjustments, they could use custom.css.sample (similar to how the sample config is used):

That is the more sensible idea and fits indeed nicely the other sample MM has.

--grid-gap: 2rem;

Are you planning on making this customaziable too? 'cause I think font size and colors seems reasonable and managable for a first PR, but grid-gap and other padding/margins would (if at all) better fit in a later PR once we get a hang of these.

Agree on the grid gap. Lets take it step by step.

Yep yep, will save layout changes for later. Not super comfortable with building a startup sequence so I’ll let somebody take that one on. Thanks all 🙂

Yep yep, will save layout changes for later. Not super comfortable with building a startup sequence so I’ll let somebody take that one on. Thanks all 🙂

I think you can ignore that startup sequence idea anyway, right @MichMich ?

Yeah that's ok.

What could be an option though is adding a check to the startup sequence of the mirror to see if the custom.css file exists. And if not, generate one (which won't be tracked by git).

Regarding the check in the start up sequence:

Shall we just generate an empty custom.css file if there does not exist one ?
And in case the mirror gets restarted - we then just use the (maybe empty) generated file from the previous start, right ?

Currently the console of the browser console reports that the MM can not find the custom.css file, since the reason mentioned above, right ?
Once the main.css uses variables it would be possible to provide a custom.css.sample file - similar to the config.js.sample file.

if u used the automated installer it will create custom.css
https://github.com/sdetweil/MagicMirror_scripts#install-magicmirror

Oh okay, cool!
This might be the reason... I followed the manual installation guide given here:
https://docs.magicmirror.builders/getting-started/installation.html#manual-installation

the alternative install tools  are listed after manual install

Merged!


wrong WS2812FXStripSettings.stripSize

I am trying to use mclightning with a matrix of 48 by 27 LEDs (=1296 LEDs). But I got a wrong pixel count information when I run the code. The UART Output shows first the correct number (1296) but later on the last digit is cut off (129):
...
Reading neoconfig file... Opened!
Config:  Parsed!
{"pixel_count":1296,"rgb_order":82,"pin":14}Reading config file... Opened!
Config:  Parsed!
...
then later:
...
E1.31 mode setup complete.
Read cfg: {"mode":1,"strip_mode":0,"brightness":15,"speed":255,"red":255,"green":168,"blue":13} Success!
*WM: freeing allocated params!
Saving Strip cfg: {"pixel_count":129,"rgb_order":82,"pin":14}
...
I looked through the code an insert NUMLEDS as strip size in line 260 of McLighning.ino
void initStrip(uint16_t stripSize = NUMLEDS, neoPixelType RGBOrder = WS2812FXStripSettings.RGBOrder, uint8_t pin = WS2812FXStripSettings.pin){
instead of
void initStrip(uint16_t stripSize = WS2812FXStripSettings.stripSiz, neoPixelType RGBOrder = WS2812FXStripSettings.RGBOrder, uint8_t pin = WS2812FXStripSettings.pin){
as a quick fix.
It seems to work, but I think this is not the root cause of my problem.
Does anyone know how why the pixel count information is wrong in my case?

@Talumux How did you set the number of LEDs? Using REST API?
http://YOUR_MCL_IP/pixelconf?ct=1296

@toblum  I edited the definitions.h and set #define NUMLEDS 1296

@Talumux Could you please try and set the number of LEDs using the call is posted above?

Hi, I set the number of LED using the pixelconf?ct=1296 command.
After that all LEDs are working as expected.  But after a reset (example power off), the wrong pixel size of 129 ist restored. The Output via Uart is (see the last line!):
`FS File: /neoconfig.json, size: 44B
FS Usage: 1004/957314 bytes
Reading neoconfig file... Opened!
Config:  Parsed!
{"pixel_count":1296,"rgb_order":82,"pin":14}Reading config file... Opened!
Config:  Parsed!
{"mqtt_host":"","mqtt_port":"","mqtt_user":"","mqtt_pass":""}WiFiManager config FS Read success!
*WM: Adding parameter
*WM: host
*WM: Adding parameter
*WM: port
*WM: Adding parameter
*WM: user
*WM: Adding parameter
*WM: pass
*WM: Adding parameter
*WM: strip_size
*WM: Adding parameter
*WM: led_pin
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
Saving Strip cfg: {"pixel_count":1296,"rgb_order":82,"pin":14}
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: <IP_ADDRESS>
SaveConfig is False!
WiFiManager config FS Save failure!
connected...yeey :)
Open http://<IP_ADDRESS>/ to open McLighting.
Use http://LEDTable.local/ when you have Bonjour installed.
New users: Open http://<IP_ADDRESS>/upload to upload the webpages first.
E1.31 mode setup complete.
Couldn't find "/stripstate.json"
Failure!
*WM: freeing allocated params!
SET_MODE: 0 0
Saving Strip cfg: {"pixel_count":129,"rgb_order":82,"pin":14}
`

Hi @Talumux,
it seems like the config file couldn't be stored. What is returned when you call:
http://<YOUR_MCL_IP>/list?dir=/
Regards
Tobias

when I execute http://<YOUR_MCL_IP>/list?dir=/  I receive
[{"type":"file","name":"config.json"},{"type":"file","name":"stripstate.json"},{"type":"file","name":"neoconfig.json"}]

This looks OK. And what do you get when you call: http://<YOUR_MCL_IP>/neoconfig.json

Hi Tobias,
the output of http://<YOUR_MCL_IP>/neoconfig.json is various. After a reset the output is
{"pixel_count":129,"rgb_order":82,"pin":14}. After executing http://YOUR_MCL_IP/pixelconf?ct=1296 the output is {"pixel_count":1296,"rgb_order":82,"pin":14}
Thanks for your ideas so far!

Maybe you can have a look at the following output.
I set /pixelconf?ct=1296
I checked /list?dir=/
I checked /neoconfig.json
I did a hw reset (e.g. I opened the Arduino Serial monitor again) and get the following output
FS File: /style.css, size: 489B
FS File: /stripstate.json, size: 86B
FS File: /neoconfig.json, size: 44B
FS Usage: 2761/957314 bytes
Reading neoconfig file... Opened!
Config:  Parsed!
{"pixel_count":1296,"rgb_order":82,"pin":14}Coudnt find config.json
WiFiManager config FS Read failure!
*WM: Adding parameter
*WM: host
*WM: Adding parameter
*WM: port
*WM: Adding parameter
*WM: user
*WM: Adding parameter
*WM: pass
*WM: Adding parameter
*WM: strip_size
*WM: Adding parameter
*WM: led_pin
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
Saving Strip cfg: {"pixel_count":1296,"rgb_order":82,"pin":14}
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: <IP_ADDRESS>
SaveConfig is False!
WiFiManager config FS Save failure!
connected...yeey :)
Open http://<IP_ADDRESS>/ to open McLighting.
Use http://LEDTable.local/ when you have Bonjour installed.
New users: Open http://<IP_ADDRESS>/upload to upload the webpages first.
E1.31 mode setup complete.
Read cfg: {"mode":1,"strip_mode":1,"brightness":196,"speed":196,"red":67,"green":172,"blue":255} Success!
*WM: freeing allocated params!
Saving Strip cfg: {"pixel_count":129,"rgb_order":82,"pin":14}

Hi @Talumux,
I think I found the cause of the issue. The setting was truncted to three numbers, so that 1296 resulted in 129 after restart. The issue should be fixed in the next release 2.2.5.
Many greeting
Tobias

@Talumux I just published the new release: https://github.com/toblum/McLighting/releases/tag/v2.2.5


cleanup code

fix TODO's or make issues of them
#define MAGIC_NUMBERS
improve variable names
...

done most in 0.3.0


Adding links in CONTRIBUTING.md to sub folders and headers mentioned

This small change would make it easier for viewers of the file to find folders and headers mentioned. I will reference a PR to this soon.

My appologizes, I accidently used the wrong issue template


feature: Toggle conform formatting

Did you check the docs?

[X] I have read all the LazyVim docs

Is your feature request related to a problem? Please describe.
I'd like to maunally disable conform formatting for certain files and the  <leader>uf or <leader>uF key bindings only disable LSP formatting, not conform formatting.
Describe the solution you'd like
As I haven't used manually disabling formatting before I'd be fine if the already existing key bindings mentioned above would also disable conform formatting, but this might introduce a change for ppl used to these key bindings, so a dedicated key binding to only disable conform formatting might be better.
Describe alternatives you've considered
Right now, I have to remove the specific conform formatter from the conform config each time I need it, which is not very practical.
Additional context
I tried following the conform documentation for disabling formatting on save, but failed to make it work, as I'm not very good with LazyVim custom config options.

Those keys do actually disable conform formatting as well. I tried with default LazyVim settings in Lua files, which by default uses stylua in conform to format, and when I disabled formatting with <leader>uf it didn't format at all.

That's weird. Here's my noice history when toggling format with <leader>uf, both times is see conform.nvim ***(active)*** regardless that LSP is toggling fine:
   Warn  11:46:50 notify.warn LazyFormat (disabled) # Status
- [ ] global **disabled**
- [ ] buffer **inherit**

# conform.nvim ***(active)***
- [x] **stylua**

# LSP
- [ ] **lua_ls**
   Info  11:46:56 notify.info LazyFormat (enabled) # Status
- [x] global **enabled**
- [x] buffer **inherit**

# conform.nvim ***(active)***
- [x] **stylua**

Maybe it's the way I am configuring  conform ?
return {
  {
    -- https://github.com/stevearc/conform.nvim?tab=readme-ov-file#setup
    -- https://www.lazyvim.org/plugins/formatting#conformnvim
    "stevearc/conform.nvim",
    opts = function()
      local plugin = require("lazy.core.config").plugins["conform.nvim"]
      local opts = {
        -- /home/varac/.local/state/nvim/conform.log
        log_level = vim.log.levels.DEBUG,
        format = {
          timeout_ms = 3000,
          async = false,
          quiet = false,
        },
        ---@type table<string, conform.FormatterUnit[]>
        formatters_by_ft = {
          beancount = { "bean-format" },
          lua = { "stylua" },
          markdown = { "mdformat" },
          -- https://docs.astral.sh/ruff/faq/#is-the-ruff-linter-compatible-with-black
          -- Black is only added to fix long lines, with `--preview` enabled in
          -- `~/pyproject.toml`, because I can't make it work with `ruff format`
          python = { "black", "ruff_format" },
          -- beautysh: last commit 2023-04, defaults to 4 spaces for indentation
          sh = { "shfmt", "shellharden" },
          -- https://www.lazyvim.org/extras/lang/terraform#conformnvim-optional
          terraform = { "terraform_fmt" },
          tf = { "terraform_fmt" },
          ["terraform-vars"] = { "terraform_fmt" },
          -- yamlfix and yamlfmt are both in maintenance mode / slow
          yaml = { "prettier" },
        },
        -- The options you set here will be merged with the builtin formatters.
        -- You can also define any custom formatters here.
        ---@type table<string, conform.FormatterConfigOverride|fun(bufnr: integer): nil|conform.FormatterConfigOverride>
        formatters = {
          injected = { options = { ignore_errors = true } },
        },
      }
      return opts
    end,
  },
}

LazyVim implements its own formatter, which makes use of both conform and lsp. What is important is what you're seeing in status. That is the status of the LazyVim formatter. The easiest thing is to try it out. When I toggle formatting off with <leader>uf, no formatting takes place whatever changes I make to the file. Simple as that.

closing, since toggling formatting works

closing, since toggling formatting works

How could I disable formatting default.

I'm also seeing conform.nvim formatting always shown as "active", even if automatic formatting is indeed disabled.  The screenshot below captures the status displayed after quickly  toggling autoformatting off/on twice in succession:

Is this expected behaviour?

Yes, it's expected behavior. You should be looking at the Status and the title of the window. Those indicate if formatting is enabled or disabled globally or for the buffer. conform will always show as active source except if there's no formatter for a filetype defined and then fall back to the LSP formatting if the LSP server supports it.

Thanks for the clarification!


Add Clear Playlist Button

Clear the playlist array.
Reset Total Duration.
Reload the Page.
Set Title of the page to "Youtube Fast Playlist"

@chamow97 great work! :tada:


Import a .js and redirect to .ts(x)

Feature request

What is the expected behavior?
For TypeScript's new nodenext module resolution (which is still in nightly build), we are required to write a full file name including extension like:
import {foo} from './foo.js';

Even though we have a source code foo.ts or foo.tsx, the file extension on import statement is .js, this results webpack to fail with errors like:
error  in ./src/index.tsx

Module not found: Error: Can't resolve './Boundary.js' in '/Users/otakustay/Develop/react-suspense-boundary/src'

What is motivation or use case for adding/changing the behavior?
We need to satisfy TypeScript's coming nodenext module resolution and be compatible with pure ESM resolve rules
How should this be implemented in your opinion?
Make .js a special case that on resolve webpack could remove the .js part and then do a normal resolve
Another solution is to make resolve.fallback a function so that we can remove .js part before webpack do it's resolve
Are you willing to work on this yourself?
not familiar with this

Duplicate https://github.com/webpack/webpack/issues/13252, current solution https://github.com/webpack/webpack/issues/13252#issuecomment-971922821, maybe we move it in core


In browsers supporting native dialog, click close on backdrop not working

In Chrome/Edge latest, desktop and Android (Chrome iOS works OK), the dialog backdrop does not respond to a click, so it's only poss to close the dialog via keyboard or click on X close button. In Firefox and Safari the overlay does close the dialog with a click. I'm testing with the default example file

Apologies - I've now seen in the closed issues that this problem has already been commented on and solutions suggested.


How can I decrease apk size of FFmpegPlayer

Hi! Is there any way to change the apk size of this player. Now It is 26 Mb. May be delete some libs?

Now we use gradle so you can easly use ABIs Splits "http://tools.android.com/tech-docs/new-build-system/user-guide/apk-splits" and upload multiple apk's to playstore so user will only have libs in architecture for theirs phones.
You can also remove some codecs from ffmpeg build.


On click profile modal should get close

Describe the bug
In the profile menu, when we click on my solutions button, it doesn't close the profile modal
To Reproduce
Steps to reproduce the behavior:

log in to the website
Click on your profile picture
then click on my solutions
See an error

Expected behavior
When we click on my solutions button or outside that profile modal, it should get close.
Screenshots
https://user-images.githubusercontent.com/57035408/136691573-b53e1caf-a8a8-463e-834a-c91f319f094b.mov

@rishipurwar1 can i work on this bro

@programmerraja yes, you can work on this.

@rishipurwar1 Hey Can you please assign it to me? I would like to work on this.

@RashiSingh20 you can work on this

Yes, I created a project on firebase and used the config file . My email id<EMAIL_ADDRESS>@rishipurwar1

@rishipurwar1 hey, recently I implement this in my project. using a simple custom hooks. Can i add this

Yes, You can work on this but I think I already have a setOpen something in the code that will help you in achieving this functionality.

i know. but when we click outside the components , it must be close. For
this I used a custom hooks before.
On Mon, Oct 18, 2021, 11:05 AM Rishi Purwar @.***>
wrote:

@rishipurwar1 https://github.com/rishipurwar1 hey, recently I implement
this in my project. using a simple custom hooks. Can i add this
Yes, You can work on this but I think I already have a setOpen something
in the code that will help you in achieving this functionality.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rishipurwar1/coding-space/issues/138#issuecomment-945380293,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASDJR4SGLYYVVB7UDHPMD3DUHOW3PANCNFSM5FWJ3PPQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You can make use of the same thing for that as well! You need to give a transparent background to the outer div and then that div should occupy the cover the whole content and then add onClick event to that div, so, when the user clicks on the outer part of the modal then it'll run set setIsOpen(false). I did the same for the delete solution button.

okey, got it


chore: jx-k8s-days-go-02 to 0.0.1

chore: Promote jx-k8s-days-go-02 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


First implementation of quotas

So trusted agents have a limited quota of nanopublications that they can publish.

Done with 3f8ab48b290395fc65f0b08f2e5ec31e39002d54.


Add ghcr permissions to dependabot

Hello tcarmet,
My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.
Status report is not available.

Missing Jira issue
It is mandatory to specify a Jira issue in the source branch name
in order to merge into development/3.6. The issue key must follow
the prefix of the branch.
I could not find such an issue in feature/add-dependabot-permission.


fix(android): refactor source, fix random DRM issue and crop start on local asset

Summary
Move source prop in a dedicated class
Motivation
Keep code clean and more split
In the same time I fix:
Also fix a side issue when using a local file cropping props were not applied
Also fix random DRM issue by refactoring initializePlayerSource : https://github.com/TheWidlarzGroup/react-native-video/issues/3082
Prepare another refactor to fix: https://github.com/TheWidlarzGroup/react-native-video/issues/2693 and https://github.com/TheWidlarzGroup/react-native-video/issues/3665
Changes
Move parsing of source in a dedicated class
Rework usage of the source
Rework MediaMetadata initialization (ping @KrzysztofMoch)
merge setSrc and setRawSrc
Add missing clearResumePosition(); in setSrc
improve logs
Test plan
Can be tested with the sample

@freeboub
is there any reason about below changes??
- eventEmitter.error("Failed to initialize DRM Session Manager Framework!", new Exception("DRM Session Manager Framework failure!"), "3003");


adb.exe: error: more than one device/emulatorERROR: "adb reverse" returned with value 1

[ ] I have read the FAQ.

[ ] I have searched in existing issues.

I have read the [FAQ](https://github.com/Genymobile/scrcpy/blob/master/FAQ.md).

I have searched in existing [issues](https://github.com/Genymobile/scrcpy/issues).

Environment

OS: Window11
scrcpy version: 2.2
installation method: from homebrew
device model: OnePlus 6
Android version: 8

Describe the bug
I suceess run redroid
adb connect also suceess in my pc
but scrcpy con't working
adb.exe: error: more than one device/emulatorERROR: "adb reverse" returned with value 1

`"adb reverse" failure followed by the fallback is not an error: #5.
But after that you can't get display info, because the DisplayManager is null. See #932

@rom1v So what should I do？

Unfortunately, if your device has no DisplayManager instance (and probably other missing parts like in #932), I have no solution.

But I succeed before.

It run my PC vmware. Linux version is Ubuntu 22.04._x86. But run in oracle cloud is can not connect.So orcale cloud (Ubuntu 20.04arm64)has no DisplayManager instance? Or my PC has no it?

But I succeed before.

Can you make it work with an older version of scrcpy?

Or my PC has no it?

Your Android device (so "oracle cloud").

But I succeed before.

Can you make it work with an older version of scrcpy?
Both failed

Or my PC has no it?

Your Android device (so "oracle cloud").

But I succeed before.

Can you make it work with an older version of scrcpy?

Or my PC has no it?

Your Android device (so "oracle cloud").

Can you make it work with an older version of scrcpy？
Both failed


Add schemas for plans

Todo

[x] context
[x] discover
[x] prepare
[x] provision
[x] execute
[x] finish
[x] report

Signed-off-by: Miroslav Vadkerti<EMAIL_ADDRESS>

@happz @lukaszachy @psss this now passes for me and validates all available plans.
One thing that is fairly unclear is the role of the core attributes, I would expect they can be part of any fmf node, i.e. a plan, test or story. But according to @lukaszachy they can be in any leaf of the node data??

@psss @lukaszachy @happz this one needs finally review to unblock #1178
I had one discussion topic, but I moved it to #1182 discussion topics, and I guess we will discuss it briefly on the hacking session.

@thrix Please add 'id' to the schema (it was added to the core attributes just recently)

@thrix Please add 'id' to the schema (it was added to the core attributes just recently)

@lukaszachy thanks, added

Thanks much for preparing this. This must have been a lot of work! Looks good in general. Added a bunch of comments and questions.

Thanks for the great review and good eyes, I knew I had to miss some things. Should have looked more on module code, I actually used the documentation, which is not actually mentioning some attributes. I believe it is ready for the next round.
CC @lukaszachy @happz

@lukaszachy @happz @psss addressed all concerns! Thanks for all the comments, feel free to take a look again, happy this finally gets in and unblocks base.py typing

oh my, forgot to squash


DQN mnist & mountain car performance

Hi,
while working on a PyTorch DQN agent for BSuite experiments, I noticed quite bad results on the mnist and mountain car experiments. I see that a similar question was addressed here, but the thread was closed.
To further investigate, I created a new conda environment, downloaded and installed a fresh copy of BSuite and ran the DQN agent from the baselines. The only settings I've changed were "bsuite_id" to "SWEEP" and the save path.
When you compare the results from both agents with the barplot on page 16 of the BSuite manuscript, you notice that both agents have worse performance on mnist and mountaincar and better performance on catch.

Were there any changes on the environments that I missed? The DQN agent from the manuscript did use the default parameters from the baseline directory, correct?
Thanks,
Peter

Hi Peter!
Thanks for raising this... I think we might have seen some slippage in agent performance.
I'm not sure if this has come from updates to:

Tensorflow 1 --> 2
Different parameter settings
Changes to random seed

My suspicion is there are some small details in this migration TF1->TF2 that changed some scores (the agents aren't exactly the same).
We will look into this and then re-run baselines with updated numbers.
Many thanks,
Ian

Hello again!
I have just run the agents checked in at HEAD and I did not see your observed scoring...

We may need to tool in some more continuous testing, but the scores on mnist in particular seem "off" for the DQN implementation.
Can you confirm this is still an issue for you?
Is this poor performance for your implementation of DQN, or the baseline implementation we provide?

I also have a similar observation concerning MountainCar, however it is related to the AC algorithm. To me it seems like there is a major difference between the results reported in the paper (close to 1) versus the ones in this thread (close to 0). I have also tried running actor_critic_rnn on mountain_car and it does not seem to learn (on default hyper params).

Yes @mklissa - I see that difference above.
There have been several moving pieces:

Changes to the bsuite environment (at release MountainCar had gravity the wrong direction)
Changes to agent (migrate from TF1 -> TF2/JAX)

However, I think the best approach is to go from what is at HEAD and start a new issue to update paper/reference colabs to incorporate this bug fix.

Dear Ian,
Thanks for looking into this! Back in march, I observed poor performance on mnist with both the baseline implementation as well as my own implementation of DQN.
Given that mnist seems to work perfectly fine for you, I assume there must be some problem on my side. I will set up a system from scratch and run the baseline implementation of dqn again. It might take a while though until I find time to do that.
Best regards,
Peter

Hi,
I finally found some time to look into the issue. On my laptop, the performance of the baselines tensorflow DQN agent is still quite bad (with a score somewhere around 0.25 in the bar plots above).
I used a fresh install of pop!_os 20.04 (distribution based on Ubuntu) and then performed as few steps as possible to run the agent:

Installed Anaconda
Created a Conda environment with Python 3.7
Steps from the bsuite github page:

pip install --upgrade pip setuptools
pip install bsuite
pip install bsuite[baselines]

Opened bsuite/bsuite/baselines/tf/dqn/run.py, changed the bsuite_id to 'SWEEP' and set the 'verbose' flag to False
python run.py

Hope this helps.
Best regards,
Peter

Ah... OK well I think in order to get the claimed performance, you need to run the dqn.default_agent()
I can see that this is a bit confusing, but we wanted to expose the flags as an easy way for people to tinker!
If you instead fo to baselines/tf/run.py then you should be able to get the same behaviour... is that right?
BTW... do you think we should instead remove the flag options and avoid this kind of confusion?

I would keep the flag options but maybe have the same values as the default agent as default.
As you suggested, I replaced the agent (that uses the flags) with the dqn.default_agent() in run.py and ran the experiments again. Unfortunately no improvement on the mnist experiments.
Best regards,
Peter

Hey there, I'm writing to report that I'm also experiencing the same problem as @pluebcke in MNIST. I couldn't replicate the good MNIST results as reported in the paper. I also noticed a bad performance (0.2-0.26 score at most) using PPO and DQN agents from an external library (stable-baselines), tried different hyper-parameters, number of layers/neurons, activation functions, with no effect. I also checked the MNIST env implementation offered here and seemed OK to me.
Today I created a new virtual env with the latest BSuite version with the baselines, runned the 20 seeds twice and the baseline DQN agent also scored 0.23. This also happens with noise and scale variants.

Hi @jbarsce - I'm not sure I understand the question.
So, are you saying that:
(a) The TF DQN checked into bsuite.baselines is not solving the bandit task for you?
(b) Another agent is unable to solve the MNIST task?
We have some tools for testing this internally within Google/DeepMind... and based on that I'm confident that the bsuite/baselines/jax/dqn and bsuite/baselines/tf/dqn do reproduce the performance.
However... we clearly need to work out a way to share these tests/reproducibility/installation instructions so that this confusion does not arise.

For reference, here is a record of the nightly runs for the TF baselines.
You can see that some of the experiments are a little noisy... but that the DQN TF is consistently reproducing the MNIST results abov.

Hi Ian, thanks for the quick reply! yes, I ran the BSuite experiments with another DQN agent and noticed that, while the other envs performed similar than in the accompanying paper, MNIST was the only that underperformed.
As this external agent had several variations, I tried to replicate the results with the DQN agent from this repo, trying tf and jax and isolating them in a new virtual environment. In case they are of any help, the following were the steps I followed (I took them from the jax and from this repo)

Created a conda environment with python==3.6
pip install --upgrade pip setuptools
pip install bsuite[baselines]

For tensorflow 2.1
I ran the experiments with

python bsuite/bsuite/baselines/dqn/run.py --bsuite_id=MNIST

For jax

pip install git+https://github.com/deepmind/dm-haiku
pip install --upgrade jax jaxlib
pip install git+git://github.com/deepmind/optax.git
pip install git+git://github.com/deepmind/rlax.git
python bsuite/bsuite/baselines/jax/dqn/run.py --bsuite_id=MNIST

Environment: Ubuntu 18.04 bionic
Please let me know if you need any other information. Finally, thanks for this great repository
Juan

Just a wild guess, maybe something went wrong with the download of the input mnist dataset for Juan and me?

Yes interesting... something is getting lost between the version that is checked in to Google3 and the settings you are running.
@yotam @aslanides and I will have a look into this...
Going to keep this open for now and try to reproduce this...

Minimal repro (~10 lines of code ignoring imports): https://colab.research.google.com/drive/1XtTv-p2bXfvMBT_77cWjWRHPXIvimWlO?usp=sharing
Cheers,
Braham

Hi,
Recently, I also started working with Bsuite, which I find a lovely environment to work with. I noticed as well that the results of the MNIST experiment are off. Apparently, you have discussed this issue a while back already. Did you find a solution in the meantime already?
Thanks,
Ilias


Create new release

Hi,
I am currently using a github dep on tokio-diesel to get the changes in #15.
Please bump this crate and push to crates.io.

For additional context to this issue:
From https://docs.rs/tokio/0.2.21/tokio/task/fn.block_in_place.html

Although this function avoids starving other independently spawned tasks, any other code running concurrently in the same task will be suspended during the call to block_in_place. This can happen e.g. when using the join! macro. To avoid this issue, use spawn_blocking instead.

The project I'm working on does make use of try_join!() for db related futures and this implementation does make our joins happen serially.
We are looking into sending queries to a synchronous threadpool to execute instead so we can get our db queries to execute in parallel.

I've also had issues with the current block_in_place implementation. actix_rt defaults to creating a Tokio runtime using the basic scheduler (source), and I can't seem to get it to play nicely with Tokio's multi-threaded runtime. Every call to tokio_diesel (pointing to master) ends up panicking when I use it in my actix-web project.
I'm not sure if such a "bug" would be in-scope for this project, but I think it's important to keep in mind before making a new release.


How to change a looping animation to idle?

What is your question?
Up

I'm pretty sure using playAnim() to tell it to play the idle animation will work just fine

So playAnim(idle)

So for gf, it would be playAnim(‘gf’, ‘idle’)

yes


Improving GradientDesignable implementation

History that bring this issue: #84  / #81
Historically, GradientDesignable wasn't working even if a subview was conforming the protocol. In order to fix this, we moved all the gradient's intelligence directly in the protocol, by creating creating a sublayer directly in the protocol.
That solution is working well for basic usage. We still need to improve it in order to support rotation... and if possible, let GradientDesignable handle everything itself in order to keep the protocol reusable everywhere, without breaking changes.
Any suggestions?

Merge in #87

Final details are discussing, but we can consider this issue fixed.


Reject requirements that are both hashed and editable?

The current requirements parser allows a requirement to specify both --hash ... and -e, despite the two being incompatible and rejected by pip itself (https://github.com/pypa/pip/issues/4995).
IMO, we should probably reject these outright with an exception, or perhaps with an UnparsedRequirement. Thoughts?

We should do whatever pip does, but also keep https://github.com/di/pip-api/issues/121 in mind.


Allow searching for just lemmas or just definitions (I guess: Prop/Sort)

It'd be nice to only be shown lemmas when I'm looking for lemmas, as opposed to other stuff that I don't particularly want; I assume it'd be the same for defs!

Any concrete syntax in mind?

Maybe just "lemma" or "def" as special keywords? That should be fine to special-case I guess

That a reasonable suggestion. If they are “filters” of their own you’d have to comma-searate them, e.g.
theorem, 1 + 1 =2

which probably takes getting used to. Or the syntax could be more liberal and not require a comma after theorem or def.
(Note that lemma is a Mathlib’ism, not a lean keyword. I’ll have to think about whether loogle should be generous or generic here.)

BTW, the current syntax allows this already, although less convenient: You can write
|- (?a : Prop)

to get theorems and
|- (?a : Type _)

to get everything else.


fix dead link

PR Checklist

Please check all that apply to this PR using "x":

[x] I have checked that this PR is not a duplicate of an existing PR (open, closed or merged)
[x] I have checked that this PR does not introduce a breaking change
[ ] This PR introduces breaking changes and I have provided a detailed explanation below

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting)
[ ] Refactoring (no functional changes)
[ ] Documentation changes
[ ] Other - Please describe:

Fixes
Issue Number:
What is the current behavior?
https://www.reddit.com/lbry gives page not found.
What is the new behavior?
It actually goes to the lbry subreddit.
Other information

Thank you!


Repo Readme.md improved

Fixed #147
Made little change in the Contribution section; Please let me know your thoughts;
@DhanushNehru

@ShubhamNagure, can you share your repo valid for hacktoberfest ?


CLI/API access for AWS services

What we're after: Users can inspect/manage AWS-side settings brokered AWS resources without having their own AWS account
Benefits/why:

Enable fine-grained management of the brokered service (eg monitoring, alerting, and read-replica configuration for RDS)

@afeld can you parent any existing stories about this topic onto this feature?

@mogul Added!


[WIP] Create part-1-the-engine.md

Merged locally in https://github.com/thangngoc89/blog/commit/26683c0d7035c5b98e9b15465e2aec482b4e9f27


initial implementation: work in progress

The initial implementation will have the following wallets (we will be taking the code from LNbits as reference):

[ ] CLightningWallet
[ ] LNbitsWallet
[ ] LndWallet (gRPC)
[ ] LndRestWallet (REST)
[ ] LNPayWallet
[ ] LntxbotWallet
[ ] OpenNodeWallet

We need to decide what are the methods we will implement (no need to cover the whole LND API, for example) and what these methods will return.
Error handling and tests need to be contemplated.

I'm a little bit on the fence here but I would tend to favor a broader way of handling errors with exceptions. More power to the developers and allowing applications to manage these as they see fit (viewing conductas a standalone piece of software with a wide range of applications).

I'm a little bit on the fence here but I would tend to favor a broader way of handling errors with exceptions. More power to the developers and allowing applications to manage these as they see fit (viewing conductas a standalone piece of software with a wide range of applications).

Yes, I am leaning towards that too. Raise a comprehensive exception, or return data, and let users decide how to handle these exceptions.

Can we have invoices with description_hash? I need them for lnurl-pay stuff.


It is support yolov7？

It is support yolov7？

There is no pre-made yolov7 in DJL, however you should be able to either implement yolov7 using DJL or import yolov7 from one of our supported engines like PyTorch or Tensorflow into DJL


Add macOS Sierra support

Since only the about box needs High Sierra, it would be nice to include macOS Sierra.

This is great, thank you!


[BUG] No redeployment after updating global parameter

Describe the bug
After a successful deployment using Seedfarmer that uses a reference to a global parameter (i.e. parametersGlobal) in one or more modules, if we change the referenced value in the deployment.yaml file, Seedfarmer won't pick up that change and redeploy affected modules.
To Reproduce
Steps to reproduce the behavior:

Create a global parameter in deployment.yaml, and reference it in one or more modules:

In deployment.yaml:
targetAccountMappings:
[...]
    parametersGlobal:
      foo: bar
[...]

In example-module.yaml:
- name: ecr-repo-tag
    valueFrom:
      parameterValue: foo

Deploy using Seedfarmer:

seedfarmer apply manifests/realm-infra/deployment.yaml --debug

Change that global parameter to any other value:

targetAccountMappings:
[...]
    parametersGlobal:
      foo: baz
[...]

All modules deployed will be up to date (no module redeployment with new global parameter value)

Expected behavior
Seedfarmer redeploys modules that reference that updated global parameter

@gonzalobarbeito Yes, this is as-designed.  Seed-Farrmer and modules are module-centric, in that everything revolves around the module, it's code and metadata.  The global parameters are defined in the deployment.yaml manifest and apply to all modules, but are only metadata that is not taken into the changeset criteria.  This was designed in this fashion b/c a signal to apply changes on a change to the deployment manifest would trigger a redeployment of all modules in the deployment...which is opposite the design methodology.
Leaving this issue open for now....lets debate offline.


One of the Github actions are failing - Important - Disable or remove the Github action Greeting

I noticed that one of the action checks greeting was failing. I am not familiar with Github actions/workflow. But I was trying to look at the logs to see what changed between when it was working and failing
When actions were successful:

When actions began failing:

It looks like an upgrade issue - anyone who is familiar with Github workflow please take a look. I will try some more googling to see what can be done. But this seems to be a show stopper for people trying to commit files. Needs to be looked at right away.

Okay now I feel foolish - even without the checks passing, PRs are being approved and being merged. So yes if it is not that critical, we can let it go. But I was curious as to why it was failing. If someone finds the solution and why the checks were not passing, please mention it as a comment on this issue. And close this issue. Thanks guys!

@Mira-Alf why can't we remove the file @johnjacobkenny


Add meta/cos-light

Drop dependency of elemental-cli on cos-setup which brings the binary
also in unwanted situations. We have metapackages to cover desired
use-scenarios.
Also adds a new meta "cos-light" which ships just static config and a
selection of default cloud-config files. (Context, would be used in os2 to just consume framework configs when switching to SLE Micro for Rancher as base)
See: https://github.com/rancher-sandbox/rancher-node-image/pull/2
Part of: https://github.com/rancher-sandbox/os2/issues/94
Signed-off-by: Ettore Di Giacinto<EMAIL_ADDRESS>

ISO looks good, getting issues using the ova image somehow.. can't seems to import it locally. trying now to debug the image with vbox to see if it fails here..

mh. getting weird issue locally while trying to import the box image:
=> default: Importing base box 'cOS'...
Progress: 90%There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["import", "/home/ettore/.vagrant.d/boxes/cOS/0/virtualbox/box.ovf", "--vsys", "0", "--vmname", "cOS_1652260257555_6699", "--vsys", "0", "--unit", "10", "--disk", "/home/ettore/VirtualBox VMs/cOS_1652260257555_6699/cOS-disk001.vmdk"]

Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting /home/ettore/.vagrant.d/boxes/cOS/0/virtualbox/box.ovf...
OK.
0%...10%...20%...30%...
Progress state: NS_ERROR_INVALID_ARG
VBoxManage: error: Appliance import failed
VBoxManage: error: Code NS_ERROR_INVALID_ARG (0x80070057) - Invalid argument value (extended info not available)
VBoxManage: error: Context: "RTEXITCODE handleImportAppliance(HandlerArg*)" at line 1119 of file VBoxManageAppliance.cpp


fix: configure logger instance only once

By now the logger instance is configured on every LOG_XXXX macro invocation, thus the message Lib log level: X is printed to stdout quite often.

Thanks for your contribution


Couldn't change the column name when editing the dataset

I am using 2.1.0 (development server) and have deployed Superset on EC2. I tried to change the column names to be different from the ones in the database when I created the chart using the physical dataset, but it looks like there is no drop down option for 'column' in 'Edit Dataset' -> 'COLUMNS' that I can type in the name in 'Label'. I even used Admin account, but still has the same issue. How can I fix it?
It should be like this:

In my UI:

You can use Label as you've surmised, but if you want to change what comes out of the database, you should do it at the query or virtual dataset (also a query) and SELECT foo as bar. Hope that helps!


Navigation drawer header UI fix

Describe the bug
Previously the header in navigation drawer was blank with unwanted view object with no appname
To Reproduce
Added Screenshot for this
Expected behavior
Removed unwanted padding and view object from header and added appname with expected padding.
Screenshots

Would you like to work on the issue?
Yes, I would like to work on this.

@adityastic  how can we add codeheat and fix label to it ?

Only the maintainers have the access to do that. Don't worry I'll add them

Thanks


Add AC180P support

Is it possible to add AC180P support?
Logger: homeassistant.config_entries
Source: config_entries.py:406
First occurred: 15:59:42 (1 occurrences)
Last logged: 15:59:42

Error setting up entry AC180P2341000448157 for bluetti_bt
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 406, in async_setup
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/bluetti_bt/__init__.py", line 55, in async_setup_entry
    coordinator = PollingCoordinator(hass, address, device_name, polling_interval, persistent_conn, polling_timeout, max_retries)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/bluetti_bt/coordinator.py", line 153, in __init__
    bluetti_device = build_device(address, device_name)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/bluetti_mqtt/bluetooth/__init__.py", line 28, in build_device
    if match[1] == 'AC200M':
       ~~~~~^^^
TypeError: 'NoneType' object is not subscriptable

Do you see your Powerstation as PBOX in your Bluetooth devices?

I removed your picture because it contained your SN.
You could try the scan command in bluetti_mqtt. In the results we will see what protocol version it uses.

This is it?
discovery_021124124813.log

Yes. That's the information I'm looking for. I'll need some time to check it.
I'll delete the file because this also contains personal info.

Super!
Please check which result matches your Powerstation model below
Result V1:
Result V2:   AC180P

Sorry, I forgot to add the AC180P in the current beta release. I'll add it in the next (probably next friday if I have some spare time).
If you want to do it yourself, just create a new device based on a ProtocolV2Device (AC60 is similar)

I've added basic AC180P support in 0.0.19.
Can you test if the values show up?

Ok, I'll check now

Only two sensors are displayed:
AC180P Total Battery Percent
AC180P Total Power Generation

That's expected for now. Those two are the only ones available on all v2 devices
If I have more time, I can look deeper into the discovery log

The biggest problem with v2 devices are the different amounts of inputs and outputs (f.ex. solar: 2 on EP600, 3 on EP760)

Thank you for adding even this basic integration! It helped me to resolve a very critical issue with this device. Anyone can connect to it using Bluetti app and control it using Bluetooth when there is no any other device connected to it. I live in the apartment block and any of my neighbors could connect to my power station and mess with it.
It seems that it's a hardware bug which can't be fixed even with the firmware update. By connecting my home assistant instance to my station using your integration I was able to block other people from connecting to it (I had to set "Persistent connection" mode for this device, hopefully it's OK).
Now I can sleep peacefully and don't think all the time that someone can turn off my station or even worse - turn on the power lifting mode and damage some of my electronics. Thanks again for your work!


feat(documentation): Add documentation to stories

closes #526

oops 😝 ... it's fine, since we don't build /documentation for our netlify preview

@zvonimirfras example-url is a compodoc thing

Forgot to squash commits 🤦♂


Upgrade ZeroMQ to libzmq 4.3.4

To fix #2149 issue
Replace zeromq4-1 with libzmq version 4.3.4
remove_libstd_link.patch to avoid error on libdogecoinqt build
There are some problem when build this lib using mingw 4.7 on Ubuntu Trusty. I think we should upgrade linux distro on travis-ci & gitian build to at least Ubuntu Xenial. What do you think?

We're changing the build system to 20.04 (which is what bitcoin/bitcoin master uses.) Because this also impacts gitian builds, I will focus on the items in #2321 first, and as soon as those are done and we have a working gitian build, we can cherry-pick this into 1.14.4. I'll mark this as "do not merge" until then.

Potentially this replaces #2236

Closing and reopening to trigger CI

Closing as #2236 now passes tests and this does not, to avoid confusion.


Handle failure of scheduler over long period of time or repeated failure of scheduler

If the scheduler fails at the same time that a node task dies and stops for a significant period of time (more than 5 - 10 minutes) and then starts up, it will try to recover dead node tasks even though they may have been dead for some time. This also could happen in the case of the scheduler restarting over and over.

Zookeeper storage with an in memory cache may be a good solution for this. In fact, refactoring of persistent state to use an in memory cache would be ideal.

Hi, @elingg
I didn't understand "it will try to recover dead node tasks even though they may have been dead for some time".
The persistentstate ( zookeeper state ) may be not consistent with actual state in this situation.  But each time we restart the scheduler, it will clear the zookeeper state based on livestate, right?
And if a node has dead, then Mesos will not offer the resource of this node to hdfs-mesos scheduler,
So why scheduler will try to recover the task in dead node since the ReconcileStateTask has cleared the zookeeper state ?

hi @tangzhankun,
With the current implementation, if a node dies it has 1.5 minutes to recover (this time is configurable). If the scheduler fails over and a node has died while the scheduler is down, then when the scheduler starts up, the node is given 1.5 minutes to recover. This works well, except in cases where the scheduler has been down for a long period of time or continually restarts.

hi @elingg
Thanks a lot for the explanation! I saw the implementation of this 1.5 minutes timeout. The scheduler will not remove the host record from "journalNodes" until timeout. If the host is back during this 1.5 minutes, the scheduler will re-launch the task on the same host if offer.getHostname() in dead node hashmap. This make sense.
But I am still not sure the work flow if the scheduler process is down and restart. Here is my understanding:

the scheduler's run() will execute and then callback registed() will be called.
reconcileTasks() will be called
in reconcileTasks's run() method, persistentState will get all taskId from zookeeper, but liveState.getRunningTasks return an empty hashmap. So the persistentState.removeTaskId(taskId) got executed. then reconcile finished.
Once reconcile finished, the callback resourceOffers will move to JOURNAL_NODES phase. then it will tryToLaunchJournalNode.
If DeadJournalNode is not empty and contains the offer.getHostname, it will call launchNode to launch a new journalnode daemon. If DeadJournalNode is empty, the scheduler will realize that already running 3 journalnodes, so declineOffer.

Based on the steps above, I am confused of the reconcileTasks(). I thought the scheduler should first make the liveState object consistent with the actual zookeeper, like member "runningTasks".  Then call the reconcileTasks(). Because if liveState is not sync with zookeeper, the "runningTasks" is empty, how can correctCurrentPhase works well?
Above all, my questions are (seems a little more :( ):

How can the liveState be synced with actual situation when scheduler restart? if not synced, everything is fine?
Is my above understanding of the call trace right (step1 to 5)?

Corrected Steps:

the scheduler's run() will execute and then callback registered() or reregistered() will be called.
driver.reconcileTasks() will be called which will send status updates for all running tasks.
in reconcileTasks's run() method, persistentState will get all taskId from zookeepers. Also, liveState.getRunningTasks will return a map with all running tasks since the status updates would have been sent from the tasks since we called driver.reconcile. If there a task that has died that was persisted in zookeeper, we will remove it.
Once reconcile finished, the callback resourceOffers will move to JOURNAL_NODES phase. then it will tryToLaunchJournalNode.
If DeadJournalNode is not empty and contains the offer.getHostname, it will call launchNode to relaunch the journal node on the same node. If DeadJournalNode is empty (i.e. the timeout has elapsed or there are no dead journal nodes), the scheduler will try to launch a journalnode wherever it finds an offer.

LiveState should be reconciled correctly with PersistentState. I corrected the steps above. Please let me know if you need further clarification.

Hi, @elingg
Thanks very much. I missed the step 2 that you mentioned. I remembered it called in reconcileTasks(), but didn't know what the "driver.reconcileTasks()" means.
But I still don't make the issue clear:
If a host (like journalNode) died after scheduler died, then 5-10 mins passed, when the scheduler start again, it will think the died host just died ( because deadJournalNodeTimeStamp newly created in persistentState.removeTaskId(taskId) ), and return it as DeadJournalNode.

Then the DeadJournalNode is not empty, in the next 1.5 mins, this journalNode will not be launched to any host except the one dead before.
But after 1.5 mins expires, the scheduler will remove this host from the deadJournal and launch a journalnode wherever it finds an offer.

Do you think the situation 1 above is the issue?

hi @tangzhankun, yes your description of the issue is correct.

hi @elingg
Thanks for quick reply. But this is not a serious bug, right? :) After the 1.5 mins timeout, the scheduler will remove it and accept offer to launch journalnode.

Correct, not serious, but we still want to get rid of these bugs as well!

Hi, @elingg
I agree. And I see your "Fix reconciliation features" merged. It clear the dead timestamp when start.
Thanks for your reply. And I have one question here:
How can I get the API document of mesos? I know the callback that one need to implement. But I saw some APIs used beyond the callbacks. like the method "ExecutorInfo.newBuilder().setName()" and so on.

hi @tangzhankun, I find the protobufs for Mesos very useful in this regard, https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto.

hi @elingg
Thanks for the reminder of protocol buffer. The APIs also include MesosSchedulerDriver's "reconcileTasks()" "sendFrameworkMessage" and so on.  Although we can understand it form the source code of mesos and it's example, there are no detail document for these APIs' usage, right?

You might also find this link useful for the Java API's, see http://mesos.apache.org/api/latest/java/org/apache/mesos/MesosSchedulerDriver.html.

Hi, @elingg
Yes. Thanks very much, elingg. :)


Ionic 5 Update Request

Ionic version:  (check one with "x")
[ ] 2.x
[ ] 3.x
[ ] 4.x
[ - ] 5.x
Ion2-calendar mode:  (check one with "x")
[ ] components mode
[ ] modal mode
I'm submitting a ...  (check one with "x")
[ - ] bug report
[ ] feature request
[ ] help me
Current behavior:

The error comes from momentjs package which I believe must be updated and optimised for Ionic 5.
Expected behavior:

Steps to reproduce:

Related code:
insert short code snippets here
I ran the following code in Ionic 5 as you'd expect from your documentation:
`  async openCalendar() {
    const options: CalendarModalOptions = {
      pickMode: 'range',
      title: 'Range',
      color: 'danger'
    };

    let myCalendar = await this.modalCtrl.create({
      component: CalendarModal,
      componentProps: { options }
    });

    myCalendar.present();
  }`

Other information:
Ionic info: (run ionic info from a terminal/cmd prompt and paste output below):
insert the output from ionic info here

After running the above code snippet from the documentation, this is an error I got below:
ERROR TypeError: moment is not a function     at CalendarModal.push../node_modules/ion2-calendar/dist/components/calendar.modal.js.CalendarModal.init (calendar.modal.js:47)     at CalendarModal.push../node_modules/ion2-calendar/dist/components/calendar.modal.js.CalendarModal.ngOnInit (calendar.modal.js:31)     at checkAndUpdateDirectiveInline (core.js:31910)     at checkAndUpdateNodeInline (core.js:44367)     at checkAndUpdateNode (core.js:44306)     at debugCheckAndUpdateNode (core.js:45328)     at debugCheckDirectivesFn (core.js:45271)     at Object.eval [as updateDirectives] (CalendarModal_Host.ngfactory.js? [sm]:1)     at Object.debugUpdateDirectives [as updateDirectives] (core.js:45259)     at checkAndUpdateView (core.js:44271)
I then figured that the dependencies haven't been updated in a while, especially with some changes in Ionic 5. I would like to request that you update this very important calendar in Ionic to be also used in Ionic 5.

this plugin supports ionic 5?

There's a PR that fix this, in the meanwhile use this repo: https://github.com/shaneparsons/ion2-calendar
Run these commmands:
npm uninstall ion2-calendar
npm i git+https://github.com/shaneparsons/ion2-calendar.git

Did the PR ever get merged, or we still need to use Shanes repo for Ionic 5/6?


Fix changelog for 5.2.1

Just fixes the changelog version

Ok so it looks like the release action doesn't work like I expected it to. Making another PR.


Fix the endering of http urls in architecture.md's mermaid diagram

Hey,
The diagram here is currently broken > https://opentelemetry.io/docs/demo/architecture/
What I did (and I think this is probably a terrible idea) was adding a Zero-width space before the colon in the urls.
I also tested adding a  and it also allows the rending to take place.
I'm not super familiar with Mermaid so there might exist a better way to do this (I hope so at least).
Raising this for awareness, if you are aware of an easy fix let me know and I can fix it quickly. Otherwise I will try to look into it whenever I have time available.

@monteiro-renato Please check https://github.com/open-telemetry/opentelemetry.io/issues/5168


Missing Symbols, no Dependency Errors?

Running a self-hosted agent, build pipeline fails due to missing symbols from a dependency app, but no indication that the dependency app is either missing or not available. Log output from Compile segment:
2023-04-12T17:35:12.6024432Z ##[section]Starting: Compile app
2023-04-12T17:35:12.6331076Z ==============================================================================
2023-04-12T17:35:12.6331469Z Task         : PowerShell
2023-04-12T17:35:12.6331784Z Description  : Run a PowerShell script on Linux, macOS, or Windows
2023-04-12T17:35:12.6332254Z Version      : 2.212.0
2023-04-12T17:35:12.6332511Z Author       : Microsoft Corporation
2023-04-12T17:35:12.6332869Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/powershell
2023-04-12T17:35:12.6333258Z ==============================================================================
2023-04-12T17:35:14.1270490Z Generating script.
2023-04-12T17:35:14.1666964Z ========================== Starting Command Output ===========================
2023-04-12T17:35:14.1907256Z ##[command]"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'C:\agent_work_temp\ee87e9c6-3beb-4a7d-82dd-7f6bb53e6c8a.ps1'"
2023-04-12T17:35:15.0089103Z BcContainerHelper version 4.0.16
2023-04-12T17:35:15.5609721Z BC.HelperFunctions emits usage statistics telemetry to Microsoft
2023-04-12T17:35:23.7146135Z Using Symbols Folder: C:\agent\appfiles
2023-04-12T17:35:53.5638775Z Processing dependency Microsoft_Application_<IP_ADDRESS> ()
2023-04-12T17:35:53.5939886Z Dependency App exists
2023-04-12T17:35:53.6346351Z Processing dependency Microsoft_System_<IP_ADDRESS> ()
2023-04-12T17:35:53.6352442Z Dependency App exists
2023-04-12T17:35:53.6410578Z Processing dependency CAI Software_CAi Software Precious Metals Solution_<IP_ADDRESS> (8788f8f7-2afb-4cd8-9935-068947847f2a)
2023-04-12T17:35:53.6672580Z Dependency App exists
2023-04-12T17:35:53.9488925Z Compiling...
2023-04-12T17:35:54.0109315Z .\alc.exe /project:"C:\ProgramData\BcContainerHelper\Extensions\NobleMetalBuild\Source" /packagecachepath:"C:\shareddata" /out:"C:\ProgramData\BcContainerHelper\Extensions\NobleMetalBuild\Source\output\CAI Software_Noble Metal Services Custom Mods_<IP_ADDRESS>.app" /assemblyprobingpaths:"C:\Program Files (x86)\Microsoft Dynamics NAV\190\RoleTailored Client","C:\Program Files\Microsoft Dynamics NAV\190\Service","C:\Program Files (x86)\Open XML SDK\V2.5\lib","c:\Windows\Microsoft.NET\Assembly","C:\Test Assemblies\Mock Assemblies"
2023-04-12T17:36:17.0691180Z Microsoft (R) AL Compiler version <IP_ADDRESS>163
2023-04-12T17:36:17.1492349Z Copyright (C) Microsoft Corporation. All rights reserved
2023-04-12T17:36:17.1581332Z
2023-04-12T17:36:17.1598791Z Compilation started for project 'Noble Metal Services Custom Mods' containing '60' files at '13:35:55.304'.
2023-04-12T17:36:17.1683355Z
2023-04-12T17:36:17.1975045Z ##[error]./C:/ProgramData/BcContainerHelper/Extensions/NobleMetalBuild/Source/src/pageext/NOB100VendorContractHdrLst.PageExt.al(18,33): error AL0185: Table 'CAIRef Vendor Contract Header' is missing
2023-04-12T17:36:17.2028848Z ##[error]./C:/ProgramData/BcContainerHelper/Extensions/NobleMetalBuild/Source/src/codeunit/NOB100CustomFunctions.Codeunit.al(8,24): error AL0185: Table 'CAiRef Refining Setup' is missing
2023-04-12T17:36:17.2050766Z ##[error]./C:/ProgramData/BcContainerHelper/Extensions/NobleMetalBuild/Source/src/codeunit/NOB100CustomFunctions.Codeunit.al(13,58): error AL0185: Table 'CAiRef Lot Detail' is missing
2023-04-12T17:36:17.2059480Z ##[error]./C:/ProgramData/BcContainerHelper/Extensions/NobleMetalBuild/Source/src/codeunit/NOB100CustomFunctions.Codeunit.al(15,24): error AL0185: Table 'CAiRef Refining Setup' is missing
2023-04-12T17:36:17.2078989Z ##[error]./C:/ProgramData/BcContainerHelper/Extensions/NobleMetalBuild/Source/src/codeunit/NOB100CustomFunctions.Codeunit.al(17,16): error AL0185: Table 'CAiRef Lot' is missing
2023-04-12T17:36:17.2085085Z ##[error]./C:/ProgramData/BcContainerHelper/Extensions/NobleMetalBuild/Source/src/codeunit/NOB100CustomFunctions.Codeunit.al(18,19): error AL0185: Codeunit 'CAiRef External System' is missing
2023-04-12T17:36:17.2090559Z ##[error]./C:/ProgramData/BcContainerHelper/Extensions/NobleMetalBuild/Source/src/codeunit/NOB100CustomFunctions.Codeunit.al(21,18): error AL0185: Table 'CAiRef Prod. Order Header' is missing
2023-04-12T17:36:17.2098838Z ##
...and so on, for every symbol reference in the app. I have confirmed that the dependency .app file is where it is supposed to be, in the Symbols folder. We have run this same compile many times, has something changed in BCContainerHelper?

Hi,
I had a similar issue when the app was present but the right artifact was not released/published/uploaded yet.

Hi!
Can you elaborate on what you mean by "right artifact was not released/published/uploaded'? Is that something we have to do, or is that supposed to happen during the build run?

Do you know which app contains these missing symbols?
Assuming it is: CAI Software_CAi Software Precious Metals Solution_<IP_ADDRESS>
Is it the right version that you have provided to the build?

That is the correct app for the symbols (we only have one), and that version is present in the appfiles folder. Can't show the screenshot here, you will have to take my word that it is and has been there throughout.
We have been through this a few times, having to make sure our main .app file is there, so I can't figure why it would balk at this version. If you need more log data, let me know.

Hi! Can you elaborate on what you mean by "right artifact was not released/published/uploaded'? Is that something we have to do, or is that supposed to happen during the build run?

Sorry, yes this error means you're trying to compile with the wrong symbols. For me (using github packages) this means the right version wasn't yet published to github packages.
Im not sure where you get your symbols from, do you just store them in a folder on the server? Im not sure how multiple versions of the same app in the folder might be handled? Maybe you can describe the mechanism you are using to manage your dependency in more detail?
@freddydk maybe its time to recommend github packages as the default? It's been flawless for me for a while now, 36 apps published to AppSource are a good indicator for how well it works. I never think about dependency problems anymore. As I said for me the only way this error can occur is, if the right version wasn't published yet. And thats very straight forward to track down when using github packages.

Okay I'm going to need a little more background. On a self-hosted agent, we have a folder on the server where we place the .app file from which the necessary symbols (ours) are to be derived. We found we had to do the same thing--I.e., place an .app file in that folder--for the MS symbols: system, application, etc. Placing multiple versions of any of these in the same folder was not a problem until just recently (we have multiple versions of our main app codebase for reasons related to client deployments).
No experience with GitHub packages--what they are, where they come from, where they go. But we are now in AL-Go for our base app. Perfectly happy to go with packages if someone wants to point us in the right direction, how to get started.

Thanks to Freddy's session at Directions, now we know all about packages and packaging! Will report back when we have that set up.

Thanks