text:
Uncaught exception 'Zend\Session\Exception\RuntimeException' with message 'Session validation failed'

when installing the session validators
'validators' => array(
'Zend\Session\Validator\RemoteAddr',
'Zend\Session\Validator\HttpUserAgent',
),

at the start of the session checks the validity of data (Httpuseragent or Remoteaddr)
https://github.com/zendframework/zf2/blob/master/library/Zend/Session/SessionManager.php#L110-L112
if the data is not valid displays errors
Fatal error: Uncaught exception 'Zend\Session\Exception\RuntimeException' with message 'Session validation failed' in C:\xampp\htdocs\application\vendor\zendframework\zendframework\library\Zend\Session\SessionManager.php:111 Stack trace: #0 C:\xampp\htdocs\application\module\Application\Module.php(81): Zend\Session\SessionManager->start() #1 C:\xampp\htdocs\application\module\Application\Module.php(29): Application\Module->bootstrapSession(Object(Zend\Mvc\MvcEvent)) #2 [internal function]: Application\Module->onBootstrap(Object(Zend\Mvc\MvcEvent)) #3 C:\xampp\htdocs\application\vendor\zendframework\zendframework\library\Zend\EventManager\EventManager.php(468): call_user_func(Array, Object(Zend\Mvc\MvcEvent)) #4 C:\xampp\htdocs\application\vendor\zendframework\zendframework\library\Zend\EventManager\EventManager.php(207): Zend\EventManager\EventManager->triggerListeners('bootstrap', Object(Zend\Mvc\MvcEvent), Array) #5 C:\xampp\htdocs\application\vendor\zendframework\zendframework\library\Zend\Mvc\Application.php(156): Zen in C:\xampp\htdocs\application\vendor\zendframework\zendframework\library\Zend\Session\SessionManager.php on line 111

@googlle @Ocramius it can be closed as @Martin-P said above ;)

@googlle @Ocramius @samsonasik @Martin-P  Is this issue #6364 fixed or I want to handle that exception. i look at the session manager documentation but it doesn't handle invalid session can someone give me an example?

@Misikir Issue #6364 was indeed fixed. It was a documentation issue and was fixed with https://github.com/zendframework/zf2-documentation/pull/1342
Regarding the exception, you can add a try/catch block and check for Zend\Session\Exception\RuntimeException:
use Zend\Session\Exception\ExceptionInterface as SessionException;

try {
    // create session etc.
} catch (SessionException $exception) {
    echo 'Something went wrong with the session';
    // echo $exception;
}

@Martin-P Thank you

@Misikir You're welcome

Thanks. Close this issue

authors: Martin-P Misikir googlle samsonasik


text:
Memcached and SASL

How can I specify some SASL values inside the configuration of a Memcached Adapter in ZF2? I'm using Heroku that ask something like this: https://devcenter.heroku.com/articles/memcachier#php
My actual configuration in module.config.php is:
'caches' => array(
    'memcached' => array(
        'adapter' => array(
            'name'     => 'memcached',
            'lifetime' => 3600,
            'options'  => array(
                'servers'       => array(
                    array(getenv('MEMCACHED_HOST'), getenv('MEMCACHED_PORT')),
                ),
                'namespace'     => __NAMESPACE__ . '_Memcached',
                'persistent_id' => strtolower(__NAMESPACE__) . '_memcached_pool',
                'ttl'           => 3600,
                'liboptions' => array(
                    'compression'          => true,
                    'binary_protocol'      => true,
                    'auto_eject_hosts'     => true,
                    'distribution'         => \Memcached::DISTRIBUTION_CONSISTENT,
                    'libketama_compatible' => true,
                    'connect_timeout'      => 100,
                    'poll_timeout'         => 100,
                    'retry_timeout'        => 2,
                    'no_block'             => true,
                ),
            ),
        ),
        'plugins' => array(
            'exception_handler' => array(
                'throw_exceptions' => false
            ),
        ),
    ),
),

Thanks

This tracker is for things related to the development of this repository. Please ask your question in a Q&A site like StackOverflow

source: gharchive/issue

license_type: permissive

license_source: bigquery


text:
改变代码 但是代码没有生效

maven项目  我改变代码 也重新编译过  target文件夹里的东西也是对的  但是使用smarttomcat 启动时 发现使用的是以前的代码
感觉是有缓存的样子
不知道里面是不是用了缓存  还是直接读取target里的东西  还是存放在其他地方
如果有缓存 我想知道缓存存放在哪   怎么清除缓存

找到原因了  vm参数制定了 catalina

web目录设置为src下的webapp.

From: hg460713171 notifications@github.com
Sent: Monday, August 10, 2020 7:14:52 PM
To: zengkid/SmartTomcat SmartTomcat@noreply.github.com
Cc: Subscribed subscribed@noreply.github.com
Subject: [zengkid/SmartTomcat] 改变代码 但是代码没有生效 (#49)
maven项目 我改变代码 也重新编译过 target文件夹里的东西也是对的 但是使用smarttomcat 启动时 发现使用的是以前的代码
感觉是有缓存的样子
不知道里面是不是用了缓存 还是直接读取target里的东西 还是存放在其他地方
如果有缓存 我想知道缓存存放在哪 怎么清除缓存
―
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/zengkid/SmartTomcat/issues/49, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAZZ3U6PNCMAWPYIOG4NNP3R77JCZANCNFSM4PZ3E4NA.

repo: zengkid/SmartTomcat


text:
Fixes first level without children / Adds placeholder option

Fix: If data tree has only first level without children / sublevel, the script breaks.
Added: Placeholder text option if you want to display default text before first selection and prevent the selects from being prefilled with the first option of each level.

@emkayy Let's split this PR into tow issues #2 #3

#2 can be easily fixed; as for #3, IMHO, we can prepend a default option as placeholder for every select

@emkayy what do you think

Sorry for my incomplete pull request, I only realised afterwards!
But thanks for your quick response!
After another review I think I'll set entries to something like " - " in case there are no children, because these are two different cases. My placeholder message will say "Please select". However, if children are empty, there's nothing to select. So initially I want the first drop down to say "Please select" and all subsequent selects so show " - " to indicate they are empty. Only when you select an actual option the next select will say "Please select" and so on.
if (curNode && curNode.children && curNode.children.length) {
	entries = curNode.children;
} else {
	entries = [{text: '-', value: ''}];
}

Or you could introduce another option "empty" that has a default value of "-"?

@emkayy thanks! FYI, this PR fixed issue #2 and #3 with options placeholder and placeholderWhenEmpty added

That's perfect! Thanks!

source: gharchive/pull-request

authors: emkayy zenkiezhu

repo: zenkiezhu/jquery-cascading-select

license: MIT

license_source: github-api


text:
Introduce post_execution.BaseView to reduce duplicate code

Describe changes
I added an abstract base class BaseView for post-execution classes.
This base class has several purposes:

Calling XView.y_attr now automatically gets the value of y_attr from the corresponding response model, so it is no longer necessary to define a @property in the views for every single field of the respective underlying models.
Post execution classes are now strongly linked to their respective models and trying to initialize a post execution class with a different model (e.g. StepView(ArtifactResponseModel) will now fail with a corresponding custom error message.
__repr__ and __eq__ no longer need to be defined on each post-execution class. Which attributes to include in __repr__ is now instead defined via a REPR_KEYS class var that is also validated during the __init__.

Pre-requisites
Please ensure you have done the following:

[x] I have read the CONTRIBUTING.md document.
[ ] If my change requires a change to docs, I have updated the documentation accordingly.
[ ] If I have added an integration, I have updated the integrations table and the corresponding website section.
[ ] I have added tests to cover my changes.

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Other (add details above)

@schustmi good point on the tests, I just added a bunch of unit tests that should ensure that BaseView does what it's supposed to 👍

repo: zenml-io/zenml


text:
Add tests for fileio

Pre-requisites
Please ensure you have done the following:

[x] I have read the CONTRIBUTING.md document.
[x] If my change requires a change to the documentation, I have updated the documentation accordingly.
[x] I have added tests to cover my changes.

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Describe changes

Added tests for our fileio functionality.
Fixed places where get_grandparent and get_parent were being called inside the codebase, since I fixed this in fileio to what makes sense.

@bcdurak and/or @htahir1 would appreciate your eyes on this. intersects with tfx for obv reasons and I want to be sure I didn't approach this in the wrong way.


text:
esptool: Pad sections to account for alignment

Parse ELF section alignment values and use those to check to see if successive sections are separated because of them. Pad a previous section if doing so would cause it to precisely align with the next section start address. This ensures that alignment requirements don't spoil our attempt to merge sections.

Hi @keith-packard, is this ready to be reviewed? By the way, what triggered you to submit this? Is that libc discussion or any other related issue?

authors: keith-packard sylvioalves


text:
mimxrt1060_evk tests/kernel/mem_pool/mem_pool_threadsafe meets Imprecise data bus error

Describe the bug
Imprecise data bus error
To Reproduce
Steps to reproduce the behavior:

mkdir build; cd build
cmake -DBOARD=mimxrt1060_evk ..
make
See error

Expected behavior
Test pass
Impact
memory pool
Screenshots or console output
***** Booting Zephyr OS 1.14.0-rc1 *****

Running test suite mpool_threadsafe

===================================================================

starting test - test_mpool_threadsafe

***** BUS FAULT *****

  Imprecise data bus error

***** Hardware exception *****

Current thread ID = 0x800000d0

Faulting instruction address = 0x600056ae

Fatal fault in ISR! Spinning..

Environment (please complete the following information):

OS: (Linux)
Toolchain (Zephyr SDK)
Commit SHA or Version used: v1.14.0_rc1

Additional context
Add any other context about the problem here.

@MaureenHelm

This sounds a lot like a duplicate of #12559, which has a fix up in #13770.  Could you try with that applied and verify it works for you?

@andyross thanks it fixed

authors: andyross hakehuang

repo: zephyrproject-rtos/zephyr


text:
dts feature on dma perpheral feature

Is your enhancement proposal related to a problem? Please describe.
in many DMA peripheral there are some address alignment on source and target address.
Describe the solution you'd like
There are 2 option to resolved this

option 1:

currently we can use the existing dma-buf-alignment define in dma dts feature, and let application to select the purpore one.

option 2

We need define dma-buf-alignment in each perpherial dts feature. and all dma enabled peripheral will be required to do so.
and together with dma-buf-alignment in the exiting dma dts to control the src and dst address alignment
Additional context
refer to below PR for more details
dma-buf-alignment

I think it would be useful to have the alignment property known somehow in the pair of DMA + Peripheral, the best place for that to me and maybe others would think otherwise, would be on the peripheral, but if there's some better way to describe some attributes tied to the pair of devices that would be best.
@mbolivar-nordic or @galak any thoughts on how best to do this?

@teburd I'm confused. From @hakehuang 's description it sounds like the DMA peripheral itself is where the alignment restrictions are. E.g. a memory to peripheral transfer can only read from 4-byte aligned memory addresses and things like that. When you say "pair of DMA + Peripheral", what do you mean? Are there additional alignment constraints that are specific to the combination of the DMA controller and a specific peripheral address it's talking to that you need to capture?

@mbolivar-nordic , I think pair means each peripheral with DMA support need add such constrains.
for peripheral dma, the src is usually a 4 byte aliged 32 bit word. but it depends on the peripheral. so if we need add this to each peripheral, would this be better that we create a common dts for all peripheral that supports dma?

Just to be clear, when you say "peripheral DMA", you mean the DMA controller, right?

no it is the peripheral that has DMA can read from,  such register is usually 4 bytes address aligned, but it is platform dependant.

I'm sorry, I'm still lost. If we're talking about a peripheral register then its address is fixed so I don't get what we need to do -- we can figure out its alignment by looking at the bits in the register.
Maybe you can point me to some real hardware with example devicetrees for option 1 and option 2 from the PR description?
If not,  I think we may need to call a meeting.

I'm sorry, I'm still lost. If we're talking about a peripheral register then its address is fixed so I don't get what we need to do -- we can figure out its alignment by looking at the bits in the register address.
Maybe you can point me to some real hardware with example devicetrees for option 1 and option 2 from the PR description?
If not, I think we may need to call a meeting.

soem platfrom may support 16/32 bits and 64 bits in the future.
and the question now is:
we have define a dma-buf-alignment in dma engine dts, which limits the DMA buffer address alignment, but for different peripheral do we need define a common dts attribute which can be inherient and applys to different peripheral? as the two address alignment may not the same.

authors: hakehuang mbolivar-nordic teburd


text:
[RFC] Get rid of Zephyr's prefer-later-defaults behavior

Zephyr adds a patch to vanilla Kconfig that makes it prefer later defaults, as documented here.
I think that change was made so that Kconfig.defconfig files can override defaults in the "base" configuration. They are included last.
I think the standard Kconfig behavior would be nicer, which is to use the first default with a satisfied condition. It's what people expect coming from other projects that use Kconfig, and you wouldn't have to carry that patch around.
I thought of a "safe" way to make the transformation:

Hack Kconfiglib to print defaults in reverse order when printing symbols. Print all symbols and save the output somewhere.

Include the Kconfig.defconfig files first instead of last, and switch the order of all the defaults around. Maybe other includes would need to be switched around as well.

Remove the Kconfiglib hack, print all symbols, and check that the output is still the same.

It would still take some boring manual work, but it seems doable.
Any objections? After that change, Zephyr would use mostly vanilla Kconfig (except for gsource and rsource -- IMO, gsource should usually be avoided as well).
At some point, it might be possible to install Kconfiglib and the menuconfig via pip instead of having them in the source tree.

CC @carlescufi @SebastianBoe @mbolivar

as long as you have a way to verify that the change does not impact the generated configurations and does generate the same final .config we should be fine with such change. Need to test this basically on all boards and tests and check if there are any differences.

@nashif
Should be fine as long as the defaults are evaluated in the same order as before. I'll check with some of the examples too.
Thought I'd do what doc/Makefile does to include everything when comparing outputs.

Any objections?

None from me, but as @nashif said, we need to make completely sure we haven't modified the generated .config files by running some sort of diffconfig on all .config files generated by sanitycheck.

gsource should usually be avoided as well

Why? I am not sure why globbing is a bad idea. We also use it in the current work to split Zephyr into multiple repositories, as you can see here:
https://github.com/zephyrproject-rtos/zephyr/pull/7338/files#diff-d6f4145321ef0d57a017a2079114715dR41

@carlescufi
Just some personal anti-globbing bias. Can't see at a glance what (isn't) being included, plus you might accidentally put something in there that matches (and yeah, that's actually happened to me in other projects).
The Python blowhard version would be "explicit is better than implicit" I think. :D
Maybe it's not a static set though, and yeah, just some personal experience. No biggie.

Working on https://github.com/zephyrproject-rtos/zephyr/issues/6879 now. Getting that fixed will help with some copy-paste action here.

Any objections?

What about out of tree applications? We currently specifically recommend applications put their content after including the Zephyr config file:
http://docs.zephyrproject.org/application/application.html#application-cmakelists-txt
This reversal would probably mean they should put their config options (and any default settings they want to override Zephyr's with) before including Zephyr's root Kconfig, no?
If so, this is a breaking change that should be communicated clearly to users.

@mbolivar
They'd also need to reverse the defaults on all symbols that have more than one default, so could get messy if there's a lot of out-of-tree stuff.

@ulfalizer hmm, "messy" makes me a little nervous :).
It makes sense to get back to the standard Kconfig behavior, though.
Is it possible to default to the standard behavior, but emit a message that it has changed, and letting apps define a CMake variable before including the boilerplate file that restores the "odd" behavior?
We could keep that for a deprecation period of say one release, before removing the odd behavior entirely.
I also want to confirm that by defining a default before including Zephyr's Kconfig root, they could override any default provided by the build (this is important when setting defaults conditionally).

Maybe some temporary ugly hack that switches stuff around in some way if you put a flag in the Kconfig file would be possible, if needed...

That's what I'm saying, basically.
If the user runs "cmake -DKCONFIG_USE_WEIRD_ZEPHYR_BEHAVIOR", then kconfiglib gets passed some option that enables the existing behavior.
Otherwise, it reverts to the "normal" Linux kernel behavior, but emits a warning that there was a breaking change (perhaps through a second option, so as not to pollute output when  run in its primary use case).
This at least gives app developers a sporting chance to notice what happened and fix any issues, especially if the warning is high quality and offers hints on what to do in case things go wrong.

@ulfalizer I think we can close this now, agree?

Yups, fine to close.

authors: carlescufi mbolivar nashif ulfalizer


text:
tests/kernel/tickless/tickless_concept fails on nRF5x with 1000msec boot delay

The test tests/kernel/tickless/tickless_concept results in Assertion failure in test_tickless_slice subtestcase, when boot delay of 1000msec is added.
Arch: arm
Board: nrf51/52 - nrf51_pca10028:arm, nrf52_pca10040:arm, nrf52840_pca10056:arm
Zephyr commit: 6a01c69f9b94009e924ab56edf3e65dca97019bb
Toolchain:  ZEPHYR_TOOLCHAIN_VARIANT=zephyr
Additional Info: Add CONFIG_BOOT_DELAY=1000 in tests/kernel/tickless/tickless_concept/prj.conf
Error Console Log:
***** delaying boot 1000ms (per build configuration) *****
***** Booting Zephyr OS v1.13.0-rc1-69-g6a01c69 (delayed boot 1000ms) *****
Running test suite tickless_concept
===================================================================
starting test - test_tickless_sysclock
time 1027, 1237
time 1247, 1446
PASS - test_tickless_sysclock
===================================================================
starting test - test_tickless_slice
elapsed slice 110, expected: <99, 109>

    Assertion failed at /home/pswarnak/workspace/1.13_execution/zephyr/tests/kernel/tickless/tickless_concept/src/main.c:59: thread_tslice: t <= SLICE_SIZE_LIMIT is false

elapsed slice 10, expected: <99, 109>

    Assertion failed at /home/pswarnak/workspace/1.13_execution/zephyr/tests/kernel/tickless/tickless_concept/src/main.c:57: thread_tslice: t >= SLICE_SIZE is false

elapsed slice 20, expected: <99, 109>

    Assertion failed at /home/pswarnak/workspace/1.13_execution/zephyr/tests/kernel/tickless/tickless_concept/src/main.c:57: thread_tslice: t >= SLICE_SIZE is false

elapsed slice 20, expected: <99, 109>

    Assertion failed at /home/pswarnak/workspace/1.13_execution/zephyr/tests/kernel/tickless/tickless_concept/src/main.c:57: thread_tslice: t >= SLICE_SIZE is false

FAIL - test_tickless_slice
===================================================================
===================================================================
RunID: :r7eb
PROJECT EXECUTION FAILED

Steps to reproduce:
cd zephyr/tests/kernel/tickless/tickless_concept
rm -rf build && mkdir build && cd build
cmake -D BOARD=nrf51_pca10028 ../
make BOARD=nrf51_pca10028 flash

Check the console log.

Hi @pizi-nordic,
Can you please check the failure, #9137 still does not resolve the failure, when boot delay of 1000msec is added.

Just figured out that tests/kernel/sched/schedule_api/testcase.yaml#kernel.sched.slice_reset also fails by adding 1000msec boot delay on nRF5x boards. Please find console output below:
***** delaying boot 1000ms (per build configuration) *****
***** Booting Zephyr OS 1.13.0-rc1 (delayed boot 1000ms) *****
Running test suite threads_scheduling
===================================================================
starting test - test_priority_cooperative
PASS - test_priority_cooperative
===================================================================
starting test - test_priority_preemptible
PASS - test_priority_preemptible
===================================================================
starting test - test_yield_cooperative
PASS - test_yield_cooperative
===================================================================
starting test - test_sleep_cooperative
PASS - test_sleep_cooperative
===================================================================
starting test - test_sleep_wakeup_preemptible
PASS - test_sleep_wakeup_preemptible
===================================================================
starting test - test_pending_thread_wakeup
PASS - test_pending_thread_wakeup
===================================================================
starting test - test_time_slicing_preemptible
PASS - test_time_slicing_preemptible
===================================================================
starting test - test_time_slicing_disable_preemptible
PASS - test_time_slicing_disable_preemptible
===================================================================
starting test - test_lock_preemptible
PASS - test_lock_preemptible
===================================================================
starting test - test_unlock_preemptible
PASS - test_unlock_preemptible
===================================================================
starting test - test_sched_is_preempt_thread
PASS - test_sched_is_preempt_thread
===================================================================
starting test - test_slice_reset

    Assertion failed at /home/jenkins/workspace/zephyr-master-tcf-v0.11-branch/LABEL/verify/SHARD/2-3/ZEPHYR_GCC_VARIANT/zephyr/zephyr.git/tests/kernel/sched/schedule_api/src/test_sched_timeslice_reset.c:46: thread_tslice: t <= expected_slice_max is false

    Assertion failed at /home/jenkins/workspace/zephyr-master-tcf-v0.11-branch/LABEL/verify/SHARD/2-3/ZEPHYR_GCC_VARIANT/zephyr/zephyr.git/tests/kernel/sched/schedule_api/src/test_sched_timeslice_reset.c:45: thread_tslice: t >= expected_slice_min is false

    Assertion failed at /home/jenkins/workspace/zephyr-master-tcf-v0.11-branch/LABEL/verify/SHARD/2-3/ZEPHYR_GCC_VARIANT/zephyr/zephyr.git/tests/kernel/sched/schedule_api/src/test_sched_timeslice_reset.c:45: thread_tslice: t >= expected_slice_min is false

FAIL - test_slice_reset
===================================================================
starting test - test_slice_scheduling
PASS - test_slice_scheduling
===================================================================
starting test - test_priority_scheduling
ABCDEFGHI
ABCDEFGHI
ABCDEFGHI
ABCDEFGHI
ABCDEFGHI
PASS - test_priority_scheduling
===================================================================
starting test - test_wakeup_expired_timer_thread
PASS - test_wakeup_expired_timer_thread
===================================================================
===================================================================
RunID: ci-180828-1458-2110:mp9z
PROJECT EXECUTION FAILED

Should be fixed as of the timer rework.   I just retried this on a nrf52840_pca10056, with and without BOOT_DELAY=1000 and it was reliable across 20 tries each.

@pizi-nordic can you please re-run and close if fixed?

I have tun 100 iterations without delay and 100 iterations with delay. There was no even single failure. Closing.

authors: andyross carlescufi pizi-nordic pswarnak


text:
usb: hid: macros for report descriptors

Added macros that generate simple report descriptors for mouse
and keyboard. This improves the readability of samples.
Signed-off-by: Marcin Szymczyk Marcin.Szymczyk@nordicsemi.no

Codecov Report

Merging #12158 into master will decrease coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #12158      +/-   ##
==========================================
- Coverage    48.1%   48.05%   -0.06%
==========================================
  Files         284      284
  Lines       43369    43369
  Branches    10397    10397
==========================================
- Hits        20862    20840      -22
- Misses      18368    18389      +21
- Partials     4139     4140       +1

Impacted Files
Coverage Δ

subsys/logging/log_core.c
74.67% <0%> (-7.87%)
:arrow_down:

subsys/logging/log_msg.c
86.36% <0%> (-2.28%)
: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 5740141...d4413d9. Read the comment docs.

authors: codecov-io masz-nordic


text:
counter: Clarify behavior of counter_set_channel_alarm

Explicitly state that alarm is single shot.
Signed-off-by: Krzysztof Chruscinski krzysztof.chruscinski@nordicsemi.no

Codecov Report

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

@@               Coverage Diff               @@
##           topic-counters   #12975   +/-   ##
===============================================
  Coverage           53.53%   53.53%
===============================================
  Files                 239      239
  Lines               27052    27052
  Branches             6521     6521
===============================================
  Hits                14482    14482
  Misses               9900     9900
  Partials             2670     2670

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 4d8f735...fba4fd0. Read the comment docs.

authors: codecov-io nordic-krch


text:
Bluetooth: controller: bugfix / cleanups

This patch series:

Fixes the calculation of the packet_rx_data_size / counts when CONFIG_BLUETOOTH_CONTROLLER_DATA_LENGTH is used.
Makes sure the initial value of conn->max_rx_octets is CONFIG_BLUETOOTH_CONTROLLER_DATA_LENGTH_MAX when it's set.
verifies the values in max_rx_octets/max_tx_octets for a DLE req_rsp prior to using them.
Removes duplicated code in packet_rx_reserve_get() by re-using the calculation in packet_rx_acquired_count_get().

NOTE: Along with the 2 reverts I also changed the length response octets check from:
if (lr->max_rx_octets) {
if (lr->max_tx_octets) {
to:
if (lr->max_rx_octets >= RADIO_LL_LENGTH_OCTETS_RX_MIN) {
if (lr->max_tx_octets >= RADIO_LL_LENGTH_OCTETS_RX_MIN) {

Fixed checkpatch spacing error.  But will leave line >80 warning as code would be ugly if I fix that.

Shortened patch titles to <72 char to fix Shippable checks.  NOTE: checkpatch.pl did not complain about the patch titles :/

Removed the else clauses which were duplicating the assignments done at the top of isr_rx_conn_pkt_ctrl_dle().


text:
ztest: end tests more robustly

If a ztest test case creates child thread(s), and one of the
descendent threads invokes ztest_test_pass(), ztest_test_fail(),
or ztest_thread_skip(), only that descendent thread will be
aborted.
Then ztest will try to run the next scenario on the ztest_thread
which is already in use. This was causing corruption issues on
SMP systems, and possibly other subtle, hard-to-debug
situations.
This patch ensures that ztest_thread is always dead before
re-using it, as run_test() now attempts to join on it instead
of using a semaphore.
The ztest_test_* functions now ensure that the ztest_thread
is always aborted, in addition to the current thread.
This isn't perfect. If the testcase spawned other threads,
they will keep running. The most robust way to fix this is to
iterate over all non-essential threads in the system and abort
them. Unfortunately, Zephyr doesn't have a facility to do
this safely.
It would also be simpler to re-use thread objects if
k_thread_create() could detect whether the thread was already
active and abort it, but this is currently not possible
since k_thread_create() can be used with uninitialzed
thread object memory and no checks are possible. This
may be improved in the future, see #23030.
Fixes: #22738
Partial fix for: #24713
Signed-off-by: Andrew Boie andrew.p.boie@intel.com

@andyross the changes to ztest exposed some problems in the mem_protect test which were failing CI. so to get CI to work properly again, I had to address that, and added the second patch last night. I'll update the PR description.


text:
mcumgr: Update revision, update Kconfig and update release notes

The series of commits update mcumgr to latest revision and include support for following features:

Optional image verification, enabled with CONFIG_IMG_MGMT_REJECT_DIRECT_XIP_MISMATCHED_SLOT, that will reject .bin images that would not be able to boot from offered Direct-XIP slot; such image needs to be signed and have the base address embedded into header with imgtool.

Tthe PR depends on: https://github.com/apache/mynewt-mcumgr/pull/104

@de-nordic Upstream PRs are merged, please sync the Zephyr repos.

@de-nordic Upstream PRs are merged, please sync the Zephyr repos.

Just to be sure, you're also supposed to sync https://github.com/zephyrproject-rtos/mcuboot with upstream, correct?

@de-nordic Upstream PRs are merged, please sync the Zephyr repos.

Just to be sure, you're also supposed to sync https://github.com/zephyrproject-rtos/mcuboot with upstream, correct?

Yes. This is not final till it is synced.

@de-nordic Upstream PRs are merged, please sync the Zephyr repos.

Just to be sure, you're also supposed to sync https://github.com/zephyrproject-rtos/mcuboot with upstream, correct?

@de-nordic Upstream PRs are merged, please sync the Zephyr repos.

Just to be sure, you're also supposed to sync https://github.com/zephyrproject-rtos/mcuboot with upstream, correct?

Yes. This is not final till it is synced.

Ok, I just looked at it again, this does not need mcuboot itself, so you should drop the west imgtool commit; maybe update requirements-extra.txt to use imgtool==1.8.0a1 but not strictly necessary!

Ok, I just looked at it again, this does not need mcuboot itself, so you should drop the west imgtool commit; maybe update requirements-extra.txt to use imgtool==1.8.0a1 but not strictly necessary!

Done.

I think we should not be putting an alpha release into requirements-extra.txt like this.
What's blocking the final imgtool 1.8.0 release, and why can't we wait for it before merging this?

I think we should not be putting an alpha release into requirements-extra.txt like this.
What's blocking the final imgtool 1.8.0 release, and why can't we wait for it before merging this?

It's not "unreleased". imgtool releases follow MCUboot releases, we have not discussed releasing 1.8.0 so far. For imgtool it does not mean it is unstable.

Also I should get a more "precise" mouse! Sorry for closing/reopening.

It's not "unreleased". imgtool releases follow MCUboot releases, we have not discussed releasing 1.8.0 so far. For imgtool it does not mean it is unstable.

Will you update this to 1.8.0 when that is released?
Can you add a comment explaining why this is the way it is for now?

Will you update this to 1.8.0 when that is released?
Can you add a comment explaining why this is the way it is for now?

So as far as I understand the 1.8.0 will follow the 1.8.0a1 and as such it would be enough to set the dependency to >=1.8.0? Right @utzig ?

Will you update this to 1.8.0 when that is released?
Can you add a comment explaining why this is the way it is for now?

So as far as I understand the 1.8.0 will follow the 1.8.0a1 and as such it would be enough to set the dependency to >=1.8.0? Right @utzig ?

So as far as I understand the 1.8.0 will follow the 1.8.0a1 and as such it would be enough to set the dependency to >=1.8.0? Right @utzig ?

imgtool==1.8.0 will be released when MCUboot 1.8.0 is released, there can be any number of imgtool "alpha"s on the way. You could make it >=1.8.0 but this will only work when 1.8.0 is released (1.8.0a1 is less than 1.8.0).
We could consider switching to a versioning that adds an extra number to imgtool releases maintaining the same base as the last official release, eg, after imgtool==1.7.0 we could release imgtool==1.7.0.1, imgtool==1.7.0.2 and so on until the next "stable" or official MCUboot is released. If @d3zd3z / @nvlsianpu think this is a good alternative I can delete 1.8.0a1 from pypi and you can submit a "bump" to 1.7.0.1 (and use it in this PR).

So as far as I understand the 1.8.0 will follow the 1.8.0a1 and as such it would be enough to set the dependency to >=1.8.0? Right @utzig ?

imgtool==1.8.0 will be released when MCUboot 1.8.0 is released, there can be any number of imgtool "alpha"s on the way. You could make it >=1.8.0 but this will only work when 1.8.0 is released (1.8.0a1 is less than 1.8.0).
We could consider switching to a versioning that adds an extra number to imgtool releases maintaining the same base as the last official release, eg, after imgtool==1.7.0 we could release imgtool==1.7.0.1, imgtool==1.7.0.2 and so on until the next "stable" or official MCUboot is released. If @d3zd3z / @nvlsianpu think this is a good alternative I can delete 1.8.0a1 from pypi and you can submit a "bump" to 1.7.0.1 (and use it in this PR).

It would be nice if we could get the fix for https://github.com/mcu-tools/mcuboot/pull/896 included in this update as well.

It would be nice if we could get the fix for https://github.com/mcu-tools/mcuboot/pull/896 included in this update as well.

It would be nice if we could get the fix for mcu-tools/mcuboot#896 included in this update as well.

@henrikbrixandersen I think that mcuboot change is unrelated and the west update for mcuboot may be quickly done without waiting for this. This PR is only bumping up the mcumgr revision.

It would be nice if we could get the fix for mcu-tools/mcuboot#896 included in this update as well.

@henrikbrixandersen I think that mcuboot change is unrelated and the west update for mcuboot may be quickly done without waiting for this. This PR is only bumping up the mcumgr revision.

@utzig, @mbolivar What are we doing with this?

@utzig, @mbolivar What are we doing with this?

@utzig, @mbolivar What are we doing with this?

I already approved this and have a suggestion to address the versioning, there's a MCUboot meeting tomorrow btw, otherwise I don't have any more inputs to give here.

@utzig, @mbolivar What are we doing with this?

I already approved this and have a suggestion to address the versioning, there's a MCUboot meeting tomorrow btw, otherwise I don't have any more inputs to give here.

As agreed yesterday on the MCUboot meeting, there won't be any more "alpha" release. We will branch every major release and from this branch release minor updates for imgtool, as well as any other major bugs if there is any found (we have already done this in the past).

As agreed yesterday on the MCUboot meeting, there won't be any more "alpha" release. We will branch every major release and from this branch release minor updates for imgtool, as well as any other major bugs if there is any found (we have already done this in the past).

@de-nordic is this ready?

@de-nordic is this ready?

@de-nordic is this ready?

@carlescufi Yes.

@de-nordic is this ready?

@carlescufi Yes.

authors: carlescufi de-nordic henrikbrixandersen mbolivar-nordic utzig


text:
boards: arm: frdm_kw41z: Fix pwm/tpm pin settings

The nodelabel for the PWM controller on KW41Z is TPM[0..n], so we need
to change the logic in the ifdef to get the pins setup.
Additionally the setup of PORTA0/1 and PORTB16/17 pins for TPM only
exists on kPORT_MuxAlt5.
Signed-off-by: Kumar Gala kumar.gala@linaro.org

@alexandru-porosanu-nxp what was trying to be done with PTA0/1 and PTB16/17?

@alexandru-porosanu-nxp what was trying to be done with PTA0/1 and PTB16/17?

I don't think I've ever tested the TPM on  PTA and PTB, so I guess the mux setting off-by-one in my settings. Unfortunately, I don't have a KW41 board handy to test this, but as long as PTC mux setting is the same, this should work as before.

I don't think I've ever tested the TPM on PTA and PTB, so I guess the mux setting off-by-one in my settings. Unfortunately, I don't have a KW41 board handy to test this, but as long as PTC mux setting is the same, this should work as before.

As this was just for testing purposes any issue with me removing the pin settings for PTA0/1 and PTB16/17 since there isn't any code that is utilizing them in Zephyr?

I don't think I've ever tested the TPM on PTA and PTB, so I guess the mux setting off-by-one in my settings. Unfortunately, I don't have a KW41 board handy to test this, but as long as PTC mux setting is the same, this should work as before.

As this was just for testing purposes any issue with me removing the pin settings for PTA0/1 and PTB16/17 since there isn't any code that is utilizing them in Zephyr?

Yep, that's fine with me.

I don't think I've ever tested the TPM on PTA and PTB, so I guess the mux setting off-by-one in my settings. Unfortunately, I don't have a KW41 board handy to test this, but as long as PTC mux setting is the same, this should work as before.

As this was just for testing purposes any issue with me removing the pin settings for PTA0/1 and PTB16/17 since there isn't any code that is utilizing them in Zephyr?

Yep, that's fine with me.

Cool.  I added a commit to remove the settings.

authors: alexandru-porosanu-nxp galak


text:
tests: logging: syst: Add testcases for mipi syst.

Adding testcases for mipi syst logging format.
Signed-off-by: Aastha Grover aastha.grover@intel.com

Hey, I know we were having trouble figuring out how to get the string constants on one line without getting newlines inserted, but I was taking a look at a PR (#43984) Tom just put up and had the idea to do this:
#define PAYLOAD "4465627567206D657373616765206578616D706C652C2025642C2025642C202564000"\
	"10000000200000003000000"
const char *payload = PAYLOAD;
...
void test_main(void)
{
	printk("PAYLOAD: %s", PAYLOAD);
...

Which printed this:
Booting from ROM..*** Booting Zephyr OS build zephyr-v3.0.0-1284-g41805a779e05  ***

PAYLOAD 4465627567206D657373616765206578616D706C652C2025642C2025642C20256400010000000200000003000000

Running test suite test_log_syst...

And when I ran the compliance check CI does (see .github/workflows/compliance.yml:72), I got no warnings:
Running checkpatch       tests in /home/herbert/zephyr-external/zephyr ...
Running Kconfig          tests in /home/herbert/zephyr-external/zephyr ...
Running Codeowners       tests in /home/herbert/zephyr-external/zephyr ...
Running Nits             tests in /home/herbert/zephyr-external/zephyr ...
Running Gitlint          tests in /home/herbert/zephyr-external/zephyr ...
Running pylint           tests in /home/herbert/zephyr-external/zephyr ...
Running Identity         tests in /home/herbert/zephyr-external/zephyr ...

Complete results in compliance.xml

Examining the string in the debugger yields one with no breaks or extra characters (copied from Visual Studio Code debugger):
payload: 0x1054ac "4465627567206D657373616765206578616D706C652C2025642C2025642C20256400010000000200000003000000"

Hopefully this should make it so you don't have to build the string yourself.

Hey, I know we were having trouble figuring out how to get the string constants in under the line length limit without getting newlines inserted, but I was taking a look at a PR (#43984) Tom just put up and had the idea to do this:
#define PAYLOAD "4465627567206D657373616765206578616D706C652C2025642C2025642C202564000"\
	"10000000200000003000000"
const char *payload = PAYLOAD;
...
void test_main(void)
{
	printk("PAYLOAD: %s", payload);
...

Which printed this:
Booting from ROM..*** Booting Zephyr OS build zephyr-v3.0.0-1284-g41805a779e05  ***

PAYLOAD 4465627567206D657373616765206578616D706C652C2025642C2025642C20256400010000000200000003000000

Running test suite test_log_syst...

And when I ran the compliance check CI does (see .github/workflows/compliance.yml:72), I got no warnings:
Running checkpatch       tests in /home/herbert/zephyr-external/zephyr ...
Running Kconfig          tests in /home/herbert/zephyr-external/zephyr ...
Running Codeowners       tests in /home/herbert/zephyr-external/zephyr ...
Running Nits             tests in /home/herbert/zephyr-external/zephyr ...
Running Gitlint          tests in /home/herbert/zephyr-external/zephyr ...
Running pylint           tests in /home/herbert/zephyr-external/zephyr ...
Running Identity         tests in /home/herbert/zephyr-external/zephyr ...

Complete results in compliance.xml

Examining the string in the debugger yields one with no breaks or extra characters (copied from Visual Studio Code debugger):
payload: 0x1054ac "4465627567206D657373616765206578616D706C652C2025642C2025642C20256400010000000200000003000000"

Hopefully this should make it so you don't have to build the string yourself.

@laurenmurphyx64 I had already tried this but checkpatch did complaint atleast in my local environment. May be CI does not complain about it and checkpatch in local still does? I can try though. Thanks!!


text:
LE Audio: Unicast group refactor

This PR refactors how the unicast group works in terms of when it is created, when it can be modified and how it is deleted. In a nutshell, the unicast group will now have the same lifetime as the underlying CIG. This gives us the same advantages and disadvantages of the CIG, and more tightly couples the unicast group to the ISO layer.
This required significant rewrite of some of the underlying structures as ISO channels need to be allocated once the bt_audio_streams were added to the group, instead of when the streams were configured.
Fixes https://github.com/zephyrproject-rtos/zephyr/issues/45374
Fixes https://github.com/zephyrproject-rtos/zephyr/issues/45741

Hello @Thalley,
Thanks for the great PR, I did a quick test with modified unicast_audio_client which search for two unicast_audio_server, connected and then start ISO stream:
https://github.com/rick1082/zephyr/blob/dual_link_unicast_audio/samples/bluetooth/unicast_audio_client/src/main.c
For now I'm able to:

Create group, scan, connect, configure, set QoS and enable the two stream if both unicast_audio_servers are connected in short time.
But if calling bt_audio_stream_start() for both unicast_audio_servers in short time, the only one stream can start properly.
The root cause could be the controller from unicast_audio_client try to connect two CISes in short time without waiting for the first one finished.
The error log is like this:

00:00:04.868,011]  bt_hci_core: opcode 0x2064 status 0x0c
[00:00:04.868,011]  bt_iso: bt_iso_chan_connect: Failed to connect CISes: -5
[00:00:04.868,041]  bt_unicast_client: bt_audio_stream_connect: -5
[00:00:04.868,041]  bt_audio_stream: bt_audio_stream_start: Starting stream failed: -5
[00:00:04.868,041]  main: Unable to start stream: -5

But if I let unicast_audio_client creates group for two streams, and then only connect to one unicast_audio_server
Then the unicast_audio_client will assert, the error log as following

[00:00:00.289,581]  bt_audio_stream: bt_audio_unicast_group_create: Added stream 0x20001d68 to group 0x200022d4
[00:00:00.289,581]  bt_audio_stream: bt_audio_unicast_group_create: Added stream 0x20001d8c to group 0x200022d4
[00:00:00.289,611]  bt_audio_stream: bt_audio_cig_create: group 0x200022d4 qos 0x20000194
[00:00:00.289,642]  bt_iso: bt_iso_chan_add: iso 0x20001928 chan 0x200022f0
[00:00:00.289,703]  bt_iso: bt_iso_chan_add: iso 0x200019f0 chan 0x20002324
[00:00:00.290,252]  main: Initialized
[00:00:00.290,252]  main: Waiting for connection
[00:00:00.292,877]  main: Scanning successfully started
[00:00:00.350,524]  main: Connected: D7:A6:2B:3E:76:29 (random)
[00:00:00.353,332]  main: Scanning successfully started
[00:00:02.600,067]  main: Security changed: level 2
[00:00:02.850,921]  main: discover sink cb for left
[00:00:03.350,189]  main: discover sink cb for left
[00:00:03.350,219]  main: Sink #0: ep 0x20002570
[00:00:04.851,531]  main: discover sink cb for left
[00:00:04.851,562]  main: Discover complete: err 0
[00:00:04.851,562]  bt_audio_stream: bt_audio_stream_config: conn 0x20001388 stream 0x20001d68, ep 0x20002570 codec 0x20000130 codec id 0x06 codec cid 0x0000 codec vid 0x0000
[00:00:04.851,593]  bt_audio_stream: bt_audio_stream_attach: conn 0x20001388 stream 0x20001d68 ep 0x20002570 codec 0x20000130
[00:00:04.851,654]  main: configure stream for sink[HEADSET_L], err = 0
[00:00:05.725,250]  main: Audio Stream 0x20001d68 configured, conn 0x20001388
[00:00:05.725,280]  bt_audio_stream: bt_audio_stream_qos: conn 0x20001388 group 0x200022d4
[00:00:05.725,280]  os: ***** MPU FAULT *****
[00:00:05.725,311]  os:   Data Access Violation
[00:00:05.725,311]  os:   MMFAR Address: 0xa0
[00:00:05.725,341]  os: r0/a1:  0x00000000  r1/a2:  0x20002324  r2/a3:  0x20001d8c
[00:00:05.725,341]  os: r3/a4:  0x20002324 r12/ip:  0x00000000 r14/lr:  0x0000f2d9
[00:00:05.725,372]  os:  xpsr:  0x61000000
[00:00:05.725,372]  os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
[00:00:05.725,402]  os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00:00:05.725,402]  os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
[00:00:05.725,402]  os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
[00:00:05.725,433]  os: fpscr:  0x00100000
[00:00:05.725,433]  os: Faulting instruction address (r15/pc): 0x0001965c
[00:00:05.725,463]  os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:05.725,463]  os: Current thread: 0x200010a0 (unknown)
[00:00:05.897,644]  os: Halting system

Faulting instruction is pointed to
https://github.com/Thalley/zephyr/blob/6494f1a8aa62b22bc57fed8eb184e437cf028cd8/subsys/bluetooth/audio/unicast_client.c#L233
LR is pointed to
https://github.com/Thalley/zephyr/blob/6494f1a8aa62b22bc57fed8eb184e437cf028cd8/include/zephyr/sys/slist.h#L274

Hello @Thalley, Thanks for the great PR, I did a quick test with modified unicast_audio_client which search for two unicast_audio_server, connected and then start ISO stream: https://github.com/rick1082/zephyr/blob/dual_link_unicast_audio/samples/bluetooth/unicast_audio_client/src/main.c
For now I'm able to:
1. Create group, scan, connect, configure, set QoS and enable the two stream if both unicast_audio_servers are connected in short time.
   But if calling bt_audio_stream_start() for both unicast_audio_servers in short time, the only one stream can start properly.
   The root cause could be the controller from unicast_audio_client try to connect two CISes in short time without waiting for the first one finished.
   The error log is like this:

00:00:04.868,011]  bt_hci_core: opcode 0x2064 status 0x0c
[00:00:04.868,011]  bt_iso: bt_iso_chan_connect: Failed to connect CISes: -5
[00:00:04.868,041]  bt_unicast_client: bt_audio_stream_connect: -5
[00:00:04.868,041]  bt_audio_stream: bt_audio_stream_start: Starting stream failed: -5
[00:00:04.868,041]  main: Unable to start stream: -5

2. But if I let unicast_audio_client creates group for two streams, and then only connect to one unicast_audio_server
   Then the unicast_audio_client will assert, the error log as following

[00:00:00.289,581]  bt_audio_stream: bt_audio_unicast_group_create: Added stream 0x20001d68 to group 0x200022d4
[00:00:00.289,581]  bt_audio_stream: bt_audio_unicast_group_create: Added stream 0x20001d8c to group 0x200022d4
[00:00:00.289,611]  bt_audio_stream: bt_audio_cig_create: group 0x200022d4 qos 0x20000194
[00:00:00.289,642]  bt_iso: bt_iso_chan_add: iso 0x20001928 chan 0x200022f0
[00:00:00.289,703]  bt_iso: bt_iso_chan_add: iso 0x200019f0 chan 0x20002324
[00:00:00.290,252]  main: Initialized
[00:00:00.290,252]  main: Waiting for connection
[00:00:00.292,877]  main: Scanning successfully started
[00:00:00.350,524]  main: Connected: D7:A6:2B:3E:76:29 (random)
[00:00:00.353,332]  main: Scanning successfully started
[00:00:02.600,067]  main: Security changed: level 2
[00:00:02.850,921]  main: discover sink cb for left
[00:00:03.350,189]  main: discover sink cb for left
[00:00:03.350,219]  main: Sink #0: ep 0x20002570
[00:00:04.851,531]  main: discover sink cb for left
[00:00:04.851,562]  main: Discover complete: err 0
[00:00:04.851,562]  bt_audio_stream: bt_audio_stream_config: conn 0x20001388 stream 0x20001d68, ep 0x20002570 codec 0x20000130 codec id 0x06 codec cid 0x0000 codec vid 0x0000
[00:00:04.851,593]  bt_audio_stream: bt_audio_stream_attach: conn 0x20001388 stream 0x20001d68 ep 0x20002570 codec 0x20000130
[00:00:04.851,654]  main: configure stream for sink[HEADSET_L], err = 0
[00:00:05.725,250]  main: Audio Stream 0x20001d68 configured, conn 0x20001388
[00:00:05.725,280]  bt_audio_stream: bt_audio_stream_qos: conn 0x20001388 group 0x200022d4
[00:00:05.725,280]  os: ***** MPU FAULT *****
[00:00:05.725,311]  os:   Data Access Violation
[00:00:05.725,311]  os:   MMFAR Address: 0xa0
[00:00:05.725,341]  os: r0/a1:  0x00000000  r1/a2:  0x20002324  r2/a3:  0x20001d8c
[00:00:05.725,341]  os: r3/a4:  0x20002324 r12/ip:  0x00000000 r14/lr:  0x0000f2d9
[00:00:05.725,372]  os:  xpsr:  0x61000000
[00:00:05.725,372]  os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
[00:00:05.725,402]  os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00:00:05.725,402]  os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
[00:00:05.725,402]  os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
[00:00:05.725,433]  os: fpscr:  0x00100000
[00:00:05.725,433]  os: Faulting instruction address (r15/pc): 0x0001965c
[00:00:05.725,463]  os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:05.725,463]  os: Current thread: 0x200010a0 (unknown)
[00:00:05.897,644]  os: Halting system

Faulting instruction is pointed to https://github.com/Thalley/zephyr/blob/6494f1a8aa62b22bc57fed8eb184e437cf028cd8/subsys/bluetooth/audio/unicast_client.c#L233 LR is pointed to https://github.com/Thalley/zephyr/blob/6494f1a8aa62b22bc57fed8eb184e437cf028cd8/include/zephyr/sys/slist.h#L274

Thanks, I'll look into this. Basically what is happening is that we are trying to connect multiple CIS in multiple commands at the same time, right?

Thank you @Thalley,
Yes, the item one is because the host should ask controller to finish the first CIS connection and then start the second one.
Otherwise only one CIS will be connected properly and the other one will fail.
But the item two is tricky, which leads to the scenario described in #45374 cannot be achieved.

Thank you @Thalley, Yes, the item one is because the host should ask controller to finish the first CIS connection and then start the second one. Otherwise only one CIS will be connected properly and the other one will fail. But the item two is tricky, which leads to the scenario described in #45374 cannot be achieved.

OK, thanks.
I'll try to see if I can find a solution for that, and somehow test it (the upstreamed unicast client sample does not support multiple servers right now).

Marking as draft as this will be rebased on top of https://github.com/zephyrproject-rtos/zephyr/pull/46440

Thank you @Thalley, Yes, the item one is because the host should ask controller to finish the first CIS connection and then start the second one. Otherwise only one CIS will be connected properly and the other one will fail. But the item two is tricky, which leads to the scenario described in #45374 cannot be achieved.

Created https://github.com/zephyrproject-rtos/zephyr/issues/46829 to deal with that (it is a separate issue to this PR).

Confirmed that this fixed the #45374, and also the issue#2 which I described in the previous comment.
The issue#1 it not a show stopper, since we can add retry mechanism if we cannot establish the ISO channel properly.

Rebased to solve merge conflicts

Rebased to solve merge conflicts

Note to self: There seemingly is still an issue with the unicast client sample if the unicast server sample restarts; need to investigate and fix as part of this change

Rebased to solve merge conflicts

Note to self: There seemingly is still an issue with the unicast client sample if the unicast server sample restarts; need to investigate and fix as part of this change

Unable to easily reproduce the issue with the current state of the PR. Will remove the DNM until issue has otherwise been reproduced.

Rebased to solve merge conflicts


text:
docs: Raspberry Pi Pico board page document fix for pwm

https://docs.zephyrproject.org/latest/boards/arm/rpi_pico/doc/index.html
There was a format problem on Supported Features table last element of pwm.

continue on #47578 as requested.


text:
Bluetooth: L2CAP: remove metadata requirement

This removes the dependency between CONFIG_BT_ATT_TX_COUNT and
CONFIG_BT_L2CAP_TX_BUF_COUNT since previously there was still a need
for an L2CAP context for every TX'd buffer.
~Stacked on https://github.com/zephyrproject-rtos/zephyr/pull/67532~

CI failure should be fixed by: https://github.com/zephyrproject-rtos/zephyr/pull/68104


text:
drivers: serial: Fix async to interrupt driven adaptation layer

Whenever UART_RX_DISABLED event is received module attempts to re-enable receiver since in interrupt driven API receiver is always on. However, it is possible that there is no free buffers and in that case attempt to enable the receiver will fail with -EBUSY. That scenario shall be accepted since the receiver will be re-enabled when at least one buffer will be freed.
Given that, -EBUSY return shall be accepted (no assert) and number of pending RX buffer requests shall be reset only on successful enabling.

Is there a bug item to track?


text:
samples: usb: webusb: Prettify binary object store descriptor

This is a simple cosmetic change. Each field in the BOS (Binary
Object Store) descriptor has a comment, to understand it better.
Signed-off-by: Iván Sánchez Ortega ivan@sanchezortega.es

Codecov Report

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

@@            Coverage Diff             @@
##           master    #7094      +/-   ##
==========================================
- Coverage   58.62%   58.61%   -0.01%
==========================================
  Files         464      464
  Lines       47440    47440
  Branches     8790     8790
==========================================
- Hits        27810    27809       -1
- Misses      15797    15798       +1
  Partials     3833     3833

Impacted Files
Coverage Δ

lib/posix/pthread.c
69.34% <0%> (-0.51%)
: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 3aa3e97...e388c2b. Read the comment docs.

authors: IvanSanchez codecov-io


text:
doc: security: Information about CVEs

Add information about published CVEs

@ceolin, should this doc update be back-ported to 3.7 and 3.6?

@ceolin, should this doc update be back-ported to 3.7 and 3.6?

That is a good question. My approach is to consider when the fix landed in Zephyr and not when we disclosed the information, but we may change it if that is misleading.


text:
doc: boards: Add ability to filter by SoC in the board catalog

https://builds.zephyrproject.io/zephyr/pr/79670/docs/boards/index.html
This introduces the ability to filter boards per SoC by adding a set of fields that allow to select
said SoC(s), possibly selecting entire families or series.
https://github.com/user-attachments/assets/0a7ddeef-5e1c-4a15-9b4a-5ce8ddec5ab0
Although still reasonably straightforward, the search/filtering UI is becoming richer and richer. Therefore, the PR also introduces a short list of "search tips", including what to do when it doesn't seem like their board is supported.
This builds on #79708, so will be rebased once this other PR is merged.
FWIW, next improvement will be to introduce the ability to filter by HW capability (see #79754), and I will likely use this as an opportunity to also tidy up the JS code a bit.

It's also not possible to unselect an architecture or vendor, which may become more relevant when more socs/capabilities extend the number of filters significantly.

Should/could selecting an architecture or vendor limit the SoC options to only those that still apply?

I was waiting for someone to ask :) maybe, yes, but then that means you'd likely want to generalize this to all select fields (ex. selecting the vendor "ST" would only leave arm/arm64 in the arch list), and I'm undecided as to whether this makes for an improved UX or not. I think I like the ability to select the criteria completely independently of whether there might actually be any hits or not, and the ability to actually create a query that shows no result (as said query might return different results in the future) rather than preventing me from doing so. Think e.g https://builds.zephyrproject.io/zephyr/pr/79670/docs/boards/index.html#arch=riscv&vendor=st

It's also not possible to unselect an architecture or vendor, which may become more relevant when more socs/capabilities extend the number of filters significantly.

Yes, unselecting is through "Reset Filters" button at the moment, and it's not possible to select multiple archs or vendors, which is not the end of the world but also an unnecessary limitation. I will introduce multi-select (hence also ability to unselect) just like the family/series/soc fields in a future PR.

rebased to get rid of the commits now merged with #79708

One comment on testing https://builds.zephyrproject.io/zephyr/pr/79670/docs/boards/index.html#
Selecting a vendor does not filter on family/series/soc columns. Not blocking but feels like an unexpected behavior.

One comment on testing builds.zephyrproject.io/zephyr/pr/79670/docs/boards/index.html Selecting a vendor does not filter on family/series/soc columns. Not blocking but feels like an unexpected behavior.

See https://github.com/zephyrproject-rtos/zephyr/pull/79670#issuecomment-2410993931 and https://github.com/zephyrproject-rtos/zephyr/pull/79670#issuecomment-2411020080
I understand it can be confusing though so maybe this can be improved over time.
Thanks for the feedback!

authors: erwango kartben pdgendt


text:
kernel: Add support for stopping workqueues

This patch adds support for stopping workqueues. This is useful for freeing resources from workqueues when subsystems/modules is deactivated or cleaning up the system between tests in ztest to reach a fully normalized state.
The patch adds a new function k_work_queue_stop() that releases the workqueues thread and stack when a workqueue is unwanted. k_work_queue_stop(...) should be viewed as a counterpart to k_work_queue_start(...).
This would allow to:
k_work_queue_start(...);

k_work_drain(..., true);
k_work_queue_stop(...);

LGTM, but I'll wait until others have reviewed too.

And just as general hygiene, can you split this up into three patches:

Add the feature
Add tracing hooks
Add tests

I'll split them up if you want, but could I ask why you prefere it that way?
Just for my own curiosity.

@Mattemagikern - separate commits make it easier to review and maintain in many cases. As general rules, to ensure if a code change needs to be backported, there are fewer side effects with smaller commits. If a regression occurs, it's easier to narrow down the root cause. We usually insist on separate code and test commits because it makes it easier to test bug fixes.
Generally good hygiene

I'll split them up if you want, but could I ask why you prefere it that way? Just for my own curiosity.

Once upon a time on Discord:
"Help help my very important code stopped working!"
"Maybe it's the new feature that just got added.  Can you try reverting this patch and see if that fixes it?"
"Help help!  I tried git revert and now it's giving me a bunch of collisions in the tracing code!  Who can help me fix this?  My code is very important!"
Small patches that do one thing in an isolated way makes it easier to figure out what broke when things inevitably break.  Maintainers are lazy and like to toss off one-line suggestions vs. addressing rebase failures in their spare time.

@cfriedt @andyross Thanks for the explination!
The patch has been updated to only contain the functionallity.
I've confirmed the changes with my testcases seperately.

Another newbi question:
When you say you want the patches in [feature, tracing, tests], are these separate pull-requests or should I just split it up in commits on this pull-request?

Separate commits within the same pull request please.

@npitre thanks! :heavy_check_mark:

FWIW:

If we allow task append to the queue continuously after setting K_WORK_QUEUE_STOP_BIT, the block will never be executed.

I think that's more of a policy decision than a bug.  I can see arguments either way: you could force the queue to reject new submissions when a STOP is pending, or you could allow it and document it as "the queue will stop processing the next time it is idle".  Either one seems like a reasonable choice.

authors: Mattemagikern andyross cfriedt npitre


text:
drivers: input: ft5336: Correct referencing to unexists symbol

The n is a non-existent symbol.
Changing it to the correct argument name to fix.

Mmmh could we add some test coverage for catching this?

Mmmh could we add some test coverage for catching this?

It's very tricky, if you put the wrong one it doesn't expand and as long as there's a single instance of the driver the output is valid and works, so to catch it you'd have to duplicate all entries in the build_all test. Or parse the macro definition somehow but there's no type checking in there so how could you tell that is supposed to be an argument or not...

Mmmh could we add some test coverage for catching this?

It's very tricky, if you put the wrong one it doesn't expand and as long as there's a single instance of the driver the output is valid and works, so to catch it you'd have to duplicate all entries in the build_all test. Or parse the macro definition somehow but there's no type checking in there so how could you tell that is supposed to be an argument or not...

It certainly doesn't seem like it will be an easy fix.
I wish I could add a BUILD_ASSERT somewhere...

authors: fabiobaltieri kartben soburi


text:
Fix precompiles E2E tests when running test-tss-migration

I disabled precompiles tests from TSS migration e2e because they were failing:
Error: 1mprecompiles  | [ERROR]
Error Trace:	/go/delivery/zeta-node/e2e/e2etests/test_precompiles_bank_through_contract.go:150
	            		/go/delivery/zeta-node/e2e/e2etests/test_precompiles_distribute.go:58
Error:      	Not equal:
	           expected: 0x0
	           actual  : 0x3e8
Messages:   	Balance should be 0, got: 1000

Let's modify the test to enable it to be run twice during the TSS migration process and then reenable it (by removing --skip-precompiles)

Yeah I/we should probably add some CI that verifies you can run the e2e suite twice

repo: zeta-chain/node


text:
can you share the model files?

can you share the model files?For example,det1.prototxt,det1_half.caffemodel,etc.

all in the project, please check the code

I see,thx.

repo: zeusees/Zeusee-LD-Living-Detection


text:
大佬能否加入多账号自动获取ck

保存多个账号在软件配置里，然后可以读取青龙的ck是否失效，失效了就登录并更新ck
可以参考一下这个项目
https://github.com/icepage/AutoUpdateJdCookie
通过青龙的 client_id和client_secret 就可以获取到ck

这，得关联青龙了。。。莫得动力呀~

post一下就搞掂

post一下就搞掂

要不你直接告诉我地址？🤔

可以参考一下这个文档 https://github.com/icepage/AutoUpdateJdCookie/blob/main/api/qinglong.py
post地址就是这样 http://127.0.0.1/open/envs/disable
OpenApi使用指南
在系统设置 -> 应用设置 -> 添加应用，权限目前支持5个模块，可以选择多个模块。选择一个模块之后，可读写此模块的所有接口。
使用生成的 client_id 和 client_secret 请求获取token接口 http://localhost:5700/open/auth/token?client_id=xxxxxx&client_secret=xxxxxxxx
上面接口返回的token有效期为30天，可用于请求青龙的接口 curl 'http://localhost:5700/open/envs?searchValue=&t=1630032278171' -H 'Authorization: Bearer 接口返回的token'
openapi的接口与系统正常接口的区别就是青龙里的是/api/envs，openapi是/open/envs，即就是青龙接口中的api换成open

@uwhatsup 青龙的可以了。多个账号这个弄不出来，webview 我没找到不共享cookie的方法。
没别的问题，我晚些时候关闭此 issues （逃 😬

是否可以隐私模式  登录的时候选择对应的账号，登录完一个账号就关闭软件  再重新打开

@uwhatsup 这种没用，每次都要输信息，更麻烦。

好的，那暂时先这样了，谢谢大佬

authors: uwhatsup zgcwkj


text:
单元格合并

强烈要求团队能出一个单元格合并的 表格组件

https://vue.ant.design/components/table-cn/#components-table-demo-colspan-and-rowspan

能不能给出一个demo

authors: xinzhexingzhe zhangdaiscott

repo: zhangdaiscott/jeecg-boot


text:
股票历史价格如何查询

某只股票历史价格如何查询？

查询
import { stocks } from "stock-api";

// 获取股票实时数据
stocks.netease.getStock("SH510500").then(console.log);

不知道股票代码就要先搜索一下
import { stocks } from "stock-api";

// 获取股票组实时数据
stocks.netease.searchStocks(["510500"]).then(console.log);

authors: lzou zhangxiangliang

repo: zhangxiangliang/stock-api


text:
为什么我ajax加载的页面里过场用不了

A页面AJAX加载B页面，
B页面里面元素事件貌似都没绑定
A:
asdasasdsadsadsadsa

B:
111111111111

u need write ur js in html... @z1024115289

**NSObject**

NSObject

authors: CoderXSLee showzyl z1024115289

repo: zhangxinxu/mobilebone

license: mit


text:
Implement mobilenetv2 with ONNX Runtime backend

Instructions
Run server:
docker run --rm --net host -v $(pwd)/models:/models nvcr.io/nvidia/tritonserver:24.06-py3 tritonserver --model-repository=/models

Run benchmark client:
docker run --rm --net host nvcr.io/nvidia/tritonserver:24.06-py3-sdk perf_analyzer -u localhost:8000 -m mobilenetv2 --concurrency-range 1:8

Benchmark results
AWS EC2 instance type: c7a.2xlarge.
Let m be the number of model instances, n be the number of intra-op threads.

Experiment 1: m=4, n=1
Experiment 2: m=2, n=2
Experiment 3: m=1, n=4

Experiment 1
Concurrency: 1, throughput: 126.975 infer/sec, latency 7836 usec
Concurrency: 2, throughput: 245.791 infer/sec, latency 8093 usec
Concurrency: 3, throughput: 338.272 infer/sec, latency 8812 usec
Concurrency: 4, throughput: 425.694 infer/sec, latency 9337 usec
Concurrency: 5, throughput: 552.312 infer/sec, latency 9017 usec
Concurrency: 6, throughput: 539.899 infer/sec, latency 11064 usec
Concurrency: 7, throughput: 538.569 infer/sec, latency 12954 usec
Concurrency: 8, throughput: 541.96 infer/sec, latency 14715 usec

Experiment 2
Concurrency: 1, throughput: 210.602 infer/sec, latency 4711 usec
Concurrency: 2, throughput: 401.039 infer/sec, latency 4948 usec
Concurrency: 3, throughput: 503.033 infer/sec, latency 5931 usec
Concurrency: 4, throughput: 494.162 infer/sec, latency 8057 usec
Concurrency: 5, throughput: 492.89 infer/sec, latency 10105 usec
Concurrency: 6, throughput: 493.183 infer/sec, latency 12126 usec
Concurrency: 7, throughput: 493.041 infer/sec, latency 14159 usec
Concurrency: 8, throughput: 493.265 infer/sec, latency 16178 usec

Experiment 3
Concurrency: 1, throughput: 363.038 infer/sec, latency 2722 usec
Concurrency: 2, throughput: 485.889 infer/sec, latency 4082 usec
Concurrency: 3, throughput: 485.753 infer/sec, latency 6144 usec
Concurrency: 4, throughput: 485.815 infer/sec, latency 8201 usec
Concurrency: 5, throughput: 485.646 infer/sec, latency 10262 usec
Concurrency: 6, throughput: 485.301 infer/sec, latency 12327 usec
Concurrency: 7, throughput: 485.349 infer/sec, latency 14388 usec
Concurrency: 8, throughput: 485.169 infer/sec, latency 16451 usec

Benchmark (take 2)
This time we generate load from remote instance.

server: c7a.xlarge
client: t3.medium

https://gist.github.com/zhanpon/69ae6de3aa86998d9a5f72fbf630149c
Experiment 1
Concurrency: 1, throughput: 93.7372 infer/sec, latency 10490 usec
Concurrency: 2, throughput: 179.886 infer/sec, latency 10911 usec
Concurrency: 3, throughput: 265.332 infer/sec, latency 11116 usec
Concurrency: 4, throughput: 328.619 infer/sec, latency 11970 usec
Concurrency: 5, throughput: 397.725 infer/sec, latency 12394 usec
Concurrency: 6, throughput: 435.615 infer/sec, latency 13584 usec
Concurrency: 7, throughput: 443.091 infer/sec, latency 15578 usec
Concurrency: 8, throughput: 456.919 infer/sec, latency 17319 usec

Experiment 2
Concurrency: 1, throughput: 129.764 infer/sec, latency 7556 usec
Concurrency: 2, throughput: 245.578 infer/sec, latency 7968 usec
Concurrency: 3, throughput: 325.872 infer/sec, latency 9028 usec
Concurrency: 4, throughput: 367.377 infer/sec, latency 10715 usec
Concurrency: 5, throughput: 375.398 infer/sec, latency 13139 usec
Concurrency: 6, throughput: 377.027 infer/sec, latency 15724 usec
Concurrency: 7, throughput: 382.996 infer/sec, latency 18074 usec
Concurrency: 8, throughput: 380.85 infer/sec, latency 20810 usec

Experiment 3
Inferences/Second vs. Client Average Batch Latency
Concurrency: 1, throughput: 179.43 infer/sec, latency 5432 usec
Concurrency: 2, throughput: 297.012 infer/sec, latency 6584 usec
Concurrency: 3, throughput: 315.215 infer/sec, latency 9366 usec
Concurrency: 4, throughput: 320.973 infer/sec, latency 12298 usec
Concurrency: 5, throughput: 322.04 infer/sec, latency 15354 usec
Concurrency: 6, throughput: 328.216 infer/sec, latency 18111 usec
Concurrency: 7, throughput: 327.399 infer/sec, latency 21188 usec
Concurrency: 8, throughput: 331.103 infer/sec, latency 23978 usec

repo: zhanpon/triton-server-bench


text:
🛑 ZY is down

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

HTTP code: 0
Response time: 0 ms

Resolved: ZY is back up in e1e0cae after 12 minutes.

repo: zhaodylan/uptime-ziyuan


text:
🛑 ZY is down

In 357f4e7, ZY (https://ziyuan.baidu.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZY is back up in 30d9b13.


text:
您好，是否有办法去除路径中的/1/main

挂载一个盘的时候是否可以不显示/1/
或者是否可以通过伪静态之类的操作去掉/1/main呢

不清楚伪静态是否可隐藏 /1/main，你可自行尝试，或者自己修改前端 vue 的路由源码。

@HCARX H
非常抱歉这么久才恢复，最新版本已经解决此问题。去掉了 main，其中前面的 1 也支持自定义


text:
获取直链时，某些复杂直链下载时会出现400错误

简单的直链可正常下载，比如：https://pan.ruan.moe/directlink/工具/其他软件/Voice.apk
某些复杂的直链不可下载， 比如：https://pan.ruan.moe/directlink/动漫/斩赤红之瞳/[DMG][Akame ga Kill!][04][www.yxdm.tv][720P][GB].mp4

某些复杂直链下载时会出现400错误。

@CuteLouise 明白了，下版本修复，因为 URL 中有特殊字符，如 [、]。

以发布版本，

简单的直链可正常下载，比如：https://pan.ruan.moe/directlink/工具/其他软件/Voice.apk
某些复杂的直链不可下载， 比如：[https://pan.ruan.moe/directlink/动漫/斩赤红之瞳/[DMG]Akame ga Kill!][04][www.yxdm.tv][720P][GB].mp4

某些复杂直链下载时会出现400错误。

老哥，建议不要把你的甲骨文密钥什么的都放到app里，这个加密文件夹用的password.txt目前可以直接被下载 /狗头

简单的直链可正常下载，比如：https://pan.ruan.moe/directlink/工具/其他软件/Voice.apk
某些复杂的直链不可下载， 比如：[https://pan.ruan.moe/directlink/动漫/斩赤红之瞳/[DMG]Akame ga Kill!][04][www.yxdm.tv][720P][GB].mp4

某些复杂直链下载时会出现400错误。

老哥，建议不要把你的甲骨文密钥什么的都放到app里，这个加密文件夹用的password.txt目前可以直接被下载 /狗头

谢谢你，不过我的甲骨文已经全部DD过了不使用秘钥了。那个东西没什么价值

简单的直链可正常下载，比如：https://pan.ruan.moe/directlink/工具/其他软件/Voice.apk
某些复杂的直链不可下载， 比如：[https://pan.ruan.moe/directlink/动漫/斩赤红之瞳/[DMG]Akame ga Kill!][04][www.yxdm.tv][720P][GB].mp4

某些复杂直链下载时会出现400错误。

老哥，建议不要把你的甲骨文密钥什么的都放到app里，这个加密文件夹用的password.txt目前可以直接被下载 /狗头

谢谢你，不过我的甲骨文已经全部DD过了不使用秘钥了。那个东西没什么价值

可以 老铁

font{
    line-height: 1.6;
}
ul,ol{
    padding-left: 20px;
    list-style-position: inside;
}

    大佬，这个问题不是我提问的吧，怎么会恢复到我这里呢

                            niu12503

                                niu12503@gmail.com

    签名由
    网易邮箱大师
    定制

在2020年2月17日 22:41，Shawn Peng<notifications@github.com> 写道：

简单的直链可正常下载，比如：https://pan.ruan.moe/directlink/工具/其他软件/Voice.apk
某些复杂的直链不可下载， 比如：[https://pan.ruan.moe/directlink/动漫/斩赤红之瞳/[DMG]Akame ga Kill!][04][www.yxdm.tv][720P][GB].mp4
某些复杂直链下载时会出现400错误。
老哥，建议不要把你的甲骨文密钥什么的都放到app里，这个加密文件夹用的password.txt目前可以直接被下载 /狗头
谢谢你，不过我的甲骨文已经全部DD过了不使用秘钥了。那个东西没什么价值
可以 老铁
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.


text:
Question 5 (3 points): Finding All the Corners

CornersProblem Class 구현

The real power of A* will only be apparent with a more challenging search problem. Now, it’s time to formulate a new problem and design a heuristic for it.
In corner mazes, there are four dots, one in each corner. Our new search problem is to find the shortest path through the maze that touches all four corners (whether the maze actually has food there or not). Note that for some mazes like tinyCorners, the shortest path does not always go to the closest food first! Hint: the shortest path through tinyCorners takes 28 steps.
Note: Make sure to complete Question 2 before working on Question 5, because Question 5 builds upon your answer for Question 2.
Implement the CornersProblem search problem in searchAgents.py. You will need to choose a state representation that encodes all the information necessary to detect whether all four corners have been reached. Now, your search agent should solve:
python pacman.py -l tinyCorners -p SearchAgent -a fn=bfs,prob=CornersProblem
python pacman.py -l mediumCorners -p SearchAgent -a fn=bfs,prob=CornersProblem
To receive full credit, you need to define an abstract state representation that does not encode irrelevant information (like the position of ghosts, where extra food is, etc.). In particular, do not use a Pacman GameState as a search state. Your code will be very, very slow if you do (and also wrong).
Hint: The only parts of the game state you need to reference in your implementation are the starting Pacman position and the location of the four corners.
Our implementation of breadthFirstSearch expands just under 2000 search nodes on mediumCorners. However, heuristics (used with A* search) can reduce the amount of searching required.


text:
关于CoOp和PromptKD的GFLOPS和FPS比较

感谢作者的开源，但我对文中效率的比较有点疑问，想请问

CoOp在文本分支插入learnable token，在测试前，文本分支可以只进行一次推理，然后复用到所有图像分支。PromptKD在图像分支插入learnable token，对于所有图片都增加了计算时间，还需要经过额外的MLP去进行维度对齐，为什么FPS会更高？
同理1，PromptKD测试时至少FLOPS应该和CoOp一致，为什么会少这么多倍？

或许我有什么细节疏漏，所以导致上述疑惑，希望得到您的解答

这里考虑的是，对于一个全新的inference场景，coop是包含text encoder进行计算的，promptkd的计算不涉及text encoder，只计算image encoder

感谢回复，如何理解一个全新的inference场景呢，指的是一张novel class的类别图片吗，如果是novel class，不是应该也要先计算new  class name的text embedding吗

这里promptkd的计算部分只考虑student部分的计算，对novel text feature是在第一阶段的训练完成后就有了

理解了，感谢作者的耐心解答，我将关闭这个issue。


text:
how can i get of pre-model 'regionclip_pretrained-cc_rn50_mmdet.pth' in china

up for title . thks!!!

OK, we have released the Baidu drive link


text:
Fixed coveralls not found on MacOS with py39-311

Was reviewed in https://github.com/zhmcclient/python-zhmcclient/pull/1664 - no separate review needed.

coverage: 25.088%. remained the same
when pulling 75a474ff03e8328f866e125bbb4265c80d2c2eb9 on andy/fix-coveralls-macos
into 97e7f742b1cc9433127a20dc40b53758eb697cb8 on master.

authors: andy-maier coveralls

repo: zhmcclient/zhmc-os-forwarder


text:
Start 1.0.0

No review needed.

Coverage remained the same at 36.692% when pulling 2d7d64af1224942cc2b293744847ed8dddc630b5 on start_1.0.0 into ac69199446d33623d14c1f405c40dc4751451ce2 on master.

repo: zhmcclient/zhmccli


text:
🛑 腾讯云 COS 节点 is down

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

HTTP code: 0
Response time: 0 ms

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

repo: zhonger/upptime


text:
当topic包含特殊字符时，xmind_content_dict读取为空，很多属性读取不到

WARNING:root:This is a blank sheet(None), should have at least 1 sub topic(test suite)
xmind_content_dict=[{'id': '76255e848420dcc93656efda15', 'title': None, 'topic': {'id': '76255e848420d91fe98c4526dd', 'link': None, 'title': None, 'note': None, 'label': None, 'comment': None, 'markers': []}}]

是因为什么需求需要包含特殊符号呢，特殊符号的作用是什么

@

是因为什么需求需要包含特殊符号呢，特殊符号的作用是什么

误操作，直接从产品需求文档里copy过来的，不能避免，已经第二次发生。下定决心想解决它

authors: yicaifeitian zhuifengshen

repo: zhuifengshen/xmind


text:
Issue with Entity.addEffect()

Okay, so some effects apparently broke with the recent updates. The effects in particular being:
MobEffect.movementSpeed
MobEffect.jump
EDIT: I am using the latest non-Pro version on a Moto G Android 5.0 in case there are incompatibility issues, but I hardly believe that's the case.

Both worked fine for me: I'm using https://github.com/zhuowei/ModPEScripts/blob/master/addeffect.js with the command /effect jump and /effect movementSpeed which calls
Entity.addEffect(getPlayerEnt(), MobEffect.movementSpeed, 20*30, 0, false, true);
// and
Entity.addEffect(getPlayerEnt(), MobEffect.jump, 20*30, 0, false, true);

authors: DiegoGTRatty zhuowei

repo: zhuowei/MCPELauncher


text:
Fully implement Render Targets

Turns out renderpasses/framebuffers cannot share images for whatever reason, which means it would be necessary now to implement the custom targets and to move the images themselves to the render target too.

Done