text:
Multiple BT Mesh tests are failing in main

Describe the bug
Multiple BT Mesh tests are failing in main
To Reproduce
For ex.

tests/bsim/compile.sh
tests/bsim/bluetooth/mesh/tests_scripts/dfu/dfu_cli_all_targets_lost_on_caps_get.sh
See error

Expected behavior
No failing tests
Impact
Blocked CI in PRs
Logs and console output
https://github.com/zephyrproject-rtos/zephyr/actions/runs/11220193326/job/31201648682?pr=79262
Environment (please complete the following information):

OS: Ubuntu 22.04 (CI)
Toolchain (e.g Zephyr SDK, ...): Host gcc 11/12
Commit SHA or Version used: main as of now: 318b49570a77ce631dc3d97ad7e7a05df5459d8e

Additional context

CC @PavelVPV @alxelax

I will have a look

Just took a quick look, it seems import of keys is broken. I suspect some PSA related changes were committed without running mesh tests.

This commit broke mesh: https://github.com/zephyrproject-rtos/zephyr/commit/4b479016a792a24704352566bdbf726493dd08ae

This commit broke mesh: 4b47901

I wonder if this adds PSA ITS for posix platforms, or it still requires using files.

CC @tomi-font

Seems adding select SECURE_STORAGE to config BT_MESH_USES_MBEDTLS_PSA made it working. Checked on one test, checking other mesh tests now.

Seems adding select SECURE_STORAGE to config BT_MESH_USES_MBEDTLS_PSA made it working. Checked on one test, checking other mesh tests now.

I corrected a bit my comment above. Do we need my workaround at all after this commit?

Hey. The secure storage subsystem supports native platforms. I have tested with native_sim, but I think it has run in CI on native_posix as well.
I encourage you to switch to using it, and remove your custom implementation.

@tomi-font , it forces SETTINGS option: https://github.com/zephyrproject-rtos/zephyr/blob/318b49570a77ce631dc3d97ad7e7a05df5459d8e/subsys/secure_storage/Kconfig.its_store#L15.
How can I use Secure Storage without Settings?

@tomi-font , we need some kind of this: https://github.com/zephyrproject-rtos/zephyr/blob/main/tests/subsys/secure_storage/psa/its/src/custom_store.c as one of Secure Storage ITS module implementation (call it SECURE_STORAGE_ITS_STORE_IMPLEMENTATION_RAM).

@tomi-font , it forces SETTINGS option:
https://github.com/zephyrproject-rtos/zephyr/blob/318b49570a77ce631dc3d97ad7e7a05df5459d8e/subsys/secure_storage/Kconfig.its_store#L15
How can I use Secure Storage without Settings?

You cannot do with settings enabled?

@tomi-font , we need some kind of this: https://github.com/zephyrproject-rtos/zephyr/blob/main/tests/subsys/secure_storage/psa/its/src/custom_store.c as one of Secure Storage ITS module implementation (call it SECURE_STORAGE_ITS_STORE_IMPLEMENTATION_RAM).

Yeah, not using settings would require providing an alternate ITS store module implementation. But why can't you do with an actual storage solution in the first place?

I want to keep an option to build mesh without settings. Which prevents me adding select/depends on SECURE_STORAGE to config BT_MESH_USES_MBEDTLS_PSA. Neither I get an error or warning that running a firmware without SECURE_STORAGE but with SETTINGS enabled won't work because ITS implementation is missing. I have to add an assertion into mesh code to enable SECURE_STORAGE when SETTINGS is enabled by user which is not super convenient.

It seems that your ITS implementation is only to run some tests. I don't exactly get why you'd want an option to build without settings.
But if this is breaking CI in PRs, maybe at least for now the best is to adjust what was done to config-tls-generic.h to revert the behavior change for Bsim.
Also, FYI, in the (hopefully near) future an alternative ITS store implementation than settings will be provided, some time after ZMS has made it into Zephyr.

It seems that your ITS implementation is only to run some tests. I don't exactly get why you'd want an option to build without settings.

For testing purposes, we do build and run mesh on devices without Settings SS. Having settings enabled is sure way to kill the flash while performing some large scale tests with hundreds of thousands of messages getting processed on a node and each message potentially triggering a write operation. It is also possible to build a fully functional mesh application that pre-provisions itself and becomes functional at power-on - this does not Settings SS. If the end-product/system is designed in such a way that it never encounters power-cycle, it never needs Settings SS.

It seems that your ITS implementation is only to run some tests. I don't exactly get why you'd want an option to build without settings.

For testing purposes, we do build and run mesh on devices without Settings SS. Having settings enabled is sure way to kill the flash while performing some large scale tests with hundreds of thousands of messages getting processed on a node and each message potentially triggering a write operation.

Have you considered using the flash simulator, with a small flash partition simulated in RAM?

Have you considered using the flash simulator, with a small flash partition simulated in RAM?

IIRC there was some discussion about it but it has never been prioritized.

authors: PavelVPV aescolar alxelax omkar3141 tomi-font


text:
infineon hal whd_chip.c warning

Describe the bug

When compiling modules/hal/infineon/wifi-host-driver/WiFi_Host_Driver/src/whd_chip.c with CONFIG_SPEED_OPTIMIZATIONS=y the compiler creates warnings:
modules/hal/infineon/wifi-host-driver/WiFi_Host_Driver/src/whd_chip.c: In function 'whd_ioctl_print':
modules/hal/infineon/wifi-host-driver/WiFi_Host_Driver/src/whd_chip.c:688:17: warning: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
  688 |                 strncpy(iovar, (char *)data, strlen( (char *)data ) );
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
modules/hal/infineon/wifi-host-driver/WiFi_Host_Driver/src/whd_chip.c:687:17: note: length computed here
  687 |             if (strlen( (char *)data ) <= WHD_IOVAR_STRING_SIZE)
      |                 ^~~~~~~~~~~~~~~~~~~~~~
[248/301] Building C object modules/hal_infineon/CMakeFiles/modules_hal_infineon.dir/home/brandon/fork/modules/hal/infineon/wifi-host-driver/WiFi_Host_Driver/src/whd_wifi_api.c.obj
In function 'whd_iovar_mkbuf',
    inlined from 'whd_wifi_get_iovar_buffer_with_param' at /home/brandon/fork/modules/hal/infineon/wifi-host-driver/WiFi_Host_Driver/src/whd_wifi_api.c:3739:14:
modules/hal/infineon/wifi-host-driver/WiFi_Host_Driver/src/whd_wifi_api.c:3715:5: warning: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
 3715 |     strncpy(iovar_buf, name, (iovar_len - 1) );
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
modules/hal/infineon/wifi-host-driver/WiFi_Host_Driver/src/whd_wifi_api.c:3702:17: note: length computed here
 3702 |     iovar_len = strlen(name) + 1;

To Reproduce

cd samples/net/wifi

west build -p -b cy8cproto_062_4343w -- -DCONFIG_SPEED_OPTIMIZATIONS=y

Environment (please complete the following information):

main

@brandon-exact, thank you for the bug submission. I have filed a ticket with our internal team that owns the WHD.
Ian

source: gharchive/issue

authors: brandon-exact ifyall

repo: zephyrproject-rtos/zephyr

license_type: permissive

license_source: github-api


text:
logging: refactor log_filter_set to set existing log level

Modified log_filter_set function to limit level if requested
level is not compiled in. Additionally, extended function to
return actually set level. Removed redundant code from log_cmds.
Change fixes shell log backend initialization which was setting
log levels without taking into account compiled in limits
(like log enable command was doing).
Signed-off-by: Krzysztof Chruscinski krzysztof.chruscinski@nordicsemi.no

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@18f9bb0). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master   #11436   +/-   ##
=========================================
  Coverage          ?   48.38%
=========================================
  Files             ?      265
  Lines             ?    42197
  Branches          ?    10137
=========================================
  Hits              ?    20418
  Misses            ?    17703
  Partials          ?     4076

Impacted Files
Coverage Δ

subsys/logging/log_core.c
75.53% <100%> (ø)

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 18f9bb0...13161db. Read the comment docs.

source: gharchive/pull-request

authors: codecov-io nordic-krch


text:
Bluetooth: Fix missing return statement in le_conn_param_req()

The le_conn_param_req() function was missing a return statement in
case of a failed connection lookup. This could lead to replying to the
connection parameter request twice as well as passing NULL to
bt_conn_unref(). The latter issue also triggered a Coverity warning.
Fixes CID 196638
Signed-off-by: Johan Hedberg johan.hedberg@intel.com

Codecov Report

Merging #14757 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master   #14757      +/-   ##
==========================================
- Coverage    52.5%    52.5%   -0.01%
==========================================
  Files         309      309
  Lines       45047    45047
  Branches    10418    10418
==========================================
- Hits        23654    23653       -1
- Misses      16586    16587       +1
  Partials     4807     4807

Impacted Files
Coverage Δ

subsys/bluetooth/host/hci_core.c
44.14% <0%> (-0.06%)
:arrow_down:

Continue to review full report at Codecov.

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

authors: codecov-io jhedberg


text:
samples: net: can: initialize the variables

Initialize the variables.
Fix Bug: #14819
Coverity CID: 196637
Signed-off-by: Tedd Ho-Jeong An tedd.an@intel.com

Codecov Report

Merging #14850 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #14850   +/-   ##
=======================================
  Coverage   52.49%   52.49%
=======================================
  Files         309      309
  Lines       45060    45060
  Branches    10431    10431
=======================================
  Hits        23656    23656
  Misses      16592    16592
  Partials     4812     4812

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 22cf6d9...239e767. Read the comment docs.

authors: codecov-io tedd-an


text:
Bluetooth:RFCOMM: Fix length errors when payload exceeds 127

hdr->length is the length of the payload, it should be
buf->len - sizeof(*hdr) - 1 or buf->len - (sizeof(*hdr) + 1)
Signed-off-by: ZhongYao Luo LuoZhongYao@gmail.com
PS:  When using zephry to implement the iap2 protocol, when iOS sends RequestAuthenticationCertificate, zephry responds to AuthenticationCertificate, iOS will no longer send new data, and AuthenticationCertificate exceeds 127. After using this patch, it works fine.

Fix looks ok, but could you please fix the typo in the commit message. It's RFCOMM and not RFOCOMM 😄

Also (minor): there should be a space character after Bluetooth:

Is this a fix for https://github.com/zephyrproject-rtos/zephyr/issues/18386?

@LuoZhongYao I see you've fixed the PR title, but you also have to fix the commit message

@LuoZhongYao I see you've fixed the PR title, but you also have to fix the commit message

sorry, Was using a non-work computer

Is this a fix for #18386?

I did n’t verify it because your project testing is really slow

I did n’t verify it because your project testing is really slow

You mean coverity? We can leave that issue open. Johan mentioned that he saw several things that looked suspicious. So if you are familiar with the RFCOMM spec you might want to have a look for more issues, as there is not really anybody maintaining the BR/EDR part of zephyr at the moment.

I did n’t verify it because your project testing is really slow

You mean coverity? We can leave that issue open. Johan mentioned that he saw several things that looked suspicious. So if you are familiar with the RFCOMM spec you might want to have a look for more issues, as there is not really anybody maintaining the BR/EDR part of zephyr at the moment.

OK

authors: LuoZhongYao jhedberg joerchan


text:
drivers: modem: ublox-sara-r4: fix modem reset

This fixes two problems in modem_reset():

mdata.net_iface is used without checking that it is valid.
Now, we validate mdata_net_iface before usage, and give a warning
if it was not set.

if the modem does not perform network registration within the
given time of 20s, in the previous implementation the driver
gave up.
Now, the driver disables RF for a second, enables it again and
gives the modem another 20s to register. This has been seen
to help in roaming situations.

Tested on Sara R4.
Signed-off-by: Hans Wilmers hans@wilmers.no

(closed via #22149)


text:
samples: net: sockets: big_http_download: Fix DHCP configuration

Current IP configuration of the big_http_download sample, where we
condfigure IP addresses both statically and with DHCP does not work.
Regardles of whether DHCP server is avaialbe or not, if the static
IP configuration allowed to establish the connection, the DHCP client
procedure that kicks in after a random backoff impacts the connection
negatively.
As the DHCP client clears the active gateway when it starts the
Discovery operation, the networking stack is no longer able to send
packets to the ouside network in case there no DHCP server around. And
if there is a DHCP server avaialble, the sample application stops to
recieve packets anyway, as the IP address likely changes after the DHCP
procedure.
Fix this problem, by providing a separate overlay for the DHCP
configuration, that clears the statically-configured IP addresses. This
way, if the static configuration is used (by default) it's not impacted
by the DHCP procedure. And if DHCP is inended to use, the sample will
not start until the IP address is obtained from the DHCP server.
Signed-off-by: Robert Lubos robert.lubos@nordicsemi.no

@jukkar I was not sure if this should be rather fixed at the DHCP level (i.e. clearing the GW address) or the sample level, but I didn't find a good way to address the issue in that area (i. e. after successfull DHCP the IP address will likely change anyway, so there's little use to configure address statically first). Therefore I figured this should be rather addressed in the sample (configuring address both statically and with DHCP doesn't sound right in the first place to me).

So, let me be explicitly -1 on it, and suggest to make a bisect to find what broke the correct behavior and look into fixing it.

The problem I faced (no DHCP server) was introduced by this change specifically:
https://github.com/zephyrproject-rtos/zephyr/commit/d44b4252b7fbfe8e02c807d2a6b3baf66876d8e2 (which came as a part of a larger rework https://github.com/zephyrproject-rtos/zephyr/pull/30995). The exact problem is that GW address is cleared on an interface on DHCP startup, so it's no longer possible to send packets to the outside network (we can discuss whether it's correct or not).
But, even with a DHCP server around (I've tested this scenario as well), I'm still not convinced if setting a static address first is a right approach. In my case, the sample established TCP connection, downloaded some data, and then after DHCP kicked in (it starts after a random backoff now), my device got assigned a new IP address, which became a problem. No more packets from the previously established connection could reach the device, so the open socket just kept hanging on the recv() call waiting for data that'd never come.
I'm not sure what Linux does in this case, but maybe a correct way would be to invalidate the socket if the IP address it was bound to was removed from the system? Another point is whether the statically configured IP address should be removed in that case, probably not.

Having both static and dynamic (DHCP) address set to the interface can lead to these weird connectivity issues. Most likely the addresses are allocated from different subnets and we are not able to use the static addresses after the DHCP has managed to allocate an address. Then we are left with system that might not be able to communicate anywhere without first closing the sockets.

@rlubos :

The problem I faced (no DHCP server) was introduced by this change specifically:
d44b425 (which came as a part of a larger rework #30995). The exact problem is that GW address is cleared on an interface on DHCP startup,

Thanks for bisecting and finding the culprit commit. So, apparently clearing should happen not on "DHCP startup", but only when a valid IP address (and other config) was received/confirmed over DHCP.

But, even with a DHCP server around (I've tested this scenario as well), I'm still not convinced if setting a static address first is a right approach.

I'm not sure the word "right" is the right one to use here. It should be possible to have both static IP config and DHCP enabled, and it should work as described above (and as Linux solutions work) - static IP config should be used until DHCP config is fully received and confirmed, and switchover should happen in as atomic way as realistically possible. What we have now is effectively a race condition between static config and DHCP, when just enabling DHCP leads to conflict with static config, even if DHCP won't really be used (i.e. when there's no DHCP server around, and DHCP requests sent from a Zephyr device won't be responded to).

In my case, the sample established TCP connection, downloaded some data, and then after DHCP kicked in (it starts after a random backoff now), my device got assigned a new IP address, which became a problem.

And in my case (I usually run with direct device-host connection, i.e. without DHCP), the app downloaded some data, then DHCP kicked in and overthrown the proper config, and everything hanged. And the only solution is to disable DHCP in the config. That's why I say we have been having a regression for some time now, and why I say this patch just masks the issue instead of properly resolving it. (Again, this sample specifically had this configuration to ensure that static IP + DHCP works in an expected way - failing us to have a proper unit test for that.)

No more packets from the previously established connection could reach the device, so the open socket just kept hanging on the recv() call waiting for data that'd never come.

That's orthogonal issue. It's quite well-known that one can't write real-world robust applications without timeouts for I/O (in particular, networking) operations. This sample was intended to be a simple one, and was written before we had timeout support for recv/send. We now have it (TODO: check that we actually have support for both by now), so if you'd like to add timeout for recv() here, I'm +1.
Note that IP may change under app's feet at any time. For example, DHCP has lease time, when it ends, a device should query again and may get a different IP address, and lease time may be 5min or so. That's again why I say that this patch just masks the issue, and that instead we should value this sample's config as something which exposes the issue and allows us to manage it (hopefully even improve over time).
Finally, we have had https://github.com/zephyrproject-rtos/zephyr/issues/7630 for quite some time, raising attention to these issues. That's why I'm keen to at least preserve/recover previous state of affairs, and not mask/deteriorate it.

I'm not sure what Linux does in this case, but maybe a correct way would be to invalidate the socket if the IP address it was bound to was removed from the system?

These ideas is what's #7630 dedicated to. But those are outside BSD Sockets API, and the baseline is that interface vs sockets layers are separate in the network stack, and each works independently, and there's a generic timeout mechanism available for apps to catch any connectivity issues on the socket level - timeout.

Another point is whether the statically configured IP address should be removed in that case, probably not.

I see no ambiguity here (taking Linux experience as the baseline) - if DHCP is enabled on/for interface, it overrides interface's IP address - once the address is successfully received. From Linux PoV, if I'd like to have both static and DHCP address on the same interface, I'd need to create a virtual sub-interface (e.g. eth0.1), and have static IP on eth0 and run DHCP on eth0.1. (Other trickier option may be to settle that DHCP overrides if's first IP address, so way to have both DHCP and static is to configure the latter as 2nd).

@jukkar

Having both static and dynamic (DHCP) address set to the interface can lead to these weird connectivity issues.

The talk is more about co-existence of static and DHCP configuration on the interface, where static is the default/fallback, and DHCP overrides it, once successfully received - without race conditions.

Most likely the addresses are allocated from different subnets and we are not able to use the static addresses after the DHCP has managed to allocate an address. Then we are left with system that might not be able to communicate anywhere without first closing the sockets.

That's realistic situation anyway (any network connection may break/stall for many reasons, including those beyond IP addresses being changed behind app's back), so an app should be ready to deal with those (standard generic means for that is having timeouts on I/O operations, and when those fail, retry the entire connection attempt).

The talk is more about co-existence of static and DHCP configuration on the interface, where static is the default/fallback, and DHCP overrides it, once successfully received - without race conditions.

I was just wondering the way we have this working atm, does it make actually sense to have this kind of "fallback" as it can/is causing issues when running in real life environment.

@jukkar

I was just wondering the way we have this working atm, does it make actually sense to have this kind of "fallback" as it can/is causing issues when running in real life environment.

We have had that fallback all the time, and it didn't cause any issues in real life environment, I specifically verified and tested it with this sample, that's why these options are enabled in it. Until it regressed before 2.5 (apparently with the
commit https://github.com/zephyrproject-rtos/zephyr/commit/d44b4252b7fbfe8e02c807d2a6b3baf66876d8e2, as pointed by @rlubos). And I think we should recover that behavior, rather than mask the issue.

Thank you for all the feedback. Please correct me if I misunderstood something, but the way to go for now is to restore the original behavior by:

Sorting out the DHCPv4 client behaviour, which clears the gateway configuration on init (which should fix the scenario where no DHCP server is available).
Configuring timeout on a socket with SO_RCVTIMEO/SO_SNDTIMEO so that the sample no longer stalls after the IP address configured on an interface changes.

I'll try to propose something soon(ish).

@jukkar @pfalcon I've pushed new commits, as discussed above, and updated the PR description.
As for the DHCP, the gateway IP address is updated when Router option is detected in a DHCP message. In my setup, the option was present in both, DHCP OFFER and DHCP ACK messages. however I didn't find any information in the RFC that the option is mandatory (and likely isn't since it's listed in the "Vendor extensions" section). Therefore I've kept the gateway clearing but only in a case, when there is no Router option in the DHCP OFFER message sent by the DHCP server.

@rlubos:

Sorting out the DHCPv4 client behaviour, which clears the gateway configuration on init (which should fix the scenario where no DHCP server is available).
Configuring timeout on a socket with SO_RCVTIMEO/SO_SNDTIMEO so that the sample no longer stalls after the IP address configured on an interface changes.

Sorry for the delay with response, and yes, that's what I meant. These 2 things are of course orthogonal and could be done separately (e.g. if DHCP issue turns out to take more time), but I appreciate give a try to both. Testing on my side...

authors: jukkar pfalcon rlubos


text:
Nucleo f030r8

Fixes #3923
boards: provide support for Nucleo-64 F030R8
This PR is an updated version of #1103 since @MaciejDebski won't have time to maintain this PR, authorship of the patches has been preserved.
This PR contains a fix to solve the missing memory issues on the automated build test suite.

I'm going to close #1103 since this takes it over.

Can you guys explain 'arch: arm: core: fix vector table relocate write to flash' to me a bit more.

@galak On Cortex-M0, you cannot change the vector table pointer in the CPU registers, you need to have them at address 0 in physical memory, but on STM32 address 0 can be remapped on flash or whatever, so if we need to relocate the pointers we must be sure the DRAM is mapped here and reserve the memory in the binary ram sections

If you can rebase and take of the conflict, I'll merge after that.

Ok I’ll do it ASAP

Oh, forgot to mention that we need to look at tests/kernel/common/test, fails due to needing a few more bytes of SRAM.


text:
Z_POW2_CEIL: simplify implementation

Avoid potentially calling __builtin_clz() twice with non-constant
values. Also add a test for it.
Signed-off-by: Nicolas Pitre npitre@baylibre.com

@npitre, there are unresolved conflicts in include/toolchain/gcc.h.
That shall be resolved, then the review shall be re-requested.

authors: GeorgeCGV npitre


text:
tests: Enable sbs_gauge driver testing with native_posix

This part of the work for adding a battery API.

See
https://github.com/zephyrproject-rtos/zephyr/pull/47118
Had to recreate PR due to new fork...


text:
stm32 qspi driver support sfdp parameters

Add the support of the jedec SFDP parameter read command to the quadNOR flash of the stm32 driver
This PR gives the stm32 QSPI driver the access to the jedec SFDP table given by the external quad-flash
and read with the JESD216_CMD_READ_ID    (opcode = 0x9F).
This is demonstrated by the samples/drivers/jesd216/  running on a stm32 target board with quad-NOR flash device.
Also run the samples/drivers/spi_flash on

stm32h747i_disco_m7
disco_l475_iot1
stm32l496g_disco

Signed-off-by: Francois Ramu francois.ramu@st.com

Running the  west build -p auto -b stm32h747i_disco_m7 samples/drivers/jesd216/samples/drivers/jesd216/
Booting Zephyr OS build zephyr-v3.3.0-1723-g228a5100f747 ***
qspi-nor-flash-1@0: SFDP v 1.6 AP ff with 2 PH
PH0: ff00 rev 1.6: 16 DW @ 30
Summary of BFP content:
DTR Clocking supported
Addressing: 3- or 4-Byte
4-KiBy erase: uniform
Support QSPI XIP
Support 1-1-1
Support 1-1-2: instr 3Bh, 1 mode clocks, 7 waits
Support 1-1-4: instr 6Bh, 1 mode clocks, 7 waits
Support 1-2-2: instr BBh, 1 mode clocks, 7 waits
Support 1-4-4: instr EBh, 1 mode clocks, 9 waits
Support 2-2-2: instr BBh, 1 mode clocks, 7 waits
Support 4-4-4: instr EBh, 1 mode clocks, 9 waits
Flash density: 67108864 bytes
ET1: instr 20h for 4096 By; typ 48 ms, max 480 ms
ET2: instr D8h for 65536 By; typ 160 ms, max 1600 ms
ET3: instr 52h for 32768 By; typ 112 ms, max 1120 ms
Chip erase: typ 62464 ms, max 1499136 ms
Byte program: type 15 + 1 * B us, max 360 + 24 * B us
Page program: typ 120 us, max 2880 us
Page size: 256 By
Suspend: 75h ; Resume: 7Ah
DPD: Enter B9h, exit ABh ; delay 30000 ns ; poll 0x3e
HOLD or RESET Disable: supported
QER: 0
0-4-4 Mode methods: entry 0x2 ; exit 0x03
4-4-4 Mode sequences: enable 0x14 ; disable 0xa
4-byte addressing support: enter 0x36, exit 0x0f6
Soft Reset and Rescue Sequence support: 0x3d
Status Register 1 support: 0x01
size = <536870912>;
sfdp-bfp = [
        e5 20 fb ff  ff ff ff 1f  29 eb 27 6b  27 3b 27 bb
        ff ff ff ff  ff ff 27 bb  ff ff 29 eb  0c 20 10 d8
        0f 52 00 00  24 4a 99 00  8b 8e 03 e1  ac 01 27 38
        7a 75 7a 75  fb bd d5 5c  4a 0f 82 ff  81 bd 3d 36
        ];
PH1: ff84 rev 1.0: 2 DW @ 80
sfdp-ff84 = [
        ff e7 ff ff  21 dc ff ff
        ];
jedec-id = [32 31 20];

jesd216 of the disco_l475_iot1 (west build -p auto -b disco_l475_iot1 samples/drivers/jesd216/) gives:
*** Booting Zephyr OS build zephyr-v3.3.0-1723-g228a5100f747 ***
qspi-nor-flash@0: SFDP v 1.6 AP ff with 3 PH
PH0: ff00 rev 1.6: 16 DW @ 30
Summary of BFP content:
DTR Clocking not supported
Addressing: 3-Byte only
4-KiBy erase: uniform
Support QSPI XIP
Support 1-1-1
Support 1-1-2: instr 3Bh, 0 mode clocks, 8 waits
Support 1-1-4: instr 6Bh, 0 mode clocks, 8 waits
Support 1-2-2: instr BBh, 0 mode clocks, 4 waits
Support 1-4-4: instr EBh, 2 mode clocks, 4 waits
Flash density: 8388608 bytes
ET1: instr 20h for 4096 By; typ 48 ms, max 384 ms
ET2: instr 52h for 32768 By; typ 240 ms, max 1920 ms
ET3: instr D8h for 65536 By; typ 480 ms, max 3840 ms
Chip erase: typ 52000 ms, max 312000 ms
Byte program: type 32 + 1 * B us, max 192 + 6 * B us
Page program: typ 896 us, max 5376 us
Page size: 256 By
Suspend: B0h ; Resume: 30h
DPD: Enter B9h, exit ABh ; delay 40000 ns ; poll 0x3d
HOLD or RESET Disable: unsupported
QER: 2
0-4-4 Mode methods: entry 0x9 ; exit 0x2f
4-4-4 Mode sequences: enable 0x00 ; disable 0x0
Soft Reset and Rescue Sequence support: 0x10
Status Register 1 support: 0x70
size = <67108864>;
sfdp-bfp = [
        e5 20 f1 ff  ff ff ff 03  44 eb 08 6b  08 3b 04 bb
        ee ff ff ff  ff ff 00 ff  ff ff 00 ff  0c 20 0f 52
        10 d8 00 ff  23 72 f5 00  82 ed 04 cc  44 83 48 44
        30 b0 30 b0  f7 c4 d5 5c  00 be 29 ff  f0 d0 ff ff
        ];
PH1: ffc2 rev 1.0: 4 DW @ 110
sfdp-ffc2 = [
        00 36 50 16  9d f9 c0 64  fe cf ff ff  ff ff ff ff
        ];
PH2: ff84 rev 1.0: 2 DW @ c0
sfdp-ff84 = [
        00 00 f0 ff  ff ff ff ff
        ];
jedec-id = [66 66 20];

running the samples/drivers/spi_flash:
qspi-nor-flash-1@0 SPI flash testing
==========================

Perform test on single sector
Test 1: Flash erase
Flash erase succeeded!

Test 2: Flash write
Attempting to write 4 bytes
Data read matches data written. Good!!

Perform test on multiple consequtive sectors
Test 1: Flash erase
Flash erase succeeded!

Test 2: Flash write
Attempting to write 4 bytes at offset 0xff000
Data read matches data written. Good!!
Attempting to write 4 bytes at offset 0x100000
Data read matches data written. Good!!

@erwango @de-nordic please revisit

@FRASTM Please rebase.

Rebase 3bef10f39804e74d9220f3296a156ed90aba2117
Adapt after merge of the  https://github.com/zephyrproject-rtos/zephyr/pull/55824

authors: FRASTM MaureenHelm de-nordic


text:
tests bsim: Limit parallel build

The compile script had been modified
to fully parallelize all images builds
in 1de363d9d5279e2c3d6021fecad41ffca96e09f1
And has been kept building everything in parallel since then. Over time we have seen an increase in the number of hangs for this job in CI.
This is understood as being the result of the number of images having increased, leading to a too high load
on the worker machines which cause them to timeout their connection to the github CI scheduler.
In b83a82882559f0c4a6bc0a64f83be06cdbdf79c1
these jobs priority was lowered to alleviate this issue, but again we see an increased number of CI runner
disconnects.
Let's parallelize this compile jobs a bit less.
With this change, we do not build anymore the sets of host, ll and mesh test images in parallel but sequentially.
On a local test with a clean ccache this reduces the peak 1 average load from
~1700 to ~700, and eliminates issues with system unresponsiveness;
while there is no statistically measurable increase in overall build time.
Note that the single audio image is still built in parallel to the other 3 sets, as this was seen to improve total build time by 2 seconds out of 1m51s.

Context:

The rate of this type of hangs is still relatively low: A quick check showed 2 connection losses in the last 150 runs.
These build and run scripts are meant to go away, as we plan to add support to twister for this type of tests, so this kind of quick solution should be more than good enough as a stop gap.

Note that the single audio image is still built in parallel to the other 3 sets, as this was seen to improve total build time by 2 seconds out of 1m51s.

I think perhaps it would be worth adding a comment in the script to mention this, otherwise it just kind of looks... Odd :D
If it's just a matter of 2 seconds, then we may also consider just building audio in the same way as the others.
I guess it isn't faster to build in parallel because the compile itself it done in parallel, and the only part that could benefit from parallelism is the linking?

Note that the single audio image is still built in parallel to the other 3 sets, as this was seen to improve total build time by 2 seconds out of 1m51s.

I think perhaps it would be worth adding a comment in the script to mention this, otherwise it just kind of looks... Odd :D

I can certainly do that :)

If it's just a matter of 2 seconds, then we may also consider just building audio in the same way as the others.

I did consider doing so, but then I expected somebody may get annoyed by the increase :)

I guess it isn't faster to build in parallel because the compile itself it done in parallel, and the only part that could benefit from parallelism is the linking?

I think cmake is the main issue here.

I did consider doing so, but then I expected somebody may get annoyed by the increase :)

Alright :) We may at some point consider separate binaries for each audio test (like we have for the host), at which point we may want to apply sequential compiling to it, but it is fine for now (or at least you have my permission to make it sequential ;) )

@aescolar is this something that'd make sense to merge before 3.5? (the milestone isn't set and there's no "Fixes: ..." entry, so it's not clear to me)

@aescolar is this something that'd make sense to merge before 3.5? (the milestone isn't set and there's no "Fixes: ..." entry, so it's not clear to me)

Let's better get it in. I will add a bug and a "Fixes" :)

authors: Thalley aescolar jhedberg


text:
doc: Supplement list of implemented socket operations

Add sendto() and recvfrom() to the list of implemented operations
in BSD Socket API.
Signed-off-by: Stig Bjørlykke stig.bjorlykke@nordicsemi.no

Codecov Report

Merging #6728 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6728      +/-   ##
==========================================
+ Coverage   54.31%   54.32%   +<.01%
==========================================
  Files         444      444
  Lines       42179    42179
  Branches     7995     7995
==========================================
+ Hits        22911    22912       +1
+ Misses      16060    16059       -1
  Partials     3208     3208

Impacted Files
Coverage Δ

kernel/posix/pthread.c
69.5% <0%> (+0.5%)
:arrow_up:

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 5f42a26...bfc9649. Read the comment docs.

authors: codecov-io stig-bjorlykke


text:
samples: sensor: Enable bme280 sensor using I2C driver

Added overlay to enable bme280 sensor
using i2c on esp32_devkitc_wroom board.

It is connected manually,

@MaureenHelm  any comment on this changes please.

It is connected manually

Then the value of adding this overlay to the source tree is probably very limited. We certainly don't want / can't have upstream all the overlays possible for any combination of sensors people may attach to their dev kits :)
I will close this PR if that's ok with you. Let me know if you have questions or concerns

authors: kartben srinivas-aerlync


text:
everywhere: replace double words

import os
import re

common_words = set([
    'a', 'about', 'after', 'all', 'also', 'an', 'and', 'any', 'are', 'as', 'at',
    'be', 'because', 'but', 'by', 'can', 'come', 'could', 'day', 'do', 'even',
    'first', 'for', 'from', 'get', 'give', 'go', 'has', 'have', 'he', 'her',
    'him', 'his', 'how', 'I', 'if', 'in', 'into', 'is', 'it', 'its', 'just',
    'know', 'like', 'look', 'make', 'man', 'many', 'me', 'more', 'my', 'new',
    'no', 'not', 'now', 'of', 'on', 'one', 'only', 'or', 'other', 'our', 'out',
    'over', 'people', 'say', 'see', 'she', 'so', 'some', 'take', 'tell', 'than',
    'that', 'the', 'their', 'them', 'then', 'there', 'these', 'they', 'think',
    'this', 'time', 'to', 'two', 'up', 'use', 'very', 'want', 'was', 'way',
    'we', 'well', 'what', 'when', 'which', 'who', 'will', 'with', 'would',
    'year', 'you', 'your'
])

valid_extensions = set([
    'c', 'h', 'yaml', 'cmake', 'conf', 'txt', 'overlay', 'rst', 'dtsi',
    'Kconfig', 'dts', 'defconfig', 'yml', 'ld', 'sh', 'py', 'soc', 'cfg'
])

def filter_repeated_words(text):
    # Split the text into lines
    lines = text.split('\n')

    # Combine lines into a single string with unique separator
    combined_text = '/*sep*/'.join(lines)

    # Replace repeated words within a line
    def replace_within_line(match):
        return match.group(1)

    # Regex for matching repeated words within a line
    within_line_pattern = re.compile(r'\b(' + '|'.join(map(re.escape, common_words)) + r')\b\s+\b\1\b')
    combined_text = within_line_pattern.sub(replace_within_line, combined_text)

    # Replace repeated words across line boundaries
    def replace_across_lines(match):
        return match.group(1) + match.group(2)

    # Regex for matching repeated words across line boundaries
    across_lines_pattern = re.compile(r'\b(' + '|'.join(map(re.escape, common_words)) + r')\b(\s*[*\/\n\s]*)\b\1\b')
    combined_text = across_lines_pattern.sub(replace_across_lines, combined_text)

    # Split the text back into lines
    filtered_text = combined_text.split('/*sep*/')

    return '\n'.join(filtered_text)

def process_file(file_path):
    with open(file_path, 'r', encoding='utf-8') as file:
        text = file.read()

    new_text = filter_repeated_words(text)

    with open(file_path, 'w', encoding='utf-8') as file:
        file.write(new_text)

def process_directory(directory_path):
    for root, dirs, files in os.walk(directory_path):
        dirs[:] = [d for d in dirs if not d.startswith('.')]
        for file in files:
            # Filter out hidden files
            if file.startswith('.'):
                continue
            file_extension = file.split('.')[-1]
            if file_extension in valid_extensions:  # 只处理指定后缀的文件
                file_path = os.path.join(root, file)
                print(f"Processed file: {file_path}")
                process_file(file_path)

directory_to_process = "/home/mi/works/github/zephyrproject/zephyr"
process_directory(directory_to_process)

As a supplement to this PR:https://github.com/zephyrproject-rtos/zephyr/pull/74650

@kartben Please take a look, tks.


text:
Switch to the latest release of jsoniter-scala

...with more efficient parsing and serialization of Base16 representation:
[info] Benchmark                        Mode  Cnt        Score   Error  Units
[info] z.p.data.Decode.jsoniter_scala  thrpt    2   452137.824          ops/s
[info] z.p.data.Encode.jsoniter_scala  thrpt    2  1074555.397          ops/s
[info] z.p.msg.Decode.jsoniter_scala   thrpt    2  4341021.472          ops/s
[info] z.p.msg.Encode.jsoniter_scala   thrpt    2  8486618.088          ops/s

CAUTION: The latest microcode update from Intel brings up to 30% slowdown for the most optimized code with deep inlining, loop unrolling, and vectorization.
So, the current results for same benchmarks on the same CPU but with the latest microcode are:
[info] Benchmark                        Mode  Cnt        Score   Error  Units
[info] z.p.data.Decode.jsoniter_scala  thrpt    2   393800.502          ops/s
[info] z.p.data.Encode.jsoniter_scala  thrpt    2   943211.139          ops/s
[info] z.p.msg.Decode.jsoniter_scala   thrpt    2  3888296.318          ops/s
[info] z.p.msg.Encode.jsoniter_scala   thrpt    2  6624891.402          ops/s

repo: zero-deps/protobuf-scala-macros

license: MIT


text:
[Bug]: ControlNet breaks outpainting real images

What happened?
working on a project with the imagenet dataset, where I try to collage them next to one another and inpaint in the gaps, so as to make it sort of believable. It kind of works with the standard stable diffusion inpainting model, where the constraints set by the original image are kind of respected. But once I try to use ControlNet with a model like "epicrealism" for example, the outpointing gets completely broken. The ControlNet model I'm using is Kataragi_inpaintXL-fp16 [d20c87b4] with inpaint_only+lama set as the preprocessor. It doesn't seem to work with outpainting a generated dream either. Or am I doing something wrong? Please let me know.
Steps to reproduce the problem
if you want to reproduce it download the Kataragi_inpaintXL-fp16 [d20c87b4] ControlNet model with realisticVisionV60B1_v51HyperVAE.safetensors as the base stable diffusion model and try to make a dream and then extend it with ControlNet  outpainting.
What should have happened?
ControlNet should extend the original image/dream by outpainting, yet it completely ignores it. It crates a harsh divide, which is basically a new image with no relation to the previous one.
Commit where the problem happens
latest main branch
What platforms do you use to access openOutpaint?
MacOS
What browsers do you use to access the UI ?
Google Chrome
Browser Extensions/Addons
grammarly, my bib
AUTOMATIC1111 webUI Commandline Arguments
--api --cors-allow-origins=https://zero01101.github.io
Additional information
No response

hey, sorry for the delay; check https://github.com/zero01101/openOutpaint/issues/291 to see if that's what you're experiencing - basically controlnet deprecated an API parameter and i missed it, but if it's the same thing then it should be all fixed up now - apologies


text:
Variety field is mandatory. Please update documentation

order_id = kite.place_order(tradingsymbol="INFY",
exchange=kite.EXCHANGE_NSE,
transaction_type=kite.TRANSACTION_TYPE_BUY,
quantity=1,
order_type=kite.ORDER_TYPE_MARKET,
product=kite.PRODUCT_NRML)

closed

repo: zerodhatech/pykiteconnect


text:
Add on paint and on erase background to common controls

Issue #15

Hmm... It looks like I made a big mess in my repo branches. There are things I still don't understand with Git/Github.

Now, there are 2 Background_Color procedures. One for Status_Bar_Type and one for Common_Control_Type.
The one for Status_Bar_Type is a system (Windows) one. I have not seen any effect using it.
The one for Common_Control_Type effectively paints the background with the chosen color.

Hmm... It looks like I made a big mess in my repo branches. There are things I still don't understand with Git/Github.

It seems to be easy to mess things with GitHub - see for instance this recent pull request: https://github.com/zertovitch/gwindows/pull/13#issuecomment-1657075405
About messing & git, but perhaps unrelated to the current topic, there is a good help here: https://deepbluecap.com/git-recover-from-messy-situations/

authors: NicoPy zertovitch

repo: zertovitch/gwindows


text:
unittests: the deprecation of ZetaConversionRate RPC & state variable breaks unit tests

ref: #355

Closing as it seems no longer relevant with the current state of the project. Feel free to reopen it.

repo: zeta-chain/node


text:
autpoi 2.0.1版本导出报错

版本号：autpoi 2.0.1版本
问题描述：
该版本导出有遇到如下报错
2021-02-24 22:20:07.155 [http-nio-9999-exec-1] ERROR o.a.c.c.C.[.[.[/yuns].[dispatcherServlet]:175 - Servlet.service() for servlet [dispatcherServlet] in context with path [/yuns] threw exception [Request processing failed; nested exception is org.jeecgframework.poi.exception.excel.ExcelExportException: Excel导出错误] with root cause
切换回1.2.2却没有问题
截图&代码：
友情提示： 未按格式要求发帖，会直接删掉。

什么功能？请补充issue描述

什么功能？请补充issue描述

 ModelAndView mv = new ModelAndView(new JeecgEntityExcelView());
        mv.addObject(NormalExcelConstants.FILE_NAME, title);
        mv.addObject(NormalExcelConstants.CLASS, pojoClass);
        mv.addObject(NormalExcelConstants.PARAMS, new ExportParams(title, "导出人:" + sysUser.getRealname(), "导出信息"));
        mv.addObject(NormalExcelConstants.DATA_LIST, array);

在使用导出autopoi导出功能的时候
采用@Excel标注字段的方式
在2.0.1就会出现上述报错信息
但是切换回1.2.2却没有这个问题

收录

测试未重现你说的问题，请描述一下你重现问题的整个流程步骤，方便的话，建议把相关代码或者实体配置贴出来

测试未重现你说的问题，请描述一下你重现问题的整个流程步骤，方便的话，建议把相关代码或者实体配置贴出来

我也不知道还能怎么描述，就是单纯的excel导出。在字段类对字段使用@Excel注解标记我需要导出的字段。完全是按照官方文档的教程使用来使用autopoi导出功能；
没有像其中一个issues那样有自己重写过里面相关内容。

把请把详细的错误日志帖一下

authors: Fnckerpoi lsqGitHub716 zhangdaiscott

repo: zhangdaiscott/jeecg-boot

license_source: bigquery


text:
🛑 ZY is down

In 11b1cd2, ZY (https://ziyuan.baidu.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZY is back up in 03c110f.

repo: zhaodylan/uptime-ziyuan


text:
🛑 ZY is down

In 354a381, ZY (https://ziyuan.baidu.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZY is back up in 655f316.


text:
🛑 ZY is down

In 68c098d, ZY (https://ziyuan.baidu.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZY is back up in 93d7802.


text:
Init node conv1/kernel/Assign doesn't exist in graph when freezing a model

Hey,
I'm getting this error:
Init node conv1/kernel/Assign doesn't exist in graph
When trying to freeze a model using your library and guide.
This happens even on the asset/yolo-model...
Any idea what might be the issue?
I'm using tensorflow with GPU..

This error does not affect the model freeze

@yakeer  I have the same error message here, but I have tested that the generated tflite model does not have a loss of precision.


text:
Feature sequences

Hello, I'm confused about token size because it's square(8x8 or 16x16) on ViT.
As I understand, feature sequence means 256 tokens with 1024 dimension vector.
And $N/N_w(=256/16)$ window feature sequences of Window Block means that there're 16 partitions with 16 sequences per partition.

Then 4 partitions of this figure is just for simplification? Or did I get it wrong?

Yes,  for simplicity, this figure shows the case of $N_w=N/4$.

@zhigangjiang Thanks for your reply!

repo: zhigangjiang/LGT-Net


text:
Migrating from keras to tf.keras

I'm using tf.keras (with TF2), instead of keras standalone library since TF2 integrates better.
So I had to make a few fixes:
import keras.foo becomes
import tf.keras.foo
and
Model(input = my_input, output = my_output) becomes
Model(inputs = my_input, outputs = my_output)
Otherwise, it's a great implementation. Many thanks 非常谢!

I'm using tf.keras (with TF2), instead of keras standalone library since TF2 integrates better.
So I had to make a few fixes:
import keras.foo becomes
import tf.keras.foo
and
Model(input = my_input, output = my_output) becomes
Model(inputs = my_input, outputs = my_output)
Otherwise, it's a great implementation. Many thanks 非常谢!

我也发现了这个问题，在model.py脚本56行处，需要更正为
model = Model(inputs = inputs, outputs = conv10)
这样才运行正确。
感谢

repo: zhixuhao/unet


text:
1.10: Fixed missing deps of typer package

Rolls back PR #593 into 1.10.1.

coverage: 37.115%. remained the same
when pulling a5ca919b49fbc1f1e4cde779fd77c25d6bdcb1c2 on 1.10/andy/fix-missing-deps-typer
into 40c5b5b62f8587d1b56e8be4e08b71e07fac0679 on stable_1.10.

authors: andy-maier coveralls

repo: zhmcclient/zhmccli


text:
Migrate to dotnet core

This is an initial attempt to migrate the whole project onto dotnet core.
The project can be successfully run by dotnet run --project qpmodel with the following output:
select tumble_start(a0, interval '10' second), tumble_end(a0, interval '10' second), count(*) from ast group by tumble(a0, interval '10' second)
***************** raw plan *************
LogicAgg
    Group by: tumble(a0[0],10second)
    -> LogicScanTable ast

***************** optimized plan *************
LogicAgg
    Group by: tumble(a0[0],10second)
    -> LogicScanTable ast

Memo:
0:      1, 1, [42292240][NaN]: ast,PScan(ast: 1)
*1:     1, 1, [-1941974609][NaN]: Agg(0),PHashAgg(0: 3)
---------------------------
Summary: 2,2

Memo:
0:      1, 1, [42292240][1]: ast,PScan(ast: 1)
*1:     1, 1, [-1941974609][4]: Agg(ast),PHashAgg($PScan(ast: 1): 3)
---------------------------
Summary: 2,2
***************** Memo plan *************
Total cost: 4
PhysicHashAgg  (inccost=4, cost=3, rows=1) (actual rows=0)
    Output: {tumble_start(a0,10second)}[1],{tumble_end(a0,10second)}[2],{count(*)(0)}[3]
    Aggregates: tumble_start(a0[0],10second), tumble_end(a0[0],10second), count(*)(0)
    Group by: tumble(a0[0],10second)
    -> PhysicScanTable ast (inccost=1, cost=1, rows=1) (actual rows=0)
        Output: a0[0],10second

-- profiling plan --
Total cost: 4
PhysicHashAgg  (inccost=4, cost=3, rows=1) (actual rows=0)
    Output: {tumble_start(a0,10second)}[1],{tumble_end(a0,10second)}[2],{count(*)(0)}[3]
    Aggregates: tumble_start(a0[0],10second), tumble_end(a0[0],10second), count(*)(0)
    Group by: tumble(a0[0],10second)
    -> PhysicScanTable ast (inccost=1, cost=1, rows=1) (actual rows=0)
        Output: a0[0],10second

RunTime: 00:00:00.0559630

However there are several things I want to resolve before this can be merged.

Although this project can be successfully run now, it will output some warnings:

/home/youngw/projects/qpmodel/qpmodel/qpmodel.csproj : warning NU1701: Package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform 3.5.0-preview1' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETCoreApp,Version=v3.1'. This package may not be fully compatible with your project.

I did a search and it says this warning doesn't affect the actual functionalities. I guess we need to somehow suppress this warning in the csproj file to make things tidier.

A bunch of dependencies are commented out in qpmodel.csproj.
Although they are commented out, it seems like the library just works fine. Maybe we can safely remove these unused dependencies? Or can anyone explain to me what are these commented out dependencies used for?

The app.config files are not used seemingly. Maybe we can also remove them?

For the ANTLR4 package I commented out <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> but I'm not sure what's this IncludeAssets for. With this line included the compiler complains cannot find ANTLR.

Weiyun,
Thanks for the patch.
Project configuration: most likely they are automatically generated with VS studio. Have you run unittest and make sure it passes? Some of your questions might be answered by it. Program.Main() is mostly served as an entrance for debugging specific queries.

There are 12 out of 42 tests failed.

There is another issue happens pervasively: the table name in the physical plan somehow is removed while the expected output preserves it.
For example, with an expected plan like this:
PhysicNLJoin   (actual rows=3)
    Output: a.a2[0],a.a3[1],a.a1[2]+b.b2[3]
    Filter: a.a1[2]+b.b3[4]>2
    -> PhysicScanTable a  (actual rows=1)
        Output: a.a2[1],a.a3[2],a.a1[0]
        Filter: a.a1[0]>1
    -> PhysicScanTable b  (actual rows=3)
        Output: b.b2[1],b.b3[2]

the assertion failed with:
 Assert.AreEqual failed. Expected:<a.a2[0],a.a3[1],a.a1[2]+b.b2[3]>. Actual:<a2[0],a3[1],a1[2]+b2[3]>.

 Assert.AreEqual failed. Expected:<a.a2[0],a.a3[1],a.a1[2]+b.b2[3]>. Actual:<a2[0],a3[1],a1[2]+b2[3]>.

The behavior is controlled by static ExplainOption.show_tablename_ - it can cause issues as it is global. The reason it is global because I need to use it deep in stack and passing it via global is the easiest way.
The problem might be due to how/the order we set this variable in unittest. You can set running order in "Test Explorer" window  by click "Test" column and make it alphabet sorted to see if the issue went away.

Wait for me to investigate why test/regress/expect/tpch0001/q06.txt changed.

authors: dovahcrow zhouqingqing

repo: zhouqingqing/qpmodel


text:
Blocklauncher Pro crashing when importing textures - 13.0

blocklauncher_crash_1449344068.txt
When importing textures on a Kindle Fire HD7 4 running Fire OS 4.5.5, Blocklauncher Pro will either crash or go into safe mode. Upon attempting to leave safe mode, it crashes again. I've tried clearing the cache and reinstalling several times.
EDIT: When I get it to work, the textures are corrupt. It's every texture pack.

One of your texture packs has an old terrain.meta that's not compatible with 0.13.1. Please make sure that your texture packs are compatible.

authors: Dankscrub zhuowei

repo: zhuowei/MCPELauncher


text:
Add Tuya dimmable LED controller quirk (TS0501B)

The Tuya dimmable LED controller (TS0501B) has a Color cluster but doesn't report any color capabilities: the RGB wheel is shown in Home Assistant.
This quirk overrides the color capabilities to 0.
Tested and working.
Signature: https://paste.ubuntu.com/p/ZqbRwZfxqT/

Codecov Report

Merging #818 (4bcab87) into dev (5ef6918) will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              dev     #818      +/-   ##
==========================================
+ Coverage   83.14%   83.18%   +0.04%
==========================================
  Files         181      182       +1
  Lines        4426     4437      +11
==========================================
+ Hits         3680     3691      +11
  Misses        746      746

Impacted Files
Coverage Δ

zhaquirks/tuya/ts0501b.py
100.00% <100.00%> (ø)

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 5ef6918...4bcab87. Read the comment docs.

Pull Request Test Coverage Report for Build 651728859

11 of 11 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 83.187%

Totals

Change from base Build 646589804:
0.04%

Covered Lines:
3691

Relevant Lines:
4437

💛  - Coveralls

authors: TheJulianJES codecov-io coveralls

repo: zigpy/zha-device-handlers


text:
createAccount example

Is it possible to get a little createAccount example.
I read "CreateAccount SOAP Command" doc in zimbra docs, but still have some trouble to apllicate it.
Thank you very much.

Ok, finally I found how to did it :
$create_account_res = $api->createAccount("testuser@domain.com", "secret");
Now the problems are :

How to check if user already exists? Or how to intercept an Exception that will be thrown because the user exists.
How to print (or analyse) the return of  command, i.e. $create_account_res

I saw that $create_account_res has a type of object.
It was an Xml that was converted into Object (there is a method toObject() for this).
But I have somedifficulties to work with this object... how to do it?
Or is it possible to get directly an Xml and not an object ?

I will try to help for you with your first question.
You can try to add, if it's exists, already exists will be return. Or if you want to only check, you can try to get account details with GetAccount. if it's exists account details will return. if it's not, not found will be return.
I hope understand your question.

Thank you kazimc.
But my issue is more concern about lack of documentation and/or examples for this project. And it's complicated by fact that I have not experience/knowledge in php development.
Probably for php developers it should seem obvious how to use this library, but not for me.
So my question was most about code example, not the algorithm.
Now, to get the things more concrete. This code is very ugly, but is it correct on the idea level?
I know I do twice almost the same check. But it better check twice than zero...
$account_name='testuser@domain.com';
$account = new \Zimbra\Struct\AccountSelector(\Zimbra\Enum\AccountBy::NAME(), $account_name);
try {
     $accountInfo = $api->getAccountInfo($account);

     echo "Some problem!
";
     echo "This account is probably exist already!
";
     echo $accountInfo->name."
";
     print_r($accountInfo);

     exit(1);
} catch (GuzzleHttp\Exception\ServerException $e) {
/*
    Ok, server throw an Exception, so account probably does not exist.
    echo print_r($e);
*/
}
echo "Trying to create account : ".$account_name."
";

try {
     $createAccountRes = $api->createAccount($account_name, "secret");
} catch (GuzzleHttp\Exception\ServerException $e) {
    echo "Some problem!
";
    echo "Account was NOT created!
";
    echo "Server thrown an Error, so may be this account already exist?
";
    echo "
";
//    echo print_r($e);
}

There are some things that make me unhappy...

Solution with exit(-1) seems be VERY ugly. But I don't know how to do it otherwise.
If server thrown an Exception for some other reason, not because account exists already...
I do not know, for example if the server is under maintenance mode.
I will not know this reason. I will still think that the problem is that the account exists.

repo: zimbra-api/zimbra-api


text:
Update Zim Logo and Plugin Loading

Updated the Zim logo in the README, feel free to use it. Along with that, I updated the plugin loading system to load plugins with {plugin name}.plugin.zsh and {plugin name}.zsh in order to improve compatibility.

@Brottweiler Sorry! Working on it right now!

Fixed it! Sorry!

@ericbn @Eriner Ping

I would not merge the logo. I like the idea for the init code. Actually I was working on something similar:
for zmodule_file (${zmodule_dir}/${zmodule}.zsh-theme ${zmodule_dir}/init.zsh ${zmodule_dir}/${zmodule}.zsh ${zmodule_dir}/${zmodule}.sh ${zmodule_dir}/${zmodule}.plugin.zsh); do
  [[ -f ${zmodule_file} ]] && source ${zmodule_file} && break
done

@Eriner, thoughts?

@ericbn Just made some changes to prioritize .plugin.zsh. And prepend zsh- to the plugin script if all else fails.

From a performance perspective, due to the structuring of the conditionals, this won't cause any unecessary disk I/O. I haven't read over the code maticuliously and I'll wait to see what @ericbn says, but the concept and basic structure has a :+1: from me.

@ericbn @Eriner
Would it be ok to replace the last elif with an else, I think it would be better to tell people if a plugin isn't being loaded rather than if a plugin's directory doesn't exist.

Closes #135

@Eriner, I'm more in favor of the for notation, as we can take advantage of globs and it also looks more concise. What do you think?
I like the idea of trying to match a zsh- prefix too. This is what I suggest:
local zmodule_dir
# ...
zmodule_dir=${ZIMFW_HOME}/modules/${zmodule}
if [[ ! -d ${zmodule_dir} ]]; then
  print "No such module \"${zmodule}\"." >&2
else
  for zmodule_file (${zmodule_dir}/{,zsh-}${zmodule}.zsh-theme \
      ${zmodule_dir}/init.zsh \
      ${zmodule_dir}/{,zsh-}${zmodule}.{z,}sh \
      ${zmodule_dir}/{,zsh-}${zmodule}.plugin.zsh); do
    if [[ -f ${zmodule_file} ]]; then
      source ${zmodule_file}
      break
    fi
  done
fi

@AtomicCoding, it is valid to have for example a module with just a functions subdir, but no init script, so that's why we don't fail if that case.

@Eriner, a side note partially related to this change:  I've been actually working on the "distributed modules" loading mechanism for zim, and I extracted the code above from that. Maybe I should push that to a develop branch so we can start looking at it together...

@ericbn I changed some of the priorities and had zmodule_dir be immediately set after being declared because (this might just be me) ZSH echoing the value of it for some reason when it wasn't set like that, either way, here it is:
    local zmodule_dir=${ZIM_HOME}/modules/${zmodule}
    if [[ ! -d ${zmodule_dir} ]]; then
      print "No such module \"${zmodule}\"." >&2
    else
      for zmodule_file (${zmodule_dir}/init.zsh \
          ${zmodule_dir}/{,zsh-}${zmodule}.plugin.zsh \
          ${zmodule_dir}/{,zsh-}${zmodule}.zsh-theme \
          ${zmodule_dir}/{,zsh-}${zmodule}.{z,}sh); do
        if [[ -f ${zmodule_file} ]]; then
          source ${zmodule_file}
          break
        fi
      done
    fi

authors: AtomicCoding Eriner ericbn

repo: zimfw/zimfw


text:
set lib target for tests

This makes it possible to fully typecheck, even declaration files in node_modules...
Without this we'll get a Set/Map not defined error.

Codecov Report

Merging #53 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #53   +/-   ##
=======================================
  Coverage   92.99%   92.99%
=======================================
  Files           9        9
  Lines         357      357
  Branches       46       46
=======================================
  Hits          332      332
  Misses         25       25

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 bd5caed...0459791. Read the comment docs.

authors: codecov-io zinserjan

repo: zinserjan/ts-checker-webpack-plugin

license: mit


text:
Add support for webdriver.io v5

At this stage I'm not sure what the necessary changes to make this compatible with with wdio v5 (http://beta.webdriver.io/).
@zinserjan Would you be happy to have a look?

+1 !

+1

authors: TwoLaid anto-ac batuwka

repo: zinserjan/wdio-screenshot


text:
Update cats-effect to 3.4.0

Updates org.typelevel:cats-effect from 3.3.14 to 3.4.0.
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!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel", artifactId = "cats-effect" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.typelevel", artifactId = "cats-effect" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #1024.

repo: zio/zio-aws


text:
Fix ZIO AWS breaking changes in latest release

There are breaking changes such as TableArn replaces TableName

closed by https://github.com/zio/zio-dynamodb/pull/517

repo: zio/zio-dynamodb


text:
Update sbt-bloop to 1.5.18

About this PR
📦 Updates ch.epfl.scala:sbt-bloop from 1.4.2 to 1.5.18
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
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!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "ch.epfl.scala", artifactId = "sbt-bloop" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "ch.epfl.scala", artifactId = "sbt-bloop" }
}]

labels: sbt-plugin-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #411.

repo: zio/zio-gcp


text:
Fix compilation of Recursive GADT schema derivation

/claim #547

@zio/zio-schema @jdegoes gentle reminder that this needs review, thanks!

repo: zio/zio-schema


text:
New Contribution

Contributor: cbnoi
SSH Public key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOmsjki7VLan3/Lk43YX5co30PxympMAYkBBAWiuLop1
Attestation: [any form of attestation for contribution (e.g., signature) - Optional]

I'm ready

I'm ready

repo: zircuit-labs/ceremony


text:
Helm Chart

We should provide a helm chart for version 2 to make using ZITADEL on K8s a straight and easy process.
Acceptance criteria

[ ] Provide helm chart with the necessary fields exposed (config, secrets)

@fgerschwiler we should plan that ahead due to feedback from reddit
Who has already some knowledge around this? @eliobischof, @stebenz or @thesephirot ?

repo: zitadel/zitadel


text:
Integrate frameworks in console

As a user of console I want to see predefined configurations of popular frameworks during app creation. As soon as I click on one of the predefined configurations console skips the the configuration steps and allows me to directly set the redirect uris. the redirect uris should be pre filled with the localhost defaults of the framework or according to our docs.
analog to: https://zitadel.com/docs/sdk-examples/introduction
### Tasks
- [ ] design app creation flow
- [ ] implement frameworks (list analog docs)
- [ ] implement flow

info
if possible reuse docs code so that we can manage the data at a single place

ref https://github.com/zitadel/zitadel/pull/7417

authors: adlerhurst peintnermax


text:
chore: improve ci

### 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
- [ ] 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.

Should we also move lint and build to the Makefile? And add a Dockerfile so Windows users and users who don't want to install all build dependencies can also use the Makefile?

replaced by https://github.com/zitadel/zitadel/pull/5953

authors: adlerhurst eliobischof fforootd


text:
fix(account-selection): #5505 use font color as color for labels

Definition of Ready

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

The colors configured in the instance resp. project settings for the font were not used for labels. See #5505 for more infos.

Hei @dsiscout
I quickly had a look, and from my perspective it doesn't look like the issue #5505 gets fixed by this.
Can you please add a short description in your PR what the issue is about to solve?

Hello @hifabienne
The issue is, that for labels, the font color in the settings is not taken (https://github.com/zitadel/zitadel/issues/5505). In our case, we do not want to differentiate between light and dark mode, so we use the same configs on both. But the label color is not configurable, which is why on our account selection the username is white:

In this PR, what I am basically doing is, setting the label color same as the font color, and now when I test locally it looks like this:

Let me know if you need further information or anything I should adjust in the PR.
Best regards

I think the initial idea was to distinguish the color of labels and texts.
This change would get rid of this, which i'm fine as it solves at least some part of the light / dark problems mentioned in the issue.
It will obviously have an impact on developers, resp. their design as soon as the change something and would also get another color for their labels.
IMO we should move forward as this solves more problems than it could potentially cause.
@hifabienne any objections?

@livio-a Yes I am with you.

@dsiscout thanks for this contribution 😃
If you'd like to have a small gift in return, please send us a mail to hi@zitadel.com. We will send you a form with questions about your address and shirt size.

authors: dsiscout hifabienne livio-a


text:
loss never decreasing

查看了EMBEDDING部分应该没有问题，但是输入到LSTMP layer和LSTMO layer之后对每句话的输出分布极为相似，导致后面对每个单词的标签预测都是同一个值，因此LOSS不降。标准LSTM的LOSS也不降，且标准LSTM layer1对每句话的输出分布不同，到标准LSTM layer2对每句话的输出分布就很相似了

epoch :  0
batch :  0
current loss :
 154.5876
[torch.FloatTensor of size 1]

batch :  1
current loss :
 142.3224
[torch.FloatTensor of size 1]

batch :  2
current loss :
 126.7297
[torch.FloatTensor of size 1]

batch :  3
current loss :
 106.5865
[torch.FloatTensor of size 1]

batch :  4
current loss :
 60.0537
[torch.FloatTensor of size 1]

batch :  5
current loss :
 66.7900
[torch.FloatTensor of size 1]

batch :  6
current loss :
 44.6394
[torch.FloatTensor of size 1]

batch :  7
current loss :
 42.1091
[torch.FloatTensor of size 1]

batch :  8
current loss :
 41.0118
[torch.FloatTensor of size 1]

batch :  9
current loss :
 40.1179
[torch.FloatTensor of size 1]

What changed:

use optim.SGD() instead of optim.RMSprop()
add optimizer.step() after loss.backward()

Please close this issue if you think it had resolved.
Thanks! :)

repo: zixia/xi-lstm


text:
Loot not spawning in structures generated by plugins like Custom Structures and Oh The Dungeons You'll Go.

I am currently using the plugins, Custom Structures (https://www.spigotmc.org/resources/custom-structures.38249/) and Oh The Dungeons You'll Go (https://www.spigotmc.org/resources/oh-the-dungeons-youll-go.76437/). For some reason, the chests within these generated structures do not contain any of the Acute Loot items. What qualifies as a naturally spawned chest, and is there a way to fix this?

Hi @browloga490, this is a great question. At a technical level, AcuteLoot is checking chests to see if they have a valid lootTable. Chests spawned by the vanilla world generator have lootTables. Conveniently, the lootTable is removed as soon as the chest is opened for the first time. In this way, the lootTable is a good proxy for an "unopened, naturally spawned" chest. It appears that the plugins above don't give their chests lootTables through the Spigot/Bukkit API which would explain why they are ignored by AcuteLoot.
As the plugin was originally designed to work in a relatively vanilla manner, we never considered handling it in any other way. I think it is worth at least looking into alternatives so that plugins like the ones you're running can work with AcuteLoot's generators. However it will require some thought and testing to design a system that works in the most general cases and maintains effortless compatibility with the vanilla game.

Sorry for the late replay. Thank you for the explanation!

@browloga490 Just wanted to let you know, the latest update includes a command to designate AcuteLoot chests. You can also make them auto-refilling over time. I know this won't help with automatically creating new chests in new chunks, but hopefully you can still find it useful! Hop in the Discord if you have any questions or other ideas.

repo: zizmax/AcuteLoot


text:
FileNotFoundError: [Errno 2] No such file or directory: './meta/rel2id.json'

当我跑ner任务的时候报错FileNotFoundError: [Errno 2] No such file or directory: './meta/rel2id.json'，请问怎么解决？

是standard NER？数据集应该放在data文件夹下，直接按README下载解压即可。

是的，是standard NER，数据集也在data文件夹里面，运行Python run.py报错ileNotFoundError: [Errno 2] No such file or directory: './meta/rel2id.json'

data是放在standard下面，但是standard NER数据集里没有rel2id.json这个文件，这是用在关系抽取的。
可以截图报错信息发一下吗？

您好，谢谢，这个问题解决了，出现了新的问题，是这个：ModuleNotFoundError: No module named 'transformers.configuration_bart'

我已经安装了transformers的包了

transformers版本降到3.4.0

好的谢谢，之前的报错是这样的，您可以看看

transformers版本降到3.4.0

transformers的版本是3.4.0

data是放在standard下面，但是standard NER数据集里没有rel2id.json这个文件，这是用在关系抽取的。 可以截图报错信息发一下吗？

好的谢谢，之前的报错是这样的，您可以看看

你好🙋♂，你说的问题在之前版本的deepke包中存在，也就是https://github.com/zjunlp/DeepKE/commit/ab6b52c4733fc8b0a36bbb5944309f1b23ce9345 版本的deepke/relation_extraction/document/evaluation.py文件存在这样的问题。如果你需要保留你目前对deepke其他部分的修改，可以clone一下新版的DeepKE并替换一下deepke/relation_extraction或者deepke/relation_extraction/document目录来解决这个错误。

data是放在standard下面，但是standard NER数据集里没有rel2id.json这个文件，这是用在关系抽取的。 可以截图报错信息发一下吗？

好的谢谢，之前的报错是这样的，您可以看看

你好🙋♂，你说的问题在之前版本的deepke包中存在，也就是ab6b52c 版本的deepke/relation_extraction/document/evaluation.py文件存在这样的问题。你可以把deepke更新到最新版本，如果你需要保留你目前对deepke其他部分的修改，可以clone一下新版的DeepKE并替换一下deepke/relation_extraction或者deepke/relation_extraction/document目录来解决这个错误。

好的，谢谢，麻烦您了，那我的另一个错误能帮忙看看么？

pip install deepke --upgrade试试

将deepke更新到最新版本试试

pip install deepke --upgrade

您好，我已经更新了deepke最新版本，然后出现了新的问题

这个我应该选择什么呢？

如果你不想可视化运行结果，就输入3并回车，这个是wandb包的用法，可以搜索一下一下

如果你不想可视化运行结果，就输入3并回车，这个是wandb包的用法，可以搜索一下一下

pytorch GPU没有安装成功，或者CUDA版本不对，检查一下

pip install deepke --upgrade

您好，我已经更新了deepke最新版本，然后出现了新的问题  这个我应该选择什么呢？

建议1，会有操作提示，按照提示操作即可。

如果你不想可视化运行结果，就输入3并回车，这个是wandb包的用法，可以搜索一下一下

pytorch GPU没有安装成功，或者CUDA版本不对，检查一下

你或许没有安装pytorch配套的cuda，参考一下这个文档试试，https://blog.csdn.net/HPGaa/article/details/117230868 。

pytorch 1.11.0即可

pytorch 1.11.0即可

好的谢谢

请问一下这个ner的基础模型就使用了bert直接做ner是么？

请问一下这个ner的基础模型就使用了bert直接做ner是么？

是

请问一下这个ner的基础模型就使用了bert直接做ner是么？

是

训练的时候如何看训练效果呢？

训练后会显示eval的结果

训练后会显示eval的结果

那是只训练3个epoch就可以了么？还是说需要根据数据来增加epoch的数量？

训练后会显示eval的结果

那是只训练3个epoch就可以了么？还是说需要根据数据来增加epoch的数量？

可以根据结果f1-score大小来调整epoch

训练后会显示eval的结果

那是只训练3个epoch就可以了么？还是说需要根据数据来增加epoch的数量？

可以根据结果f1-score大小来调整epoch

OK，好的谢谢，非常感谢

请问我如何修改batch size呢？在配置文件中没有看到batch size

请问我如何修改batch size呢？在配置文件中没有看到batch size

https://github.com/zjunlp/DeepKE/blob/main/example/ner/standard/conf/train.yaml 有的

https://github.com/zjunlp/DeepKE/blob/main/example/ner/standard/conf/train.yaml

eval_batch_size是这个值？

请问我如何修改batch size呢？在配置文件中没有看到batch size

https://github.com/zjunlp/DeepKE/blob/main/example/ner/standard/conf/train.yaml 有的

train_batch_size是这个值？

training时候的batch_size是train_batch_size，train之后eval的batch_size是eval_batch_size

authors: JxuHenry TimelordRi xxupiano

repo: zjunlp/DeepKE


text:
torch模块找不到

请问这是什么问题，始终找不到这个包。提示的是大于等于1.5，小于等于1.10，但是已经特意安装到1.10版本还是不行

可以通过pip list命令查看一下当前环境中有没有安装torch包，有的话可以去pytorch官网按照对应命令来重新进行安装

刚刚又换了1.7.1版本的试了，还是不行，在pip list中也是有的，可以看图

新写的python文件只写了一行import torch，运行起来也是找不到，这应该是我本地的问题了吧

在conda中的python交互环境还是可以导入的

要不重新安装环境试试？

重新安装环境后依旧有这个问题，步骤如下：
windows conda 创建 python 3.8.15 环境
根据源码安装，先后分别执行py setup.py install ; py setup.py develop(setup.py文件第20行被我设置成空字符串了)
pip install -r requirement.txt
再回来py predicate.py
报错如下：

从报错路径可以看出目前环境在\dev\source_code xxx，不是conda环境。
请用'python'而不是'py'执行python脚本，例如python predict.py

这个问题解决了，又跑出来下一个问题，算了

authors: EightMonth tlk1997 xxupiano


text:
When the parameter changes, public_inputs remain unchanged

BASEDIR=test-vectors RUST_LOG=info ELF_PATH=/mnt/data/xander/test/test_proof/hello_world_mips1.22 SEG_OUTPUT=/tmp/output SEG_SIZE=262144 ARGS="123456 321" cargo run --release --example zkmips split
warning: `/mnt/data/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
    Finished `release` profile [optimized] target(s) in 0.25s
     Running `target/release/examples/zkmips split`
[]string{"123456", "321"}
result 39629376

BASEDIR=test-vectors RUST_LOG=info SEG_FILE_NUM=2 SEG_FILE_DIR=/tmp/output SEG_SIZE=262144 cargo run --release --example zkmips aggregate_proof_all
warning: `/mnt/data/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
    Finished `release` profile [optimized] target(s) in 0.25s
     Running `target/release/examples/zkmips aggregate_proof_all`
[2024-06-17T07:01:19Z INFO  zkmips] Process segment 0
[2024-06-17T07:01:22Z INFO  zkm::cpu::bootstrap_kernel] Bootstrapping took 21030 cycles
[2024-06-17T07:01:23Z INFO  zkm::generation] CPU halted after 283174 cycles
[2024-06-17T07:01:24Z INFO  zkm::generation] CPU trace padded to 524288 cycles
[2024-06-17T07:01:24Z INFO  zkm::generation] Trace lengths (before padding): TraceCheckpoint { arithmetic_len: 141876, cpu_len: 524288, poseidon_len: 42058, poseidon_sponge_len: 42058, logic_len: 17928, memory_len: 2714935 }
[2024-06-17T07:02:41Z INFO  plonky2::util::timing] 81.7848s to prove root first
[2024-06-17T07:02:41Z INFO  zkmips] Process segment 1
[2024-06-17T07:02:44Z INFO  zkm::cpu::bootstrap_kernel] Bootstrapping took 27222 cycles
[2024-06-17T07:02:44Z INFO  zkm::generation] CPU halted after 131428 cycles
[2024-06-17T07:02:45Z INFO  zkm::generation] CPU trace padded to 262144 cycles
[2024-06-17T07:02:45Z INFO  zkm::generation] Trace lengths (before padding): TraceCheckpoint { arithmetic_len: 41320, cpu_len: 262144, poseidon_len: 54442, poseidon_sponge_len: 54442, logic_len: 4941, memory_len: 2427913 }
[2024-06-17T07:03:43Z INFO  plonky2::util::timing] 62.6836s to prove root second
[2024-06-17T07:03:45Z INFO  plonky2::util::timing] 1.2870s to prove aggression
[2024-06-17T07:03:47Z INFO  zkmips] proof size: 412845
[2024-06-17T07:03:50Z INFO  zkmips] build finish
[2024-06-17T07:03:55Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote common circuit data to common_circuit_data.json
[2024-06-17T07:03:55Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote verifier data to verifier_only_circuit_data.json
[2024-06-17T07:03:55Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote proof to proof_with_public_inputs.json
[2024-06-17T07:03:55Z INFO  plonky2::util::timing] 204.8115s to prove total time

public_inputs in proof_with_public_inputs.json
"public_inputs":[3,176,196,66,152,252,28,20,154,251,244,200,153,111,185,36,39,174,65,228,100,155,147,76,164,149,153,27,120,82,184,85,3,176,196,66,152,252,28,20,154,251,244,200,153,111,185,36,39,174,65,228,100,155,147,76,164,149,153,27,120,82,184,85]}

BASEDIR=test-vectors RUST_LOG=info ELF_PATH=/mnt/data/xander/test/test_proof/hello_world_mips1.22 SEG_OUTPUT=/tmp/output SEG_SIZE=262144 ARGS="123 321" cargo run --release --example zkmips split
warning: `/mnt/data/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
    Finished `release` profile [optimized] target(s) in 0.27s
     Running `target/release/examples/zkmips split`
[]string{"123", "321"}
result 39483
[2024-06-17T07:09:36Z INFO  zkmips] Split done 365745

BASEDIR=test-vectors RUST_LOG=info SEG_FILE_NUM=2 SEG_FILE_DIR=/tmp/output SEG_SIZE=262144 cargo run --release --example zkmips aggregate_proof_all
warning: `/mnt/data/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
    Finished `release` profile [optimized] target(s) in 0.24s
     Running `target/release/examples/zkmips aggregate_proof_all`
[2024-06-17T07:10:52Z INFO  zkmips] Process segment 0
[2024-06-17T07:10:56Z INFO  zkm::cpu::bootstrap_kernel] Bootstrapping took 21030 cycles
[2024-06-17T07:10:56Z INFO  zkm::generation] CPU halted after 283174 cycles
[2024-06-17T07:10:57Z INFO  zkm::generation] CPU trace padded to 524288 cycles
[2024-06-17T07:10:57Z INFO  zkm::generation] Trace lengths (before padding): TraceCheckpoint { arithmetic_len: 141871, cpu_len: 524288, poseidon_len: 42058, poseidon_sponge_len: 42058, logic_len: 17928, memory_len: 2714924 }
[2024-06-17T07:12:15Z INFO  plonky2::util::timing] 82.6788s to prove root first
[2024-06-17T07:12:15Z INFO  zkmips] Process segment 1
[2024-06-17T07:12:18Z INFO  zkm::cpu::bootstrap_kernel] Bootstrapping took 27222 cycles
[2024-06-17T07:12:18Z INFO  zkm::generation] CPU halted after 130823 cycles
[2024-06-17T07:12:20Z INFO  zkm::generation] CPU trace padded to 262144 cycles
[2024-06-17T07:12:20Z INFO  zkm::generation] Trace lengths (before padding): TraceCheckpoint { arithmetic_len: 41008, cpu_len: 262144, poseidon_len: 54442, poseidon_sponge_len: 54442, logic_len: 4923, memory_len: 2425143 }
[2024-06-17T07:13:18Z INFO  plonky2::util::timing] 62.9830s to prove root second
[2024-06-17T07:13:19Z INFO  plonky2::util::timing] 1.2882s to prove aggression
[2024-06-17T07:13:21Z INFO  zkmips] proof size: 412855
[2024-06-17T07:13:25Z INFO  zkmips] build finish
[2024-06-17T07:13:29Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote common circuit data to common_circuit_data.json
[2024-06-17T07:13:29Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote verifier data to verifier_only_circuit_data.json
[2024-06-17T07:13:29Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote proof to proof_with_public_inputs.json
[2024-06-17T07:13:29Z INFO  plonky2::util::timing] 205.9857s to prove total time

public_inputs in proof_with_public_inputs.json
"public_inputs":[3,176,196,66,152,252,28,20,154,251,244,200,153,111,185,36,39,174,65,228,100,155,147,76,164,149,153,27,120,82,184,85,3,176,196,66,152,252,28,20,154,251,244,200,153,111,185,36,39,174,65,228,100,155,147,76,164,149,153,27,120,82,184,85]}

fixed by https://github.com/zkMIPS/succinctx/commit/885530166fa5895dbcd7e2db57a72e1f2c982c0d

repo: zkMIPS/zkm


text:
Experiment: backport ff_derive x86_64 assembly from fff crate

This is an experimental backport of the changes from https://github.com/filecoin-project/ff (published as the fff crate). I've opened this as a draft PR for discussion. I see two main additions:

ASM for modular multiplication. This is specific to BLS12-381, and is probably unlikely to be beneficial here. When the fff fork was created, the main BLS12-381 implementation was in pairing::bls12_381, and it used ff_derive for its field logic. That implementation has been removed from pairing, and replaced with the bls12_381 crate which implements field logic directly. So we might want to consider potentially adding assembly optimisations there.

ASM to use _addcarry_u64 and _subborrow_u64 explicitly on x86_64. I'm surprised that Rust doesn't figure this out itself; it seems like we should be able to rework ff_derive to encourage LLVM to lower to this directly.

ASM to use _addcarry_u64 and _subborrow_u64 explicitly on x86_64. I'm surprised that Rust doesn't figure this out itself; it seems like we should be able to rework ff_derive to encourage LLVM to lower to this directly.

This was definitely working at one point. Did something change?

IDK. @dignifiedquire implemented that in January 2020 so it's "relatively" recent; they might have more information about what they were seeing that motivated the change.

Here's a Godbolt example which shows adc lowering: https://godbolt.org/z/rq7xTsvx6
Taken from the crypto-bigint crate just to cross-check what it's doing, although the implementation is ultimately derived from and quite similar to what's in this crate (but amended to be const-friendly)

For add I don't remember the exact assembly difference, but back then the intrinsic implementation ended up being faster than the non intrinsic version, at least all the ones we tried.

authors: dignifiedquire str4d tarcieri

repo: zkcrypto/ff


text:
Simplify inflate window checks

Based on PR #1713, needs rebase when that has gone in. Didn't want to add it to that PR this late, although it really belongs there.
Since there is no need to worry about alloc calls failing after init has been done, we can
simplify the initialization and error checking of windows.
Optimization wasn't the purpose here, but in my preliminary tests, this improved inflate speed on big files by ~0.4-0.67%, so that is looking pretty good too.
PS: inflateReset2 is called during init and whenever the windows needs a reset and its size set to 0.

According to codecov, this and #1713 together remove 26 branches, that is nearly 1% of the branches in the whole codebase (including tests). That doesn't necessarily mean much, it was just an interesting tidbit I noticed 😃

Rebased.

repo: zlib-ng/zlib-ng

license: Zlib


text:
Change bi_reverse to use a byte table.

bi_reverse old versus new table method sees 240x improvement according to Quick C++ Benchmark. You can see minor improvements to both speed and size to the library itself. Two benchmark runs included below.
ZLIB-NG (DEVELOP)
 Tool: minigzip-ng.exe Levels: 1-9
 Runs: 70         Trim worst: 40

 Level   Comp   Comptime min/avg/max/stddev   Compressed size
 1     48.014%      1.106/1.125/1.135/0.008       111,512,026
 2     35.391%      1.812/1.840/1.851/0.009        82,195,416
 3     34.039%      2.243/2.260/2.271/0.008        79,055,001
 4     32.751%      2.662/2.691/2.704/0.011        76,065,070
 5     32.484%      2.892/2.911/2.921/0.008        75,443,521
 6     32.318%      3.496/3.526/3.544/0.013        75,057,363
 7     32.061%      4.727/4.743/4.753/0.007        74,461,300
 8     31.978%      7.225/7.259/7.279/0.014        74,269,032
 9     31.961%      9.807/9.843/9.867/0.015        74,230,342

 avg1  34.555%                        4.022
 tot                               1085.923       722,289,071

 Tool: minigzip-ng.exe Levels: 1-9
 Runs: 70         Trim worst: 40

 Level   Comp   Comptime min/avg/max/stddev   Compressed size
 1     48.014%      1.066/1.078/1.095/0.009       111,512,026
 2     35.391%      1.786/1.816/1.833/0.012        82,195,416
 3     34.039%      2.217/2.237/2.260/0.011        79,055,001
 4     32.751%      2.642/2.675/2.694/0.014        76,065,070
 5     32.484%      2.855/2.893/2.918/0.015        75,443,521
 6     32.318%      3.472/3.500/3.529/0.017        75,057,363
 7     32.061%      4.685/4.728/4.751/0.018        74,461,300
 8     31.978%      7.209/7.243/7.290/0.023        74,269,032
 9     31.961%      9.777/9.825/9.889/0.035        74,230,342

 avg1  34.555%                        3.999
 tot                               1079.856       722,289,071

ZLIB-NG (BI-REVERSE)
 Runs: 70         Trim worst: 40

 Level   Comp   Comptime min/avg/max/stddev   Compressed size
 1     48.014%      1.128/1.144/1.153/0.007       111,512,026
 2     35.391%      1.779/1.798/1.813/0.009        82,195,418
 3     34.039%      2.192/2.211/2.226/0.007        79,055,000
 4     32.751%      2.618/2.638/2.658/0.012        76,065,071
 5     32.484%      2.823/2.854/2.872/0.011        75,443,519
 6     32.318%      3.435/3.459/3.476/0.010        75,057,362
 7     32.061%      4.746/4.773/4.788/0.012        74,461,288
 8     31.978%      7.257/7.291/7.307/0.012        74,268,981
 9     31.961%      9.846/9.872/9.894/0.014        74,230,313

 avg1  34.555%                        4.005
 tot                               1081.243       722,288,978

 Tool: minigzip-ng-bi-reverse.exe Levels: 1-9
 Runs: 70         Trim worst: 40

 Level   Comp   Comptime min/avg/max/stddev   Compressed size
 1     48.014%      1.095/1.109/1.116/0.005       111,512,026
 2     35.391%      1.773/1.785/1.794/0.007        82,195,418
 3     34.039%      2.186/2.196/2.203/0.005        79,055,000
 4     32.751%      2.598/2.612/2.621/0.007        76,065,071
 5     32.484%      2.809/2.826/2.835/0.007        75,443,519
 6     32.318%      3.419/3.435/3.443/0.006        75,057,362
 7     32.061%      4.735/4.747/4.757/0.007        74,461,288
 8     31.978%      7.242/7.264/7.276/0.011        74,268,981
 9     31.961%      9.811/9.840/9.852/0.011        74,230,313

 avg1  34.555%                        3.979
 tot                               1074.405       722,288,978

Here is my test code:
https://gist.github.com/nmoinvaz/ac30fc08f19488e4efa38707d5004291

Did you experiment with using a 16-bit and full 32-bit table too? Just curious.
The results looks great, but I am unclear on how this changes the output, and that makes me nervous.

I think I did experiment with larger tables months ago but the size of the tables increases the code size by too much. I didn't do any performance testing at the time but just abandoned it.

Even if things get a lot faster, we have to really limit the increase of memory usage of zlib-ng, otherwise it will become pretty much unusable on devices (and with software) with limited memory space.

Of course, I was just curious whether there was any perf difference with those.
But what about the difference in output? I would have thought there would be no difference in output by using a pre-calculated table, so how did that happen?

@Dead2 I'm pretty sure it shouldn't change the output, so there is obviously some hidden bug in either new or old version...

We may be able to get away with only 16 bits because the assertion about len in the comments but I haven't tested it.

When changing it to the code below the compression stays the same as before:

Z_INTERNAL unsigned bi_reverse(unsigned code, int len) {
    /* code: the value to invert */
    /* len: its bit length */
    return ((unsigned)bi_reverse_table[code & 0xff] << 8 |
            (unsigned)bi_reverse_table[(code >> 8) & 0xff]) >> (16 - len);
}

@nmoinvaz As the return value of bi_reverseis cast to uint16_t anything more than 16 bits will get truncated...

In that case, would it perhaps be a good idea to change the return type of bi_reverse to uint16_t at the same time, I think that would make it easier to understand the function without needing to look up that context?
And uint16_t should be big enough since that is what it would have been on 16-bit platforms anyway.
Adding the assert can also help static code analysis as it then knows the required bounds of len.
Btw, looked into non-table alternatives to bit-shifting a bit:
Obviously the old loop-style bit shifting will be very slow, but did you compare this with solutions like this?
http://graphics.stanford.edu/~seander/bithacks.html#ReverseByteWith64Bits

I'm assuming indexed load doesn't have high penalty on most systems as long as the whole array can fit in cache.
There is still bit manipulation due to zero extending, shifting and ORing the two values together, but most processors can do it with two general purpose registers.
Using 16-bit array (65536 entries) would avoid the penalty on bit manipulation, but I'm not sure if all processors can do that large indexed load without penalty. In worst case it would require "load effective address" followed by regular load.

Reducing the amount of dead data in the cache is also worth considering, if it can be done in a way that is not too expensive, hence my suggestion above.
This is not as important/visible for a single-threaded benchmark, but for an actual running system doing a multitude of things, that can still end up faster because of all the competing load on the cache.
This is very relevant for for example busy webservers running php applications where zlib-ng is compressing the data sent to the browser. In those cases, the OS/PHP/webserver/etc will probably be the main load on the cpu and the caches, and the zlib-ng data structures will have a hard time competing to stay in the caches and might end up pushed to slow ram more often than we'd prefer.

Please rebase, for CI

Rebased.

Fixed the comment.

Baseline c475ec95525ac4bbf4838a6943ebd2c88c1fb5a1 x86-64
   text    data     bss     dec     hex filename
 111488    1296      32  112816   1b8b0 libz-ng.so.2

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 1     57.780%      1.889/1.905/1.911/0.006        1.275/1.285/1.292/0.005       90,924,650
 2     43.876%      2.022/2.044/2.052/0.008        0.774/0.825/0.837/0.014       41,427,218
 3     42.490%      2.092/2.109/2.117/0.008        0.669/0.679/0.686/0.005       33,432,016
 4     41.467%      2.014/2.041/2.053/0.009        0.518/0.527/0.532/0.004       26,101,482
 5     41.212%      2.178/2.196/2.206/0.007        0.513/0.525/0.531/0.005       25,940,920
 6     41.039%      1.925/1.933/1.939/0.004        0.385/0.394/0.397/0.003       19,374,021
 7     40.781%      1.662/1.669/1.674/0.004        0.255/0.260/0.263/0.003       12,834,980
 8     40.706%      2.073/2.088/2.095/0.006        0.252/0.258/0.261/0.003       12,811,166
 9     40.695%      2.265/2.281/2.288/0.007        0.252/0.258/0.262/0.003       12,807,941

 avg1  43.339%                        2.029                          0.557
 tot                                365.303                        100.206      275,654,394

PR #948 36fd045e238e61c9c27494126b4b65359abca460 x86-64
   text    data     bss     dec     hex filename
 111624    1296      32  112952   1b938 libz-ng.so.2

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 1     57.780%      1.891/1.899/1.908/0.004        1.267/1.281/1.291/0.008       90,924,650
 2     43.876%      2.029/2.040/2.046/0.005        0.821/0.832/0.838/0.005       41,427,218
 3     42.490%      2.085/2.103/2.112/0.008        0.666/0.679/0.684/0.004       33,432,016
 4     41.467%      2.004/2.031/2.040/0.009        0.522/0.529/0.533/0.003       26,101,482
 5     41.212%      2.172/2.191/2.200/0.007        0.519/0.527/0.532/0.003       25,940,920
 6     41.039%      1.902/1.922/1.931/0.008        0.389/0.395/0.398/0.002       19,374,021
 7     40.781%      1.648/1.664/1.671/0.007        0.254/0.260/0.263/0.002       12,834,980
 8     40.706%      2.068/2.079/2.088/0.007        0.249/0.259/0.262/0.003       12,811,166
 9     40.695%      2.260/2.271/2.280/0.006        0.254/0.258/0.261/0.002       12,807,941

 avg1  43.339%                        2.022                          0.558
 tot                                363.992                        100.376      275,654,394

Bigger compiled size.
Small speed improvement in all compression levels, averaging at ~0.35% faster.

Baseline c475ec95525ac4bbf4838a6943ebd2c88c1fb5a1 aarch64
   text    data     bss     dec     hex filename
 103138    1504      16  104658   198d2 libz-ng.so.2

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 1     57.784%      3.002/3.030/3.050/0.016        0.939/0.995/1.008/0.017       45,465,419
 2     43.879%      2.775/2.805/2.832/0.018        0.583/0.616/0.637/0.015       20,714,938
 3     42.489%      3.422/3.454/3.472/0.016        0.567/0.593/0.615/0.015       20,058,827
 4     41.468%      2.732/2.757/2.773/0.011        0.366/0.380/0.388/0.008       13,050,960
 5     41.218%      2.916/2.980/3.003/0.027        0.340/0.380/0.396/0.014       12,972,368
 6     41.040%      3.453/3.479/3.495/0.013        0.361/0.382/0.393/0.009       12,916,434
 7     40.778%      2.234/2.254/2.270/0.011        0.160/0.178/0.190/0.009        6,416,924
 8     40.704%      2.759/2.782/2.798/0.013        0.155/0.176/0.191/0.012        6,405,244
 9     40.696%      2.947/3.001/3.016/0.018        0.169/0.177/0.185/0.005        6,404,084

 avg1  43.340%                        2.949                          0.431
 tot                                398.134                         58.159      144,405,198

PR #948 36fd045e238e61c9c27494126b4b65359abca460 aarch64
   text    data     bss     dec     hex filename
 103266    1504      16  104786   19952 libz-ng.so.2

 Level   Comp   Comptime min/avg/max/stddev  Decomptime min/avg/max/stddev  Compressed size
 1     57.784%      2.970/3.021/3.049/0.023        0.945/0.984/1.003/0.015       45,465,419
 2     43.879%      2.758/2.792/2.814/0.019        0.591/0.614/0.629/0.010       20,714,938
 3     42.489%      3.412/3.459/3.473/0.016        0.543/0.595/0.611/0.018       20,058,827
 4     41.468%      2.735/2.755/2.772/0.010        0.359/0.382/0.395/0.011       13,050,960
 5     41.218%      2.947/2.980/2.996/0.016        0.344/0.379/0.392/0.013       12,972,368
 6     41.040%      3.452/3.486/3.509/0.018        0.360/0.379/0.389/0.009       12,916,434
 7     40.778%      2.234/2.253/2.268/0.011        0.171/0.181/0.189/0.006        6,416,924
 8     40.704%      2.773/2.791/2.804/0.009        0.143/0.175/0.193/0.016        6,405,244
 9     40.696%      2.987/3.003/3.015/0.008        0.170/0.184/0.195/0.009        6,404,084

 avg1  43.340%                        2.949                          0.430
 tot                                398.119                         58.100      144,405,198

Bigger compiled size.
Speeds are within margin of error.