some issues with grid map

Hi, i have tested your code with ros kinetic ,but I found some question when I run the demo, the log like this
WARNING: Logging before InitGoogleLogging() is written to STDERR
I0513 08:58:02.135192 11617 tension_smoother.cpp:84] Tension smoother succeeded!
I0513 08:58:02.135460 11617 reference_path_impl.cpp:417] Reference states are built from spline.
[1]    11617 segmentation fault (core dumped)  rosrun path_optimizer path_optimizer_benchmark
Then I  found some problem with the code :
auto clearance_0 = getClearanceWithDirectionStrict(c0, map);
I wonder if i have some problem with my ros package grip map?

Hi, are you running the latest version of this program? I noticed in your log that the Tension smoother is used, but I set another smoother as default because Tension smoother behaves strangely sometimes. I'm not sure if this caused your problem.
Also, did you try
roslaunch path_optimizer demo

If Rviz displays your map correctly as below, grid_map package works fine.

You can try this demo as instructed in the Readme file, and see if the same problem occurs.
Thanks for testing this package.:smile:

Hi ,i also have tried  run roslaunch path_optimizer demo,the  log look like this
[ INFO] [1589335964.906761698]: Setting goal: Frame:map, Position(63.693, -38.176, 0.000), Orientation(0.000, 0.000, -0.732, 0.681) = Angle: -1.642
get the goal.
Search time cost: 0.77 ms.
ref path length: 81.6211

This program contains Ipopt, a library for large-scale nonlinear optimization.
Ipopt is released as open source code under the Eclipse Public License (EPL).
For more information visit http://projects.coin-or.org/Ipopt

I0513 10:12:44.964879 17481 angle_diff_smoother.cpp:192] Angle diff smoother succeeded!
I0513 10:12:44.965195 17481 reference_path_impl.cpp:417] Reference states are built from spline.
[path_optimizer_demo-1] process has died [pid 17481, exit code -11, cmd /home/feng/catkin_ws/devel/lib/path_optimizer/path_optimizer_demo --log_dir=. __name:=path_optimizer_demo __log:=/home/feng/.ros/log/c1e2d4f2-94bd-11ea-b4b0-005056c00001/path_optimizer_demo-1.log].
log file: /home/feng/.ros/log/c1e2d4f2-94bd-11ea-b4b0-005056c00001/path_optimizer_demo-1*.log
The question is remain. I also found some problem with the code :
auto clearance_0 = getClearanceWithDirectionStrict(c0, map);
I have change some config file and my code  is matser branch

Sorry, I wasn't able to reproduce the bug. It seems to be related to memory corruption.
Did this problem occur when you use the default config? I wonder if this is due to the change of config.
It is likely that the bug exists in the function getClearanceWithDirectionStrict, I think I wrote pretty bad code in that function, and I'm thinking about rewrite it...but it has been working fine for me yet. Can you locate the exact line that killed the program?
Thanks.

Everything works well after i reinstall the operate system, so i think it is my problem
the code works well


InfluxDB: Throwing exception when storing IP address

Home Assistant release (hass --version):
0.47.0
Python release (python3 --version):
3.4.2
Component/platform:
InfluxDB component
Description of problem:
InfluxDB component will not create a measurement from an event that holds an IP address. See traceback below.
Looking at the code in influxdb.py (extract below), you can see that when "value" is an ip address, say "<IP_ADDRESS>", then line 164 will correctly generate an exception as it is not a float and the test on line 168 will return true as there are digits in the string. But the attempt to strip out non numerical characters in line 170 does not result in a parseable float as it does not process the multiple "." separators. Hence Line 169 ultimately generates an unhandled exception.

Expected:
Component should handle events containing IP addresses.
Problem-relevant configuration.yaml entries and steps to reproduce:
This can be replicated by enabling influxdb component and creating a sensor using the dnsip platform in configuration.yaml
influxdb:
  host: server
  port: 8086
  database: home_assistant

sensor:
  - platform: dnsip

Traceback (if applicable):
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/influxdb.py", line 164, in influx_event_listener
    json_body[0]['fields'][key] = float(value)
ValueError: could not convert string to float: '<IP_ADDRESS>'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/influxdb.py", line 170, in influx_event_listener
    non_decimal.sub('', value))
ValueError: could not convert string to float: '<IP_ADDRESS>'

Additional info:

Just seen and tested as fixed in 0.47.1. Man, that was quick!


Event System

Event system with struct arguments, sub/unsubscribe, fire, listener handling

suggestion: event system should supports not only marshal-by-value types, but marshal-by-ref too.


libmpack: fix darwin build

On darwin we need the correct prefix during the buildPhase, otherwise
the dynamic libraries have an incorrect install_name.
Motivation for this change
Things done

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

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

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

@GrahamcOfBorg build libmpack luaPackages.mpack

@GrahamcOfBorg build libmpack luaPackages.mpack

needs to be
(if lib.hasPrefix "luajit" lua.name then "CFLAGS=-lluajit-${lua.luaversion}" else "CFLAGS=-llua")

@orivej neovim is still broken as of that commit, with ld complaining that all the lua* symbols are not found

@orivej Thanks!

 I just pulled and still get the ld error

False alarm, my git pull wasn't git pull-y enough


Recursively call SSM API

I noticed we weren't retrieving all the parameters for a given namespace, so I changed the params get subcommand, making the fetch_results function recursive.

It's annoying that awscli accepts arbitrary unsupported command line options without so much as a warning.


bug: Suggestion Emoji Issue

Describe the bug in as much detail as possible:
Using the unicode characters (as told to in the readme) returns this error: Failed executing template: template: CC #16:42:5: executing "CC #16" at <addMessageReactions ...>: error calling addMessageReactions: HTTP 400 Bad Request, {"emoji_id": ["Value \"\ud83d\udc4d\" is not snowflake."]}
To Reproduce:

Implement command
Set upvote and downvote variables to 👍 & 👎
Command returns error

Expected behavior:
No error
Screenshots:

You are using unicode emoji, these suffice when put as plain text.
In your case like this:
{{$Upvote:="👍"}}
{{$Downvote:="👎"}}

You are using unicode emoji, these suffice when put as plain text.
In your case like this:
{{$Upvote:="👍"}}
{{$Downvote:="👎"}}

You are using unicode emoji, these suffice when put as plain text.
In your case like this:
{{$Upvote:="👍"}}
{{$Downvote:="👎"}}

Ah, alright, I'll try this - Maybe the readme could be updated to be a bit more clear?
Thank you <3

You are using unicode emoji, these suffice when put as plain text.
In your case like this:
{{$Upvote:="👍"}}
{{$Downvote:="👎"}}

Ah, alright, I'll try this - Maybe the readme could be updated to be a bit more clear?
Thank you <3

What Olde said is correct and is noted on the doc page. Please consider first contacting the support server or open a discussion (Discussions tab on GitHub) before opening an issue in the future.
Cheers!

What Olde said is correct and is noted on the doc page. Please consider first contacting the support server or open a discussion (Discussions tab on GitHub) before opening an issue in the future.
Cheers!

I'll maybe take a look into making the readme a bit more clear. Just as Joe said, please contact the support server first.

I'll maybe take a look into making the readme a bit more clear. Just as Joe said, please contact the support server first.


fixed local checks

Signed-off-by: aisuko<EMAIL_ADDRESS>The PR includes local-check script and remove the functions which according to the golangci-lint checks, you can run make local-check command and to validate the code

@leecalcote 2020-10-16T03:53:54.1684867Z Error parsing reference: "***:edge-refs/pull/130/merge" is not a valid repository/tag: invalid reference format. The docker tag ${{ secrets.IMAGE_NAME }}:edge-latest ${{ secrets.IMAGE_NAME }}:edge-${GITHUB_REF/refs\/tags\//} was not work very well.

@leecalcote Is there any idea? I saw that work for other projects
2020-10-16T03:53:54.1684867Z Error parsing reference: "***:edge-refs/pull/130/merge" is not a valid repository/tag: invalid reference format.
The docker tag ${{ secrets.IMAGE_NAME }}:edge-latest ${{ secrets.IMAGE_NAME }}:edge-${GITHUB_REF/refs\/tags\//} was not work very well.

Oh, that the when we were in the edge situation we do not have any tag, so, we should remove the tag. And if we push with a tag, it's must be we are going to release the stable versions.

We can merge this I believe @kumarabd

We can merge this I believe @kumarabd

@Aisuko Sounds good. We will address to the tags later on.


Move to prism for code highlighting

https://www.docsy.dev/docs/adding-content/lookandfeel/#code-highlighting-with-prism seems to have benefits over the default setting, see https://github.com/google/docsy/issues/370

Done by @thebe14 via #244

This is already done


The LineIterator is not usable

In C++, this is the example of LineIterator usage:
// grabs pixels along the line (pt1, pt2)
// from 8-bit 3-channel image to the buffer
LineIterator it(img, pt1, pt2, 8);
LineIterator it2 = it;
vector<Vec3b> buf(it.count);
for(int i = 0; i < it.count; i++, ++it)
    buf[i] = *(const Vec3b*)*it;
// alternative way of iterating through the line
for(int i = 0; i < it2.count; i++, ++it2)
{
    Vec3b val = img.at<Vec3b>(it2.pos());
    CV_Assert(buf[i] == val);
}

The problem is the ++ operator has not bind to Rust.
I glanced at it and there seemed to be no relevant example. I appreciate it if anyone can help.

Thanks for the report, it looks like missing bindings indeed. I'll take a look and try to fix it!

Just realized that I closed the issue by accident, sorry!

This is fixed in v0.63.0, you can now use incr() method to advance the iterator.


Confirmation sent from wrong address

In this line:
https://github.com/Rias500/craft-contact-form-extensions/blob/b998d30f90db48e3e7ab8f9c193ed1ecdb60b966/src/ContactFormExtensions.php#L161
It sets the from mail address to the to mail address of the previous message...
Shouldn't this be getFrom() ?

Using V1.1.1
I'm using this for a contact form. I want to send a notification to the mail configured in the Contact Form plugin, and send a confirmation to the mailaddress filled in. But the mailaddress configured in Mail settings is a noreply, and the mailaddress receiving the notifications is another mail address, resulting in:
Error sending email: Expected response code 250 but got code "554"
because the first mail for the notification is send from<EMAIL_ADDRESS>to<EMAIL_ADDRESS>but then the confirmation mail is send from<EMAIL_ADDRESS>which generates the error. So isn't it safer to set the setFrom to the configured mailaddress?

Created PR: #49

I can confirm that getTo is not working and getFrom does.

@kevinmu17 I also found another situation where the getFrom is incorrect. I’ll edit my pr with a better solution.

Should be fixed in 1.1.2


tutorial inference question

hi? I'm trying to apply ecg-fm, but the process of importing physionet_finetune.pt doesn't work. 5. In load model!
The mimic pt works well, but why is that?
root = os.getcwd()
root
model_pretrained = build_model_from_checkpoint(
checkpoint_path=os.path.join(root, 'ckpts', 'physionet_finetuned.pt')
)
model_pretrained

Are you on the latest versions of both ECG-FM and fairseq-signals repositories? If not, see if that fixes your issue.
Otherwise, please report back the error message you receive, as well as information about your virtual environment.

Hi I am facing a similar issue, where I cannot load the physionet_finetuned.pt
I have installed the latest ECG-FM and fairseq-signals. I tested with the code below.
import os
import pandas as pd
import torch

from fairseq_signals.utils.store import MemmapReader

# Manage directories
root = os.getcwd()
fairseq_signals_root = '/users/fairseq-signals'
fairseq_signals_root = fairseq_signals_root.rstrip('/')

# Download finetuned checkpoint
from huggingface_hub import hf_hub_download
_ = hf_hub_download(
    repo_id='wanglab/ecg-fm-preprint',
    filename='physionet_finetuned.pt',
    local_dir=os.path.join(root, 'ckpts'),
)
_ = hf_hub_download(
    repo_id='wanglab/ecg-fm-preprint',
    filename='physionet_finetuned.yaml',
    local_dir=os.path.join(root, 'ckpts'),
)

# Load model
from fairseq_signals.models import build_model_from_checkpoint
model_finetuned = build_model_from_checkpoint(
    checkpoint_path=os.path.join(root, 'ckpts/physionet_finetuned.pt')
)

I am getting the error
Traceback (most recent call last):
  File "/users/ECG-FM/inference_example.py", line 31, in <module>
    model_finetuned = build_model_from_checkpoint(
  File "/users/fairseq-signals/fairseq_signals/models/__init__.py", line 106, in build_model_from_checkpoint
    return build_model(model_cfg, task=None, from_checkpoint=True, checkpoint_path=checkpoint_path)
  File "/users/fairseq-signals/fairseq_signals/models/__init__.py", line 93, in build_model
    model_instance = model.build_model(cfg, task)
  File "/users/fairseq-signals/fairseq_signals/models/ecg_transformer.py", line 260, in build_model
    encoder = ECGTransformerModel.from_pretrained(cfg.model_path, cfg)
  File "/users/fairseq-signals/fairseq_signals/models/ecg_transformer.py", line 232, in from_pretrained
    model = super().from_pretrained(model_path, cfg, arg_overrides)
  File "/users/fairseq-signals/fairseq_signals/models/transformer.py", line 237, in from_pretrained
    return super().from_pretrained(model_path, cfg, arg_overrides, **kwargs)
  File "/users/fairseq-signals/fairseq_signals/models/pretraining_model.py", line 81, in from_pretrained
    model = task.build_model(args.model)
  File "/users/fairseq-signals/fairseq_signals/tasks/ecg_pretraining.py", line 380, in build_model
    model = super().build_model(model_cfg)
  File "/users/fairseq-signals/fairseq_signals/tasks/task.py", line 291, in build_model
    model = models.build_model(cfg, self, from_checkpoint)
  File "/users/fairseq-signals/fairseq_signals/models/__init__.py", line 93, in build_model
    model_instance = model.build_model(cfg, task)
  File "/users/fairseq-signals/fairseq_signals/models/ecg_transformer.py", line 260, in build_model
    encoder = ECGTransformerModel.from_pretrained(cfg.model_path, cfg)
  File "/users/fairseq-signals/fairseq_signals/models/ecg_transformer.py", line 232, in from_pretrained
    model = super().from_pretrained(model_path, cfg, arg_overrides)
  File "/users/fairseq-signals/fairseq_signals/models/transformer.py", line 237, in from_pretrained
    return super().from_pretrained(model_path, cfg, arg_overrides, **kwargs)
  File "/users/fairseq-signals/fairseq_signals/models/pretraining_model.py", line 63, in from_pretrained
    state = checkpoint_utils.load_checkpoint_to_cpu(model_path, arg_overrides)
  File "/users/fairseq-signals/fairseq_signals/utils/checkpoint_utils.py", line 267, in load_checkpoint_to_cpu
    with open(local_path, "rb") as f:
FileNotFoundError: [Errno 2] No such file or directory: '<REDACTED>'

In the physionet_finetuned.pt checkpoint, the model.model_path variable in the cfg is REDACTED, and the build_model_from_checkpoint function appears to use that variable?

It seems that the publisher of fairseq-signals has fixed the related issue. I was experiencing the same problem, but it now works smoothly. Try updating fairseq-signals to the latest commit and give it another shot.


replace HttpClient by ContentNegotiator, TypeMapper + VOs

Codecov Report

Merging #64 into master will decrease coverage by 1.62%.
The diff coverage is 95.49%.

@@             Coverage Diff              @@
##             master      #64      +/-   ##
============================================
- Coverage     98.67%   97.04%   -1.63%
- Complexity      102      107       +5
============================================
  Files            19       22       +3
  Lines           301      305       +4
============================================
- Hits            297      296       -1
- Misses            4        9       +5

Impacted Files
Coverage Δ
Complexity Δ

src/Serialize/FormatException.php
0.00% <0.00%> (ø)
2.00 <2.00> (?)

src/Serialize/TypeMapper.php
87.50% <87.50%> (ø)
5.00 <5.00> (?)

src/DependencyInjection/Configuration.php
100.00% <100.00%> (ø)
1.00 <0.00> (ø)

src/DependencyInjection/TerryApiExtension.php
100.00% <100.00%> (ø)
1.00 <0.00> (ø)

src/Error/ErrorListener.php
100.00% <100.00%> (ø)
4.00 <0.00> (ø)

src/Error/ValidationExceptionListener.php
100.00% <100.00%> (ø)
4.00 <0.00> (ø)

src/Negotiation/ContentNegotiator.php
100.00% <100.00%> (ø)
9.00 <9.00> (?)

src/Request/AcceptHeader.php
100.00% <100.00%> (ø)
5.00 <5.00> (?)

src/Request/ContentTypeHeader.php
100.00% <100.00%> (ø)
3.00 <3.00> (?)

src/Request/HttpApiArgumentResolver.php
100.00% <100.00%> (ø)
13.00 <0.00> (ø)

... and 14 more

Continue to review full report at Codecov.

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


feat(router): customize error_log level via etcd

Add method to customize the nginx error_log level via etcd. This helps when
debugging issues in deis-router.
Fixes #3560
Pretty easy to test:
deisctl config router set errorLogLevel=debug
deisctl config router set errorLogLevel=error

And check the log.

Code LGTM.

Code LGTM. I double-checked the error_log values here: http://nginx.org/en/docs/ngx_core_module.html#error_log
We don't have integration tests that set /deis/router/errorLogLevel, so this needs some manual testing.

LGTM, tested interactively on vagrant as specified above. debug output is quite verbose--this will be useful in troubleshooting.

LGTM, tested interactively on vagrant as specified above. debug output is quite verbose--this will be useful in troubleshooting.

:ship:?


Events does not occupy its slot correctly

When we start going from 9 am to 5 pm the events slowly slowly are not occupying the slots correctly leaving some whitespaces. I will give an example using a screenshot.
So in the screenshot the event 1 with grey at 9 am is perfectly occupying the space of its slot but when we go further down at 11 am, the event is not perfectly occupying the slot leaving some space at the start of the slot. And this space keeps on increasing as shown in the picture at 2pm and 5pm.
How to resolve this?

My code looks like this:
import { Scheduler } from "@aldabil/react-scheduler";

export default function Temp() {
  const EVENTS = [
    {
      event_id: 1,
      title: "Event 1",
      start: new Date(new Date(new Date().setHours(9)).setMinutes(0)),
      end: new Date(new Date(new Date().setHours(10)).setMinutes(0)),
      disabled: true,
      admin_id: [1, 2, 3, 4],
    },
    {
      event_id: 2,
      title: "Event 2",
      start: new Date(new Date(new Date().setHours(10)).setMinutes(0)),
      end: new Date(new Date(new Date().setHours(12)).setMinutes(0)),
      admin_id: 2,
      color: "#50b500",
    },
    {
      event_id: 3,
      title: "Event 3",
      start: new Date(new Date(new Date().setHours(11)).setMinutes(0)),
      end: new Date(new Date(new Date().setHours(12)).setMinutes(0)),
      admin_id: 1,
      editable: false,
      deletable: false,
    },
    {
      event_id: 4,
      title: "Event 4",
      start: new Date(
        new Date(new Date(new Date().setHours(9)).setMinutes(30)).setDate(
          new Date().getDate() - 2
        )
      ),
      end: new Date(
        new Date(new Date(new Date().setHours(11)).setMinutes(0)).setDate(
          new Date().getDate() - 2
        )
      ),
      admin_id: 2,
      color: "#900000",
    },
    {
      event_id: 5,
      title: "Event 5",
      start: new Date(
        new Date(new Date(new Date().setHours(10)).setMinutes(30)).setDate(
          new Date().getDate() - 2
        )
      ),
      end: new Date(
        new Date(new Date(new Date().setHours(14)).setMinutes(0)).setDate(
          new Date().getDate() - 2
        )
      ),
      admin_id: 2,
      editable: true,
    },
    {
      event_id: 6,
      title: "Event 6",
      start: new Date(
        new Date(new Date(new Date().setHours(10)).setMinutes(30)).setDate(
          new Date().getDate() - 4
        )
      ),
      end: new Date(new Date(new Date().setHours(14)).setMinutes(0)),
      admin_id: 2,
    },
  ];

  return <Scheduler events={EVENTS} />;
}

Have you checked if you have some overriding CSS as in #271 ?


Initial changes for 4.11

This is a small tweak to how we manage the networks so that we can do a deployment on 4.11 too with isolated networks and 2 nics.
It fixes a bug on the iface hint for single nic
Type of change
Please select the appropriate options:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] This change is a documentation update

Testing

Test Configuration:

Versions:
Hardware:

Checklist

[ ] I have performed a self-review of my own code
[ ] If a change is adding a feature, it should require a change to the README.md and the review should catch this.
[ ] If the change is a fix, it should have an issue. The review should make sure the comments state the issue (not just the number) and it should use the keywords that will close the issue on merge.
[ ] A change should not be merged unless it passes CI or there is a comment/update saying what testing was passed.
[ ] PRs should not be merged unless positively reviewed.

/lgtm
Not sure how the metrics help :)

Right now (on 4.10) I can't get OVN+SNO to work, the routing table looks like this:
[core@ztpfw-cpe0-master-0 ~]$ ip route
default via <IP_ADDRESS> dev ens1f0.102 proto kernel metric 99
default via <IP_ADDRESS> dev ens1f0 proto dhcp metric 100

Because <IP_ADDRESS> is the default, with a lower metric, the server can't access outside its subnet, since that network goes nowhere

Right now (on 4.10) I can't get OVN+SNO to work, the routing table looks like this:
[core@ztpfw-cpe0-master-0 ~]$ ip route
default via <IP_ADDRESS> dev ens1f0.102 proto kernel metric 99
default via <IP_ADDRESS> dev ens1f0 proto dhcp metric 100

Because <IP_ADDRESS> is the default, with a lower metric, the server can't access outside its subnet, since that network goes nowhere

This commit will help


Return a promise to allow simplified waiting for async.

Returning the wait() promise, allows consumers to have a  nice mechanism to allow async that is triggered by these helpers to interact with the world after all things have settled.
For example:
test('foo', async function(assert) {
  this.render(hbs`{{some-component}}`);

  await click('.selector');

  assert.equal('whatever', 'lol');
});

Can you rebase? Also, why is the point in waiting if everything is wrapped in Ember.run?
BTW, focus is not exported, you might not need to return wait() from it

Closed since I've copied this lines manually.


Pug parser : Include not supported

Hi :)
I'm trying to generate my component documentation, but an error is raised:
TypeError: A child of Block (Pug:2) is of type Include, which is not supported by pug-code-gen. Please use pug-linker to preprocess this AST.
Here is the template parsed:
<template lang="pug">
    include configured.pug
</template>

If you need more information. Let me know.

Hey @Akanoa did you have time to try it ?

Hello @Akanoa, it should be working now. If there is a bug and you find that it is not can you open a bug issue ?


Support for servant 0.11?

Is there going to be an update that adds support for recent versions of servant?

the package didn't make it to lts-9.0 because of servant breaking update

Sorry for that big break in maintaining this package. migrated to servant-0.11

Although it's about time to start worrying about servant-0.12 :)

oh yeah, seems to be a big change


Pi5 with two cameras, maximum resolution causes error when 'starting' both

I've written some software to take two photos at the same time (within a fraction of a second hopefully). To do this, I create two instances of Picamera2, then call .start on each of them.
When I choose a lower resolution, the code works fine, and I'm able to grab two images, but if I try to use the maximum resolution of both cameras, I get an error.
from picamera2 import Picamera2

print("instantiating 1")
pi_zero = Picamera2(0)
print(pi_zero.sensor_modes)
config_zero = pi_zero.create_still_configuration()
pi_zero.configure(config_zero)

print("instantiating 2")
pi_one = Picamera2(1)
print(pi_one.sensor_modes)
config_one = pi_one.create_still_configuration()
pi_one.configure(config_one)

print('starting 1');
pi_zero.start()
print('starting 2');
pi_one.start()

print('capturing 1')
pi_zero.capture_file('first.jpg')
print('capturing 2')
pi_one.capture_file('second.jpg') # It shows an error and hangs on this line

print('stopping 1')
pi_zero.stop()
print('stopping 2')
pi_one.stop()

print('closing 1')
pi_zero.close()
print('closing 1')
pi_one.close()

I would expect the above code to produce two images at the full sensor resolution.
The relevant error/info logs are;
instantiating 1
instantiating 2
starting 1
starting 2
capturing 1
capturing 2
[1:01:49.221951758] [4776] ERROR V4L2 v4l2_videodevice.cpp:1697 /dev/video35[52:cap]: Failed to queue buffer 1: Invalid argument
[1:01:49.221983647] [4776] ERROR RPISTREAM rpi_stream.cpp:276 Failed to queue buffer for ISP TDN Output

Hardware;
Raspberry PI 5 (4gb)
Arducam 64mp Hawkeye (arducam_64mp) - 9152x6944
High Quality Camera Module (imx477) - 4056x3040
Software;
Debian GNU/Linux 12 (bookworm)
rpicam-apps build: 966fa99736d8-intree-dirty 24-04-2024 (09:27:41)
libcamera build: v0.1.0+320-5b2af7e6-dirty (2024-04-24T09:02:46+01:00)
python3-picamera2/stable,stable,now 0.3.18-1

Hi, could you say what you mean by "choose a lower resolution"? Does the 64MP camera have a 2x2 binned mode that makes this work? It might be worth looking if there is anything in dmesg.
I'm afraid I don't have access to one of these 64MP cameras, so let's perhaps try and find the most minimal change that makes it work, and see if we can figure out what the difference then is.

Hi @davidplowman
If I modify the code to have
config_zero = pi_zero.create_still_configuration(main={'format': 'XBGR8888', 'size': (640,480)},raw=None)
With the above parameters, it is able to start. I can't remember exactly what resolution it stopped working at, but I can re-assemble if you think there's a possibility it can be fixed?
I read somewhere that it might be related to limited CMA memory. So it might be related to the hardware rather than the picamera2 software.

It's hard to see what's going on. CMA memory is actually much less of a constraint on a Pi 5 because it has an IO MMU. So far as we are aware, there are no specific constraints on the TDN (temporal denoise) buffer, so we're struggling to see where things would be going wrong. Again, it would be good to know if dmesg shows any errors.
The TDN buffer is allocated to match the size of the input image from the sensor, so it's whatever size has been selected for the raw stream. We assume from the message that it's this buffer that is causing the problem, but it's possible that something earlier is going wrong and it only shows up here. It might be worth trying to change the 64MP camera to select a non-full-resolution sensor mode.  Assuming that pi_one is the camera in question, maybe try:
half_resolution = (pi_one.sensor_resolution[0] // 2, pi_one.sensor_resolution[1] // 2)
config_one = pi_one.create_still_configuration(raw={'size': half_resolution})

Also, it might be worth capturing a log file. This kind of thing should work:
LIBCAMERA_LOG_LEVELS=*:0 python script.py >& log.txt

The file would be quite large, I expect, so you might want to post it somewhere where we can download it.
I'm sorry not to have any particular answers at the moment, just lots of questions. I guess I'm wondering all kinds of things like, does the 64MP work on its own? Does it work in rpicam-apps? and so on.

Hello,
This is the output from dmesg - I tried running my script twice to ensure that these entries relate to what I'm doing.

OK, that's pretty interesting. It does suggest that some kind of buffer mapping in the MMU might be the problem. There is a lot of address space there, on the other hand these 64MP buffers can get very large indeed. I'll poke around a bit.

camera-logs.zip
Actually, compressed, both logs are only 400k

Can you confirm that if you run the 64MP camera on its own, that it works?
Doing the sums, I can see that a 64MP + 12MP camera arrangement is starting to approach the limits in the IO MMU driver, but I'm not yet understanding why it seems actually to be going over. Certainly two 64MP cams is absolutely too much, but I'd have thought this configuration should squeeze through. More digging required.

Yes, it works fine on its own, and even if with both cameras plugged in and I take two photos (one after the other) it also works at full resolution, but I'm trying to start both cameras, then wait for 'focus' on the 64mp one, then take two photos at the same time.
Just curious, if each pixel is 3 bytes, then the total bytes used for a 64mp camera would be 192mb, but this isn't even close to the 4gb of memory the Pi has, so why would 2x64mp cams be too much?? (or are some of my presumptions wrong?)

Hmm, we're thinking the problem is not the number of buffers we allocate as such, it's that buffers may get mapped more than once if different bits of the system are using them. This explains why the amount of address space we're gobbling up is larger than expected. We'll have to think about that.

As far as I can tell, it seems that the underlying V4L2 Linux framework is causing quite a few of the buffers to be mapped twice. Once when we "request" the buffers, and then again the first time they're "queued". I don't really understand why this would happen, and there's probably nothing we can really do about it either.
Having said that, some of our buffer allocations could actually be avoided, though there's a certain amount of work required to do that. Also, a good idea would be to let the IO MMU's page tables expand dynamically - but that needs to be done very carefully as otherwise you brick the entire system. So whilst we can put those things on our to do list, I don't think there's any immediate prospect of those happening.
In the short term, then, it might be worth trying some workarounds. I'd give something like this a go:
import cv2
import time

from picamera2 import Picamera2

pi_zero = Picamera2(0)
pi_one = Picamera2(1)

pi_zero.start()
pi_one.start()
time.sleep(0.5)
pi_zero.stop()
pi_one.stop()

config_zero = pi_zero.create_still_configuration({'format': 'YUV420'})
pi_zero.configure(config_zero)
config_one = pi_one.create_still_configuration({'format': 'YUV420'})
pi_one.configure(config_one)

pi_zero.start()
pi_one.start() # probably start the 64MP cam second

im_one_yuv = pi_one.capture_array('main') # capture and stop the 64MP cam first
pi_one.stop()

im_zero_yuv = pi_zero.capture_array('main')
pi_zero.stop()

pi_zero.close()
pi_one.close()

cv2.imwrite("first.jpg", cv2.cvtColor(im_zero_yuv, cv2.COLOR_YUV420p2RGB))
cv2.imwrite("second.jpg", cv2.cvtColor(im_one_yuv, cv2.COLOR_YUV420p2RGB))

There are two principal changes here.

I've run 0.5 seconds of preview before switching to the full resolution capture. When the camera starts it normally processes 6 or 7 frames to let AGC/AEC and AWB  settle, which means it works its way through quite a lot of buffers, causing them all to be mapped. It's better if we use low resolution preview buffers for this purpose. When we switch to the capture, it should only need to process one full resolution buffer so that, as long as we stop the camera immediately, this should cause fewer large buffers to get mapped. (You can see I've re-arranged things a bit to leave the 64MP cam running as little time as possible.)

I'm using YUV420 buffers as these are half the size of the RGB888 ones. Unfortunately it does mean they have to be converted before saving, but at least this can happen "offline", and doesn't affect when the captures happen.

I've not tried this code, but hopefully it's obvious enough that you get the idea.

Hello David,
Thank you for responding with  the full example. I have tried it, and really like the idea of doing the processing 'off-line'.
However, there are still some issues with the capture, although probably unrelated to PiCamera2 and more the 64mp camera.
I mentioned before that I am able to capture full 64mp (9152 x 6944) images with this camera, but it's still not without issue.

If I capture 64mp, the auto-focus doesn't work. I send the relevant command and monitor post_callback for the LensPosition , but it just stays at 1.0 and the AfState remains at 1 / Auto - rather than switching to 2 / Focused (as it does on lower resolutions) - however, I can set the focus with the Manual mode, passing a LensPosition
When I capture YUV420, I get an image slightly wider than the largest image listed in the sensor modes, and there's a green stripe down the right hand side of the image (the returned image from imwrite (above) is 9216 x 6944. But the image quality seems similar to that of the standard capture.
I don't seem to be able to get AeMeteringMode working with anything other than spot or 'matrix'. I want to be able to pass a region/point (for the spot), although I think this might be another 'case' as it's not specifically linked to issues with two cameras.

I really appreciate your help with this issue, it's a learning curve for me, but a very interesting one.

Hi again, let me work through those various questions.

Autofocus

You might need to ask Arducam about that. It may be that they have code to support the autofocus but which they haven't upstreamed to our repository. We strongly encourage third parties to do this, but sometimes they don't for reasons of their own. This may mean that you have to install Arducam forks of our software but of course, it gets hard for us to support  as we have no idea what they've changed. Obviously we'll always do our best to be helpful, but you would inevitably become more reliant on Arducam for some aspects of support.

YUV420 capture

This tends to happen because hardware often has constraints on how many bytes it can write to memory at once, and software engineers have historically not always taken this into account.
So on a Pi, the imaging system has to start every new image row on a multiple of 32 (Pi 4, I think) or 64 (Pi 5, IIRC) bytes. Because of the way Linux V4L2 works, this means the Y plane of the image, being double the width of the U and V, has to start at double that, thus 128 byte multiples on a Pi 5. This is what gives you those extra unused rows on the edge of the image - the image stride (line to line distance in memory measured in bytes) is rounded up to a multiple of 128.
If you're dealing with (for example) RGB, you can just slice of the dud pixels by creating a new "slice" of the array, you don't even need to copy the image data. This is nice and efficient. YUV420 is more awkard because of the way numpy/OpenCV stores the image. First you get H (the image height) rows of Y data, each with <= 127 bytes of dud pixels on the end (to make the stride up to a multiple of 128). Then you get H/2 rows of UV data, which is W/2 (W = image width) bytes of U, plus <= 63 bytes of dud pixels (corresponding to the dud Y pixels), then W/2 bytes of V with again <= 63 dud values.
It should be clear that there because we get dud values in the middle of the array's UV rows (a YUV420 image is stored as H+H/2 equally sized rows), there's no way to get rid of them without actually copying the entire array - which is wasteful and slow.
So the best solution is to turn this array - dud pixels and all - into RGB, and then perform the slice operation on the RGB array. The other solution would be to ask for images with a width satisfying these alignment constraints in the first place (which I guess would be 9088 pixels in this case). Does that make sense?

Metering

So the default (normal, or centre weighted). matrix (whole image average) and spot metering methods should all be supported. Unfortunately there's no libcamera API for setting exactly where the "spot" is, so the only place you could change it would be in the camera tuning file. This would take effect when you open the camera, and you couldn't change it once it's running.
Would that cover you use case? Let me know if you want to learn how to edit the camera tuning file; it's not difficult!

Thank you so much for your comprehensive response.

Autofocus - this works on lower resolutions as expected, it's only on the full res that it doesn't do anything
YUV - will need to absorb this info
Metering - When you say 'open' the camera, is this at the point that you ;

a) boot up the PI
b) create an instance if PiCamera2
c) 'start' the camera?

Thanks again
b)

Thank you so much for your comprehensive response.

Autofocus - this works on lower resolutions as expected, it's only on the full res that it doesn't do anything

Ah OK, that's a bit weird. I only have a Camera Module 3 here, but I've tried that and AfMode auto works as expected for me in the full resolution mode. Might be worth asking Arducam if they think this should work.

YUV - will need to absorb this info
Metering - When you say 'open' the camera, is this at the point that you ;

a) boot up the PI
b) create an instance of PiCamera2

I think this. I'm not 100% sure if you need to quit the Python process as well and restart it, but you certainly shouldn't need a reboot.

c) 'start' the camera?

Thanks again
b)


modules/hyprland/workspace: ignore empty window-rewrite

I'd like to ignore some windows from having icons or empty space taken on the bar. By filtering out empty repr we can supply rewrite rules that will ignore them from being processed and showing an empty space or default icon.

Thanks!


Fasts are going to need to have a media property

Fasts will need an image associated with them. To be used a header when displaying them, and a thumbnail when listing them.

Resolved in feature/ui-enhancements branch! Marking as resolved.


Minified js not eligible for integrity checks since it’s neither CORS-enabled nor same-origin

Hello,
When using the noteworthy theme in my hugo site, the server will launch successfully using the command hugo server.
However, the site itself seems to be missing some visual elements.
When I look at the console tab, I get the following error:
“http://localhost:1313/js/main.min.fa5c2b23e07b5d9bfad267a52b4b24fdb053e6fb7524993383594926a3ac270c.js” is not eligible for integrity checks since it’s neither CORS-enabled nor same-origin.
I do not get this error when using other themes.
Let me know if any further information is needed/could be useful.
Thanks

@jakehell This should be fixed in the latest update, but let me know if this is still an issue.


Add paragraph link when hovering a heading

Is your feature request related to a problem? Please describe.
N/A
Describe the solution you'd like
[getbootstrap.com] shows an anchor when hovering a paragraph header. This simplifies the sharing of content links.
Describe alternatives you've considered
N/A
Additional context
Consider adding <i class="fa-solid fa-link"></i> as icon.

See AnchorJS for a light-weight solution.


how to get 2048 videos for computing FVD?

Hi author,
Thanks for your great work.
I would like to know how to get 2048 videos for computing FVD? Thanks

Hi author, Thanks for your great work. I would like to know how to get 2048 videos for computing FVD? Thanks

Just run bash sample/ffs_ddp.sh or bash sample/ffs_ddp.sh.

Hi @maxin-cn ,
Thanks for your reply. My questions is how to get corresponding 2048 ground truth data, not generated data.
Thanks

Hi @maxin-cn , Thanks for your reply. My questions is how to get corresponding 2048 ground truth data, not generated data. In this paper, it says 2048 real videos with 16 frames. I am not sure about how to get it. Any help is appreciated, thanks

You can randomly sample 2048 videos from the real dataset or also use the entire real video to calculate FVD.


Snapshot service doesn't work

Describe the bug
Service camera.snapshot doesn't work. The service execute without error but image generated  is not up to date.
Additional information

Home Assistant OS: 211.1
Home Assistant Core Version: 2023.11.2
Eufy Security Add-on Version: 1.7.1
Eufy Security Integration Version: 7.7.4

Hardware Information;

Camera Model: Eufy cam 2C

Please follow the bug template


Adding uri support for mongo

Adding uri configuration
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
For changelog. Remove if this is non-significant change.
Category (leave one):

New Feature
Bug Fix
Improvement
Performance Improvement
Backward Incompatible Change
Build/Testing/Packaging Improvement
Other

Short description (up to few sentences):
...
Detailed description (optional):
...

Closed as incomplete/accidential PR.

@alexey-milovidov  This is the continuation of PR #5387


[log] TLS syslog TLS PEM is a path to a file, not a cert

What does this PR do?
The syslog_pem config option should be a path to a PEM cert, this PR implements that.
Motivation
Providing the (undocumented) PEM option in the datadog.yaml wasn't user-friendly.
Additional Notes
Anything else we should know when reviewing?

@truthbk Could you also document the option in config_template.yaml?

Added option to config_template.yaml - PR had been previously approved. Merging.


Cannot execute aliased action with redux-thunk

I'm trying to execute an async action in main process with this code:
Actions file:
//My target task
const saveSettings = (properties, callback) => {
  console.log('Executing in main process...')
  console.log('Doing some stuff...')
  console.log('Work finished!')
  callback()
}

const SAVE_SETTINGS_TO_CONF_FILE_SUCCESS = 'SAVE_SETTINGS_TO_CONF_FILE_SUCCESS'
const saveSettingsToConfFileSuccess = createAliasedAction(
  SAVE_SETTINGS_TO_CONF_FILE_SUCCESS,
  () => {
    return {
      type: SAVE_SETTINGS_TO_CONF_FILE_SUCCESS,
      payload: {test: 'TEST'}
    }
  }
)

const SAVE_SETTINGS_TO_CONF_FILE_IN_PROGRESS = 'SAVE_SETTINGS_TO_CONF_FILE_IN_PROGRESS'
const saveSettingsToConfFileInProgress = createAliasedAction(
  SAVE_SETTINGS_TO_CONF_FILE_IN_PROGRESS,
  () => {
    return {
      type: SAVE_SETTINGS_TO_CONF_FILE_IN_PROGRESS,
      payload: {test: 'TEST'}
    }
  }
)

const SAVE_SETTINGS_TO_CONF_FILE = 'SAVE_SETTINGS_TO_CONF_FILE'
const saveSettingsToConfFile = createAliasedAction(
  SAVE_SETTINGS_TO_CONF_FILE, (properties) => {
    return (dispatch) => {
      dispatch(saveSettingsToConfFileInProgress())
      //My target task
      return saveSettings(properties, () => {
        dispatch(saveSettingsToConfFileSuccess())
      })
    }
  }
)

module.exports = {
  saveSettingsToConfFileInProgress,
  saveSettingsToConfFile,
  SAVE_SETTINGS_TO_CONF_FILE_IN_PROGRESS,
  SAVE_SETTINGS_TO_CONF_FILE
}

When I dispatch the async action:
import { saveSettingsToConfFile, saveSettingsToConfFileInProgress } from '../../../../actions/settings-actions'

(...)

const mapDispatchToProps = (dispatch) => ({
  closeSettingsModal: () => {
    dispatch(closeSettingsPage())
  },
  saveSettings: () => {
    dispatch(saveSettingsToConfFile())
  }
})

The system shows the error:

I tried to dispatch a synchronous action saveSettingsToConfFileInProgress() and it works fine:
import { saveSettingsToConfFile, saveSettingsToConfFileInProgress } from '../../../../actions/settings-actions'

(...)

const mapDispatchToProps = (dispatch) => ({
  closeSettingsModal: () => {
    dispatch(closeSettingsPage())
  },
  saveSettings: () => {
    dispatch(saveSettingsToConfFileInProgress())
  }
})

With a few observation I saw that my reducer to capture settings-actions was not declared importing the settings-actions.js file.
When I imported the file settings-actions.js, then the actions inside it were registered into the aliased actions see:
const { SAVE_SETTINGS_TO_CONF_FILE_SUCCESS } = require('../actions/settings-actions')

const settings = (state={}, action) => {
  switch (action.type) {
  case SAVE_SETTINGS_TO_CONF_FILE_SUCCESS:
    return state

  default:
    return state

  }
}

module.exports = {
  settings
}

I inserted a log line in ./node_modules/electron-redux/dist/middleware/triggerAlias to print all registered aliased actions using /src/registry/alias.js and got this output:
registered actions:  { OPEN_CONNECTION: [Function],
  SAVE_SETTINGS_TO_CONF_FILE_REQUEST: [Function],
  SAVE_SETTINGS_TO_CONF_FILE_SUCCESS: [Function],
  SAVE_SETTINGS_TO_CONF_FILE_02: [Function] }

The store dispatches properly.
But if I do not import the file with the actions doesn't work.
//const { SAVE_SETTINGS_TO_CONF_FILE_SUCCESS } = require('../actions/settings-actions')

const settings = (state={}, action) => {
  switch (action.type) {
//  case SAVE_SETTINGS_TO_CONF_FILE_SUCCESS:
//    return state

  default:
    return state

  }
}

module.exports = {
  settings
}

The registered aliased actions output was:
registered actions:  {  }

It seems that actions are registered only if the file containing the actions are imported in one reducer.
Issue fixed, but need explanation.


mutt: fix broken on systems without "admin" group (non-OSX)

[X] Have you followed the guidelines in our Contributing document?
[X] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

[ ] Have you included a log of the failed build without your patch using brew gist-logs <formula>?

[X] Does your submission pass
brew audit --strict <formula> (where <formula> is the name of the formula you're submitting)?
[X] Have you built your formula locally prior to submission with brew install <formula>?

Merged. Thanks for your contribution, Mark.


"Do not use BuildContexts across async gaps" in views/main_popup_menu_button.dart

It seems that recently flutter lint has been updated with a new linting rule that warns the developer to not use the context in async functions after an await has been performed: Use Build Context Synchronously.

In step-8 we are using it in the views/main_popup_menu_button.dart when showing the logout and delete account dialogs for dispatching the action to the bloc:

https://github.com/vandadnp/youtube-course-bloc/blob/main/lib/views/main_popup_menu_button.dart#L21
https://github.com/vandadnp/youtube-course-bloc/blob/main/lib/views/main_popup_menu_button.dart#L29

Some solutions are suggesting to check whether or not the component is mounted before dispatching the event, but I was wondering if there is another solution with still using the StatelessWidget, without the need of converting it into a StatefulWidget.

yeah, please write this line before using context in the async method:
if(!mounted) return;
context.read<...>(...);


Support Alexa v3

First off, thank you for putting this project together and for writing such great setup instructions!
While initially trying it out, I ran into the v2/v3 upgrade issue (as others have) and decided to dig in. Here is a summary of the changes included in this p/r:

Support Alexa v3
Added a lot of tests with sample payloads and responses.  I opted for jest since it's an all-in-one test framework, but I'm happy to use a different one if you're not a fan.
Move auth to separate iComfort.js file for easier sharing between code and tests. (Only have to hard-code user information once)
Support DEBUG Lambda environment variable for extra logging.
No longer need to send Celsius to Alexa, because we can specify Fahrenheit in the response (Alexa will still speak in Celsius to those who have chosen that preference for their Alexa device).
Deny requests while in Away mode.
Deny requests that are out-of-range (allowed range is between 60-99F)

Let me know if you have any feedback or concerns about these changes. I'm happy to tweak as necessary.
I am currently using this version of the module with my home system, and it seems to be working well.  But I would very much appreciate feedback if there are opportunities to improve here.
-Ben
Fixes #19

@barwin, thanks so much again (and sorry I'm so slow!) So far everything's working great in my trial run, I rewrote the Wiki instructions to match the new setup and will merge, then take a look at how this matches up with some of the new functions I'd been writing.
I extra appreciate the jest tests, testing is not my forte and this is a good kick in the pants to learn more!

Thanks for the merge @kate-hall :)  Glad to hear it's working for you as well.   Thanks again for a great project.

@kate-hall @barwin going to test it out now.  Thanks to both of you for the effort.

@kate-hall @barwin  I am happy to report that it is working.  It also found my 2 zones with no problem.  The odd thing is that it is showing I have them set to COOL / HEAT when they are cool only and when I asked to change the temperature - even though it worked - it told me they are set to keep the temperature between X and Y degrees.


⚠ PrivateHD has degraded performance

In 6a2043f, PrivateHD ($PHD) experienced degraded performance:

HTTP code: 200
Response time: 2280 ms

Resolved: PrivateHD performance has improved in 6f747b3.


Add a small "pre-train size calculation" section to the main read.me

It would be good to have a section in the top level read.me on initializing a new pre-train model of various common sizes (up to 70B) for each architecture.
ie:
For RWKV to initialize a pre-train model of size 70B set flags:
example.py --n_embd XXXXX etc
For transformer to initialize a pre-train model of size 70B set flags:
example2.py --some_flag etc
Do this for each arch at 3B, 7B, 34B, 70B (or just a few small and large examples each)

There is no such initialization needed currently. Let me know if there's
something I'm misunderstanding about your request tho!
On Wed, Feb 7, 2024, 9:44 AM bennmann @.***> wrote:

It would be good to have a section in the top level read.me on
initializing a new pre-train model of various common sizes (up to 70B) for
each architecture.
ie:
For RWKV to initialize a pre-train model of size 70B set flags:
example.py --n_embd XXXXX etc
For transformer to initialize a pre-train model of size 70B set flags:
example2.py --some_flag etc
Do this for each arch at 3B, 7B, 34B, 70B (or just a few small and large
examples each)
—
Reply to this email directly, view it on GitHub
https://github.com/SmerkyG/gptcore/issues/5, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACDK33VPGREMHUF3VGQGKWDYSPKRHAVCNFSM6AAAAABC6NLQ5OVHI2DSMVQWIX3LMV43ASLTON2WKOZSGEZDGNZUHE4TAMI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Requires Scope

Not sure if this is something specific to OAuth or not, but would a RequiresScope be worthwhile?

This package is mostly about integration with MS's IAuthenticatonManager which is about ClaimsPrincipal.
The answer is "I don't know" but my gut is saying it wouldn't feel right.

Am open to being educated on this...

In Thinktecture IdentityModel, you are provided with the following:
https://github.com/IdentityModel/Thinktecture.IdentityModel/blob/master/source/WebApi.ScopeAuthorization/ScopeAuthorizeAttribute.cs
I'm possibly being lazy, as it's just a specific claim type, but it expresses intent a bit more fluently.  Not sure exactly with the OAuth2 spec, but as I recall, one of the claims you get back from IdentityServer is specifically "Scope" that can be utilized to decide what sections of the system you have access to.  Dominick offered this, I believe, to be able to better break-up the system into areas of concern.

OAuth defines scopes - and the mentioned attribute is an Web API authorize attribute that checks for the presence of a given scope claim.
So in Nance - RequiresScope would be similar to that.
But not in this repo - as Damian said this is all about Katana integration.

Ok.  No worries.  Thx @leastprivilege for the clarification.

I do have this extension though
@dealproc you may have a point. But Nancy v2 is in the works and since it uses ClaimsPrincipal, I'll prob have to update this repo to remove this extension.


Explicit focus ring style

Use a similar focus-ring style as for many other elements (2px blue outline).
Remove unnecessary background-color override (no default theme anymore).
Center align text (nicer when the tab label wraps on multiple lines).
Fixes #77

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks broke.

theme/lumo/vaadin-tab.html, line 138 at r1 (raw file):

      /* Focus-ring */

please remove one empty line here to satisfy the stylelint:
 133:1  ✖  Expected no more than 1 empty line   max-empty-lines

Comments from Reviewable

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

theme/lumo/vaadin-tab.html, line 138 at r1 (raw file):
Previously, web-padawan (Sergey Kulikov) wrote…
please remove one empty line here to satisfy the stylelint:
 133:1  ✖  Expected no more than 1 empty line   max-empty-lines

Done.

Comments from Reviewable

Review status: all files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable


Performance fixes

I applied some of the fixes @aaronjwood point out on my last PR

Nice job @egimbernat! :)


Please consider fixing issues detected by repository checker

Notification from ioBroker Check and Service Bot
Dear adapter developer,
I'm the ioBroker Check and Service Bot. I'm an automated tool processing routine tasks for the ioBroker infrastructure. I have recently checked the repository for your adapter rmb-bhkw for common errors and appropiate suggestions to keep this adapter up to date.
This check is based the current head revisions (master / main  branch) of the adapter repository
Please see the result of the check below.
ioBroker.rmb-bhkw
   -
ERRORS:

[ ] :heavy_exclamation_mark: [E254] Version "1.1.0" listed at common.news at io-package.json does not exist at NPM. Please remove from news section.

WARNINGS:

[ ] :eyes: [W252] Version of package.json (1.1.0) doesn't match latest version on NPM (1.0.7)

:thumbsup: No suggestions found
Please review issues reported and consider fixing them as soon as appropiate.
Errors reported by repository checker should be fixed as soon as possible. Some of them require a new release to be considered as fixed. Please note that errors reported by checker might be considered as blocking point for future updates at stable repository.
Warnings reported by repository checker should be reviewed. While some warnings can be ignored due to good reasons or a dedicated decision of the developer, most warnings should be fixed as soon as appropiate.
You may start a new check or force the creation of a new issue at any time by adding the following comment to this issue:
@iobroker-bot recheck
@iobroker-bot recreate
Please note that I (and the server at GitHub) have always plenty of work to do. So it may last up to 30 minutes until you see a reaction. I will drop a comment here as soon as I start processing.
Feel free to contact me (@iobroker-bot) if you have any questions or feel that an issue is incorrectly flagged.
And THANKS A LOT for maintaining this adapter from me and all users.
Let's work together for the best user experience.
your
ioBroker Check and Service Bot
@mcm1957 for evidence
Last update at Fri, 13 Sep 2024 13:04:15 GMT based on commit d5d7dca73ac7d0202452cdb21a3d5f45799703af
ioBroker.repochecker 3.0.5

This issue has been updated by ioBroker Check and Service Bot
The following issues are new and have been added
[E011] "@iobroker/dev-server" must not be listed as dependency at package.json

This issue has been updated by ioBroker Check and Service Bot
The following issues have been fixed
[E011] "@iobroker/dev-server" must not be listed as dependency at package.json
:thumbsup:Thanks for fixing the issues.


Add cache for Go modules and npm packages

According to #209 , we want to add cache for tests CI to improve running time of tests. This PR added cache for both Go modules and Next.js/npm packages. Since setup-go GHA already has caching function built-in since V4, we only need to modify the sequence where we checkout the code. For node packages, following the guide from Next.js, I added cache for it.

Hm -- Brian Lin's approval appears to not have made GitHub happy so I'm seconding it to see if it'll greenlight.

It seems that GitHub says Brian Lin didn't have write access to the repo? I saw that as the reason it can't get merged yesterday.

It seems that GitHub says Brian Lin didn't have write access to the repo? I saw that as the reason it can't get merged yesterday.

Yup, approvals from people without write access to the repo are nice but not meaningful to GitHub's merge checks.


Updating order of 10 codes doesn't save

What version of Node.js are you using?
16.13.1
What version of npm are you using?
8.3.0
What operating system are you using?
Linux (ubuntu 20.04)
Describe the Bug
When re-ordering state codes in the admin values page, they do not save and re-order themselves afterwards.
Expected Behavior
When moving state codes it should stay in order to ensure that in the drop downs they are not mixed up.
To Reproduce

Also is it possible to not show situation codes when updating units statuses? Should this not only show the status codes? Situation codes should only apply to 911 calls and maybe incidents if that is added?


$notification->text and $notification->notifyBody

From what I can tell, these two attributes are equivalent (both contain the parsed notification category text), but $notification->text isn't always available. In my project, I have a simple GET route and controller method that returns a view to display a user's notifications, and I can use $notification->text there. However, in a custom sender class context, the 'text' property on a notification object returned by NotifynderSender::sendOne() contains null. notifyBody contains the parsed text, as expected.

Ok, found the problem. In the \Fenos\Notifynder\Models\NotifynderCollection::parse() it assigns the values to the text attribute but in the model itself it uses the notify_body key. Will create a PR for this to make it unique.

PR is opened - now both keys should be every time present.

Can you pls test if it fixes your problem, composer version: dev-issue-145
https://github.com/fenos/Notifynder/pull/151

Yeah, that works for me.

Ok, PR is merged and tagged: 3.2.11 - https://github.com/fenos/Notifynder/releases/tag/3.2.11


/glow is not working

Describe the bug
/glow is not a command even though the store site states it does with rune rank.
To Reproduce
Steps to reproduce the behavior:

go on to the server
Type in /glow
Unknown command error

Expected behavior
a /glow menu should show up where you can select your glow with the colours
Screenshots

Username:
JamieRRE
Server name (all applicable):
All

it's a planned feature, coming soon

closing this as a planned feature


Improvements on Dockerfile

Use Fedora as base, it contains more [updated] packages than CentOS
Invoke shell commands directly rather than invoke scripts

No luck with this?


📃: Sugarcane Leaf Disease Detection

:red_circle: Title : Sugarcane Leaf Disease Detection
:red_circle: Aim :

This project focuses on classifying sugarcane leaf diseases using different machine learning models. The dataset contains images of sugarcane leaves classified into various categories. Image preprocessing, data augmentation, and ensemble learning methods are applied to boost the model’s accuracy.
Feature Description

:red_circle: Brief Explanation :

Add a Jupyter notebook implementing an ensemble model for sugarcane disease prediction.
Combine multiple deep learning architectures: MobileNet, InceptionV3, VGG16, Conv2D, and ResNet152 into a cohesive model.
Implement data preprocessing steps, including image augmentation and normalization.
Conduct model training and evaluation, achieving an overall high accuracy
Included detailed comments and explanations throughout the notebook for clarity and reproducibility.
Visualized model performance metrics and comparison graphs for individual models.

Screenshots 📷

:white_check_mark: To be Mentioned while taking the issue :

Full name : Vivek Prakash
What is your participant role?
Gssoc-ext and hacktoberfest

Pls assign me level 3 as I will be implementing 5-6 deep learning models for ensemble model

@IkkiOcean based on the work i will update the labels, don't worry about it. Just keep contributing


METRON-1185: Stellar REPL does not work on a kerberized cluster when calling functions interacting with HBase

Contributor Comments
Because we put all the jars on the classpath from $METRON_HOME/lib via a glob, if we get the wrong order, we get classpath issues around Stopwatch (i.e. more recent guava may sneak onto the classpath first). This is non-deterministic and can cause issues randomly. Instead of a glob, we should choose one of the uber jars with all the metron Stellar functions baked in and allow users to provide any extra directories we should include via an env variable. Also, we are not pulling the full hbase classpath, so in a kerberized cluster we do not get all of the configs on the classpath, so we can't find always find tgts.
Pull Request Checklist
Thank you for submitting a contribution to Apache Metron.
Please refer to our Development Guidelines for the complete guide to follow for contributions.
Please refer also to our Build Verification Guidelines for complete smoke testing guides.
In order to streamline the review of the contribution we ask you follow these guidelines and ask you to double check the following:
For all changes:

[x] Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
[x] Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

For code changes:

[x] Have you included steps to reproduce the behavior or problem that is being changed or addressed?

[x] Have you included steps or a guide to how the change may be verified and tested manually?

[x] Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
mvn -q clean integration-test install && build_utils/verify_licenses.sh

[x] Have you written or updated unit tests and or integration tests to verify your changes?

[x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

[x] Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

For documentation related changes:

[x] Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes via site-book/target/site/index.html:
cd site-book
mvn site

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommended that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.

Is this just a temporary thing?
I think the longer term thing is to split the stellar out into their own modules, an possibly have modules split further by special dependencies.
I would like to do this with stellar extensions based on bundles.

@ottobackwards I'd argue that it SHOULD be a temporary thing.  At the moment things are broken as they are.

ok, if and when we look at stellar archetypes and extensions we'll have to keep this in mind

Ok, I just want to be completely clear, we're actually choosing one of our jars, the parsers jar, because it's an uber jar that has ALL of our stellar functions in Metron in it.  I'm also providing explicit support for the management functions.  This should make our classpath more deterministic, I think, and provide a mechanism that is more flexible for passing in custom jars (the env variable, rather than presuming users would drop things in $METRON_HOME/lib.

Whatever it takes in the meantime.  When this is plugin based, this all goes away.

So, I tested this on a kerberized multi-node cluster and full-dev.  I ensured that I tried with and without the management functions jar and with/without kerberos as well.

I'm +1 with this (as a temporary measure to make things work), assuming @ottobackwards and @nickwallen are as well.

@ottobackwards and @nickwallen any issues?

+1 by inspection.  I agree with @justinleet; its good for a temporary work around.  Thanks for the fix.

+1, just for the record


fix dns endpoint controller merged two different type record's targets with same dns name

What happened:
we have cluster A in zone A, cluster B in zone A,
now we create a federated service nginx, deploy service only in cluster A, then create a servicednsrecord associate with this federated service,  and dns endpoint will generate two zone-level endpoint with same dns name.
clusterA: nginx.default.dsj-test.svc.cn-north-7b.cn-north-7.jessiading.com:Record A: xxx.xxx.xxx.xxx
clusterB: nginx.default.dsj-test.svc.cn-north-7b.cn-north-7.jessiading.com:Record CNAME: nginx.default.dsj-test.svc.cn-north-7.jessiading.com
finally, controller will merge two endpont into one,  nginx.default.dsj-test.svc.cn-north-7b.cn-north-7.jessiading.com:Record A: xxx.xxx.xxx.xxx,nginx.default.dsj-test.svc.cn-north-7.jessiading.com
when external-dns create this endpoint in provider,  get error response, because Record A targets must be ipv4 address list.

/lgtm
/approve
Thanks @Dingshujie


Added REDIS_NO_AUTO_FREE_REPLIES flag

The new flag can be set on the redisOptions struct and given to the async connection. If set, the new flag makes sure the replies given to the async callback will not be freed by hiredis. Instead, the reply ownership is given to the callback and it's the user's
responsibility to free it when he finished using it.

Thanks for the PR!
This is a useful addition and small enough a change that we can probably get it in v1.0.1.
I'll also play around with how we might want this flag to work for PUSH messages as being able to retain those may also be useful for certain use cases.

@michael-grunder anything else you want me to change/add here?

Nope, I think it's good.  I'll get it merged over the weekend.

Merged, thanks! (and sorry for the delay)


feat: show status icon in the file header

This will only appear when the corresponding Sourcegraph extension for this language is enabled.
This does not check the health, and only shows green (not red or yellow)
There are no links to the /site-admin/code-intelligence page, upstream repo, bugs, etc.

@sqs How do we go about publishing this to Google Storage, and how does this get included in Sourcegraph instances? Do we manually upload the bundle to https://console.cloud.google.com/storage/browser/sourcegraph-cx-dev?project=sourcegraph-dev and overwrite v3.js?
TODO after merging: remove the existing indicator from webapp and browser extension

Will review today (GMT+2). See the readme for info on publishing it.

And if you don’t want to change behavior of existing instances, change the 3 to a 4 in the file name you upload and in sourcegraph. (Obviously normalizing this process is a priority, relevant to our chat yesterday about language support extensions.)


Cleanup timers when Menu component unmounts to prevent exceptions

I'm using Menu components inside an infinite scroll grid where non visible rows get unmounted. When users scroll quickly the Menu components can get unmounted before their timeouts fire, throwing exceptions when the timeout functions does eventually get invoked. This change stores handles to the timeouts and clears them when Menu unmounts.

Thanks!


Can not return a merged object via Object.assign within entity.set()

Describe the bug
entity.set does not work if returning a merged object with Object.assign
To Reproduce
const obj = entity({ x:1 })

var dataToBeUpdated = { x:2, y:1 }

const updateDoesNotWork = data => {
    obj.set( value => {
        return Object.assign(value, data)
    })
}

const updateWorks = data => {
    obj.set( value => {
        return {
            ...value,
           ...data
        }
    })
}

Expected behavior
Both scenario should work

Hi.  Those 2 are not equivalent.  The Object.assign() one is mutating the original object, then returns the same object.  Can you try this instead?
return Object.assign({}, value, data)

Closing issue as this does not appear to be a problem with the library at all.  Please see my comment above.


update build process

Could you please have look at the build process?
After cloning the repo, init submodule and running the build I got the following error:
Error: Could not resolve entry module (tinymce/modules/tinymce/lib/plugins/paste/main/ts/core/WordFilter)
FirstI think the directory structure is wrong, its now
tinymce/modules/tinymce/src/plugins/paste/main/ts/core/WordFilter
But the error still occurs after updateing the path.
thx

closed in https://github.com/jasonphillips/tinymce-word-paste-filter/pull/12

closed in https://github.com/jasonphillips/tinymce-word-paste-filter/pull/12


support jest-cli 0.8.0

Is this project still alive? This PR is needed.

If you'd like to use this PR now, it's possible to install by the following command.
npm install mas0061/gulp-jest.git

Fixed to used Jest 15.0.0


Render after watch includes live.js reloader

If I do:
bb quickblog watch

make some changes in a post and then close the watcher it renders as expected with a live.js script tag.
If I then do:
bb quickblog render

the generated HTML includes live.js, I would have expected it not to.
Doing bb quickblog clean before render works around this problem.

Taking a look now


Fix provider cipher reinit issue

Calling Init()/Update() and then Init()/Update() again gave a different result when using the same key and iv.
Cipher modes that were using ctx->num were not resetting this value, this includes OFB, CFB & CTR.
The fix is to reset this value during the ciphers einit() and dinit() methods.
Most ciphers go thru a generic method so one line fixes most cases.

Checklist

[ ] documentation is added or updated
[x] tests are added or updated

Would you mind wrapping your commit message  a little bit and adding the following two 'Fixes' lines?
Fix provider cipher reinit issue

Calling Init()/Update() and then Init()/Update() again gave a different result
when using the same key and iv. Cipher modes that were using ctx->num were not
resetting this value, this includes OFB, CFB & CTR.

The fix is to reset this value during the ciphers einit() and dinit() methods.
Most ciphers go thru a generic method so one line fixes most cases.

Fixes #12405
Fixes #12377

Travis job for #12414 finished with two failing jobs only. Failures are unrelated.

I assume you tested with @mattcaswell's reproducer from #12405, @slontis?

I assume you tested with @mattcaswell's reproducer from #12405, @slontis?

Yes I did.
A new test is added also..
This also found a few other issues in aes_siv and aes_ocb..

rebased with new commit message + test + fixes for aes

@slontis sorry for the force-push. I needed to rebase your pull request once more over ce3080e931d77fda3bb4f2d923fcc6cec967d1a3 in order to resolve the conflicts in my reseed-after-fork test #12413.

I won't be able to do a formal approval. But I rebased #12414 on top of your current HEAD to rerun the fork-on-reseed test on it.

I had to fix a travis compiler error anyway, so rebased and forced pushed again.
If you dont review and approve this PR may sit here for a while.

If you dont review and approve this PR may sit here for a while.

Are you blackmailing <...looks up dictionary...> extorting me?

Travis error was another memory leak in the siv_init() when the init was called multiple times..

The new test fixed up an issue in the newly merged cipher for aes_cts.
So a rebase with a few small fixes was required.
@t8m can you have another look now please.

This pull request is ready to merge

Thanks. Merged to master.


SOLR/API/IMPORTER - major infrastructure update

Issue #: /bcgov/entity#21174 , /bcgov/entity#21342
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the PPR license (Apache 2.0).

NOTE: importer CI is only failing because it is dependent on the api changes


Multi gpus training bug

Hi, thanks for sharing the code.  I encountered bug when I tried to make a finetuning on the VQA2.0 dataset. The logs are displayed as follows. The resulting accuracy is only 60, far short of what you did in your paper. I'm training with 2*2080ti graphics cards.
[1,0]:[2021-11-20 04:52:04.885367: W horovod/common/stall_inspector.cc:105] One or more tensors were submitted to be reduced, gathered or broadcasted by subset of ranks and are waiting for remainder of ranks for more than 60 seconds. This may indicate that different ranks are trying to submit different tensors or that only subset of ranks is submitting tensors, which will cause deadlock.
[1,0]:Stalled ranks:
[1,0]:0: [allreduce.cnn.feature.backbone.res3.0.conv1.weight, allreduce.cnn.feature.backbone.res3.0.conv2.weight, allreduce.cnn.feature.backbone.res3.0.conv3.weight, allreduce.cnn.feature.backbone.res3.0.shortcut.weight, allreduce.cnn.feature.backbone.res3.1.conv1.weight, allreduce.cnn.feature.backbone.res3.1.conv2.weight ...]
[1,0]:[2021-11-20 04:53:04.888208: W horovod/common/stall_inspector.cc:105] One or more tensors were submitted to be reduced, gathered or broadcasted by subset of ranks and are waiting for remainder of ranks for more than 60 seconds. This may indicate that different ranks are trying to submit different tensors or that only subset of ranks is submitting tensors, which will cause deadlock.
[1,0]:Stalled ranks:
[1,0]:0: [allreduce.cnn.feature.backbone.res3.0.conv1.weight, allreduce.cnn.feature.backbone.res3.0.conv2.weight, allreduce.cnn.feature.backbone.res3.0.conv3.weight, allreduce.cnn.feature.backbone.res3.0.shortcut.weight, allreduce.cnn.feature.backbone.res3.1.conv1.weight, allreduce.cnn.feature.backbone.res3.1.conv2.weight ...]

I am not sure how this error happens. For your lower accuracy, it might because that your setting differs from ours, e.g., you used fewer GPUs to train the model.

stalled ranks means that the different processes are not synced, hence one or more of them get stalled waiting for the other ranks. We also observed stalled ranks from time to time, this is  a warning message from horovod implementation, not from our code. Therefore, we do not have an immediate solution. Note that stalled ranks may cause the training stay idle, but if the experiment is still running when you see this warning message, the final performance should not be affected.
As mentioned by @jayleicn , the accuracy difference might be related to the number of GPUs, as our hyperparameters search is based on 4 V100 GPUs.
One possible way to reach similar accuracy is to increase the gradient accumulation steps. For example, double the gradient accumulation steps if you are using only two GPUs. And I suspect you also need to decrease the batch size to accommodate for 2080ti GPUs (11GB vs. 32GB used in our experiments). These are the factors that may impact the performance.


Add ADC sequence sample

The current ADC sample using "channel" DTS construction lacks flexibility in the sequence use. For example, if I create a struct adc_dt_spec like the sample says:
/* Data of ADC io-channels specified in devicetree. */
static const struct adc_dt_spec adc_channels[] = {
	DT_FOREACH_PROP_ELEM(DT_PATH(zephyr_user), io_channels,
			     DT_SPEC_AND_COMMA)
};

It is clear that each struct adc_dt_spec represents a channel from my DTS. There is no problem with that.
The issue happens when you try to make full use of the struct adc_sequence capabilities. Since you can specify more than one channel to read, let's say:
struct adc_sequence sequence = {
	.channels = BIT(0) | BIT(1) | BIT(2),
};

Passing the created channel as an argument of adc_read_dt(&adc_channels[i], &sequence) with a sequence that requires more than one channel (and possibly not the one you passed on the API call) is unintuitive and error-leading. What's the sense of passing a channel to read other channels?
To solve this, it feels natural to pass not the channel, but the ADC device as the dev argument of adc_read (and not the _dt version of it), and then make full use of struct adc_sequence.
This PR fits this purpose, showing a neat, clear way, to get the full value of struct adc_sequence on a batch reading, without losing coherence on the API calls.
The previous sample was moved to a new adc_dt directory.

Worth noting that even though this PR may look oversized, 82 of the files were just moved to a subdirectory in order from having another ADC sample. Revision and code changes are located in the second commit, where I actually make the new sample.

I have tried to get it working on nucleo_f429zi board. As long as I specify only one channel for the sequence (in the overlay), the results are as expected. With default 5 samples per channel.
But when I select more than one channel, the adc_read() is getting blocked - also with e.g. 1 or 2 samples per channel. No error à la -22 or whatever else is reported:
*** Booting Zephyr OS build v3.6.0-3796-g6b048fdf7109 ***
ADC sequence reading [0]:      # comment: failing multi-channel approach
*** Booting Zephyr OS build v3.6.0-3796-g6b048fdf7109 ***
ADC sequence reading [0]:
- adc@40012000, channel 3, 2 sequence samples:
- - 588 = 0mV    # comment: the failing mV is just a matter of missing mv
- - 663 = 0mV
ADC sequence reading [1]:
- adc@40012000, channel 3, 2 sequence samples:
- - 400 = 0mV
- - 500 = 0mV

For the purpose of this experiment I added an overlay file for the board - see patch file. The additions/changes are based upon recent commit 6b048fd.
When I inspect the code execution using breakpoints, the function set_sequencer() in drivers/adc/adc_stm32.c is iterated correctly, including correct processing of the set channel bits. After the setup is finished, I see no return from adc_context_wait_for_completion(&data->ctx). This is quite curious because there is no problem when only one channel is sequenced.
0001-samples-drivers-adc_sequence-for-nucleo_f429-board.txt (no patch-suffix: If you use Linux and try to upload a .patch file, you will receive an error message. This is a known issue.)

@wkhadgar - today, a nucleo C031C6 board arrived here. I encounter the same problem as with my added nucleo_f429zi overlay. Even in commit 6173f71 (samples: drivers: adc: naming adc sample), see below extract from latest commit and the commit just mentioned.
*** Booting Zephyr OS build v3.6.0-3797-gf04f5183f415 ***
ADC sequence reading [0]:
*** Booting Zephyr OS build v3.6.0-2899-g6173f71d42cd ***
ADC sequence reading [0]:

@rjmaris I took a note on that, made some static code review, and it seems to be something with the STM driver implementation...
Will try to debug the cause for this behavior, since the Zephyr side is configured accordingly to the sequence use, it falls on the API implementation to process and act as expected, reading the data as the sequence has been set to.
Since the call stack up to adc_context_wait_for_completion(&data->ctx) is ok (thus no error), I suspect the problem to be ISR related.

@wkhadgar  Thanks for your quick response! First of all: this sequencer approach is indeed the only reasonable way to process several channels, instead of the former approach. But where you recall the adc_context_wait... this now makes me aware of the fact that the efficiency gain (and approachable sample rate) related to the former approach is within certain limits, because the caller's program flow is halted during this wait.
Am I right in my guess that not all boards with overlay in this sequencer approach were actually tested to be functional? The reason that I ordered a nucleoC031C6 after persisting failing operation with my project board (STM32F4xx) is simply because it's a STM32 board.
At the moment I hardly can imagine to get the problem solved because of too little Zephyr experience. Perhaps a contributor to zephyrproject from ST could be contacted, and asked to look at this.

Meanwhile I had found a FRDM board in my office (the move to another office space gave rise to questions where stuff has been located). It's a FRDM-KL25z, but it may be expected that the sequencer will operate on all Kinetis based boards.
Because the order of sampling in sequence mode is not intuitively visible in the output, I have swapped both for loops. And made detail changes. It looks like this now:
*** Booting Zephyr OS build v3.6.0-3454-g0a4f1236bb06 ***
ADC sequence reading [0], 5 sequence samples:
      adc0.8       adc0.9       adc0.12      adc0.13
 1: 1025=0001mV  4095=0003mV  0002=0000mV  0260=0000mV
 2: 0789=0000mV  4095=0003mV  0002=0000mV  0267=0000mV
 3: 0763=0000mV  4095=0003mV  0001=0000mV  0315=0000mV
 4: 0934=0000mV  4095=0003mV  0001=0000mV  0410=0000mV
 5: 0697=0000mV  4095=0003mV  0001=0000mV  0277=0000mV
ADC sequence reading [1], 5 sequence samples:
      adc0.8       adc0.9       adc0.12      adc0.13
 1: 0265=0000mV  4095=0003mV  0002=0000mV  0237=0000mV
 2: 0648=0000mV  4095=0003mV  0001=0000mV  0459=0000mV
 3: 0807=0000mV  4095=0003mV  0001=0000mV  0406=0000mV
 4: 0841=0000mV  4095=0003mV  0001=0000mV  0490=0000mV
 5: 0865=0000mV  4095=0003mV  0001=0000mV  0429=0000mV
ADC sequence reading [2], 5 sequence samples:
      adc0.8       adc0.9       adc0.12      adc0.13
 1: 0267=0000mV  4095=0003mV  0002=0000mV  0243=0000mV
 2: 0407=0000mV  4095=0003mV  0001=0000mV  0243=0000mV
 3: 0565=0000mV  4095=0003mV  0001=0000mV  0245=0000mV
 4: 0783=0000mV  4095=0003mV  0000=0000mV  0472=0000mV
 5: 0830=0000mV  4095=0003mV  0001=0000mV  0551=0000mV

See attached patch.
Note: the '0' in 'adc0' should be made automatically right when channels might be attached to another adc unit. I don't know how to accomplish that (I remember dat in earlier Zephyr versions (pre 3.3?) this was dons so in the adc sample.
0001-samples-drivers-adc-adc_sequence-represent-output-ta.patch.txt

@rjmaris that is awesome! Loved the grouped view of the channels, really makes clearer how the sampling is made!


add ktepcknute.kyiv.ua domain

ktepcknute.kyiv.ua

@PrimeGlorious I have to close this request without merging, because you requested to add a non-existent domain to this repository: Host ktepcknute.kiev.ua not found: 3(NXDOMAIN) Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for your understanding!


[Bug] Button onClick-Js executed multiple times on page load, with no click

Description
Loading a page triggers multiple times the execution of javscript set in onClick button action
Steps to reproduce the behaviour:

Edit "AppSmith tutorial" app (or any); add a Button
In the onClick action of that new button, add some javascript instructions
Publish the application, visit the page, you will see that the javascript instructions have been executed multiple times (ex.: 7 times in my test case), despite the button not having been clicked yet.

@AndreaPravato this was a great catch! Fortunately, this does not affect actions such as APIs / navigation but I agree the evaluation should not take place in these cases as well.

This issue is no longer reproducible in production. It has been fixed as part of our performance upgrades.

This issue is no longer reproducible in production. It has been fixed as part of our performance upgrades.


rds: extracting base classes as reusable generic routing DS implementation.

Commit Message:
Extracting base classes from the existing code as reusable generic routing DS implementation.
Additional Description:

The current RDS implementation is tied to the HTTP protocol. To make it reusable for other protocols
base classes containing the generic part are extracted from the existing code.
The Config and RouteConfiguration proto classes are opaque for the generic implementation.
The location of the base classes are envoy/rds and source/common/rds and the Envoy::Rds namespace.
Existing code is reworked to use the base classes and HTTP specific features added back by decorator pattern
(StaticRouteConfigProviderImpl, RdsRouteConfigProviderImpl, RouteConfigUpdateReceiverImpl)
and template method pattern (RdsRouteConfigSubscription).
One thing which has to be implemented separately for every protocol is the Rds::ConfigTraits and Rds::ProtoTraits interface
which provides basic information about the otherwise opaque classes.
Other is a wrapper around the Rds::RouteConfigProviderManagerImpl which creates the provider
objects with the proper types.

This PR is split from #17631
Risk Level:
Medium
Testing:

Unittest
Manual test with static routing from bootstrap config, static routing and dynamic routing from GRPC based xDS server.

Docs Changes:
Release Notes:
Platform Specific Features:

@adisuissa do you want to take a first pas over this (see https://github.com/envoyproxy/envoy/pull/17631#issuecomment-955868494)?

/retest

/retest

I have moved the logic from the protocol specific manager completely to the Rds::RouteConfigProviderManagerImpl.
Now the Envoy::Rds contains every logic and no dependency on the specific route config type.

Looks like the main branch has evolved recently and needs to be merged.
/wait-any

/retest

@zuercher
Your comments for the generic part on #17631 are fixed here, please check the latest state.

Hi @htuch,
All comments so far embedded or explained but recently there was no reviewer activity. Do you have any suggestion how to move on?

@adisuissa can you take another pass on this one? Thanks.

Hi @adisuissa
Since this change is a little bigger and kind of core part, do you want any further split or description what would make the review easier?
Or is there any scenario what you think should be tested better with unittest or beyond the unittests?

/retest

/retest

/retest

/retest

@htuch I have made the ProtoTraits simplifications, please check once, thanks.

I find that with reviews like this, having some pointers to which code is cut+paste and which is new and/or worth paying attention to is helpful

Ok, I try to put together a summary about this.

/wait

@htuch here is the summary for the new files. I wrote what was the source and the changes compared to that for the cut+paste created ones:
envoy/rds/config.h
New
envoy/rds/config_traits.h
New
envoy/rds/route_config_provider.h
Same as old envoy/router/rds.h except:

The protocol specific requestVirtualHostsUpdate() removed.
In ConfigInfo the type of config_ has changed to Protobuf::Message and the version_ became const (because review comment).
The ConfigConstSharedPtr is the new dummy base Rds::Config not the old Router::Config

envoy/rds/route_config_update_receiver.h
Same as old envoy/router/route_config_update_receiver.h except:

Protocol specific resourceIdsInLastVhdsUpdate() vhdsConfigurationChanged() and onVhdsUpdate() have been removed.
The ConfigConstSharedPtr is the new dummy base Rds::Config not the old Router::Config
Protobuf::Message is used instead protocol specific route configuration.

source/common/rds/rds_route_config_provider_impl.cc/.h
Same as old Router::RouteConfigProviderImpl except:

Constructor simplified, the initial_config is fetched form the RouteConfigUpdateReceiver.
Until there is no valid config it will pass back the null Config implementation.
Protocol specific requestVirtualHostsUpdate() and VHDS handling from onConfigUpdate() have been removed.

source/common/rds/rds_route_config_subscription.cc/.h
Same as old Router::RdsRouteConfigSubscription except:

Inherited from Envoy::Config::SubscriptionCallbacks instead of Envoy::Config::SubscriptionBase since that requires the specific route configuration type.
The OpaqueResourceDecoder got as argument in constructor.
In constructor RouteConfigUpdateReceiver not created but got as argument.
In constructor config_source and route_config_name passed separately since the Rds proto is not generic.
In constructor rds type passed, this will be used directly in error messages and init manager.
(RDS is only for http, other protocols will have different name for example TRDS for thrift)
In constructor stat_prefix has to contain the rds type as well.
Is it ok or the lowercase rds type parameter should be appended automatically?
In onConfigUpdate() VHDS related parts replaced to virtual function call to beforeProviderUpdate() and afterProviderUpdate() by default they do nothing.
Can be these two merged into one?
Protocol specific maybeCreateInitManager() and updateOnDemand() has been removed.
Added initTarget() to retrieve parent_init_target_ (called by provider manager).

source/common/rds/route_config_update_receiver_impl.cc/.h
Same as old Router::RouteConfigUpdateReceiverImpl except:

Constructor initializes the config_ with the null Config implementation.
Protocol specific onVhdsUpdate(), removeVhosts(), updateVhosts() and VHDS related parts in onRdsUpdate() have been removed.
From onRdsUpdate() code couple public helper functions have been extracted to manage some members:
getHash(), checkHash(), updateConfig(), updateConfig()
For example the new Router::RouteConfigUpdateReceiverImpl has own onRdsUpdate() implementation where not possible to reuse this onRdsUpdate().
With these functions at least possible to decrease the duplication of the generic behaviour.

source/common/rds/static_route_config_provider_impl.cc/.h
Same as old Router::StaticRouteConfigProviderImpl except:

From constructor the registration of the instance has been removed. It is done by the provider manager.
Protocol specific requestVirtualHostsUpdate() has been removed.

source/common/rds/route_config_provider_manager.h
New

This interface is just to hide the provider manager details from the route config providers (RdsRouteConfigSubscription and StaticRouteConfigProviderImpl)
Is it ok or drop and refer to RouteConfigProviderManagerImpl directly?

source/common/rds/route_config_provider_manager_impl.cc/.h
The generic part of Router::RouteConfigProviderManagerImpl has been moved here.

The value type in dynamic_route_config_providers_ has been changed to RouteConfigProvider.
When the provider is reused the parent_init_target_ from the subscription is still needed but not reachable through this interface.
Because of this the init target is stored together with the provider as pair.
All the friend relation between the classes have been eliminated. The provider destructors (RdsRouteConfigSubscription and StaticRouteConfigProviderImpl) will call the eraseDynamicProvider() and eraseStaticProvider() for self deregistration instead of directly operate on members.
The addStaticProvider() and addDynamicProvider() do the same like old createStaticRouteConfigProvider() and createRdsRouteConfigProvider() except the provider object creation.
In dumpRouteConfigs() since subscription is not reachable for dynamic providers the same handling is used like for static providers.

source/common/rds/util.cc/.h
New

Is it ok or the lowercase rds type parameter should be appended automatically?

Probably fine, assuming there is a stat_prefix from each consumer supplied, it should be unique anyway.

Is there still any sense to use absl::optional to store the pointer back to the route config rovider?

Not sure? If it's not used, I'd drop it.

Is it ok, or drop and refer to RouteConfigProviderManagerImpl directly?

If the indirection isn't doing anything functional, I'd skip it.

Thanks so much for the detailed commentary, very helpful. @adisuissa said he would take a look shortly.
I've taken another pass over the implementation (not tests). LGTM,
@envoyproxy/senior-maintainers this is a pretty major refactor of RDS (mostly mechanical). It doesn't have any runtime guarding, which would be hugely messy to implement I think. Any thoughts on whether we should be asking for runtime guarding here?
I'm a little worried about the impact this PR might have

Is there still any sense to use absl::optional to store the pointer back to the route config rovider?

Not sure? If it's not used, I'd drop it.

I'm asking this because it is little cumbersome to downcast the provider pointer inside reference to absl::optional.
As I understand the RdsRouteConfigSubscription and RdsRouteConfigProviderImpl is created or destroyed together. The provider's constructor sets the this into route_config_provider_opt_ of the subscription which is used in onConfigUpdate().
Can it somehow happen the onConfigUpdate is called before the provider sets the this? I think no, but maybe I miss something.

I don't think so, that sounds broken if it is possible.

/retest

@htuch

I'm a little worried about the impact this PR might have

Actually I have a feeling this change will be never merged, however I also understand concerns because the risks.
So how about to split it into two again? One is the new common/rds/ part other is the common/router/ part.
The first has no risk so it could be merged more easily. However introduces some duplication temporarily but at least it will have own unittests. Now it is mostly tested by common/router/ which is a little odd.
Then we could merge the old thrift part, which has low risk and its major part, the interface change, was already accepted.
Finally the common/router/ part.

@tkovacs-2 yep. Let me ping maintainers again. I rather simplify and merge the current PR as is if folks will accept the potential risk on control plane (and potential for rollback). Otherwise we should follow your strategy.

I'm leaning towards merging without flag protection, since I think the only substantive change that might impact logic in a way that would not be obvious during canary and that poses risk here is around onRdsUpdate and it seems correct to me. @adisuissa will take another look as well.
@tkovacs-2 do you agree with this assessment or are there are other parts of the PR you would consider risky?
The other options is to consider increasing test coverage around the areas that seem risky.
I do worry a bit about the dangers of having large amounts of duplicate code flag protected, we know from the unified gRPC mux experience this is really hard to maintain and is not a healthy state for the code base during the period of flag protection.

The main struggle I'm having when reviewing this PR, is that it is unclear what is new and what is moved/refactored

https://github.com/envoyproxy/envoy/pull/18846#issuecomment-1008323530 has some explanation of this.

I rather simplify and merge the current PR as is if folks

What simplification do you mean?

are there are other parts of the PR you would consider risky?

I wouldn't say risky but maybe these two parts worth bigger attention:

Rds::RouteConfigProviderManager the hadling of init targets.
Rds::RdsRouteConfigSubscription::onConfigUpdate and the beforeProviderUpdate/afterProviderUpdate from Router::RdsRouteConfigSubscription

Also one question:
I added Router::RouteConfigUpdateReceiver::protobufConfigurationCast and Router::RouteConfigProvider::configCast methods to the interfaces to provide the downcasted routing config instead the generic opaque one.
But I'm not sure this is the best solution. Maybe some utility functions in the namespace would be better. Or any other idea?

Also one question: I added Router::RouteConfigUpdateReceiver::protobufConfigurationCast and Router::RouteConfigProvider::configCast methods to the interfaces to provide the downcasted routing config instead the generic opaque one. But I'm not sure this is the best solution. Maybe some utility functions in the namespace would be better. Or any other idea?

IMHO using template method in this case (if I understand correctly) makes sense. If we use a utility function, then I'm assuming that it will have some kind of if/switch statement, which is less favorable (e.g., if new types (if any) will need to be added). Another option is to use templated methods, but then it would look very similar to the static_cast call.

/wait

IMHO using template method in this case (if I understand correctly) makes sense. If we use a utility function, then I'm assuming that it will have some kind of if/switch statement, which is less favorable (e.g., if new types (if any) will need to be added). Another option is to use templated methods, but then it would look very similar to the static_cast call.

For example there is this call from vhds.cc: config_update_info_->protobufConfiguration().vhds().config_source()
Previously the Router::RouteConfigUpdateReceiver::protobufConfiguration gave back envoy::config::route::v3::RouteConfiguration but now just Protobuf::Message. The underlying object is still the same, but a static cast is needed to get back the full access.
For this I intoduced the Router::RouteConfigUpdateReceiver::protobufConfigurationCast but it has drawbacks, like:

Additional changes required for example in the mocks because the new method in the interface.
Such doesn't really belong to the interface.
I meant with the utility function the above call would look like this:
cast(config_update_info_->protobufConfiguration()).vhds().config_source()
The cast() would be defined in the Router namespace with the same signature and body like protobufConfigurationCast now.

@tkovacs-2 thanks for your patient and working through the feedback. @adisuissa appreciate the review bandwidth.