text:
ARC context switch to interrupted thread busted with CONFIG_ARC_FIRQ=y and CONFIG_NUM_IRQ_PRIO_LEVELS=1

Describe the bug
The ARC can be configured with support for fast IRQs and only a single priority level.  In this configuration, fast IRQs is the only interrupt type supported by the hardware.
However, the _switch_return_from_firq implementation is expecting the lowest priority interrupt to perform a "regular" interrupt return and thus restore context from the stack.  This does not happen with fast IRQs and therefore the processor state is not restored correctly on such a context switch.  The system immediately goes off the rails as, among other things, neither the stack pointer nor the program counter are restored correctly.
To Reproduce
Steps to reproduce the behavior:

Configure the ARC interrupt controller with firq_option=true and number_of_levels=1, and configure Zephyr to match.
Run any application that performs a context switch to a previously-interrupted task (I called k_msleep twice: the first context switch to the idle thread works but the second crashes after the idle thread is interrupted by the timer).
Watch the processor do crazy things.

Expected behavior
Processor state should be correctly restored.
Impact
Behaviour is essentially random, processor typically faults after a few instructions and the system halts.
Environment (please complete the following information):

OS: Zephyr
Toolchain Zephyr SDK
Version 2.6

The attached patch corrects the issue for me.
fix-arc-context-switch.patch.txt

Thanks Nick, for not only reporting the issue but also debugging and suggesting a fix.
Indeed the implicit assumption in the switch code is that a fake interrupt return can be done using the RIRQ. But, if the hardware is configured with only 1 priority (which is not very common, usually there are at least 2 levels), the rtie will follow the FIRQ sequence. We'll need to check if there are other corner cases for your configuration (are you using usermode?).
Would you like to submit your patch as a PR yourself, or do you prefer the ARC team to handle it further?

Probably best to have the ARC team handle it. The patch was the bare minimum to unblock our current project.

In discussion with the reporters, it was decided not to support the FIRQ with only single priority level. To avoid others run in the same issue, a constraint on the configurations is added in #39103.

authors: GavinGonsalves nbowlersnps ruuddw


text:
Newer versions of pylink are not supported in latest zephyr 2.7 release

Describe the bug
It is not possible to mix a zephyr 3.1.99 and zephyr 2.7.3 development environment on a single PC due to the code in zephyr 2.7 not supporting the renamed files in newer versions of pylink, when trying to run ninja debug:
-- west debug: rebuilding
ninja: no work to do.
-- west debug: using runner jlink
Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/jamie/.local/lib/python3.10/site-packages/west/__main__.py", line 3, in <module>
    main()
  File "/home/jamie/.local/lib/python3.10/site-packages/west/app/main.py", line 786, in main
    app.run(argv or sys.argv[1:])
  File "/home/jamie/.local/lib/python3.10/site-packages/west/app/main.py", line 109, in run
    self.run_command(argv)
  File "/home/jamie/.local/lib/python3.10/site-packages/west/app/main.py", line 343, in run_command
    self.run_extension(args.command, argv)
  File "/home/jamie/.local/lib/python3.10/site-packages/west/app/main.py", line 415, in run_extension
    command.run(args, unknown, self.topdir, manifest=self.manifest,
  File "/home/jamie/.local/lib/python3.10/site-packages/west/commands.py", line 135, in run
    self.do_run(args, unknown)
  File "/tmp/bb/zephyr/scripts/west_commands/debug.py", line 34, in do_run
    do_run_common(self, my_args, runner_args)
  File "/tmp/bb/zephyr/scripts/west_commands/run_common.py", line 228, in do_run_common
    runner.run(command_name)
  File "/tmp/bb/zephyr/scripts/west_commands/runners/core.py", line 509, in run
    self.do_run(command, **kwargs)
  File "/tmp/bb/zephyr/scripts/west_commands/runners/jlink.py", line 196, in do_run
    self.logger.info(f'JLink version: {self.jlink_version_str}')
  File "/tmp/bb/zephyr/scripts/west_commands/runners/jlink.py", line 171, in jlink_version_str
    major, minor, rev = self.jlink_version
  File "/tmp/bb/zephyr/scripts/west_commands/runners/jlink.py", line 155, in jlink_version
    lib = Library(dllpath=os.fspath(Path(self.commander).parent /
  File "/home/jamie/.local/lib/python3.10/site-packages/pylink/library.py", line 278, in __init__
    self.load(dllpath)
  File "/home/jamie/.local/lib/python3.10/site-packages/pylink/library.py", line 384, in load
    with open(self._path, 'rb') as inputfile:
FileNotFoundError: [Errno 2] No such file or directory: '/opt/SEGGER/JLink/jlinkarm.so'
FAILED: zephyr/cmake/flash/CMakeFiles/debug /tmp/bb/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/_AA/zephyr/cmake/flash/CMakeFiles/debug
cd /tmp/bb/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/_AA && /usr/bin/cmake -DTARGET=debug -DDEPENDENCIES="" -P /tmp/bb/zephyr/cmake/flash/check_runner_dependencies.cmake && /usr/bin/cmake -E env /usr/bin/python3.10 -m west debug
ninja: build stopped: subcommand failed.

To Reproduce
Get zephyr main, install requirements.txt, get zephyr 2.7.3, build and debug a project using ninja debug
Expected behavior
For the command to work
Impact
Probably a bug impact for people trying to use both environments
Environment (please complete the following information):

OS: Linux
Toolchain unrelated
Commit SHA or Version used: 003de78ce0dd213a1c7b3d159b967fb19a12aa45

Fixed by https://github.com/zephyrproject-rtos/zephyr/pull/49566

source: gharchive/issue

authors: nordicjm stephanosio

repo: zephyrproject-rtos/zephyr

license_type: permissive

license_source: github-api


text:
Add more GPIO flags for configuration inside devicetree

I want to configure GPIO's inside the devicetree. For that purpose I would like to use the gpio_dt_spec structure.
I wanted to make the following code work. I used the arm microchip mec152x in this example:
#define GET_DT_SPEC(n) GPIO_DT_SPEC_GET(n, gpios)
const struct gpio_dt_spec gpio_configs[] = {
	DT_FOREACH_CHILD_SEP(DT_NODELABEL(gpios), GET_DT_SPEC, (,))
};

void gpio_init()
{
	for (int i = 0; i < sizeof(gpio_configs)/sizeof(struct gpio_dt_spec); i++) {
		gpio_pin_configure(gpio_configs[i].port, gpio_configs[i].pin, gpio_configs[i].dt_flags);
	}
}

with this devicetree:
gpios {
    some_input_pin {
	gpios = <&gpio_000_036 0 GPIO_INPUT>;
    };
    some_output_pin {
	gpios = <&gpio_000_036 2 GPIO_OUTPUT_HIGH>;
    };
    unconnected {
	gpios = <&gpio_000_036 9 GPIO_DISCONNECTED>;
    };
    ...
};

This code is (thanks to zephy's devicetree/macro capabilties) quite small and get's the job done. Now sadly the gpio header for devicetree is currently missing most flags that I would need in order to configure the gpios (for example as input or output).
I have considered using pinctrl, but according to what I read in the documentation, pinctrl is not meant for GPIO's (https://docs.zephyrproject.org/latest/hardware/pinctrl/index.html#pin-control-vs-gpio). Furthermore it would seem to be more complicated to get that up and running for gpios.

Closing as #54110 was merged.


text:
cppcheck warnings in the eth_stm32_hal driver

Describe the bug
When running cppcheck (cppcheck-2.7)  it reported some suspicious code in drivers/ethernet/eth_stm32_hal.c.
drivers/ethernet/eth_stm32_hal.c:1398:16: portability: Shifting signed 32-bit value by 31 bits is implementation-defined behaviour [shiftTooManyBitsSigned]
  if (val & (1 << i)) {
               ^
drivers/ethernet/eth_stm32_hal.c:1397:16: note: Assuming that condition 'i<32' is not redundant
 for (i = 0; i < 32; i++) {
               ^
drivers/ethernet/eth_stm32_hal.c:1398:16: note: Shift
  if (val & (1 << i)) {
               ^
drivers/ethernet/eth_stm32_hal.c:1398:16: error: Signed integer overflow for expression '1<<i'. [integerOverflow]
  if (val & (1 << i)) {
               ^
drivers/ethernet/eth_stm32_hal.c:1397:16: note: Assuming that condition 'i<32' is not redundant
 for (i = 0; i < 32; i++) {
               ^
drivers/ethernet/eth_stm32_hal.c:1398:16: note: Integer overflow
  if (val & (1 << i)) {
               ^

To Reproduce
Use cppcheck to analyze the code.
Expected behavior
No warnings.
Impact
Mostly annoying, but being in the murky corners of the C standard is never good (see "undefined behaviour)
Fix
In function reverse() of drivers/ethernet/eth_stm32_hal.c, on line 1353, change
if (val & (1 << i)) {
to
if (val & (1UL << i)) {
Additional context
The change is so small and silly so it would be more job to produce a pull request. Hope this is acceptable.

Thanks for reporting the analysis of the cppcheck.
Even if "trivial" you could directly raise a Pull Request with this fix (without going through an issue). Then sort that  PR with  trivial label

authors: FRASTM spe-ciellt


text:
Introduce mcux driver for new unified counter/rtc interface

Implements the new counter API for mcux rtc, based on #8340.

Codecov Report

Merging #11347 into topic-counters will not change coverage.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           topic-counters   #11347   +/-   ##
===============================================
  Coverage           53.11%   53.11%
===============================================
  Files                 218      218
  Lines               26868    26868
  Branches             5952     5952
===============================================
  Hits                14271    14271
  Misses              10162    10162
  Partials             2435     2435

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 564f02e...7b0c354. Read the comment docs.

@MaureenHelm you need to rebase on top of topic-counter, since the branch now contains the additional commits

@MaureenHelm, please check #11204. It's an attempt to provide compatibility layer for legacy API's. To make rtc.h work additional function must be added to counter.h for getting user_data where RTC callback is stored. It must be added to counter based on mcux rtc. Since it is not yet in #11204 you would need to rebase on that or do it in second step when #11204 goes in.

@MaureenHelm you need to rebase on top of topic-counter, since the branch now contains the additional commits

Done, sorry for the delay. The combination of some rebasing problems and travel made this take longer than it should have.

source: gharchive/pull-request

authors: MaureenHelm carlescufi codecov-io nordic-krch


text:
kernel: fixup thread monitor locking

The lock in kernel/thread.c was pulling double-duty, protecting
both the thread monitor linked list and also serializing access
to k_thread_suspend/resume functions.
The monitor list now has its own dedicated lock.
The object tracing test has been updated to use k_thread_foreach().
Signed-off-by: Andrew Boie andrew.p.boie@intel.com

note: the remaining use of 'lock' in thread.c (serializing k_thread_suspend() and k_thread_resume()) I have suspicions would be better served by the sched_lock, but I'm still analyzing this and will address, if needed, in another PR.

@andrewboie  please rebase

authors: andrewboie nashif


text:
kernel: use sched lock for k_thread_suspend/resume

This logic should be using the sched_lock and not its own
separate lock for these two functions.
Some simplications were made; z_thread_single_resume and
z_thread_single_suspend were only used in one place, and there was
some redundant logic for whether to reschedule in the suspend case.
Signed-off-by: Andrew Boie andrew.p.boie@intel.com

This exposed a stack overflow issue in samples/smp/pi, added a patch to fix it.

@andrewboie on question regarding smp/pi example: was it affected by the first change in this series? I.e. memory corruptions were not seen before? I don't see significant difference in stack usage w/ your first patch...

@andrewboie on question regarding smp/pi example: was it affected by the first change in this series? I.e. memory corruptions were not seen before? I don't see significant difference in stack usage w/ your first patch...

Memory was always corrupted on x86-64, my patch subtly altered memory layout which produced a crash (the timeout_lock specifically was being corrupted)

authors: abrodkin andrewboie


text:
Bluetooth: controller: Fixes for extended advertising

Some fixes for extended advertising found during dev and testing.

Separate into 3 different PRs:

Bluetooth: controller: Fix AdvA/TgtA for extended adv PDUs
Related to scan response
Other timing and hci cmds related, keep in this PR.

authors: andrzej-kaczmarek cvinayak


text:
drivers: gpio_ite_it8xxx2: fix use of uninitialized variable

Retain the assumption that the loop will assign a pointer, but
initialize it pointer first to eliminate build warnings.
Fixes nightly build failure: https://buildkite.com/zephyr/zephyr-daily/builds/204

This board seems to have gotten in with a codeowner that does not exist, and "it8" isn't mentioned in maintainers.  @YCSu0517 who added it in  #26297 doesn't seem to be associated with the project so can't be added as a reviewer.
I've adding people who seem to be associated with this board, but this should get cleaned up so other maintainers don't have to search for people to confirm fixes.

This board seems to have gotten in with a codeowner that does not exist, and "it8" isn't mentioned in maintainers.  @YCSu0517 who added it in  #26297 doesn't seem to be associated with the project so can't be added as a reviewer.
I've adding people who seem to be associated with this board, but this should get cleaned up so other maintainers don't have to search for people to confirm fixes.


text:
modules: Introduce hal-nxp-mcux-sdk

Introduces the new GitHub-based distribution of the MCUXpresso SDK as a
module in the west manifest. This new distribution provides the same
bare metal drivers as those downloaded from mcuxpresso.nxp.com and
imported into the hal_nxp module, however in this distribution they are
organized in a different directory structure that doesn't duplicate each
driver for every device. It can be integrated as-is into Zephyr without
the reorganization done in the hal_nxp module, and will therefore
simplify future updates of the SDK into Zephyr.
Currently the west manifest points to an NXP-hosted GitHub repo, but
will be updated once we have a Zephyr-hosted fork available.
Signed-off-by: Maureen Helm maureen.helm@nxp.com

[ ] Depends on #32278
[ ] Depends on NXPmicro/mcux-sdk#6

cc: @nxp-susan

I assume its reasonable to say that for a given board/SoC we'd never mix drivers from one HAL or the other? If this is the case, seems like we can simplify the Kconfig a bit.

I hope so, but I'm not sure yet.

Feels like you can use the same Kconfig symbols in both the current zephyr HAL repo and the new mcux-sdk based repo, and just have a high level switch on MCUX v MCUX_SDK.

I agree having both MCUX and MCUX_SDK prefixed symbols feels like a lot of duplication, but I also don't think there should be any interdependencies between the two modules. If we did have a unified set of Kconfig symbols, where would they be defined? Also, the MCUXpresso SDK is considering adding support for Kconfig in NXPmicro/mcux-sdk#6, in which case we would only use the symbols in Zephyr, not define them in Zephyr.

Don't the symbols need to be defined in Zephyr in order not to break Kconfig for people with custom west manifests where the MCUX SDK is not included?

Don't the symbols need to be defined in Zephyr in order not to break Kconfig for people with custom west manifests where the MCUX SDK is not included?

Now that you mention it, I think I remember hearing this during one of the module discussions.
@tejlmand can you give some guidance? Is there a way we can use Kconfig symbols defined in a module? These symbols are not specific to Zephyr and could be used by other projects.
This is a simplified version of what I want to do:
In the module:
config HAS_MCUX_SDK_DRIVER_FLEXCAN
	bool

config MCUX_SDK_DEVICE_MK64F12
	bool "MK64F12"
	select HAS_MCUX_SDK_DRIVER_FLEXCAN

config MCUX_SDK_DRIVER_FLEXCAN
	bool "FLEXCAN"
	depends on HAS_MCUX_SDK_DRIVER_FLEXCAN
	help
	  Build the FlexCAN bare metal driver

In Zephyr:
config CAN_MCUX_FLEXCAN
	bool "MCUX FlexCAN driver"
	depends on HAS_MCUX_SDK_DRIVER_FLEXCAN
	imply MCUX_SDK_DRIVER_FLEXCAN
	help
	  Build the FlexCAN shim driver

Don't the symbols need to be defined in Zephyr in order not to break Kconfig for people with custom west manifests where the MCUX SDK is not included?

Now that you mention it, I think I remember hearing this during one of the module discussions.
@tejlmand can you give some guidance? Is there a way we can use Kconfig symbols defined in a module? These symbols are not specific to Zephyr and could be used by other projects.

If you refer to a Kconfig symbol defined in a module from a Kconfig file in the Zephyr repo, then that symbol must also exists inside Zephyr itself, in order for everything to work when the module is not present.
This is why all known Zephyr modules have their Kconfig files inside the Zephyr repo: https://github.com/nrfconnect/sdk-zephyr/tree/master/modules
If you only want the settings visible / configurable to the user when the module is actively present, then you can just have a dummy duplication inside Zephyr.
Like this:
if 0
# These are dummy definitions to avoid unknown symbols when the module is missing.
config HAS_MCUX_SDK_DRIVER_FLEXCAN
	bool

config MCUX_SDK_DRIVER_FLEXCAN
	bool
endif

config CAN_MCUX_FLEXCAN
	bool "MCUX FlexCAN driver"
	depends on HAS_MCUX_SDK_DRIVER_FLEXCAN
	imply MCUX_SDK_DRIVER_FLEXCAN
	help
	  Build the FlexCAN shim driver

That will ensure Zephyr builds, and only if the module is present, then the settings are configurable as those settings are now available in the module with prompts.
This is in principle what we do here:
https://github.com/zephyrproject-rtos/zephyr/blob/0106d8f2a391fffcefabd053e17c683ea2e53d8a/modules/Kconfig#L69-L74
and then as soon as the module is present, the Kconfig file is sourced properly with all symbols available to the user :smile:

authors: MaureenHelm henrikbrixandersen tejlmand


text:
samples: clock_skew: conversion of k_work API

Replace all existing deprecated API with the recommended alternative.
Fixes #34096

@nordic-krch since I was anyway at the original commit I have split it out.

closing in favor of #33355


text:
Add missing net_buf_unref for non-recoverable errors while sending l2cap data

In case the connection breaks while transmitting, the net_buf while be dequeued but not unreferenced.

I updated the commit message and also removed the trailing whitespace to hopefully get through compliance.

Sign-off was missing for compliance.

Does bt_l2cap_chan_send() require a similar fix (end of the function)?

@Vudentz @joerchan would be good if you guys could take a look, since this brings back memories of the ref-counting discussion we had a few months ago 😄

@Vudentz @joerchan would be good if you guys could take a look, since this brings back memories of the ref-counting discussion we had a few months ago

@jhedberg Perhaps we should add the DNM label if we want their input first

@jhedberg Perhaps we should add the DNM label if we want their input first

@Thalley I dismissed my own review until then, which does the same trick in practice (can't merge now)

Vudentz joerchan would be good if you guys could take a look, since this brings back memories of the ref-counting discussion we had a few months ago

So this is a regression due to that change. I suggest to add this comment above the net_buf_unref .
				/* The ownership of the buffer is with the stack
				 * since bt_l2cap_chan_send has returned success
				 */

@joerchan I think a comment won't hurt, so I just went ahead and added it 👍

@prathje Thanks. I think you could squash the two commits though.

@prathje Thanks. I think you could squash the two commits though.

Yes, I have thought of that but decided not to as the first commit has been merged already (https://github.com/nrfconnect/sdk-zephyr/pull/555). I am happy to merge if you still prefer it?

@prathje Thanks. I think you could squash the two commits though.

Yes, I have thought of that but decided not to as the first commit has been merged already (nrfconnect/sdk-zephyr#555). I am happy to merge if you still prefer it?

That has not been merged to Zephyr, this commit was cherry-picked into a fork of the Zephyr repo.

@prathje That's not a problem, what Carles said is correct, so please squash them. But thank you for being considerate.
If you keep the first commit message it will go smoothly.

@carlescufi @joerchan Thanks! With the requested comment removal, we are back to just the first commit anyway. I also did a quick rebase 👍

authors: Thalley carlescufi jhedberg joerchan prathje


text:
[drivers]: :counter :sam expose RC reg to DT

Exposes the RC register so that the initial value can be set in
the device tree. This is useful in the case where the timer
generates an event but an interrupt is not required.
e.g generate event to sample adc on RC register match.
Tested on Atmel SMART SAM E70 Xplained Ultra board
Signed-off-by: Marius Scholtz mariuss@ricelectronics.com

Oh, there is one thing, actually: @mcscholtz , could you please change the commit shortlog to drivers: counter: sam: expose RC reg to DT instead?

Oh, there is one thing, actually: @mcscholtz , could you please change the commit shortlog to drivers: counter: sam: expose RC reg to DT instead?

Thanks, will do.

authors: mbolivar-nordic mcscholtz


text:
Add PLL2 clock support for STM32H7

Adds PLL2 clock support to STM32 H7 clock driver similarly to existing PLL3.
Allows usage of PLL2 P/Q/R for peripherals. Tested with SPI1,2,3 using PLL2P.
Resolves #51785.
Corrects H7 PLL div-m description in the bindings file. The value shall start from 1.

@FRASTM I looked into it a bit.
The test suit supposed to run on NUCLEO-H723ZG.  When I re-create clock configuration within Cube-MX from existing core_init.overlay and optionally anything else (i.e. spi1_pll3p_1_d1ppre_4.overlay), then such clock configuration is considered to be invalid:

The clock configuration that is described in core_init.overlay fits discontinued NUCLEO-H743ZI that exists in Zephyr:

It seems like existing NUCLEO-H743ZI board definition in Zephyr won't work for the newer  NUCLEO-H743ZI2 due to invalid USART clock configuration:

I am not sure if existing test-suit really works on platform_allow: nucleo_h723zg. Unfortunately, I don't have aforementioned boards to test and clean everything up.

The test suit supposed to run on NUCLEO-H723ZG. When I re-create clock configuration within Cube-MX from existing core_init.overlay and optionally anything else (i.e. spi1_pll3p_1_d1ppre_4.overlay), then such clock configuration is considered to be invalid.

This configuration is valid when using VoltageRegulatorScaling scale 0, which is the case in Zephyr, but indeed not valid  in default CubeMx configuration (VOS3).

@erwango thank you for having a look. Indeed, that was the issue.
@FRASTM rebased and added a test for PPL2_P to be as the source for SPI1.
Is there any reason that PLL clock configuration tests modify d1ppre? It is set to 1 in the core_init.overlay, then changed in different PLL tests to 1 or 4. Considering that used SPI1 sits on APB2 that is not affected by d1ppre is it a mistake?

Rebased and resolved a conflict that appeared after the #52582 merge.

authors: GeorgeCGV erwango


text:
lib: os: fix armclang compiler warnings with is*() functions

We get compile warnings of the form:
error: converting the result of
'<<' to a boolean; did you mean
'((_aeabi_ctype_table + 1)[(byte)] << 28) != 0'?
[-Werror,-Wint-in-bool-context]
if (!isprint(byte)) {
^
Since isprint (and the other is* functions) return an int, change check to an explicit test against the return value.

oh and also: why wasn't this caught before? doesn't our CI test with armclang?

oh and also: why wasn't this caught before? doesn't our CI test with armclang?

CI doesn't test armclang.


text:
tests: cpp/libcxx: change test filter for picolibc

TOOLCHAIN_HAS_PICOLIBC actually does not exist, so the test never runs under twister. Use CONFIG_PICOLIBC_SUPPORTED instead for filter (the same as in tests/lib/cpp/cxx).

Yeah, for the C++ library to work, we need the toolchain to provide the C library too -- the C++ library won't work unless it's built against the matching C library. This test is different -- it needs the C++ library, unlike the other C++ test.
The Zephyr SDK does define TOOLCHAIN_HAS_PICOLIBC in cmake/zephyr/generic.cmake:
$ grep TOOLCHAIN_HAS_PICOLIBC ./cmake/zephyr/generic.cmake
set(TOOLCHAIN_HAS_PICOLIBC ON CACHE BOOL "True if toolchain supports picolibc")

I do get tests built (and run) when using the 0.16.2-rc1 Zephyr toolchain; are you experimenting with something else?

Ah... missed that one in SDK.
Let me dig deeper to see why twister is not building the picolibc test.

authors: dcpleung keith-packard


text:
[devicetree] Add some APIs

Added IS_NEQ, DT_COMPAT & DT_COMPAT_AT_IDX

Putting this back to draft, as the need has not arise yet


text:
LE Audio shell better LTV prints

Improves how the LTV values in codec capabilities and codec configurations are printed, so that it is more human readable.
fixes https://github.com/zephyrproject-rtos/zephyr/issues/53199

Rebased to solve merge conflicts

Rebased to solve merge conflicts


text:
pinctrl: Allow applying pins of disabled peripherals

According to the nrfx peripheral resource sharing example in samples/boards/nrf/nrfx_prs it should be possible to share a resource and apply the pins on peripheral that share resource ID. However the sample only works since it only demonstrates UART and SPIM, and by enabling both another SPIM driver, and UART is enabled for the console. It would not be possible to enable a TWIM driver in addition. Instead allow the PSELs if the configuration for NRFX has been enabled.

It is the approach recommended to solve the problem of peripheral instance sharing though, it is demonstrated here:
https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/boards/nrf/nrfx_prs/src/main.c#L148

It is the approach recommended to solve the problem of peripheral instance sharing though, it is demonstrated here: https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/boards/nrf/nrfx_prs/src/main.c#L148
Also, this is basically what the zephyr drivers is doing, so I don't really see the issue in allowing the user to write their own drivers in the same way. The only issue is that the pin-assignment code is compiled out when no device has status okay.

This was probably blindly converted, but mixing direct HAL access with Zephyr way of doing things is not a good idea. If you need the HAL, the only thing you should do is to make sure the module you're using gets compiled (often using Kconfig glue code like CONFIG_NRFX_SPIM, or CONFIG_USE_STM32_LL_SPI), the rest depends on how the HAL works, not how Zephyr works.

The problem is how to get in this sample the pin numbers from the board definition.

It is the approach recommended to solve the problem of peripheral instance sharing though, it is demonstrated here: https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/boards/nrf/nrfx_prs/src/main.c#L148
Also, this is basically what the zephyr drivers is doing, so I don't really see the issue in allowing the user to write their own drivers in the same way. The only issue is that the pin-assignment code is compiled out when no device has status okay.

This was probably blindly converted, but mixing direct HAL access with Zephyr way of doing things is not a good idea. If you need the HAL, the only thing you should do is to make sure the module you're using gets compiled (often using Kconfig glue code like CONFIG_NRFX_SPIM, or CONFIG_USE_STM32_LL_SPI), the rest depends on how the HAL works, not how Zephyr works.

The problem is how to get in this sample the pin numbers from the board definition.

When using HAL directly in applications (not in drivers), devicetree should be avoided.

drivers: pinctrl_nrf:

Thanks. Updated, but I don't know how to address the comment from @gmarull .

@gmarull @anangl Can you help resolve the issue?

authors: anangl gmarull joerchan


text:
Still more scheduler-related refactoring

Discovered a bunch of cut-and-paste fixery while dealing with the scheduler rewrite that would be more cleanly expressed if I fixed up the code to begin with.
No behavior changes here, just refactoring.

Codecov Report

Merging #7461 into master will decrease coverage by 0.46%.
The diff coverage is 90.62%.

@@            Coverage Diff            @@
##           master   #7461      +/-   ##
=========================================
- Coverage   55.26%   54.8%   -0.47%
=========================================
  Files         467     440      -27
  Lines       51645   50334    -1311
  Branches     9886    9678     -208
=========================================
- Hits        28543   27585     -958
+ Misses      19192   18955     -237
+ Partials     3910    3794     -116

Impacted Files
Coverage Δ

kernel/include/ksched.h
93.82% <ø> (-0.43%)
:arrow_down:

include/kernel.h
94.73% <ø> (ø)
:arrow_up:

kernel/mempool.c
92.06% <100%> (-0.48%)
:arrow_down:

kernel/stack.c
94.59% <100%> (ø)
:arrow_up:

kernel/sched.c
86.19% <100%> (+0.4%)
:arrow_up:

kernel/sem.c
83.33% <100%> (-8.34%)
:arrow_down:

kernel/timer.c
93.82% <100%> (ø)
:arrow_up:

kernel/mem_slab.c
100% <100%> (ø)
:arrow_up:

kernel/include/wait_q.h
100% <100%> (ø)

kernel/queue.c
87.65% <100%> (ø)
:arrow_up:

... and 39 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 071212b...6d8b2a2. Read the comment docs.

Think I got this one fixed up now.  Note that the build failures are the whole point: _wait_q_t used to be a typedef for sys_dlist_t, allowing for all sorts of direct usage all over the tree.  Now it's an opaque (but identical as far as the generated code goes) type that fails when used like that.
Note also that there's a false positive checkpatch failure: this isn't adding a new typedef, it's redefining one that was already there.

need rebase

authors: andyross codecov-io nashif


text:
arch: riscv: stacktrace: fix user thread stack bound check

According to the riscv's arch.h:
 +------------+ <- thread.arch.priv_stack_start
 | Guard      | } Z_RISCV_STACK_GUARD_SIZE
 +------------+
 | Priv Stack | } CONFIG_PRIVILEGED_STACK_SIZE
 +------------+ <- thread.arch.priv_stack_start +
                   CONFIG_PRIVILEGED_STACK_SIZE +
                   Z_RISCV_STACK_GUARD_SIZE

The start of the privilege stack should be:
thread.arch.priv_stack_start + Z_RISCV_STACK_GUARD_SIZE
Instead of
thread.arch.priv_stack_start - CONFIG_PRIVILEGED_STACK_SIZE
The end of the privilege stack will always be the start + CONFIG_PRIVILEGED_STACK_SIZE, regardless of
CONFIG_PMP_POWER_OF_TWO_ALIGNMENT

It might be better not to rely too much on CONFIG_PRIVILEGED_STACK_SIZE
directly as it ends up being subjected to extra rounding and alignment
through Z_STACK_PTR_ALIGN(). Might be worth to double-check against the
actual code in setup_thread_stack() and arch_user_mode_enter().

Thanks for the insights

It might be better not to rely too much on CONFIG_PRIVILEGED_STACK_SIZE
directly as it ends up being subjected to extra rounding and alignment
through Z_STACK_PTR_ALIGN().

Should it be
Z_STACK_PTR_ALIGN(_current->arch.priv_stack_start + K_KERNEL_STACK_RESERVED + CONFIG_PRIVILEGED_STACK_SIZE);

instead? According to
https://github.com/zephyrproject-rtos/zephyr/blob/80ce7d2315046e0852e6b95036baf29d62ac731b/arch/riscv/core/thread.c#L143-L145

If it is the privileged/exception stack for user threads that you need then
arch_curr_cpu()->arch.user_exc_sp would be its top.

So yes, that's pretty much equivalent.

Maybe this ought to be abstracted in a single location eventually.
It is too easy to change one spot and miss the other otherwise.

Maybe this ought to be abstracted in a single location eventually. It is too easy to change one spot and miss the other otherwise.

what if we store in some where, just like what we did with the stack_info?

ping @fkokosinski @kgugala @tgorochowik

authors: npitre ycsin


text:
Bluetooth: Classic: Add support for Serial Port Profile (SPP)

add spp client and server feature
select the condig
CONFIG_BT_SPP
then we could experience SPP Server  with shell

> uart:~$ bt init
> uart:~$ spp register_cb
> uart:~$ spp register_srv  9
> uart:~$ br pscan on
> uart:~$ br iscan on

your phone which was installed spp tool, could discovery the device，and connect it，after paring done，HID server would be connected

uart:~$ spp send  //would send test data {0, 1, 2, 3, 4, 5}

besides, you phone could send data as well.
then we could experience SPP Client  with shell
> uart:~$ bt init
> uart:~$ br connect 44:71:47:XX:XX:XX

when br connection ready, then you could connect spp service
> uart:~$ spp connect
>
> uart:~$ spp send  //would send test data {0, 1, 2, 3, 4, 5}

I think the one obvious question that this raises, is should this go the same way as #69881 did. I think it should, i.e. it'd make a lot of sense to be able to represent SPP connections using the Zephyr UART API, and create new instances based on devicetree nodes.

I think the one obvious question that this raises, is should this go the same way as #69881 did. I think it should, i.e. it'd make a lot of sense to be able to represent SPP connections using the Zephyr UART API, and create new instances based on devicetree nodes.

I agree this makes sense - I think having the SPP API be used by the UART driver (uart_bt_classic.c?), instantiated on dts (compatible: zephyr,spp_uart?) would connect both pieces together.

I think the one obvious question that this raises, is should this go the same way as #69881 did. I think it should, i.e. it'd make a lot of sense to be able to represent SPP connections using the Zephyr UART API, and create new instances based on devicetree nodes.

I agree this makes sense - I think having the SPP API be used by the UART driver (uart_bt_classic.c?), instantiated on dts (compatible: zephyr,spp_uart?) would connect both pieces together.

Is it possible that the physical interface is not UART, such as USB-CDC? Or the "UART" is not a specific asynchronous serial communication peripheral, but a general term for all peripherals that can be virtualized into this "UART".

Is it possible that the physical interface is not UART, such as USB-CDC? Or the "UART" is not a specific asynchronous serial communication peripheral, but a general term for all peripherals that can be virtualized into this "UART".
Correct. That's exactly what NUS does on uart.bt. See:
https://github.com/zephyrproject-rtos/zephyr/blob/386263cc668b10a2546b93a2a3e7444d75b7b05d/drivers/serial/uart_bt.c#L258-L272

I think the one obvious question that this raises, is should this go the same way as #69881 did. I think it should, i.e. it'd make a lot of sense to be able to represent SPP connections using the Zephyr UART API, and create new instances based on devicetree nodes.

the gatt uart nut service has no middle-layer abstract code, if we would like to adapter it， we nee to add some middle-layer  for spp
Beside,  IPSP(Internet Protocol Support Profile )  maybe is  also a good way to encode and decode IPV4 net packet from user.

Touching base here: what is a good hardware to test this PR? Not familiar with BT classic-supported targets in Zephyr


text:
drivers: nrfwifi: Fix random MAC address setting

Random MAC address setting can never be configured as the two defaults cover all cases. Fix the defaults, now the order is

Fixed
OTP (default, in case of no config)
Random

@hlord2000 FYI.


text:
Codemod for adapting contracts to be valid backing implementations for proxies

With the fixed proxy model, any Solidity contract can be a backing implementation for a proxy as long as it does not rely on any constructor logic. Such logic needs to be moved to an initialize method, to be called only once.
Research building a preprocessing step for automating this procedure with existing contracts.

I don't think codemod is the right concept here because it is apparently a tool used for refactors.
When I proposed this idea I was talking about a preprocessing step to be always run before deploying a new version of a contract.

Alternatively a linter to validate, instead of a preprocessor.

@spalladino can I close this one since https://github.com/zeppelinos/labs/pull/127 was already merged?

authors: facuspagnuolo frangio spalladino

repo: zeppelinos/labs

license: MIT


text:
Adding REST API consumable as an independent app.

Is it possible to get this feature so that we are not obliged to always go through CLI? I would like to use this app as an external independant exe plug-in for my software?

Hi @gdeverlant, currently I am in the process of developing the core features for the software. It is being designed keeping exports in mind, however, right now moving out of the CLI is out of scope.

authors: gdeverlant zerefwayne

repo: zerefwayne/quizgo


text:
Proposal: scopes

scope is function that's return new entity with cloned dependencies. All examples and comments in the tests.

React example:
<Provider scope={createScope()}>...
// ...
const Component = () => {
  const storeScoped = useStore(useScope(store))
  const eventScoped = useScope(event)

Cloning a single entity is a wrong way to do that, as everything exists in graphs only

authors: artalar zerobias

repo: zerobias/effector


text:
goctl template  --home 指定自定义模板目录不生效

我还是用中文描述吧！
Describe the bug
goctl release v1.2.4 使用 --home 指定自定义模板目录不生效
版本：
➜ goctl --version
goctl version 1.2.3-cli darwin/amd64

To Reproduce
Steps to reproduce the behavior, if applicable:

The code is
➜ goctl api go -api="test.api" -dir="api" -style GoZero --home ./template/1.2.3-cli

The error is

我修改了默认模板中 api 的 handler 和 logic 模板  api/handler.tpl 和 api/logic.tpl ，通过上面的命令生成后发现还是使用的默认自带的模板。
更具体一点，我是参照 https://go-zero.dev/cn/template.html 这个例子，更改了 handler 中的返回格式 将 httpx.OkJson(w, body) 改成了 reponse.Response(w, resp, err)  这种。
开始我以为是目录的问题，然后我就放到了 ~/.goctl 下面，测试发现还是不生效。
后来我又换回了之前使用的 goctl v1.2.1 , 发现这个是生效的。所以怀疑是 v1.2.4 有问题。
Expected behavior
A clear and concise description of what you expected to happen.
Environments (please complete the following information):

OS: [macbook 11.4]
go-zero version [1.2.4]
goctl version [1.2.4]

More description
Add any other context about the problem here.

so do I

感谢反馈，这个问题已经发现了，目前我们已经在讨论这个解决方案，目前的解决方案是在通过 --home 指定的目录下需要创建一个与 goctl 版本号的目录来存放你的模板，这样 --home才能生效，如你的 goctl 版本为 1.2.3, 你的自定模板版本应该在 path/to/custom/1.2.3/templates, 那么 --home 指定的值应该为 path/to/custom

突然有一个想法，是否可以根据goctl的当前版本来自动判断加载哪个目录。或者是，将版本作为一个参数传入。
当然，不清楚你们这样设计的目的是为什么解决什么问题。只是觉得对于开发者来说，在使用上还是越简单越好，可能设计就会比较复杂一些。
谢谢！

这个问题在哪个版本解决掉了呀？我go-zero 1.6.3 版本还是有这个问题

@kesonan 这个问题在哪个版本解决掉了呀？我go-zero 1.6.3 版本还是有这个问题

authors: 1278651995 anqiansong leafney pengmingfong

repo: zeromicro/go-zero


text:
建议新版本生成model代码将sql统一从方法中分离出来，方便自己扩展方法调用，达到更新数据库而不需要修改自己的代码。

现在生成的代码如下:
func (m *defaultCompanyModel) Insert(data *Company) (sql.Result, error) {
	query := fmt.Sprintf("insert into %s (%s) values (?, ?, ?, ?, ?, ?, ?, ?, ?)", m.table, companyRowsExpectAutoSet)
	ret, err := m.conn.Exec(query, data.ComId, data.CompanyName, data.Telephone, data.Email, data.Status, data.ShareRatio, data.GameList, data.CreatedAt, data.UpdatedAt)
	return ret, err
}

期待一:将sql改成变量，方便自定义方法调用，解决更新字段不需要修改自己代码问题
type(
query := fmt.Sprintf("insert into %s (%s) values (?, ?, ?, ?, ?, ?, ?, ?, ?)", m.table, companyRowsExpectAutoSet)
)
func (m *defaultCompanyModel) Insert(data *Company) (sql.Result, error) {
	ret, err := m.conn.Exec(query, data.ComId, data.CompanyName, data.Telephone, data.Email, data.Status, data.ShareRatio, data.GameList, data.CreatedAt, data.UpdatedAt)
	return ret, err
}

期待二:生成代码模板新增一个Trans,供自定义方法调用，解决 对应数据表更新后需要修改Exec对应字段问题
type (
	query := fmt.Sprintf("insert into %s (%s) values (?, ?, ?, ?, ?, ?, ?, ?, ?)", m.table, companyRowsExpectAutoSet)
)
func (m *defaultCompanyModel) TransSession(session sqlx.Session, data *Company) (err error) {

	_, err = session.Exec(query, data.ComId, data.CompanyName, data.Telephone, data.Email, data.Status, data.ShareRatio, data.GameList, data.CreatedAt, data.UpdatedAt)
	return err
}

func (m *defaultCompanyModel) TransConn(data *Company) (err error) {

	_, err = m.conn.Exec(query, data.ComId, data.CompanyName, data.Telephone, data.Email, data.Status, data.ShareRatio, data.GameList, data.CreatedAt, data.UpdatedAt)
	return err
}

最终model代码大概如下:
	CompanyModel interface {
		Insert(data *Company) (sql.Result, error)
		FindOne(id int64) (*Company, error)
		Update(data *Company) error
		Delete(id int64) error
		CompanyBase
	}

type (
	CompanyBase interface {
		FindOneByTeleOrEmail(telephone string, email string) (*Company, error)
		InsertTrans(session sqlx.Session, data *Company) (err error)
	}
)

Duplicate of #1431

authors: jsonMark kevwan


text:
fixed use of args variable

Fixed use of wrong variable.
As stated in https://github.com/zerossl/certbot-zerossl/issues/3 and https://github.com/zerossl/certbot-zerossl/issues/4 this was suggested by others before.

@StefanMarkmann Is this still a problem? Could merge in case, although  in my opinion it was most probably a quoting problem which made the leading dash cause errors?

Closed as very old and no an answer provided.

authors: Blackbam StefanMarkmann

repo: zerossl/zerossl-bot


text:
social links? et cetera

I see how to edit the main content, but I am not seeing how to edit markdown files in order to, say, change the GitHub link to point to my own profile. In a related thing, I wound up editing the theme itself to change the URL link in the subfooter and I think that that was not what you intended. Are there markdown files that control these things? Thanks, I love the theme!

Well, I found the social links at least in "base directory > data > social.json". Hope that helps anyone else with the same question!

repo: zerostaticthemes/hugo-hero-theme


text:
Support for convert reserved words to uppercase

Most sql formats are have reserved keywords, SELECT, FROM, WHERE, as uppercase. It would be nice to add in a configuration option to convert these words to uppercase.

That has been requested before, but it's not quite as easy as it sounds. See #22
If you're interested in this, then perhaps you're interested enough to move that pull request forward. The main problem there being that we currently don't have a list of keywords that could be always safely capitalized.

authors: nene rigogsilva

repo: zeroturnaround/sql-formatter

license: mit

license_source: bigquery


text:
組み込みのpwdコマンドがUNCパス上で正しく動作しない

UNCパス上でpwdコマンドを実行してもホスト名と共有名を返しません。
例えば
\\foo\bar\hoge\fuga

でpwdを実行した場合、実行結果は
hoge\fuga

となります。
commands/pwd.go内のdos.Getwdに原因があるようでos.Getwdだと大丈夫です。

dos.Getwd はカレントディレクトリの英大文字・小文字を正しく修正するコードがあるのですが、UNCパスのホスト名で、ディレクトリ一覧を取れなくなってエラー扱いされてしまっていたようです。
エラーになったら、そこで大文字・小文字の修正をストップして、エラー自体は無視し、その時点のものをそのまま使用するようにしました。バイナリは、Lua 5.3 対応あたりが出来ましたらアップします。

ありがとうございます。 c3d5c756a107b1af517ab945e0300e4dfabc2c2d で修正されていること確認いたしました。
こちらのissue閉じさせて頂きます

repo: zetamatta/nyagos


text:
Filter logs created by APIs

Allow the client developper to chose log level of the APIs

closed by #6

authors: aGautrain ghoullier

repo: zetapush/zetapush-angular


repo: zhangkaitao/es


text:
ajax访问html页面中js执行问题

您好，是这样的：首先使用了Mobilebone.evalScript=true，然后在a页面通过ajax无缓存的访问b页面（如果有缓存的话b页面的js只会第一次执行），b页面通过api中说的外链形式加载并执行b.js。但是让我来回在a和b页面访问时候b.js的script会多次append到页面中，请问这样会不会对页面b.js中方法调用产生问题？如果通过记录历史只加载一次b.js,不重复加载相同的js，但是又要保证每次访问b页面的时候b.js都得执行一次。这有什么好的解决方案吗？会不会在下一个版本中修复一下

你好，可以试试使用onpagefirstinto回调，或者你判断下b.js是否已经加载过~

页面内的JS不是经常要做绑定数据之类的事情吗？如果把这些js的执行顺序调后一点是不是会好点，那就不会经常要处理dom未加载完的问题了。延时执行之类的办法我觉得都不太靠谱啊。因为这个问题，iscroll经常出现高度计算不足的问题，浪费了不少精力都没处理好，暂时只能用setTimeout的办法，timeout设定长了会影响体验。

authors: dancinglone duyinghua zhangxinxu

repo: zhangxinxu/mobilebone


text:
🛑 ZY is down

In 3c18b3c, ZY (https://ziyuan.baidu.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZY is back up in 4a417e3.

repo: zhaodylan/uptime-ziyuan


text:
Add new target

Congratulations on a great project !!
I would like to add a new target to my XIAOMI 4A router, but it probably exceeds my capabilities - please add the default mt7621 target to your project, it will be easier for me to modify it for my router :)

Hi, thank you for your advice. But unfortunately there is not enough time for me to maintain this project recently. The RT-BOOT only support the kernel on MT7621, which means the RT-BOOT kernel can work fine on MT7621. The bootstrap for MTK platform is finished so it is easy to build a image for SOC of MTK such as MT7621 and that image will work and boot rtos kernel. However, no uart driver or net driver is supported. Porting these drivers from linux is a time-consuming work, especially the net driver. That's why this project has been suspended.

I'm sorry to hear that, but learning is the most important :)
Unfortunately, I won't write drivers without any examples.
I can only count on anyone else being interested in this great project :)
Best regards and best teach results!

repo: zhaohengbo/rt-boot


text:
author添加email信息

当我在author后添加email时："fileheader.Author": "Nemo xxxxx@dddd.com", 显示效果为：* @Author: Nemo <xxxxx@dddd.com> ，请问这个无问题如何解决

在这里添加试试
"fileheader.customMade": {
"Author": "myname, e-mail: test@abc.com"
}

authors: happyangry ying-bin

repo: zhaopengme/vscode-fileheader


text:
ARNPerf with CAR issue

If ARNPerf stays with CAR, and moves around, the data record maybe incomplete.
Sometimes, Perf.py will do nothing and hang over 20 seconds.
The solution is, the ARN device stays with ARNPerf, should always be configured as EAR!
-- from Kevin Zhang

After discussing with Kevin, I think it's the CPU over heat caused this issue.
With Kevin's help, will identify if new shielding can stopped the CPU's head radiation.

repo: zhaoqige/ARNPerf


text:
当启用用Dall-E-3画图插件后，提出的问题和响应回复的问题存在很大差异，关闭后正常

前置确认

[X] 我确认我运行的是最新版本的代码，并且安装了所需的依赖，在FAQS中也未找到类似问题。

⚠ 搜索issues中是否已存在类似问题

[X] 我已经搜索过issues和disscussions，没有跟我遇到的问题相关的issue

操作系统类型?
MacOS
运行的python版本是?
python 3.9.18
使用的chatgpt-on-wechat版本是?
Master (branch)
运行的channel类型是?
wx(个人微信, itchat)
复现步骤 🕹
chatgpt-on-wechat版本

config.json（对token进行了去除）
{
"channel_type": "wx",
"model": "",
"text_to_image": "dall-e-2",
"voice_to_text": "openai",
"text_to_voice": "openai",
"proxy": "",
"hot_reload": false,
"single_chat_prefix": [""],
"single_chat_reply_prefix": "",
"group_chat_prefix": ["@AI生活助手"],
"group_chat_in_one_session": [""],
"image_create_prefix": ["帮我画","画","帮我绘","绘"],
"speech_recognition": true,
"group_speech_recognition": false,
"voice_reply_voice": false,
"conversation_max_tokens": 2500,
"expires_in_seconds": 3600,
"character_desc": "你是ChatGPT, 一个由OpenAI训练的大型语言模型, 你旨在回答并解决人们的任何问题，并且可以使用多种语言与人交流。",
"temperature": 0.7,
"top_p": 1,
"subscribe_msg": "感谢您的关注！\n这里是ChatGPT，可以自由对话。\n支持语音对话。\n支持图片输入。\n支持图片输出，画字开头的消息将按要求创作图片。\n支持tool、角色扮演和文字冒险等丰富的插件。\n输入{trigger_prefix}#help 查看详细指令。",
"use_linkai": true,
"linkai_app_code": "nRuWui6M",
"linkai_api_base":"https://api.link-ai.chat"
}
link-ai后台配置

问题与回复

不正常的（Dall-E画图插件状态为开启）

正常的（Dall-E画图插件状态为关闭）

问题描述 😯
参考复现步骤
终端日志 📒
[INFO][2023-12-08 19:53:45][link_ai_bot.py:97] - [LINKAI] query=帮我起十个博客标题，主题是MySQL，内容包括MySQL是什么，有点和缺点、适用场景，我挑一个最好的, app_code=nRuWui6M, model=, file_id=None
[INFO][2023-12-08 19:54:08][link_ai_bot.py:109] - [LINKAI] reply=1.MySQL是什么的可视化表示（作为一个有利于可靠性和速度的开源数据库系统构建）。2.展示MySQL优缺点的插图，可能以图标或符号的平衡比例表示。3.MySQL适用的各种场景的描述，如电子商务网站、数据仓库或在线交易处理。4.一张图片，突出了MySQL使用的最佳场景（例如繁忙的市场），展示了其性能和可扩展性。, total_tokens=0
[INFO][2023-12-08 19:54:08][link_ai_bot.py:350] - [LinkAgent] use plugins: ['Dall-E画图']
[INFO][2023-12-08 19:54:09][wechat_channel.py:191] - [WX] sendMsg=Reply(type=TEXT, content=1.MySQL是什么的可视化表示（作为一个有利于可靠性和速度的开源数据库系统构建）。2.展示MySQL优缺点的插图，可能以图标或符号的平衡比例表示。3.MySQL适用的各种场景的描述，如电子商务网站、数据仓库或在线交易处理。4.一张图片，突出了MySQL使用的最佳场景（例如繁忙的市场），展示了其性能和可扩展性。), receiver=@00559ab4d41d892e0251aa8954bda0904cf75fbb36285bdc1f1d19b551c5960a
[INFO][2023-12-08 19:54:11][wechat_channel.py:207] - [WX] download image success, size=3147861, img_url=https://image-1317903499.cos.accelerate.myqcloud.com/delle/b6f12d2b-2883-4623-8ef5-9a74e075cf74.png
[INFO][2023-12-08 19:54:17][wechat_channel.py:210] - [WX] sendImage url=https://image-1317903499.cos.accelerate.myqcloud.com/delle/b6f12d2b-2883-4623-8ef5-9a74e075cf74.png, receiver=@00559ab4d41d892e0251aa8954bda0904cf75fbb36285bdc1f1d19b551c5960a
[INFO][2023-12-08 19:54:38][link_ai_bot.py:97] - [LINKAI] query=帮我起十个博客标题，主题是MySQL，内容包括MySQL是什么，有点和缺点、适用场景，我挑一个最好的, app_code=nRuWui6M, model=, file_id=None
[INFO][2023-12-08 19:54:39][wechat_channel.py:54] - Wechat message 5345584840041485303 already received, ignore
[INFO][2023-12-08 19:54:43][link_ai_bot.py:109] - [LINKAI] reply=当然，以下是十个关于MySQL的博客标题，希望你会喜欢：

1.《MySQL数据库详解：优缺点与最佳应用场景》
2.《MySQL解密：功能概述、优势劣势及典型应用场景》
3.《深入探讨MySQL：特点、不足和最佳使用场景全面分析》
4.《MySQL数据库综述：功能特性、优势劣势及最佳适用场景》
5.《MySQL数据库全方位解析：优势、劣势与最佳应用场景详解》
6.《MySQL内幕揭秘：特点、不足及最佳应用场景深度剖析》
7.《MySQL数据库完全攻略：功能特性、优缺点及最佳应用场景一览》
8.《了解MySQL：特点、不足和最佳适用场景深入剖析》
9.《MySQL数据库详细介绍：功能特点、优劣势及最佳使用场景解读》
10.《MySQL数据库解读：功能、优势劣势及最佳应用场景全面指南》

希望你能找到一篇满意的博客题目！, total_tokens=1276
[INFO][2023-12-08 19:54:44][wechat_channel.py:191] - [WX] sendMsg=Reply(type=TEXT, content=当然，以下是十个关于MySQL的博客标题，希望你会喜欢：

1.《MySQL数据库详解：优缺点与最佳应用场景》
2.《MySQL解密：功能概述、优势劣势及典型应用场景》
3.《深入探讨MySQL：特点、不足和最佳使用场景全面分析》
4.《MySQL数据库综述：功能特性、优势劣势及最佳适用场景》
5.《MySQL数据库全方位解析：优势、劣势与最佳应用场景详解》
6.《MySQL内幕揭秘：特点、不足及最佳应用场景深度剖析》
7.《MySQL数据库完全攻略：功能特性、优缺点及最佳应用场景一览》
8.《了解MySQL：特点、不足和最佳适用场景深入剖析》
9.《MySQL数据库详细介绍：功能特点、优劣势及最佳使用场景解读》
10.《MySQL数据库解读：功能、优势劣势及最佳应用场景全面指南》

希望你能找到一篇满意的博客题目！), receiver=@00559ab4d41d892e0251aa8954bda0904cf75fbb36285bdc1f1d19b551c5960a

应该是 DALL-E 插件 对意图的判断 有点问题， 刚刚调整了一下 策略你再试试看
如果需要严格匹配，也可以把插件关了，使用image_create_prefix 关键词匹配的方式来画图

应该是 DALL-E 插件 对意图的判断 有点问题， 刚刚调整了一下 策略你再试试看
如果需要严格匹配，也可以把插件关了，使用image_create_prefix 关键词匹配的方式来画图

经过实际的测试，该问题依旧存在，测试方式：
1.更新同步自有仓库的Sync fork。git log如下
`[root@ip-172-31-14-64 chatgpt-on-wechat]# git log
commit 95260e303c8407279db17ac401f4f3ac0bbb714f (HEAD -> master, origin/master, origin/HEAD)
Author: zhayujie yjzha1996@163.com
Date:   Mon Dec 11 20:48:13 2023 +0800
fix: process markdown url in knowledge base

commit be0bb591e71a54cc43488a4d0c9dca51646d229c
`
2.重新启动项目，执行scripts/start.sh
3.重新测试生成图片的功能

Dall-E画图插件未启用
当Dall-E画图插件未启用时，通过回复如下：
 "image_create_prefix": ["帮我画","画","帮我绘","绘", "生成"],

Dall-E画图插件启用后

目前我不知道我该如何解决这个问题，只能把Dall-E画图插件关掉，希望能得到官方的支持，或者是我的测试方法不对？那么作者告诉我该如何测试？

应该是 DALL-E 插件 对意图的判断 有点问题， 刚刚调整了一下 策略你再试试看
如果需要严格匹配，也可以把插件关了，使用image_create_prefix 关键词匹配的方式来画图

谢谢，经过测试，在关闭DALL-E插件的情况下，通过关键词可以发起对图片的创造。但是对于文本内容的响应，识别度不是很高。比如：

我要求的是十个，返回的只有一个。
[INFO][2023-12-12 17:08:22][link_ai_bot.py:99] - [LINKAI] query=帮我起十个博客标题，主题是MySQL，内容包括MySQL是什么，优点和缺点、适用场景，我挑一个最好的、, app_code=nRuWui6M, model=, file_id=None [INFO][2023-12-12 17:08:25][link_ai_bot.py:111] - [LINKAI] reply=当数据库与MySQL相遇：揭秘这一关系型数据库的特点、优势和劣势，以及最佳适用场景, total_tokens=872 [INFO][2023-12-12 17:08:25][wechat_channel.py:191] - [WX] sendMsg=Reply(type=TEXT, content=当数据库与MySQL相遇：揭秘这一关系型数据库的特点、优势和劣势，以及最佳适用场景), receiver=@66a57f9e1d96e5c5e33799d1ecf06b707a861fe93133c538137388c89cc65ecd
不知道是我的提问问题，还是后端语义解析的问题。

repo: zhayujie/chatgpt-on-wechat


text:
How to test on a single image?

Hi,
thank you for your work, I like the results. We are thinking about utilizing the model to improve the registration pipeline for pairs of images. However, I am not successful in using the code for testing on our dataset. I would find it very useful if you could provide some info about how to get predictions from inputs which are not in the IIW/SAW dataset format - e.g. how to get an output from a single image.
Best regards,
Milan Pultar

Hi,
thank you for your work, I like the results. We are thinking about utilizing the model to improve the registration pipeline for pairs of images. However, I am not successful in using the code for testing on our dataset. I would find it very useful if you could provide some info about how to get predictions from inputs which are not in the IIW/SAW dataset format - e.g. how to get an output from a single image.
Best regards,
Milan Pultar

Did you manage to make it work on single image? Can you share any script for others to use?

No, sorry. I haven't paid much attention to this since I wrote this question. But it looks like it should not be too hard to create such script.

I succeeded in testing on a single image with the provided pre-trained model, but found severe checkerboard artifacts. It may be because of the image pre-process.

I can load pretrained model. However, the outputs are two gray-scale (single) channel images. One looks like shading and another I am not sure (residual?). Is this correct?
Minimal code to import pretrained model:
from CGIntrinsics.models.intrinsic_model import * from CGIntrinsics.models.networks import * from CGIntrinsics.models.base_model import * cgnet = define_G(input_nc=3, output_nc=3, ngf=64, which_model_netG="unet_256") cgnet.load_state_dict(torch.load("pretrained_models/cgintrinsics_iiw_saw_final_net_G.pth")) cgnet = cgnet.cuda(); cgnet.eval();

I succeeded in testing on a single image with the provided pre-trained model, but found severe checkerboard artifacts. It may be because of the image pre-process.

I personally think the checkerboard artifacts are caused by the deconv layers and the unreasonable implementation of computing image gradient.
I solved the checkerboard artifacts by addressing the above two problems.

I succeeded in testing on a single image with the provided pre-trained model, but found severe checkerboard artifacts. It may be because of the image pre-process.

I personally think the checkerboard artifacts are caused by the deconv layers and the unreasonable implementation of computing image gradient.
I removed all the checkerboard artifacts by addressing the above two problems.

Hello, could you please share how you address the two problems ? Thank you!

I succeeded in testing on a single image with the provided pre-trained model, but found severe checkerboard artifacts. It may be because of the image pre-process.

I personally think the checkerboard artifacts are caused by the deconv layers and the unreasonable implementation of computing image gradient.
I removed all the checkerboard artifacts by addressing the above two problems.

Hello, could you please share how you address the two problems ? Thank you!

Replace deconv layers with upsample. This can reduce artifacts but lead to larger computation.
It's hard to explain why the implementation of computing image gradients is unreasonable. Please compute the image gradient by x_(i+1) - x_i, rather that 'x_(i+2) - x_i'. Skipping the pixel x_(i+1) leads to artifacts.

This is my NIID-Net. Hope the modified loss functions  can help you.

authors: HawaiiZeng MayuOshima SystemErrorWang anandbhattad pultarmi tlsshh

repo: zhengqili/CGIntrinsics


text:
如何插入照片？

resume-photo.tex这个文件好像并没有包含照片。请问怎么做出resume-photo.pdf那种效果呢？多谢。

感谢指出这个问题. 问题来源于resume-photo.tex中有关学校logo以及个人照片的相关代码在https://github.com/zheyuye/resume-chinese/commit/13f2a7f632f9ac16eff999efc38ad65a680c90b9 中没有及时更新.
现以在#4 中得到修复,  overleaf版本也会及时更新.

authors: liujqian zheyuye

repo: zheyuye/resume-chinese


text:
🛑 腾讯云 COS 节点 is down

In 53520d2, 腾讯云 COS 节点 (https://lisz.ink) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 腾讯云 COS 节点 is back up in 84be4bc.

repo: zhonger/upptime


text:
🛑 腾讯云 COS 节点 is down

In 69141cf, 腾讯云 COS 节点 (https://lisz.ink) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 腾讯云 COS 节点 is back up in f744f6d.


text:
关于数据集最短长度的问题

我自己的数据集在训练过程中出现__len__() should return >= 0问题，因为我的数据集为股市日度数据，长度较短，所以我尝试将原数据集ETTh1缩短寻找问题，发现原本train+val+test的长度为8521+2857+2857，当数据集长度大于该值时train、val、test长度不变，小于该值时train、val不变，test缩短，继续缩短数据集长度到小于8521+2857时，训练同样报错__len__() should return >= 0，请问这是因为模型已经规定了数据集的最短长度了吗？有没有哪些参数可以修改改变这一现状呢？

你可以修改def len(self)这个函数，或者调整ETT数据集里面的size参数。

你可以修改def len(self)这个函数，或者调整ETT数据集里面的size参数。

请问应该在哪里修改呢？我没有找到这个函数的位置或是size参数……

请问解决了吗？能解释一下为什么长度固定吗？

我也遇到这个问题，数据集过短导致的，seq_len和pred_len有限制，你的数据集大小应该符合下面情况：
custom模式下
[train, test, vail] ->[data70%, test20%, vail 剩下的 ]
border1s=[0, train-seq_len, data-test-seq_len]
border2s=[train, train+vail, data]
最终在len输出时候还要满足：
三划分之一的长度 - seq_len - pred_len +1 >0
所以你应该在main_informer里修改这三个参数的大小
parser.add_argument('--seq_len', type=int, default=24, help='input sequence length of Informer encoder') parser.add_argument('--label_len', type=int, default=16, help='start token length of Informer decoder') parser.add_argument('--pred_len', type=int, default=24, help='prediction sequence length')

也可以考虑修改DatasetCustom部分的代码

authors: MountVoom kuraoumu rintoo wjmbalala zhouhaoyi


text:
源码包要怎么安装？

如题，不会编译，求方法。

同求 有没有哪位大神编译一下

百度 学习 自己动手自动享受~

我打包成功了，但太极那边提示不支持这个版本，大佬可以修改一下太极那边支持的版本吗 或者我自己另外上传个版本自己用？ @zhudongya123

大佬分享下安装包，教程也可以，感谢。

@muihiuwev
执行bat，然后执行.\gradlew assembleRelease , 就打包好了

需要装个java8，然后用keytool生成打包apk需要的key文件，把配置信息写到local.properties文件里, 然后装个安卓sdk(需要28版本的api和build tool)
用到的链接
https://blog.csdn.net/m0_47265814/article/details/112758292
https://blog.csdn.net/huanglei201502/article/details/88533134
https://blog.csdn.net/qq_52183856/article/details/123496936
https://blog.csdn.net/z2431435/article/details/121086844
不想自己打包，或者详细教程的，加我V(zht__2021)我发你，不过要点辛苦费(嘿嘿嘿)

authors: muihiuwev nibeizhongjiele zht163


text:
[Device Support Request] Abode / ClimaxTechnology Light, Humidity and Temperature Sensor Battery Level Support

Is your feature request related to a problem? Please describe.
The core functionality for light, humidity, and temperature of these sensors work great, however, the battery level reports as "Unknown", so this request is to specifically get that attribute working properly.
Describe the solution you'd like
Fix battery level reporting for the sensor.
{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=0, maximum_buffer_size=80, maximum_incoming_transfer_size=160, server_mask=0, maximum_outgoing_transfer_size=160, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0106",
      "in_clusters": [
        "0x0000",
        "0x0001",
        "0x0003",
        "0x0400",
        "0x0402",
        "0x0405"
      ],
      "out_clusters": [
        "0x0000",
        "0x0003"
      ]
    }
  },
  "manufacturer": "ClimaxTechnology",
  "model": "LMHT_00.00.03.06TC",
  "class": "zigpy.device.Device"
}

Additional context
Here's the Abode's documentation: https://help.goabode.com/hc/en-us/articles/360000500472-Abode-Light-Humidity-and-Temperature-Sensor-Guide
Here's the ClimateTechnology manual: https://usermanual.wiki/Climax-Technology-Co/LMHTZB/html
Here's a screenshot of how the device currently shows up after being configured:

This is still an issue in Home Assistant 2022.10.1

repo: zigpy/zha-device-handlers


text:
Compatibility list of Zigbee Thermostats and HVACs units compatible with ZHA?

Could there be a compatibility list of Zigbee Thermostat and HVAC units compatible with ZHA climate?
@Adminiuga has just submitted a first pull request for "ZHA Climate" (beta) with thermostats support were he mentions "tested with Sinope and Zen Zigbee thermostats".

See new ZHA climate feature PR https://github.com/home-assistant/core/pull/35682 and docs https://github.com/home-assistant/home-assistant.io/pull/13506

As I do not yet own any Zigbee Thermostat and HVAC units I was wondering what other Thermostat and HVAC units are based on Zigbee devices and are or could be made compatible with ZHA climate feature?
As I understand it, the manufacturer's interpretation of the Zigbee specifications varies wildly between vendors as some device firmware developers deviate from standards, (which indeed is why ZHA Device Handlers are even needed in the first place).
Most thermostat and HVAC control devices also seem to have different feature sets, and not just by the fact that some full HVAC controllers (temperature, fan, heating/cooling system control) while others only have basic temperature controls (heating with no cooling, etc.).
To try to sort out this confusion, a few other projects, like ex. Zigbee2mqtt and deCONZ, has a wiki or webpages editable via GitHub with lists of "supported devices" which kind-of also acts as lists of recommended devices in regards with what features should at least work with ZHA.

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/information/supported_devices.md
https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Supported-Devices

Quick google search found these devices, some of which are central thermostats / HVAC control units and others are thermostats with different feature set. Zigbee2mqtt pages does offer feature-sets.
Centralite Pearl Thermostat (3157100) - HVAC, fan, and A/C Controller

https://centralite.com/products/pearl-thermostat

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/3157100.md

Zen Thermostat (Zen-01 / Zen-01-W) - Zigbee Edition - HVAC controller (temperature, heating/cooling system control)

https://store.zenthermostat.com/products/zen-thermostat

Sinope TH1123ZB - Smart thermostat for electric heating 3000 W / 4000 W – Zigbee

https://www.sinopetech.com/us/product/smart-thermostat-for-electric-heating-3000-w-zigbee/

Sinope TH1124ZB

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/TH1124ZB.md

Sinope TH1300ZB - Smart floor heating thermostat 3600 W – Zigbee

https://www.sinopetech.com/us/product/smart-floor-heating-thermostat-3600-w-zigbee/

Sinope TH1400ZB - Low voltage smart thermostat 24 Vac – Zigbee

https://www.sinopetech.com/us/product/low-voltage-smart-thermostat-24-vac-zigbee/

Sinope TH1500ZB

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/TH1500ZB.md

Stelpro Ki Convector (ST218) line-voltage thermostat
Stelpro Ki (STZB402) line-voltage thermostat

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/STZB402.md

Stelpro Maestro (SMT402 & MT402AD) line-voltage  line-voltage thermostats

https://www.stelpro.com/en-CA/maestro-smart-thermostat

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/SMT402.md
https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/SMT402AD.md

Schneider Electric Wiser Thermostat Radiator Valve (WV704R0A0902) - Temperature, battery, keypad lock, heating demand

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/WV704R0A0902.md

Eurotronic Spirit Zigbee - Thermostat Radiator Valve (TRV)

https://eurotronic.org/produkte/zigbee-heizkoerperthermostat/spirit-zigbee/
https://eurotronic.org/wp-content/uploads/2019/11/Spirit_ZigBee_BAL_web_EN_November-2019.pdf

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/SPZB0001.md

Siterwell GS361A-H04 - TRV - Same Tuya hardware as Viessmann ZK03840 & Essentials Smart 120112?

https://www.china-siter.com/product/194.html

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/GS361A-H04.md

https://siterlink.en.alibaba.com/?spm=a2756.trade-order-list.0.0.38b976e9thNNyI&tracelog=from_orderlist_company

https://www.red-dot.org/project/siterwell-gs361-39193/

Viessmann ViCare (ZK03840) - TRV (Thermostat Radiator Valve) - Same as Siterwell GS361A-H04 based on Tuya hardware?
-https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/ZK03840.md
Essentials Smart (120112) - TRV (Thermostat Radiator Valve) - Same as Siterwell GS361A-H04 based on Tuya hardware?

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/GS361A-H04.md

Moes Radiator valve (HY369RT) - TVR (Thermostat Radiator Valve)- Based on Tuya Zigbee 3.0 compatible hardware?

https://www.moeshouse.com/products/zigbee-smart-thermostatic-radiator-valve-controller-trv-thermostat-tuya-temperature-voice-control-works-with-alexa-google-home

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/HY369RT.md

SASWELL SEA801 / SEA801-Zigbee (SEA801-Tuya-Zigbee) TVR - Based on Tuya Zigbee compatible hardware?

https://www.saswell.com/etrv-smart-radiator-valve-tuya-zigbee-thermostatic-radiator-valve-sea801-zigbee_p103.html

https://saswell.en.alibaba.com/product/60747147965-806204213/TUYA_zigbee_radiator_thermostat_wifi_thermostatic_radiator_valve.html

Leviton Wireless Omnistat2 (RC-2000WH / RC-2000WHZB) Multistage & Heat Pump Thermostat

https://www.leviton.com/en/products/RC-2000WHZB

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/RC-2000WH.md

eCozy Smart Thermostat (1TST-EU) - TVR (Thermostat Radiator Valve)

http://www.ecozy.de/en/support/thermostat

Danfoss Ally Radiator Thermostat (TRV)

https://zigbeealliance.org/zigbee_products/danfoss-ally-radiator-thermostat/

Bitron Video Wireless thermostat AV2010/32 902010/32

https://bvsite.smabit.eu/index.php/produkte/smart-home-produkte/funkthermostat/

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/AV2010_32.md

Hive Heating thermostat (SLR1b)  (thermostat, occupied heating, weekly schedule)

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/SLR1b.md

Hive Heating thermostat remote control (WPT1) (none, communicate via Hive Heating thermostat SLR1b)

https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/WPT1.md

@Hedda https://zigbee.blakadder.com/zha.html seems like a good source.

Hey there, I want to use the "Viessmann ViCare (ZK03840) - TRV (Thermostat Radiator Valve)" mentioned above, but it doesn't seem working currently. I tried paring it multiple times, but it just not work.
Does anyone have a solution for this?

authors: Creepios Hedda saz


text:
Restore original Mija button device triggers

Partially reverts (#783)
Addresses comments in https://github.com/home-assistant/core/issues/52579

Codecov Report

Merging #947 (c008148) into dev (204fca8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev     #947   +/-   ##
=======================================
  Coverage   82.60%   82.60%
=======================================
  Files         191      191
  Lines        4812     4812
=======================================
  Hits         3975     3975
  Misses        837      837

Impacted Files
Coverage Δ

zhaquirks/xiaomi/mija/sensor_switch.py
58.69% <ø> (ø)

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 204fca8...c008148. Read the comment docs.

Pull Request Test Coverage Report for Build 1006205502

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 82.606%

Totals

Change from base Build 999741790:
0.0%

Covered Lines:
3975

Relevant Lines:
4812

💛  - Coveralls

authors: Adminiuga codecov-commenter coveralls


text:
[terms] doesn't support values of type: map[string]interface {}

How to use trem query,
The format required in the sdk is
map[string]map[string]interface{}
// SetTerms gets a reference to the given map[string]map[string]interface{} and assigns it to the Terms field. func (o *MetaQuery) SetTerms(v map[string]map[string]interface{}) { o.Terms = &v }
report error
reason: [terms] doesn't support values of type: map[string]interface {}"}
Check out the zincsearch code
https://github.com/zincsearch/zincsearch/blob/main/pkg/uquery/query/terms.go
The required format is
query map[string]interface{}
how to use ？

Suggest use https://github.com/elastic/go-elasticsearch v7, this SDK is not good. Thanks

See that the latest version is 8.9.0.
Is it also available

Suggest use https://github.com/elastic/go-elasticsearch v7, this SDK is not good. Thanks

Did your SetTerms work?
How to use SetTerms?
This sdk has no examples of related functions.

authors: feiyangbeyond hengfeiyang ickeep

repo: zincsearch/sdk-go-zincsearch


text:
ZIP 320 Implementation

Goal
The purpose of this tracking issue is to manage the efficient implementation of 320.
Objectives:

Converge LRZ and zingolib to the best distance for rapid implementation of 320
Provide functionality to unblock mobile developers allowing them to test UI/UX and Front End Test (FET) for 320 ASAP
Implement and test 320

Subtasks

[ ] manage all dependencies such that 1. is rapidly achievable
[ ] ensure that CI functions across cargo updates

[ ] https://github.com/zingolabs/zingolib/pull/1368

[ ]  produce a test showing parse recognizes address types, including TEX
[ ] produce a test showing multi-step transaction created when TEX is parsed

Currently tagged PRs:
https://github.com/zingolabs/zingolib/pulls?q=is%3Apr+is%3Aopen+label%3A320

Some things I’ve seen in other wallets that must be taken into consideration:

don’t show memos on Tex
account for 2x fees
prepare to receive 2 transactions as a result
librustzcash uses the proposal API (I think you already do)
resubmit both tx on expiry (Zashi does this)

authors: pacu zancas

repo: zingolabs/zingolib


text:
Update scalafmt-core to 3.0.5

Updates org.scalameta:scalafmt-core from 2.7.5 to 3.0.5.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalafmt-core" } ]

labels: library-update, semver-major

Superseded by #219.

repo: zio/interop-scalaz


text:
Strona zapisów ma różne dziwne problemy...

Z jakiegoś powodu, JS nie działa, myślę że to jest problem z importowaniem skryptów ale idk
Nie jest to aż tak pilne, bo z jakiegoś powodu to trochę samo podpowiada błędy w formularzu xD

Okazuje się, że pierwsza funkcja blokowała drugą

Zdaje się, że tym razem funkcja do walidacji danych blokuje funkcje od menu

dropdown menu w zakładce zapisy jest inne niż w reszcie zakładek i na stronie głównej i trzeba zmienić

authors: ninsson ziomciopoziomcio

repo: ziomciopoziomcio/TUL-HTML-project

license: Unlicense


text:
feat: option to disallow public org registration

The PR adds the Admin APIs for limiting an instance and resetting an instances limits.
On the Admin API, the property disallow_public_org_registration is available and resettable, wheras on the System API, the property audit_log_retention is still available and resettable. Calling the reset endpoints from the Admin API and from the System API only reset their managed properties and don't interfere which each other.
Under the hood, it's the same limits aggregrate with the instance ID as resource owner, but that's not transparent to the API.
If a public org registrations are disallowed, the endpoint /ui/login/org/register returns the status 404 on GET and 409 on POST without rendering a form.
Besides that, the PR also:

fixes the permission requirements for the limiting methods on the system API (from authenticated to system.limits.write and system.limits.delete)
silences the integration tests
Adds the option to avoid updating certain columns on upserts. The option is used to only set the creation date when inserting a restriction. For rolling out to other projections, there is a follow-up PR #6930.

TODO

[x] DefaultInstance property
[x] Integration Test
[x] Docs

Definition of Ready

[ ] I am happy with the code
[ ] Short description of the feature/issue is added in the pr description
[ ] PR is linked to the corresponding user story
[ ] Acceptance criteria are met
[ ] All open todos and follow ups are defined in a new ticket and justified
[ ] Deviations from the acceptance criteria and design are agreed with the PO and documented.
[ ] No debug or dead code
[ ] My code has no repetitions
[ ] Critical parts are tested automatically
[ ] Where possible E2E tests are implemented
[ ] Documentation/examples are up-to-date
[ ] All non-functional requirements are met
[ ] Functionality of the acceptance criteria is checked manually on the dev system.

@stebenz can you approve again, plz?
Thanks @muhlemmer for fixing the linter.

repo: zitadel/zitadel


text:
Replace PPTK

It seems that PPTK is not supported in Python > 3.8, which is the default for Ubuntu 20.04.
Alternatives: vtk (using it already), Open3D

Installing VTK was challenging, perhaps Open3D is the solution.

Installing VTK was challenging, perhaps Open3D is the solution.

PPTK says it supports python 2.6 or newer, but they have not made any packages for 3.8. I want to try Open3D. It is a new library with continous support and updates. PPTK has not been updated since 2018.

PPTK says it supports python 2.6 or newer, but they have not made any packages for 3.8. I want to try Open3D. It is a new library with continous support and updates. PPTK has not been updated since 2018.

Is there any concrete reason to discard VTK? If I am correct we already have (or we had) a code sample that is using VTK so it might be faster to implement it. However, I am not discouraging using Open3D, on the contrary.
We should choose whatever is best and most used. I think we should choose one library to be our default visualization library (Open3D or VTK for example) and then have a sample to demonstrate visualization with the other one (in case some customers want to use it instead of our default one).

Is there any concrete reason to discard VTK? If I am correct we already have (or we had) a code sample that is using VTK so it might be faster to implement it. However, I am not discouraging using Open3D, on the contrary.
We should choose whatever is best and most used. I think we should choose one library to be our default visualization library (Open3D or VTK for example) and then have a sample to demonstrate visualization with the other one (in case some customers want to use it instead of our default one).

No reason, i can read up on VTK as well. Btw, why doesn't we have a visualizer in python? Cant we wrap the c++ visualiser to python?

No reason, i can read up on VTK as well. Btw, why doesn't we have a visualizer in python? Cant we wrap the c++ visualiser to python?

I am sure we could bu that would have to be implemented in zivid-python. Create an issue in that repo if you want. But that will take time, plus we do want to demonstrate using popular 3D point cloud libraries anyway.

I am sure we could bu that would have to be implemented in zivid-python. Create an issue in that repo if you want. But that will take time, plus we do want to demonstrate using popular 3D point cloud libraries anyway.

Did some digging into this. I would go for open_3d as our new standard.
it supports Python 3.6, 3.7 and 3.8, and both windows and Ubuntu(18.04 and 20.04)  OS.
the code would like something like this:

And the resulting viewer will look like this:

Whats nice about Open3D is that its new and updated/improved regularly. Its easy to install and the visualization is fast without any lagging. You can also switch between color image and depth map view inside the 3D viewer, see image below

I tried VTK but found it very complicated to use (maybe i did something wrong...), as well as something called vedo. The last one did not work at all because it could not process 2.3M points.

Sounds good. Let's go to for open3d then.

created a PR for this:
https://github.com/zivid/zivid-python-samples/pull/110

authors: SatjaSivcev chrisasc

repo: zivid/zivid-python-samples


text:
code

Thank you for your excellent work and look forward to your code.

Hi, sorry for late reply. I will try to achieve it in next two weeks.

Hi, sorry for late reply. I will try to achieve it in next two weeks.

Completed


text:
完善Go SDK

go项目放在子目录里面不便于更新，我把相关的代码迁移出去了，在这个项目里以子模块的方式引入

非常感谢你的贡献，我觉得，迁出去，可能也不是最好的办法，我最早的想法是，不同的语言，使用一个子文件夹即可，因为每个sdk都不算太大，弄出来很多个库，管理也麻烦。
但是也的确如你所发现，放在一起，也有一些麻烦，比如发版本、修bug，开发贡献的时候，会拉到其他语言sdk。
思考了一下，单独给wxpusher建立了一个组织，把wxpusher相关的一些东西，都放到这个组织下面去，包括docs、demo、管理后台等。

已经建立了在wxpusher下建立了一个go的库，并且给你加了权限，麻烦你迁移到这个库里面吧，后面我把java和python的也迁移出来。感谢。
https://github.com/wxpusher/wxpusher-sdk-go/invitations

git有个子模块的功能，你看下应该符合你最初的需求。

go有点特殊，它没有中央仓库的概念，升级是通过git的tag来实现的，没有push权限不太好升级。
还有go mod需要在根目录建立两个mod和sum文件，这样就破坏了你的目录结构

git有个子模块的功能，你看下应该符合你最初的需求。

是的，这个我知道，后面计划就是按照你的这个方案，来操作。但是每个子模块，也是一个单独的repo，我想把这些单独的repo，全部放在这个组织下面https://github.com/wxpusher/，你觉得怎嚒样？

这样，就避免放在个人账号下面，可能更利于后面的发展。
go-sdk可以放在这里：https://github.com/wxpusher/wxpusher-sdk-go

这样，就避免放在个人账号下面，可能更利于后面的发展。
go-sdk可以放在这里：https://github.com/wxpusher/wxpusher-sdk-go

可以

你的这个建议很好，我后面把这个java、python的，都来迁移一下，还有docs、demo、后端管理的前端，都搬上来，哈哈

已经给你加了 maintain 权限，以后你可以帮忙管理这个仓库，😄

authors: TMaize zjiecode

repo: zjiecode/wxpusher-client


text:
Question about Evaluation implement details

Hi, Thanks a lot for your great work! Recently I encounter the same question as #114 , but I still don't understand the logic behind your reply.
I quote:

In your easyeditor/evaluate/evaluate_utils.py, when you test the "prediction" acc, why you input prompt_target_tok which has already contained the expected prediction target? Shouldn't it be inputted prompt_tok to get the real model output? I am a beginner and it makes me confused. I really wish to get an answer, thank you!
def test_prediction_acc(model, tok, hparams, prompts, targets, device, locality=False):
    if isinstance(prompts, str):
        prompts,targets = [prompts,], [targets,]
    prompt_target = [prompt + ' ' + target for prompt, target in zip(prompts,targets)]
    max_prompt_len = max([len(tok.encode(_)) for _ in prompt_target]) + 1
    prompt_target_tok = tok(
        prompt_target,
        padding=True,
        truncation=True,
        max_length=max(hparams.max_length, max_prompt_len),
        return_tensors="pt",
    ).to(f"cuda:{device}")
    prompt_tok = tok(
        prompts,
        padding=True,
        truncation=True,
        max_length=max(hparams.max_length, max_prompt_len),
        return_tensors="pt",
    )
    num_prompt_toks = [int((i != tok.pad_token_id).sum()) for i in prompt_tok['input_ids']]
    num_pad_toks = [int((i == tok.pad_token_id).sum()) for i in prompt_target_tok['input_ids'].cpu()]
    prompt_len = [x+y for x,y in zip(num_pad_toks,num_prompt_toks)]
    with torch.no_grad():
        outputs = model(**prompt_target_tok)
        if type(outputs) is torch.Tensor:
            logits = outputs
        else:
            logits = outputs.logits
        answers = torch.argmax(logits, dim=-1).squeeze().detach().cpu().numpy().tolist()
        labels = prompt_target_tok['input_ids'].squeeze().detach().cpu().numpy().tolist()
        answers = slice_list(answers,prompt_len,left=True)
        labels = slice_list(labels,prompt_len,left=False)
        if locality:
            return answers if type(answers[0]) is list else [answers,]
        if isinstance(answers[0], list):
            res = []
            for ans,label in zip(answers,labels):
                temp_acc = np.mean(np.equal(ans, label))
                if np.isnan(temp_acc):
                    continue
                res.append(temp_acc)
            return res
        else:
            return [np.mean(np.equal(answers, labels))]

Thanks for your attention. You can refer to the inference of the decoder-only model, which is generally to execute the next token prediction. (e.g. I want to have -> predict lunch at the location of have).
So for the expected prediction target, we execute:
input_prompt ---(predict)---> target_token_1
input_prompt +  target_token_1 ---(predict)---> target_token_2
input_prompt +  target_token_1 +  target_token_2---(predict)---> target_token_3
......

Originally posted by @pengzju in https://github.com/zjunlp/EasyEdit/issues/114#issuecomment-1854998369
Could you please elaborate a little more? Thanks again.

In essence, this evaluation method involves concatenating the question (Q) and answer (A) and feeding it into the language model for inference. Since the decoder-only model's attention is causal, it's essentially predicting the next token. Thus, the metric being tested is the probability of outputting edited knowledge through the prediction of the next token. This can be represented as follows:
input_prompt ---(LM predict)---> target_token_1
input_prompt + target_token_1 ---(LM predict)---> target_token_2
input_prompt + target_token_1 + target_token_2 ---(LM predict)---> target_token_3

hi, do you have any further issues?

hi, do you have any further issues?

No, I have understood after learning knowledge about the relationship between logits and tok['input_ids']. Thanks for your reply!

authors: asdfo123 pengzju zxlzr

repo: zjunlp/EasyEdit


text:
Add golden tests to CI

When anyone changes compiler-related code, the numbers in symbolic-examples:bench-compiler are bound to change.
Should we add the golden test run to CI to track changes?

Yes, let's add them!

Rather than golden tests, why not run symbolic-examples:bench-compiler in CI right after linting and before auto-committing? Then optimizations and regressions will show up in PRs and we can pull them from remote. It may be a little easier to write and help shorten the dev cycle.

authors: TurtlePU echatav vlasin

repo: zkFold/zkfold-base


text:
Prove Rust code on MacOS

We use MUSL as the C standard library, but it doesn't work on MacOS.

Let's work around via ubuntu docker image.
The basic steps look like:
# Pull and run the image
git clone https://github.com/zkMIPS/zkm
cd zkm
docker run -it -v ${PWD}:/app ubuntu bash

# Install Rust

# Install deps
apt install -y curl gcc pkg-config libssl-dev

# Run your MIPS zkVM example

repo: zkMIPS/zkm


text:
Full support for CMake 3.11+ FetchContent()

I've landed here because I was unhappy with zlib's ancient CMake.
I see that here you're targeting a much newer version, but it looks like the library is still expecting to be imported with ExternalProject() only.
In the last few years, the FetchContent() approach is caught on, thanks to it's major usage improvements. But, being it basically a "glorified add_subdirectory()", unfortunately it requires all targets to be properly prefixed (zlib_zlib, zlib_example, ...), and the original targets' names must disappear. (the example target, for example, is very unfortunately named, very generic).
The same may apply for install components, if relevant
I don't know this project's backward compatibility requirements (or if there are any already, since it's still in beta), could this be a possible feature?

I don't personally think it is viable option to add prefixes to all zlib-ng's target names...

Ehh fair enough, the pains of global target scoping.
(I've written "full support" because, in the current state, FetchContent() should be fine for new, prefixed, projects, as long as other, older-styled non-prefixed dependencies, don't collide)

I just use add_subdirectory() with EXCLUDE_FROM_ALL.

The EXCLUDE_FROM_ALL argument says that targets defined in the subdirectory will not be included in the ALL target of the parent directory by default. Doesn't change CMake's target scoping rule.
From Craig Scott's "Professional CMake":

CMake target names must be unique across the whole set of projects being combined, so if two external projects define a target with the same name, they cannot both be added via add_subdirectory(). If projects are following a naming convention that uses a project specific prefix or something similar, then this limitation is fairly easy to avoid. The difficulties tend to come from projects which never expected to be used in this way and which use fairly generic names that are likely to be commonplace.

@Lucide I have used more than one project that depend on for example gtest on same build tree with no clashes... More recent cmake versions (for example on Ubuntu 20.04.1) will crash hard during configuration phase, if there is duplicate target names...

I recall it was also a generator issue. Make could support (support?) that, but every other generator didn't.
see here: https://cmake.org/cmake/help/v3.17/prop_gbl/ALLOW_DUPLICATE_CUSTOM_TARGETS.html

Visual Studio generators have been broken since early days... cmake developers tried to fix the generator for Visual Studio 2019, but no sane person is using VS2019 to compile production code as it is buggy as hell... There has been a lot of discussion between zlib-ng developers and Microsoft about getting bugs in Visual Studio compiler(s) fixed for all supported architectures...

Interesting. didn't know about that!
But I think discussing about the legitimacy of CMake logic rules/generators it's beyond the original intent of this issue.

As zlib-ng plans to support Visual Studio, it limits what we can do... For some feature that is still quite volatile, it doesn't make sense to change the current system until the feature is stable enough... Otherwise we keep changing same thing over and over as the feature evolves...
We have already increased the minimum cmake version we require from 2.8 to 3.5.1, which is quite a leap...

Of course! Perhaps I didn't express it very well, but I'm very thankful of the work you're doing here, and I'm more than satisfied of what you're already offering. When the first docs arrive, I'll jump right in.
I was proposing this just for the sake of trying, you might see a lot of similar github issues spawning up here and there. CMake is extremely hard to do right for newcomers like me, and everyone aspiring to learn is redirect to the same book, so some feature gets promoted on large scale.
The current situation doesn't even block FetchContent() completely, just on some potentially bigger, more crowded, projects.
As far as I'm concerned this issue can be closed, if it's already too late to make the switch now, this will become less relevant the more time passes.

We're pretty close to first public release, so I think now is not the best time to make this kind of changes in the build process... I'm not sure if later on we will or should revisit the issue...

If we were to change the zlib-ng's CMake generated project names they would no longer have the same project names as what is generated by zlib's CMake. Not sure if that would be something we would want.

I don't think having different project names than zlib is a real issue... I'm more worried about fixing something in zlib-ng that should more likely be fixed elsewhere...

Most of the "features" FetchContent() adds can already be accomplished by using git submodules... This also makes sure the download fails at earliest stage as possible and can be retried...

If elsewhere is on CMake's side, in the terms of a new, third dependency management system, I really doubt anything new is going to appear.
I've seen no suggestion whatsoever about a new, revamped, approach to projects. Perhaps, in the future, prefixed target will be made pseudo-mandatory, on something like that.
That said, the FetchContent()/pure addsubdirectory() approach is still pretty much utopic beyond repair. Just one couple of non prefixed dependencies is almost guaranteed to collide and exclude the entire approach.
Even if you decided to support this, I don't know how much of an improvement this would be. For small, bleeding edge new projects, sure, but for the rest...

In the worst case, the best choice is adding all dependencies separately and use find_package() to get the correct include and library paths/directories... This is kind of preferred way on Unix-like systems where cmake itself has most common scripts for find_package() to find libraries...

Well if the project names are different between zlib and zlib-ng in CMake it means that it is no longer a drop in replacement for zlib at least for my minizip project. There are other ways to manually specify the .lib but it is less than ideal.

n the worst case, the best choice is adding all dependencies separately and use find_package() to get the correct include and library paths/directories...

Yes, find_package() is usually used for installed dependencies, which location would likely be outside of the project root.
In zlib's case this can be done, since is an common package enough to have preinstalled. But if you also plan to support windows, this becomes not true anymore.
The portable way is to use the ExternalProject() approach. In this case CMake builds and installs locally the project like an user would, without knowing anything about what it's actually being done and what build system the project is using. This kind of freedom is a lot harder to handle, and often requires specialized project structures called superbuilds. This is how zlib was intended to be used.
I've seen that they use project-relative variables instead of global ones, so virtually the project could be imported as a subdirectory. But everything is so old styled that I wouldn't know what to do with that.

find_package() also works on Windows, but it requires Administrator rights to install new packages as Windows doesn't normally allow writing to/under "Program Files" or "Program Files (x86)" directories...
There is junctions (compare. symlinks on Linux) for different SDK versions and compiler versions. Previously there was no centralized place to install development libraries and headers, but that was changed quite a while ago...
For non-development libraries, the default location is still application install directory or under Side-by-Side (SxS) directory...
Mixing libraries between compiler versions on Windows doesn't work as the toolchain version depends on specific build of C++ runtime library. You can compile for older version of toolchain, but not newer...

Even if you were to do add_subdirectory between two CMake projects that have different libraries you still have to use target_link_libraries to specify the names of the libraries, and if those library names change between zlib CMake and zlib-ng  CMake, it no longer becomes drop-in replacement.

@nmoinvaz There is two separate things...

being source-wise drop-in replacement
being binary-wise drop-in replacement

Like I said earlier, it is easy to use find_package() to find specific library by binary filename and header filename...
We could easily change project/target names for non-compat zlib-ng targets and leave the old ones for compatibility library... This would also allow us to build both versions at the same time...

I am talking about the project being a CMake drop-in replacement using FetchContent.

@nmoinvaz For that to work, the default values for options would need to be compatible with stock zlib... As such minimum is that compatibility mode is enabled by default, which might not be what we want in the long term...

@mtl1979 ahh, now I understand, you're talking about find_package()'s module mode. Yes, that's a fully CMake-agnostic approach, but should be reserved for non-native CMake projects.
Modern CMake projects exports targets and are found with find_package() config mode.
See here https://cmake.org/cmake/help/v3.17/command/find_package.html
Module mode should be excluded by principle

@Lucide I've seen some projects exporting targets and blowing up in developer's face... Generally having target exported doesn't mean something actually works as same target can be exported by multiple projects.

Right now in minizip I can use FetchContent between zlib CMake and zlib-ng CMake and only add ZLIB_COMPAT=ON. Changing project names will break this unless we keep it the same when ZLIB_COMPAT is enabled.

@nmoinvaz My point was that if adding ZLIB_COMPAT=ON is already required, we can safely require more definitions... But if none is required currently, it blows in our face, if we start requiring...

Yes of course.

authors: Lucide mtl1979 nmoinvaz

repo: zlib-ng/zlib-ng

license: Zlib


text:
PCM RTP封包

请问PCM数据如何进行RTP封包？？

pcm 你可以编码成aac 然后再输入zlmediakit即可

不编码为AAC，直接用PCM数据封可以么？？

没看过自己PCM打包的 建议还是编码后再打包 这样更省带宽

authors: baddogsmallq xiongziliang

repo: zlmediakit/ZLMediaPlayer


text:
Added --client-subnet for setting EDNS0 option in DNS queries

You can pass now --client-subnet and specify EDNS0 client subnet (RFC 7871)

Thanks for the contribution. I'm excited to see this functionality and overall the code looks good. That said, I'm worried that there's no test coverage — even if whether the code runs. Would you be willing to add a test that calls ZDNS with the new flag and makes sure that the response is sane?
In order to assist with testing, I have created a testing zone that should return different responses. Google Cloud (which hosts zdns-testing.com) only supports Geo-based, so this is the configuration:
I tested using three subnets belonging to Stanford, TU Munich, and University of Adelaide.
dig ecs-geo.zdns-testing.com +subnet=171.67.68.0/24 @8.8.8.8 => 2.3.4.5
dig ecs-geo.zdns-testing.com +subnet=131.159.92.0/24 @8.8.8.8 => 3.4.5.6
dig ecs-geo.zdns-testing.com +subnet=129.127.149.0/24 @8.8.8.8 => 1.2.3.4
I think that we should be safe to use those subnets in our testing.
Zakir
On Dec 13, 2022, 6:46 PM -0600, Filip @.***>, wrote:

@cujof requested review from @zmap/zdns-maintainers on: #321 Added --client-subnet for setting EDNS0 option in DNS queries as a code owner.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because your review was requested.Message ID: @.***>

Hey, Zakir! I added test for EDNS0 client subnet but spotted that there was bug in assertEqualAnswers() and seems I've fixed it in a987a7a47b3cf7f18ba880acae24cb4f57922ca8 , please take a look.

Thanks for approval. I am not authorized to merge though.

Sorry, was waiting for tests to pass after I made that change. Will approve
when I'm back at a computer.
On Tue, Dec 20, 2022 at 2:49 AM Filip @.***> wrote:

Thanks for approval. I am not authorized to merge though.
—
Reply to this email directly, view it on GitHub
https://github.com/zmap/zdns/pull/321#issuecomment-1358960213, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABREUEIV4CO3QQLXVA3DZLWOFQKHANCNFSM6AAAAAAS52ZABE
.
You are receiving this because your review was requested.Message ID:
@.***>

Thank you, Zakir! I'm switching to use main repo again since this functionality is merged ;)

authors: cujof zakird

repo: zmap/zdns


text:
What to do with ambiguous results?

We have lints that that may apply or that may pass/fail, however the runtime does not have quite enough information to prove it.
An example is in #491 wherein a certificate would fail if-and-only-if one of its parents has the TLS auth EKU. We have a discussion in #428 on enabling operators to include chains into runs of the tool in order to disambiguate such cases. However, what if the operator does not include the chain? How do we let them know that there is a lint that might benefit from seeing the full chain (as simply hiding it in the docs is a great way for these sorts of lints to go unnoticed)?
And certificate chains aside, I am sure that there will be (are?) additional lints that are otherwise ambiguous (perhaps they need access to some CSV or database that's not always going to be there, for example certificate transparency records).
Some Questions

How "loud" are these notices of ambiguous runs? Is an ambiguous Error just as loud as a proven Error? That seems noisy, however Errors are tied to MUSTS - if I were banking on this tool for my job I would personally appreciate it being this strict. Maybe --strict/--nostrict type flag (let's say that by default an unproven Error results in a non-zero exit code and you can disable that behavior via --nostrict)?
Ambiguous Warnings, however? At first blush, these actually seem even less important than an actually Warning.

Another scenario where the ambiguity is difficult is anywhere in the BRs where compliant participants MUST have a process for X or so forth, aka areas where no additional context would be able to help zlint provide a more concrete determination.
For context, that was the issue leading to #493 in which the BRs state (3.2.2.6):
the CA MUST establish and follow a documented procedure[^pubsuffix] that determines if the wildcard character occurs in the first label position to the left of a “registry‐controlled” label or “public suffix”

@cardonator So for those lints, I'm taking it as you'd support a CookieMonster level, because just like cookies are a sometime food, these are certificates that are sometimes good? 😜

@sleevi haha! I was thinking it's more like classic CookieMonster where you get all the cookies you want unless you're being a bad boy. 😉

Jokes aside, on a pragmatic level, I would think that for situations like that - where something is bad UNLESS the CA has taken steps X/Y/Z (such as a documented process) - it probably makes sense to assume the negative case entirely, and then allow the CA to suppress certain lints on a case-by-case basis (e.g. if they have a documented process).
The downside to this approach is the common downside we see throughout the CABF, which is that if the requirements change in, say, v1.x.y to 1.y.z, and we reuse the same lint, the CA may have disabled the lint for the new requirement. However, since a new requirement generally means a new effective date, and a new effective date generally means a new lint, I suspect the liklihood is that a new lint for the new requirement(s) would be introduced, and the CA would squelch the new lint if it doesn't apply.

I like that approach, it's kind of like an attestation for specific requirements that are Error scenarios without an attestation.

Exactly. Whether that attestation is implicit (i.e. the CA disabled the lint) or explicit (e.g. a "ZLint config" which can contain all of the relevant attestations a CA is making) I'm somewhat ambivalent to. I suspect that either way, there will be plenty of ways for things to go wrong, so I lean on the KISS and leave the work up to the CA to manage those attestations themselves, without any overly complex guardrails.

authors: cardonator christopher-henderson sleevi

repo: zmap/zlint