Enforce that contrast limits must be increasing

Description

Ensures that contrast limits are increasing
This is a continuation of the work started by @haesleinhuepf in PR #4159
Type of change

[x] Bug-fix (non-breaking change which fixes an issue)

References

Closes #4158
How has this been tested?

[x] example: all tests pass with my change

Final checklist:

[x] My PR is the minimum possible work for the desired functionality
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works
[x] If I included new strings, I have used trans. to make them localizable.
For more information see our translations guide.

I could use a bit of help with the CI failure. I don't understand the difference between contrast_limits and contrast_limits_range. They aren't well defined in the doc string and the code around them isn't very clean - are they just the same thing??
    contrast_limits : list (2,) of float
        Color limits to be used for determining the colormap bounds for
        luminance images. If the image is rgb the contrast_limits is ignored.
    contrast_limits_range : list (2,) of float
        Range for the color limits for luminance images. If the image is
        rgb the contrast_limits_range is ignored.

I could use a bit of help with the CI failure. I don't understand the difference between contrast_limits and contrast_limits_range. They aren't well defined in the doc string and the code around them isn't very clean - are they just the same thing??
    contrast_limits : list (2,) of float
        Color limits to be used for determining the colormap bounds for
        luminance images. If the image is rgb the contrast_limits is ignored.
    contrast_limits_range : list (2,) of float
        Range for the color limits for luminance images. If the image is
        rgb the contrast_limits_range is ignored.

Based on using napari, if have, say a greyscale 0-255 image and you use:
viewer.layers[0].contrast_limits = [50, 150]
Then you will change the set contrast limits to 50 (lower) 150 (upper) for display, out of a possible range of 0-255. Equivalent to moving the slider in the UI and making the positions of the end stops closer together.

Meanwhile, if you use:
viewer.layers[0].contrast_limits_range = [50, 150]
The visual effect on the canvas/image will be the same, but the slider will not permit setting outside that range: the slider end stops will still be at maximum. To change outside the range in the UI, one needs to right click the slider and change the range.

viewer.layers[0].contrast_limits overrides any _range setting and sets a new range if outside. So: viewer.layers[0].contrast_limits = [0, 150]:

viewer.layers[0].contrast_limits_range
Out[4]: [0, 150]

Is there any reason to keep the range on the napari/core side rather than the qt/gui side?

Thanks @psobolewskiPhD ! That was super helpful. contrast_limits_range is range extent available on the widget and contrast_limits is the visible range (the values the widget is set at)

What is the expected behavior of contrast_limits_range is set outside of contrast_limits?
An existing test expects this:
    layer.contrast_limits_range = [0, 100]
    layer.contrast_limits = [20, 40]
    layer.contrast_limits_range = [60, 100]
    assert layer.contrast_limits == [60, 60]

But the new checks fail because internally the contrast_limits are set to [60, 60] since its not monotonically increasing. They now fail with a ValueError.

What is the expected behavior of contrast_limits_range is set outside of contrast_limits?

I think it should error.
It shouldn't be possible to set the range outside the actual limits.
Setting limits outside the range should be fine and reset the range accordingly.

Setting limits outside the range should be fine and reset the range accordingly.

yes, this happens
As suggested (https://github.com/napari/napari/pull/4159#issuecomment-1053725079), I implemented an override of the contrast_limits if contrast_limits_range is outside of contrast_limits entirely. Otherwise it clips.

layer.contrast_limits = [20, 40]

layer.contrast_limits_range
Out[5]: [0, 100]

layer.contrast_limits_range = [60, 100]

layer.contrast_limits_range
Out[7]: [60, 100]

layer.contrast_limits
Out[8]: [60, 100]

Yea, to me the latest behavior is somewhat more intuitive—sort of?
If range is outside limits then limits are reset to range. So no more bizarre [60, 60].
On the surface of it this is reasonable...
But it's also wierd, because it means the image displayed is changed and there is no way to go back via the GUI, because the slider range is changed and doesn't cover the original range.
Of course, such a change can only be made programatically, so maybe it doesn't matter?
But I still think that this is case where the user should get an error "contrast range doesn't encompass contrast limits" and be forced to change contrast_limits or contrast_limits_range explicitly, so they can't complain.

Is there any reason to keep the range on the napari/core side rather than the qt/gui side?

I still stand by this; I don't see why we would even have the concept of a "range" outside of the gui. This should only live on the qt side.

Is there any reason to keep the range on the napari/core side rather than the qt/gui side?

I still stand by this; I don't see why we would even have the concept of a "range" outside of the gui. This should only live on the qt side.

This makes sense to me. The range should basically not be settable, it should be derived from the actual limits. Also, I think this touches on the need to have a reset button more accessible, as discussed in this related issue: https://github.com/napari/napari/issues/5127

Is there any reason to keep the range on the napari/core side rather than the qt/gui side?

I still stand by this; I don't see why we would even have the concept of a "range" outside of the gui. This should only live on the qt side.

This makes sense to me. The range should basically not be settable, it should be derived from the actual limits. Also, I think this touches on the need to have a reset button more accessible, as discussed in this related issue: #5127

I think the problem is that the qt/gui API is not public. So if we shove it over there, then people developing against napari (e.g. plugin devs) have no stable way of setting up the GUI to present a sensible contrast limits slider, which is why I think was added in #837 (also see relevant discussion on image.sc too).
One real case (among others) where this might be relevant if I write a reader plugin that returns 12-bit sensor data that is stored in 16-bit uints. I really the contrast slider to have a range of [0, 2^12-1] (because values outside those limits are not possible), but I want to allow the user to adjust the actual contrast limits because their actual data range may be limited. What I don't want is napari to present a contrast slider with a range of [0, 2^16-1] and have a user ask why their image is black.
Without the explicit range, it has to be inferred (either from the dtype, which could be misleading as above) or by reading all the data (which may not feasible). Or we have to add more guessing magic (e.g. reading some subset of the data to set the initial limits).
Alternatively, we could consider public ways of setting this outside of the Layer API, but I don't know what that would look like or how we could easily keep it in sync with contrast_limits, which we clearly need some logic for.

Also, if I understood correctly, this PR is trying to fix a buggy case where contrast_limits is set to be non-increasing.
I understand that contrast_limits and contrast_limits_range interact, but that seems like an independent question that should directly block this PR, right?

I understand that contrast_limits and contrast_limits_range interact, but that seems like an independent issue that should directly block this PR, right?

Yes, defintely not blocking: better fix the bug than doing nothing. However, I brought this up because I felt like we're trying to solve a problem that shouldn't exist...

Without the explicit range, it has to be inferred (either from the dtype, which could be misleading as above) or by reading all the data (which may not feasible). Or we have to add more guessing magic (e.g. reading some subset of the data to set the initial limits).

That's a good point and you gave some clear use cases... I don't see a cleaner way around this than what we currently have, so I guess I'll shut up about it :P

Yes, defintely not blocking: better fix the bug than doing nothing. However, I brought this up because I felt like we're trying to solve a problem that shouldn't exist...

Now I understand the interaction more, I'm more sympathetic. But I also think there are bigger issues to worry about this particular attribute, so still think this is worth getting in mostly as is.

@andy-sweet this is ready for another review.


Crash in integration tests

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=260716&view=logs&j=a8b516b9-5c25-5ad9-505a-b03d38bc1dad&t=e3a86c73-8122-59bf-cc44-51f5223c267f&l=913

Symbolicated trace
Operating system: Linux
                  5.15.0 -1057-azure #65~20.04.1-Ubuntu SMP Mon Feb 12 17:26:40 UTC 2024 x86_64
CPU: amd64
     family 6 model 106 stepping 6
     4 CPUs

GPU: UNKNOWN

Crash reason:  SIGSEGV /0x00000080
Crash address: 0x0
Process uptime: 30 seconds

Thread 0 (crashed)
 0  code-insiders!gin_helper::CallbackHolderBase::SecondWeakCallback(v8::WeakCallbackInfo<gin_helper::CallbackHolderBase> const&) [function_template.cc : 33 + 0x1]
    rax = 0x80f94a02f81e0000   rdx = 0x00001ef8009ca560
    rcx = 0x000055c3c6b82d80   rbx = 0x00001ef800068d20
    rsi = 0x00001ef801e1be80   rdi = 0x00001ef801e1be80
    rbp = 0x00007ffc5a562b80   rsp = 0x00007ffc5a562a68
     r8 = 0x00001ef80003c000    r9 = 0x0000000000000001
    r10 = 0x00007ffc5a5627c8   r11 = 0x00000000000520d4
    r12 = 0x00001ef800131a00   r13 = 0x000000005893a5c3
    r14 = 0x00007ffc5a562b48   r15 = 0x00007ffc5a562b30
    rip = 0x000055c3c6b82d91
    Found by: given as instruction pointer in context
 1  code-insiders!v8::internal::GlobalHandles::InvokeSecondPassPhantomCallbacks() [global-handles.cc : 866 + 0x5]
    rbx = 0x00001ef800068d20   rbp = 0x00007ffc5a562b80
    rsp = 0x00007ffc5a562a70   r12 = 0x00001ef800131a00
    r13 = 0x000000005893a5c3   r14 = 0x00007ffc5a562b48
    r15 = 0x00007ffc5a562b30   rip = 0x000055c3c7edb877
    Found by: call frame info
 2  code-insiders!node::PerIsolatePlatformData::RunForegroundTask(std::__Cr::unique_ptr<v8::Task, std::__Cr::default_delete<v8::Task>>) [node_platform.cc : 425 + 0x6]
    rbx = 0x00007ffc5a562c48   rbp = 0x00007ffc5a562c00
    rsp = 0x00007ffc5a562b90   r12 = 0x00001ef8002f0000
    r13 = 0x00007ffc5a562b98   r14 = 0xaaaaaaaaaaaaaaaa
    r15 = 0x00001ef800085218   rip = 0x000055c3cdd7eeac
    Found by: call frame info
 3  code-insiders!node::PerIsolatePlatformData::FlushForegroundTasksInternal() [node_platform.cc : 494 + 0xc]
    rbx = 0x00001ef800085218   rbp = 0x00007ffc5a562c90
    rsp = 0x00007ffc5a562c10   r12 = 0x00001ef8008724e0
    r13 = 0x0000000000000000   r14 = 0x0000000000000001
    r15 = 0x00001ef802340640   rip = 0x000055c3cdd7dc73
    Found by: call frame info
 4  code-insiders!uv__async_io [async.c : 162 + 0x5]
    rbx = 0x000055c3ce620320   rbp = 0x00007ffc5a5630e0
    rsp = 0x00007ffc5a562ca0   r12 = 0x00001ef800078e78
    r13 = 0x0000000000000000   r14 = 0x00001ef800078e10
    r15 = 0x000055c3ce6204d0   rip = 0x000055c3c69f7026
    Found by: call frame info
 5  code-insiders!uv__io_poll [epoll.c : 374 + 0x7]
    rbx = 0x0000000000000002   rbp = 0x00007ffc5a5661f0
    rsp = 0x00007ffc5a5630f0   r12 = 0x0000000000000002
    r13 = 0x000055c3ce6204e8   r14 = 0x0000000000000000
    r15 = 0x00007ffc5a5630f0   rip = 0x000055c3c6a05bca
    Found by: call frame info
 6  code-insiders!uv_run [core.c : 406 + 0x8]
    rbx = 0x000055c3ce620320   rbp = 0x00007ffc5a566260
    rsp = 0x00007ffc5a566200   r12 = 0x000055c3ce620368
    r13 = 0x00007ffc5a566501   r14 = 0x00007ffc5a566220
    r15 = 0x0000000000000001   rip = 0x000055c3c69f74c5
    Found by: call frame info
 7  code-insiders!node::Environment::CleanupHandles() [env.cc : 966 + 0xa]
    rbx = 0x00001ef8002f0000   rbp = 0x00007ffc5a5662a0
    rsp = 0x00007ffc5a566270   r12 = 0x00001ef8002f0858
    r13 = 0x00007ffc5a566500   r14 = 0x00001ef8002f0838
    r15 = 0x00001ef8002f0858   rip = 0x000055c3cdc961c4
    Found by: call frame info
 8  code-insiders!node::Environment::RunCleanup() [env.cc : 1018 + 0x8]
    rbx = 0x00001ef8002f0000   rbp = 0x00007ffc5a5664f0
    rsp = 0x00007ffc5a5662b0   r12 = 0x00001ef80026c200
    r13 = 0x00007ffc5a566500   r14 = 0x000055c3ce5dc730
    r15 = 0xaaaaaaaaaaaaaaaa   rip = 0x000055c3cdc968e7
    Found by: call frame info
 9  code-insiders!node::FreeEnvironment(node::Environment*) [environment.cc : 452 + 0x8]
    rbx = 0x00001ef8002f0000   rbp = 0x00007ffc5a566580
    rsp = 0x00007ffc5a566500   r12 = 0x00001ef80026c200
    r13 = 0x00007ffc5a566500   r14 = 0x00001ef8001b4000
    r15 = 0xaaaaaaaaaaaaaaaa   rip = 0x000055c3cdc5348c
    Found by: call frame info
10  code-insiders!std::__Cr::__shared_ptr_pointer<node::Environment*, electron::NodeBindings::CreateEnvironment(v8::Local<v8::Context>, node::MultiIsolatePlatform*, std::__Cr::vector<std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char>>, std::__Cr::allocator<std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char>>>>, std::__Cr::vector<std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char>>, std::__Cr::allocator<std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char>>>>, std::__Cr::optional<base::RepeatingCallback<void ()>>)::$_1, std::__Cr::allocator<node::Environment>>::__on_zero_shared() [node_bindings.cc : 755 + 0x8]
    rbx = 0x00001ef8004428c0   rbp = 0x00007ffc5a5665c0
    rsp = 0x00007ffc5a566590   r12 = 0x00001ef800018d00
    r13 = 0x0000000000000016   r14 = 0x00001ef8002f0000
    r15 = 0x00007ffc5a5665d0   rip = 0x000055c3c6b89639
    Found by: call frame info
11  code-insiders!electron::ElectronBrowserMainParts::PostMainMessageLoopRun() [shared_ptr.h : 173 + 0x9]
    rbx = 0x00001ef8004428c0   rbp = 0x00007ffc5a566650
    rsp = 0x00007ffc5a5665d0   r12 = 0x00001ef800018d00
    r13 = 0x0000000000000016   r14 = 0x000000000000002c
    r15 = 0x00007ffc5a5665d0   rip = 0x000055c3c6ae05cf
    Found by: call frame info
12  code-insiders!content::BrowserMainLoop::ShutdownThreadsAndCleanUp() [browser_main_loop.cc : 1145 + 0x5]
    rbx = 0x0000000000000000   rbp = 0x00007ffc5a5666f0
    rsp = 0x00007ffc5a566660   r12 = 0x00001ef80004c9a0
    r13 = 0xaaaaaaaaaaaaaaaa   r14 = 0x00007ffc5a566600
    r15 = 0xaaaaaaaaaaaaaaaa   rip = 0x000055c3c8e2bc35
    Found by: call frame info
13  code-insiders!content::BrowserMainRunnerImpl::Shutdown() [browser_main_runner_impl.cc : 176 + 0x5]
    rbx = 0x00001ef80000c360   rbp = 0x00007ffc5a566730
    rsp = 0x00007ffc5a566700   r12 = 0xaaaaaaaaaaaaaaaa
    r13 = 0x00007ffc5a566900   r14 = 0x0000000000000000
    r15 = 0xaaaaaaaaaaaaaaaa   rip = 0x000055c3c8e2d8fe
    Found by: call frame info
14  code-insiders!content::BrowserMain(content::MainFunctionParams) [browser_main.cc : 43 + 0x5]
    rbx = 0x0000000000000000   rbp = 0x00007ffc5a5667a0
    rsp = 0x00007ffc5a566740   r12 = 0x00007ffc5a5667b0
    r13 = 0x00007ffc5a566920   r14 = 0x00001ef80000c360
    r15 = 0x00007ffc5a566740   rip = 0x000055c3c8e28fd8
    Found by: call frame info
15  code-insiders!content::RunBrowserProcessMain(content::MainFunctionParams, content::ContentMainDelegate*) [content_main_runner_impl.cc : 713 + 0x8]
    rbx = 0x00007ffc5a566dd0   rbp = 0x00007ffc5a5668a0
    rsp = 0x00007ffc5a5667b0   r12 = 0x00007ffc5a5667b0
    r13 = 0x00007ffc5a566920   r14 = 0x00007ffc5a5667e8
    r15 = 0x00007ffc5a566820   rip = 0x000055c3c6d16dc4
    Found by: call frame info
16  code-insiders!content::ContentMainRunnerImpl::RunBrowser(content::MainFunctionParams, bool) [content_main_runner_impl.cc : 1302 + 0x8]
    rbx = 0x000016b800296530   rbp = 0x00007ffc5a566970
    rsp = 0x00007ffc5a5668b0   r12 = 0x00000000ffffffff
    r13 = 0x00007ffc5a566920   r14 = 0x00007ffc5a566980
    r15 = 0x00007ffc5a5668b0   rip = 0x000055c3c6d185b0
    Found by: call frame info
17  code-insiders!content::ContentMainRunnerImpl::Run() [content_main_runner_impl.cc : 1152 + 0xf]
    rbx = 0x000016b800296530   rbp = 0x00007ffc5a566a90
    rsp = 0x00007ffc5a566980   r12 = 0x00007ffc5a566a50
    r13 = 0xaaaaaaaaaaaaaaaa   r14 = 0x00007ffc5a566980
    r15 = 0x0000000000000000   rip = 0x000055c3c6d18399
    Found by: call frame info
18  code-insiders!content::RunContentProcess(content::ContentMainParams, content::ContentMainRunner*) [content_main.cc : 333 + 0x8]
    rbx = 0x000016b800296530   rbp = 0x00007ffc5a566cf0
    rsp = 0x00007ffc5a566aa0   r12 = 0x0000000000000000
    r13 = 0x00007ffc5a566b50   r14 = 0x0000000000000000
    r15 = 0x00007ffc5a566b81   rip = 0x000055c3c6d15c8d
    Found by: call frame info
19  code-insiders!content::ContentMain(content::ContentMainParams) [content_main.cc : 346 + 0x8]
    rbx = 0x00007ffc5a566d70   rbp = 0x00007ffc5a566d60
    rsp = 0x00007ffc5a566d00   r12 = 0x00007ffc5a566d28
    r13 = 0x00007ffc5a566f30   r14 = 0x00007ffc5a566d20
    r15 = 0x00007ffc5a566d08   rip = 0x000055c3c6d15d96
    Found by: call frame info
20  code-insiders!main [electron_main_linux.cc : 45 + 0x8]
    rbx = 0x00007ffc5a566f38   rbp = 0x00007ffc5a566e40
    rsp = 0x00007ffc5a566d70   r12 = 0x00007ffc5a566da0
    r13 = 0x00007ffc5a566f30   r14 = 0x00007ffc5a566d70
    r15 = 0x00007ffc5a566dd0   rip = 0x000055c3c6a081d9
    Found by: call frame info
21  libc.so.6!__libc_start_main [libc-start.c : 308 + 0x1a]
    rbx = 0x000055c3c69a3b20   rbp = 0x0000000000000000
    rsp = 0x00007ffc5a566e50   r12 = 0x000055c3c6612000
    r13 = 0x00007ffc5a566f30   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x00007fd154910083
    Found by: call frame info
22  code-insiders!_start + 0x2a
    rbx = 0x0000000000000000   rbp = 0x0000000000000000
    rsp = 0x00007ffc5a566f20   r12 = 0x000055c3c6612000
    r13 = 0x00007ffc5a566f30   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x000055c3c661202a
    Found by: call frame info
23  0x7ffc5a566f28
    rbx = 0x0000000000000000   rbp = 0x0000000000000000
    rsp = 0x00007ffc5a566f28   r12 = 0x000055c3c6612000
    r13 = 0x00007ffc5a566f30   r14 = 0x0000000000000000
    r15 = 0x0000000000000000   rip = 0x00007ffc5a566f28
    Found by: call frame info
    ```


Make ariaDropEffect attributes accesslevel to be public

The helper methods can be called using a child component that extends this component. In that case we get an attribute access exception. Make it public so that child components can render without access errors.

This is no longer needed, the access is now set to default instead of private.

thanks for the pull request, looks like the component has changed and the attribute is no longer there or moved elsewhere.


Remove --only-tag from d-latest.tag

See https://github.com/dlang/dlang.org/pull/2213#discussion_r168968067

Probably API-rate limiting again: https://github.com/dlang-bots/dlang-bot/issues/166


fasta file format not supported

Hi,
I'm using SHAPEIT5 and I'm getting this error -
ERROR: Opening [ref.fasta]: file format not supported by HTSlib
the command I'm using is as follows -
SHAPEIT5_phase_common -T 16 -I S2_WhPh.vcf.gz -H ref.fasta -R PGA_scaffold_6 -O S2_SH.vcf --log P24XYF_S2_SH.log
what does this error mean exactly?
Thanks!

Hi,
When refer to "reference panel" we mean a cohort of haplotypes (e.g. in vcf/bcf format), not the reference genome sequence (in fasta). You are simply providing a wrong file.
You can find some common definitions here, in the hope they are useful: https://odelaneau.github.io/shapeit5/docs/glossary/#reference-panel
Hope this helps,
Simone

Hi,
Unfortunately, population-based statistical phasing needs at least a certain amount of samples to be reliable.
Simone


KYLIN-3890 Add doc about usage of ./bin/metadata.sh

Can one of the admins verify this patch?

Can one of the admins verify this patch?


Fixed MosaicSupplyChangeTransaction schema issue (Direction -> Action)

Fixed MosaicSupplyChangeTransaction still uses old schema field Direction issue. Replaced to Action

Issue: #309

Pull Request Test Coverage Report for Build 774

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

Totals

Change from base Build 773:
0.0%

Covered Lines:
10

Relevant Lines:
10

💛  - Coveralls

Pull Request Test Coverage Report for Build 774

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

Totals

Change from base Build 773:
0.0%

Covered Lines:
10

Relevant Lines:
10

💛  - Coveralls


[BUG] - Autocomplete is not focused on click

NextUI Version
2.3.6
Describe the bug
When I click on autocomplete, it is not focused. It requires another click. Also click-outside event closes the menu but keeps the focus.
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue

https://nextui.org/docs/components/autocomplete#usage
click "select an animal"
menu opens but you can't type
click again
now you can type

https://nextui.org/docs/components/autocomplete#usage
click "select an animal"
menu opens but you can't type
click outside to cancel action
now you can type (???)

Expected behavior

https://nextui.org/docs/components/autocomplete#usage
click "select an animal"
menu opens, now you can type

Screenshots or Videos
https://github.com/nextui-org/nextui/assets/327717/8c3bbac0-b08e-4e42-aa21-d3fa3395e92d
Operating System Version
macos
Browser
Chrome

"When the menuTrigger is set to input, the focus behavior becomes worse. Here's how the flow works:

The user clicks on the input field.

The user types one character.

The menu opens and the focus is lost.

The user needs to click on the input field again to continue typing.

This can be very confusing for users as they may continue to type without realizing that the menu has opened and the focus has been lost, resulting in the words not being typed.

Has anyone come up with a solution for this, its still reproducing on my end. The input looses focus as soon as the menu opens up.

@shoaibarif668 I'll wrap up the fix by today and will be released afterwards.

@wingkwong Hi, friend. any news on this? I have the same problem :(

@wingkwong Hi, friend. any news on this? I have the same problem :(

It's already fixed, it will merge
https://github.com/nextui-org/nextui/pull/2854

I am still seeing this issue using a brand new project with
npx nextui-cli@latest init nextuitest

@kevinvincent I couldn't reproduce the issue.
autocomplete-focus-demo.webm

Had to upload the video as a zip due to size:
bug.mov.zip
This is from a completely new project with npx nextui-cli@latest init nextuitest using defaults.

Hmm this seems to have magically fixed itself? Maybe this was some weird local next js / browser caching or something?

@NikitaDen please provide a minimal reproducible example.

@wingkwong Basically copied example from the docs for Autocomplete component.
Project created via CLI using Vite. Autocomplete has been installed via npx nextui-cli@latest add autocomplete
App.tsx file:
import {Autocomplete, AutocompleteItem} from "@nextui-org/react";

const animals = [
  {label: "Cat", value: "cat", description: "The second most popular pet in the world"},
  {label: "Dog", value: "dog", description: "The most popular pet in the world"},
  {label: "Elephant", value: "elephant", description: "The largest land animal"},
  {label: "Lion", value: "lion", description: "The king of the jungle"},
  {label: "Tiger", value: "tiger", description: "The largest cat species"},
  {label: "Giraffe", value: "giraffe", description: "The tallest land animal"},
  {label: "Penguin", value: "penguin", description: "A group of aquatic flightless birds"},
  {label: "Zebra", value: "zebra", description: "A several species of African equids"}
];

export default function App() {
  return (
    <div className="flex w-full flex-wrap md:flex-nowrap gap-4">
      <Autocomplete
        label="Select an animal"
        className="max-w-xs"
      >
        {animals.map((animal) => (
          <AutocompleteItem key={animal.value} value={animal.value}>
            {animal.label}
          </AutocompleteItem>
        ))}
      </Autocomplete>
      <Autocomplete
        label="Favorite Animal"
        placeholder="Search an animal"
        className="max-w-xs"
        defaultItems={animals}
      >
        {(item) => <AutocompleteItem key={item.value}>{item.label}</AutocompleteItem>}
      </Autocomplete>
    </div>
  );
}

main.tsx file:
import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App.tsx'
import {NextUIProvider} from '@nextui-org/react'
import './index.css'

ReactDOM.createRoot(document.getElementById('root')!).render(
  <React.StrictMode>
    <NextUIProvider>
      <App />
    </NextUIProvider>
  </React.StrictMode>,
)

This is a great component, and I can't wait until it's improved with the above fix in production. I'm unfortunately still getting this issue when intermixing dynamic data with the menu. If I could, I'd just set the menu to always be open - so I am now considering using a Input + Listbox since this is odd behaviour.
I'm still getting this bug on "@nextui-org/react": "^2.3.6", using NextJS 14.0.3. Using a similar approach with rendering items, and mine is stuck behind a modal which could be contributing.
Switching to "manual" works on first click to get focus. "Focus" exhibits the same properties. "Input" with custom input causes the ability to only type 1 letter at a time.
Using allowsCustomValue**

I've just had a go modifying my code a few ways around, and it seems to remove this behaviour when I stop using dynamic data, and place in [] into items, or and render using the anonymous function method. When adding items, this behaviour shows up.
Removing allowsCustomValue does not fix this issue on my side when using items.
Removing managed input value does not help either.
Just wanted to add.

Same for me keeps happening with dynamic items, you have to click the input twice to get it to focus

I'm using this as a temporary hack until the next release.
  useEffect(() => {
    window.document
      .querySelectorAll('[aria-autocomplete]')[0]
      .closest('[data-slot="base"]')
      .addEventListener('click', e => {
        (e.currentTarget as Element).querySelector('input').focus();
      });
  }, []);

I have the same problem, nothing fixed it exept the temporary hack of BW-Blake.
In typescript it has to look like this:
// WORKAROUND UNTIL NEXTUI UPDATE
    React.useEffect(() => {
        const autocompleteElements = document.querySelectorAll('[aria-autocomplete]');
        autocompleteElements.forEach(element => {
            element.closest('[data-slot="base"]')?.addEventListener('click', e => {
                (e.currentTarget as Element).querySelector('input')?.focus();
            });
        });
    }, []);

I had the same problem.
I fixed it using this snippet:
 const handleClose = () => {
    if (document.activeElement instanceof HTMLElement) {
      document.activeElement.blur();
    }
  };

  <Autocomplete
            aria-label="test-type"
            inputValue={newFilterSearch?.testtype}
            value={newFilterSearch?.testtype}
            onSelectionChange={(e) => {
              setNewFilterSearch({
                ...newFilterSearch,
                testtype: (e as any) || "All",
              });
              handleClose();
            }}
            onClose={handleClose}
            size="lg"
            fullWidth
            allowsCustomValue
            isClearable={false}
            placeholder={t("SEARCHBAR.PLACEHOLDER")}
            items={types}
            radius="none"
          >
            {(item: any) => (
              <AutocompleteItem key={item.value}>{item.label}</AutocompleteItem>
            )}
          </Autocomplete>


Call to undefined method Intervention/Image/ImageManager::load()

composer require spatie/image

php -i | grep "EXIF Support"
EXIF Support => enabled

>>> Image::load('https://dummyimage.com/300')
PHP Error:  Call to undefined method Intervention/Image/ImageManager::load() in /.../vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php on line 261

Our tests prove that the package is working correctly: https://github.com/spatie/image/actions/runs/372366866
The error must be caused by something specific to your setup.

It happens with a fresh Laravel 8 install.
I don't see load as a method in the ImageManager documentation. It does mention make is to be used to read an image.
This works (in Tinker): when using make to load an image.
$manager = new Intervention\Image\ImageManager(array('driver' => 'imagick'));
$image = Image::make('https://dummyimage.com/300')
$image->width() // 300

composer require spatie/image
...
  - Installing intervention/image (2.5.1): Extracting archive
...

Please submit a PR with a failing test for me to fix.

afraid that's beyond my skillset... 😉

Seems it was a namespace issue, it was using the Intervention\Image class instead of Spatie\Image.
Spatie\Image\Image::load('https://dummyimage.com/300')->getHeight() // 300


'onStart' failed 'JSONDecodeError':'Expecting value: line 1 column 1 (char 0)'

Hello,
Trying to control a Shelly TRV through Domoticz but I am having some challanges with this shelly cloud plugin.
Have it installed succesfully i think using git clone.
when adding the plugin under hardware, i get this error in the log when Domoticz restarts:
`2022-10-02 11:56:50.269  Shelly TRV: Worker thread started.
2022-10-02 11:56:50.269  Status: Shelly TRV: Started.
2022-10-02 11:56:50.269  Status: Shelly TRV: Entering work loop.
2022-10-02 11:56:50.471  Status: Shelly TRV: Initialized version 1.0.1, author 'Mario Peters'
2022-10-02 11:56:50.472  Shelly TRV: onStart called
2022-10-02 11:56:50.945  Error: Shelly TRV: 'onStart' failed 'JSONDecodeError':'Expecting value: line 1 column 1 (char 0)'.
2022-10-02 11:56:50.946  Error: Shelly TRV: Exception traceback:
2022-10-02 11:56:50.946  Error: Shelly TRV:  ----> Line 336 in '/home/john/domoticz/plugins/ShellyCloudPlugin/plugin.py'
2022-10-02 11:56:50.946  Error: Shelly TRV:  ----> Line 134 in '/home/john/domoticz/plugins/ShellyCloudPlugin/plugin.py'
2022-10-02 11:56:50.946  Error: Shelly TRV:  ----> Line 357 in '/usr/lib/python3.8/json/init.py'
2022-10-02 11:56:50.946  Error: Shelly TRV:  ----> Line 337 in '/usr/lib/python3.8/json/decoder.py'
2022-10-02 11:56:50.946  Error: Shelly TRV:  ----> Line 355 in '/usr/lib/python3.8/json/decoder.py''
I am using Version 2022.1 (January 31 2022) of Domoticz on Ubuntu 20.04.5 LTS
And pip 22.2.2 from /home/john/.local/lib/python3.8/site-packages/pip (python 3.8)
output from settings:
{ "device":{"type":"SHTRV-01","mac":"588E81A61671","hostname":"shellytrv-588E81A61671","num_outputs":0},"wifi_ap":{"enabled":false,"ssid":"shellytrv-588E81A61671"},"wifi_sta":{"enabled":true,"ssid":"vuurwerk4U","ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"mqtt":{"enable":false,"server":"<IP_ADDRESS>:1883","user":null,"id":"shellytrv-588E81A61671","clean_session":true,"max_qos":0,"retain":false,"update_period":60},"sntp":{"server":"time.google.com","enabled":true},"login":{"enabled":false,"unprotected":false,"username":"admin","default_username":"admin"},"pin_code":"","name":"TRV","fw":"20220811-152343/v2.1.8@5afc928c","discoverable":false,"build_info":{"build_id":"20220811-152343/v2.1.8@5afc928c","build_timestamp":"2022-08-11T15:23:43Z","build_version":"2022081115"},"cloud":{"enabled":true},"coiot":{"enabled":false,"update_period":3600,"peer":""},"timezone":"Europe/Amsterdam","lat":52.394241,"lng":4.846680,"tzautodetect":true,"tz_utc_offset":7200,"tz_dst":false,"tz_dst_auto":true,"time":"21:18","child_lock":false,"clog_prevention":false,"display":{"brightness":7,"flipped":true},"hwinfo":{"hw_revision":"dev-prototype","batch_id":0},"sleep_mode":{"period":60,"unit":"m"},"thermostats":[{"target_t":{"enabled":true,"value":18.0,"value_op":8.0,"units":"C","accelerated_heating":true},"schedule":true,"schedule_profile":1,"schedule_profile_names":["Badkamer","Livingroom 1","Bedroom","Bedroom 1","Holiday"],"schedule_rules":["0600-0123456-23","0930-0123456-18"],"temperature_offset":0.0,"ext_t":{"enabled":false, "floor_heating": false},"t_auto":{"enabled":true},"boost_minutes":30,"valve_min_percent":0.00,"force_close":false,"calibration_correction":true,"extra_pressure":false,"open_window_report":true}] }

Hmm, could you tell me if the TRV-device is in some sort of sleep modus?


[doc] Aggregate - pairing_mul_n

Looking into aggregate.c it's clear what blst_pairing_aggregate_pk_in_g1 is for but blst_pairing_mul_n_aggregate_pk_in_g1 is not documented.
https://github.com/supranational/blst/blob/6d6dec39078e94ef9743a0ac842650a5cd160df5/src/aggregate.c#L7-L34
It seems like it's computing λ0 e(PK0, H(msg0)) λ1 e(PK1, H(msg1)) ...  with λi != 1

@mratsim I bet this is exactly what you've described. I think will check this shortly.
But, yep, would be nice to have some more docs

Yes, the subroutines in question facilitate multiple aggregated signature verifiction. Its usage pattern is not finalized, because straightforward/naive one is not optimal. In other words it will change.
As for documentation in more general sense. Does reference to commentary mean that you'd view it as adequate? I mean outlining the usage pattern. Next question would be what would you think if usage pattern was expressed in form of python script? Would it be valuable?

@nano-o >because straightforward/naive one is not optimal
Could it cause the issue #66 ?

As for documentation in more general sense. Does reference to commentary mean that you'd view it as adequate? I mean outlining the usage pattern. Next question would be what would you think if usage pattern was expressed in form of python script? Would it be valuable?

Sorry I missed your question. For me it's adequate but I know both the low-level details and what I want to achieve.
I assume going forward people would like more handholding and are more familiar with something like a gitbook (https://docs.gitbook.com/).
For starters, a couple of Python scripts would likely be helpful indeed or maybe a tutorial folder with:

01 - How to generate a keypair
02 - How to sign a message
03 - How to verify a message
04 - How to have multiple keys sign the same message and produce a "fast aggregated" signature
05 - How to verify a "fast aggregated" signature
06 - How to batch verify n signatures on n messages

And each folder would have your support languages: C, Go, Rust, Python as demo.
This would be similar to what Halide does with its lessons:

https://github.com/halide/Halide/tree/master/tutorial
https://halide-lang.org/docs/tutorial_2lesson_01_basics_8cpp-example.html


Upgrade object-path dependency to v0.11.5+

Please upgrade the object-path dependency to v0.11.5+ to resolve the vulnerability described here.

Why has this been closed?


Remove application/child task registration API requirements

Is your feature request related to a problem? Please describe.
APIs were removed in #1250, registration handled by ES and no longer requires API.
cES1300 and
Describe the solution you'd like
Remove associated requirements, cES1300 - ES: Register Application and cES1313 - ES: Register Child Task
Describe alternatives you've considered
None
Additional context
#1250, #1215
Requester Info
Jacob Hageman - NASA/GSFC

Closed by #1701 and #1720


Horizontal Ruler Helper - Outlook compatible

Created another useful helper that I'm sharing the community here. This is a nice way to add a horizontal ruler to your email template. Create file named "ruler.js" and place it in your helper folder.
Paste this code in the ruler.js file you created.
module.exports = function(options) {

	var color = options.hash.color;
	var spacing = options.hash.spacing;
	var height = options.hash.height;
	var width = options.hash.width;
	var widthType = '';
	var trimWidth = width.replace(/\D/g,'');
	var spacer = '';

	if (typeof color === 'undefined') color = '';
	if (typeof height === 'undefined') height = '';
	if (typeof width === 'undefined') width = '';

	if(width.match('%$')) {
		widthType = width = trimWidth+'%';
	} else if (width.match('px$')) {
		widthType = trimWidth+'px';
		width = trimWidth;
	} else {
		widthType = 'auto';
		width = trimWidth;
	}

	if (typeof spacing === 'undefined') {
		spacer = '';
	} else {
		spacer = '

';
	};

	var ruler = '
\
		'+spacer+'\

\
			\

\
		'+spacer+'\

';

	return ruler;
}

Then all you need to do is use this handlebar:
{{{ruler color="#009F8C" width="60" height="3" spacing="20"}}}
Spacing is above and below the ruler. You can leave it blank if you do not wish to have spacing before and after the ruler.
Here is an example of one of the templates I'm working on so you can see how it looks. Basically, it's the little rulers between the headline and sub headline text.
Hope you all enjoy and let me know if you have better solution as well because I really suck at javascript and coding in general :)

This is cool! Can you do a PR for this?

@DerekBess This is a great add. Definitely put in a PR for this.

@canterberrie @davehoran thanks, still got a few little tweaks to make. How do you do a PR?

https://akrabat.com/the-beginners-guide-to-contributing-to-a-github-project/
@DerekBass

@IamManchanda thank you for that. I'll mess around with it this week.

@canterberrie @davehoran @IamManchanda I just added the pull request. Hopefully I did it right but looks like I had to do it on the foundation-emails-template repository.
https://github.com/zurb/foundation-emails-template/pull/40

DerekBess commented 4 hours ago

@IamManchanda thank you for that. I'll mess around with it this week.

DerekBess commented 2 hours ago

@IamManchanda I just added the pull request.

That's interesting, so your 1 week was just 2 hours short :smiling_imp:

@IamManchanda lol, thanks. I'm still trying to get the hang of how the flow works with the requests.

Really cool @DerekBess - however just curious, why not use inky?
<spacer size="3" class="orange width-short"></spacer>
And then style the spacer so width isn't 100% and  background-color is what you desire. Didn't review the pull request, but I'd think it would be ideal to patch the inky syntax with new attributes you're suggesting (color, width, spacing). I also never liked "size" as an attribute for <spacer>, I mistakenly type "height" a lot.

@stevesmename I'll test out spacer tag this weekend when I get some free time. I believe the issue is going to be the spacer tag will not be as flexible as the helper I created when it comes to outlook. I tried to make it as email client friendly as possible which means sacrificing additional markup for optimization but that's the way the cookie crumbles with MSO :(

@DerekBess I used the helper tag for a campaign I put together yesterday. Worked great. Thanks again for the code!
@stevesmename I used to use a styled spacer element for this, then switched to a modified  tag. That said, @DerekBess solution is much smoother.

@davehoran sweet! Glad to hear someone has actually used it other then myself. I have used it in three separate client projects and I have yet to come across any type of styling issues as of yet. We could consolidate the markup if it weren't for pesky mso!

Works great, but it isn't centered in Yahoo! webmail. The line gets justified to the left.

@elliottregan Thanks for the taking the time to test my helper. I'll be honest, I haven't had a whole lot of time to get back to this as I'm working on a project at the moment. I'll get back to this soon though and I'll test this with Email on Acid to see what needs to happen. I'll investigate how we can get the ruler to align properly on Yahoo mail client. If you have any suggestions, fixes or workarounds to make this happen, please let me know so I can modify the helper to improve client support.
Thanks again and take care!

Confirmed. It seems to work fine with IE on Yahoo webmail, but not Chrome or Firefox.

I'm working on another email project right now so I'll investigate this issue and see what needs to be done to correct it.


DRILL-5987: Use one version of javassist

There were two different versions of javassist being pulled in by msgpack and reflections. This makes sure only one version is included.

@arina-ielchiieva

+1, LGTM.


[Bug][broker] Occur so many ERROR log in broker, which is confusing

Search before asking

[X] I searched in the issues and found nothing similar.

Read release policy

[X] I understand that unsupported versions don't get bug fixes. I will attempt to reproduce the issue on a supported version of Pulsar client and Pulsar broker.

Version
master
Minimal reproduce step
can implement a simple unittest in ReaderTest.class to reproduce ERROR log
@Test
    private void testRead() throws Exception {
        cleanup();
        conf.setDispatcherReadFailureBackoffInitialTimeInMs(1000);
        setup();

        String topic = "persistent://my-property/my-ns/my-reader-topic";
        boolean enableBatch = false;

        int numKeys = 10;

        Set<String> keys = publishMessages(topic, numKeys, enableBatch);
        Reader<byte[]> reader = pulsarClient.newReader()
                .topic(topic)
                .startMessageId(MessageId.earliest)
                .readerName(subscription)
                .create();

        while (reader.hasMessageAvailable()) {
            Message<byte[]> message = reader.readNext();
            Assert.assertTrue(keys.remove(message.getKey()));
        }
        reader.close();

        Thread.sleep(2000);
    }

What did you expect to see?
should not log this confusing error, since everything is OK.
What did you see instead?
In order to fix NonDurableImpl OOM problem, this pr https://github.com/apache/pulsar/pull/22454, and several previous pr make some modification.
This is the following modification.
https://github.com/apache/pulsar/blob/7c0e82739215fbae9e21270d4c70c9a52dd3e403/managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedCursorImpl.java#L992-L1002
The error log Root reason is:
If reader readNext and then close,  it would enter checkForNewEntries() with 10ms delay. During this time, nonDurableCursor's state change to closed. So after 10ms delay, it would throw CursorAlreadyClosedException in checkForNewEntries().  And PersistentDispatcherSingleActiveConsumer would log Error reading entries at 5:1 : Cursor was already closed - Retrying to read in 1.0 seconds and then log Skipping read retry: Current Consumer null, havePendingRead false
It seems once nonDurableCursor is closed. There is no need to log the error, and no need to schedule readEntry again. Besides, we should also consider that if cursor is durable, should it schedule readEntry again?
Now the code in readEntry looks still have some unreasonable area.
This is the log when reproducing, including a  confusing ERROR log.
2024-07-11T16:44:31,915+0800 [pulsar-io-75-4] INFO  org.apache.pulsar.broker.service.ServerCnx - [/<IP_ADDRESS>:61363] Created subscription on topic persistent://my-property/my-ns/my-reader-topic / reader-2b31818c8d
2024-07-11T16:44:31,915+0800 [pulsar-client-io-102-4] INFO  org.apache.pulsar.client.impl.ConsumerImpl - [persistent://my-property/my-ns/my-reader-topic][reader-2b31818c8d] Subscribed to topic on localhost/<IP_ADDRESS>:61358 -- consumer: 0
2024-07-11T16:44:31,916+0800 [broker-topic-workers-OrderedExecutor-7-0] DEBUG org.apache.pulsar.broker.service.persistent.PersistentDispatcherSingleActiveConsumer - [persistent://my-property/my-ns/my-reader-topic / reader-2b31818c8d-Consumer{subscription=PersistentSubscription{topic=persistent://my-property/my-ns/my-reader-topic, name=reader-2b31818c8d}, consumerId=0, consumerName=reader-sub, address=[id: 0x80218327, L:/<IP_ADDRESS>:61358 - R:/<IP_ADDRESS>:61363] [SR:<IP_ADDRESS>, state:Connected]}] Trigger new read after receiving flow control message
2024-07-11T16:44:31,916+0800 [broker-topic-workers-OrderedExecutor-7-0] DEBUG org.apache.pulsar.broker.service.persistent.PersistentDispatcherSingleActiveConsumer - [persistent://my-property/my-ns/my-reader-topic / reader-2b31818c8d-Consumer{subscription=PersistentSubscription{topic=persistent://my-property/my-ns/my-reader-topic, name=reader-2b31818c8d}, consumerId=0, consumerName=reader-sub, address=[id: 0x80218327, L:/<IP_ADDRESS>:61358 - R:/<IP_ADDRESS>:61363] [SR:<IP_ADDRESS>, state:Connected]}] Schedule read of 100 messages
2024-07-11T16:44:31,916+0800 [broker-topic-workers-OrderedExecutor-7-0] DEBUG org.apache.bookkeeper.mledger.impl.ManagedCursorImpl - [my-property/my-ns/persistent/my-reader-topic] [reader-2b31818c8d] Read entries immediately
2024-07-11T16:44:31,919+0800 [PulsarTestContext-executor-OrderedExecutor-0-0] DEBUG org.apache.bookkeeper.mledger.impl.ManagedCursorImpl - [my-property/my-ns/persistent/my-reader-topic] [reader-2b31818c8d] Filtering entries [5:0..5:0] - alreadyDeleted: []
2024-07-11T16:44:31,920+0800 [PulsarTestContext-executor-OrderedExecutor-0-0] DEBUG org.apache.bookkeeper.mledger.impl.ManagedCursorImpl - [my-property/my-ns/persistent/my-reader-topic] [reader-2b31818c8d] No filtering needed for entries [5:0..5:0]
2024-07-11T16:44:31,920+0800 [broker-topic-workers-OrderedExecutor-7-0] DEBUG org.apache.pulsar.broker.service.persistent.PersistentDispatcherSingleActiveConsumer - [persistent://my-property/my-ns/my-reader-topic / reader-2b31818c8d-Consumer{subscription=PersistentSubscription{topic=persistent://my-property/my-ns/my-reader-topic, name=reader-2b31818c8d}, consumerId=0, consumerName=reader-sub, address=[id: 0x80218327, L:/<IP_ADDRESS>:61358 - R:/<IP_ADDRESS>:61363] [SR:<IP_ADDRESS>, state:Connected]}] Got messages: 1
2024-07-11T16:44:31,926+0800 [broker-topic-workers-OrderedExecutor-7-0] DEBUG org.apache.pulsar.broker.service.persistent.PersistentDispatcherSingleActiveConsumer - [persistent://my-property/my-ns/my-reader-topic / reader-2b31818c8d-Consumer{subscription=PersistentSubscription{topic=persistent://my-property/my-ns/my-reader-topic, name=reader-2b31818c8d}, consumerId=0, consumerName=reader-sub, address=[id: 0x80218327, L:/<IP_ADDRESS>:61358 - R:/<IP_ADDRESS>:61363] [SR:<IP_ADDRESS>, state:Connected]}] Schedule read of 100 messages
2024-07-11T16:44:31,926+0800 [broker-topic-workers-OrderedExecutor-7-0] DEBUG org.apache.bookkeeper.mledger.impl.ManagedCursorImpl - [my-property/my-ns/persistent/my-reader-topic] [reader-2b31818c8d] Deferring retry of read at position 5:1
2024-07-11T16:44:31,929+0800 [pulsar-io-75-4] DEBUG org.apache.pulsar.broker.service.persistent.PersistentSubscription - [persistent://my-property/my-ns/my-reader-topic][reader-2b31818c8d] Cumulative ack on 5:0
2024-07-11T16:44:31,929+0800 [pulsar-io-75-4] DEBUG org.apache.bookkeeper.mledger.impl.ManagedCursorImpl - [my-property/my-ns/persistent/my-reader-topic] Mark delete cursor reader-2b31818c8d up to position: 5:0
2024-07-11T16:44:31,929+0800 [pulsar-io-75-4] DEBUG org.apache.bookkeeper.mledger.impl.ManagedCursorImpl - [my-property/my-ns/persistent/my-reader-topic] Moved ack position from: 5:-1 to: 5:0 -- skipped: 1
2024-07-11T16:44:31,932+0800 [pulsar-io-75-4] DEBUG org.apache.pulsar.broker.service.persistent.PersistentSubscription - [persistent://my-property/my-ns/my-reader-topic][reader-2b31818c8d] Mark deleted messages to position 5:0 from position 5:-1
2024-07-11T16:44:31,932+0800 [pulsar-io-75-4] INFO  org.apache.pulsar.broker.service.ServerCnx - [/<IP_ADDRESS>:61363] Closing consumer: consumerId=0
2024-07-11T16:44:31,933+0800 [pulsar-io-75-4] INFO  org.apache.pulsar.broker.service.AbstractDispatcherSingleActiveConsumer - Removing consumer Consumer{subscription=PersistentSubscription{topic=persistent://my-property/my-ns/my-reader-topic, name=reader-2b31818c8d}, consumerId=0, consumerName=reader-sub, address=[id: 0x80218327, L:/<IP_ADDRESS>:61358 - R:/<IP_ADDRESS>:61363] [SR:<IP_ADDRESS>, state:Connected]}
2024-07-11T16:44:31,933+0800 [pulsar-io-75-4] DEBUG org.apache.bookkeeper.mledger.impl.ManagedCursorImpl - [my-property/my-ns/persistent/my-reader-topic] [reader-2b31818c8d] Cancel pending read request
2024-07-11T16:44:31,933+0800 [pulsar-io-75-4] INFO  org.apache.pulsar.broker.service.persistent.PersistentSubscription - [persistent://my-property/my-ns/my-reader-topic][reader-2b31818c8d] Successfully closed subscription [NonDurableCursorImpl{ledger=my-property/my-ns/persistent/my-reader-topic, cursor=reader-2b31818c8d, ackPos=5:0, readPos=5:1}]
2024-07-11T16:44:31,933+0800 [pulsar-io-75-4] INFO  org.apache.pulsar.broker.service.persistent.PersistentSubscription - [persistent://my-property/my-ns/my-reader-topic][reader-2b31818c8d] Successfully closed dispatcher for reader
2024-07-11T16:44:31,933+0800 [pulsar-io-75-4] DEBUG org.apache.pulsar.broker.service.persistent.PersistentSubscription - [persistent://my-property/my-ns/my-reader-topic] [reader-2b31818c8d] [reader-sub] Removed consumer -- count: 0
2024-07-11T16:44:31,934+0800 [pulsar-io-75-4] INFO  org.apache.pulsar.broker.service.ServerCnx - [/<IP_ADDRESS>:61363] Closed consumer, consumerId=0
2024-07-11T16:44:31,934+0800 [pulsar-client-io-102-4] INFO  org.apache.pulsar.client.impl.ConsumerImpl - [persistent://my-property/my-ns/my-reader-topic] [reader-2b31818c8d] Closed consumer
2024-07-11T16:44:31,935+0800 [pulsar-74-1] DEBUG org.apache.bookkeeper.mledger.impl.ManagedCursorImpl - [my-property/my-ns/persistent/my-reader-topic] Consumer reader-2b31818c8d cursor ml-entries: 1 -- deleted-counter: 1 other counters: mdPos 5:0 rdPos 5:1
2024-07-11T16:44:31,938+0800 [bookkeeper-ml-scheduler-OrderedScheduler-1-0] DEBUG org.apache.bookkeeper.mledger.impl.ManagedCursorImpl - [my-property/my-ns/persistent/my-reader-topic] [reader-2b31818c8d] Re-trying the read at position null
2024-07-11T16:44:31,938+0800 [broker-topic-workers-OrderedExecutor-7-0] ERROR org.apache.pulsar.broker.service.persistent.PersistentDispatcherSingleActiveConsumer - [persistent://my-property/my-ns/my-reader-topic / reader-2b31818c8d-Consumer{subscription=PersistentSubscription{topic=persistent://my-property/my-ns/my-reader-topic, name=reader-2b31818c8d}, consumerId=0, consumerName=reader-sub, address=[id: 0x80218327, L:/<IP_ADDRESS>:61358 - R:/<IP_ADDRESS>:61363] [SR:<IP_ADDRESS>, state:Connected]}] Error reading entries at 5:1 : Cursor was already closed - Retrying to read in 1.0 seconds
2024-07-11T16:44:32,945+0800 [broker-topic-workers-OrderedExecutor-7-0] INFO  org.apache.pulsar.broker.service.persistent.PersistentDispatcherSingleActiveConsumer - [persistent://my-property/my-ns/my-reader-topic / reader-2b31818c8d-Consumer{subscription=PersistentSubscription{topic=persistent://my-property/my-ns/my-reader-topic, name=reader-2b31818c8d}, consumerId=0, consumerName=reader-sub, address=[id: 0x80218327, L:/<IP_ADDRESS>:61358 - R:/<IP_ADDRESS>:61363] [SR:<IP_ADDRESS>, state:Connected]}] Skipping read retry: Current Consumer null, havePendingRead false

Anything else?
No response
Are you willing to submit a PR?

[X] I'm willing to submit a PR!

@Technoboy- @codelipenghui @lhotari Can you take a look of this issue

close the issue because of https://github.com/apache/pulsar/pull/22751 merged


feat: add Parallel Tool mode for Vertex AI

This PR intends to add parallel tool mode for Vertex AI.
That is done by adding new mode VERTEXAI_PARALLEL_TOOLS.

[!IMPORTANT]
Adds VERTEXAI_PARALLEL_TOOLS mode for parallel tool processing in Vertex AI, with updates to model handling and response processing.

Behavior:

Adds VERTEXAI_PARALLEL_TOOLS mode in mode.py.
Updates from_vertexai() in client_vertexai.py to support the new mode.
Implements handle_vertexai_parallel_tools() in process_response.py to process responses in parallel.

Models:

Introduces VertexAIParallelBase in parallel.py for handling parallel responses.
Adds VertexAIParallelModel() in parallel.py to create instances of VertexAIParallelBase.

Functions:

Modifies _create_vertexai_tool() in client_vertexai.py to handle multiple models.
Updates vertexai_process_response() in client_vertexai.py to support parallel tools.

Misc:

Adds type checks in _create_gemini_json_schema() in client_vertexai.py.

This description was created by  for c5826180aa3a1282511f70aa5ab70a84c13abe64. It will automatically update as commits are pushed.

Verified that all vertex tests are passing locally and updated the docs
tests/llm/test_vertexai/test_format.py ....                                                                                [ 14%]
tests/llm/test_vertexai/test_message_parser.py ....                                                                                [ 28%]
tests/llm/test_vertexai/test_modes.py ......                                                                                [ 50%]
tests/llm/test_vertexai/test_retries.py ....                                                                                [ 64%]
tests/llm/test_vertexai/test_simple_types.py ......                                                                                [ 85%]
tests/llm/test_vertexai/test_stream.py ....                                                                                [100%]


/apps/whale-api - Indexer Performance Improvement

As part of #580 consolidation efforts.
https://github.com/DeFiCh/whale

What would you like to be added:
While DeFiCh/whale project is heading into maintenance, it will still be a key part of the infrastructure for active deployment. We need to optimize the indexer performance and the size of the snapshot.
/sig ecosystem
/area apps
/triage accepted

For Implementation post #977 migration

/assign @fuxingloh

/assign @monstrobishi to help out with this task, low priority as of now


Will it support 4.6.5 relase and installation instruction please ?

Hi all, will it support the older release ?
Can you guys provide the installation instructions also please ?

@caarlos0 @amalucelli @kungwangtotvs @ffjacob

Will it support 4.6.5

no.

Can you guys provide the installation instructions also please ?
just download the release and run it with --help... let me know if you have more questions...

@caarlos0 Thanks a lot for answering .
is there any specific reason it wont support version lower than 5 ?

yes, we don't use it, therefore won't test it nor spend time implementing it.

@caarlos0 fair enough , i have one old 4.6.5 running , i will test it and keep you guys posted..
Nice work 👍

ok, thanks!
will close this issue for now :)


[Event Request] table 39 "Purchase Line" OnAfterUpdateDimensionsFromJobTask

Describe the request
Can you add a event at the end of procedure UpdateDimensionsFromJobTask with Rec as reference.
Additional context
To be able to update additional custom shortcut dimension fields
Internal work item: AB#538387

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 20959.


Removed unnecessary spaces from the code

Sign-off-by: Patrick Hession<EMAIL_ADDRESS>Describe your changes in brief
Changes

Removed extra spaces that prevented an easy copy/paste for the user

View rendered doc/ProvisionReleaseBuild.md

Please close #919 . That is obsoleted by this one?


feat: Improve guide connecting machines and creating dashboards

Hi @oarne97
thanks for your input so far.
Akuell still further remarks:

I would make it clearer that step 3.1 and 3.2 are the same for all Sebsonren and then different for everything that reads not so good.
Add a disclaimer (best under the button bar) that the system must still be added analogous to our data model layers.

@Scarjit

@kruegeralex


Should create a common services set of arm templates and scripts

Login to azure
Login to cluster
Delay ARM Template

Closed with #30


Add Steeltoe.Common.Hosting as standalone option

.UseCloudHosting isn't CF specific and should be available separately

@TimHess Suggestions for the name of such an option?  --hosting?

@ccheetham  `--cloud-hosting'?
The generic option is:

nuget ref for Steeltoe.Common.Hosting
.UseCloudHosting()

What is currently there for CF hosting might be alternatively labeled Cloud Foundry Configuration.


Issue #861 Fix slow services

This PR adds an expiry to topic services and ensures we only fetch services from the server once every 24 hours for a given topic.

@rasmus-storjohann-PG I think this is ready

Looking at it now, it dropped off my radar a bit


Adding "prefix_limit_exceeded_telemetry_unsupported: true" deviation …

…for Cisco

Pull Request Functional Test Report for #2623 / 951b0cb9e8c32f61c051cc3b5359863399c161e5
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

RT-1.5: BGP Prefix Limit

Cisco 8000E

RT-1.5: BGP Prefix Limit

Cisco XRd

RT-1.5: BGP Prefix Limit

Juniper cPTX

RT-1.5: BGP Prefix Limit

Juniper ncPTX

RT-1.5: BGP Prefix Limit

Nokia SR Linux

RT-1.5: BGP Prefix Limit

Openconfig Lemming

RT-1.5: BGP Prefix Limit

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

RT-1.5: BGP Prefix Limit

Cisco 8808

RT-1.5: BGP Prefix Limit

Juniper PTX10008

RT-1.5: BGP Prefix Limit

Nokia 7250 IXR-10e

RT-1.5: BGP Prefix Limit

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1668

Relevant Lines:
3199

💛  - Coveralls


Not supporting epub3 version

Working on this. You can keep track of the progress in https://github.com/vers-one/EpubReader/issues/18


Typo

Codecov Report
Base: 80.21% // Head: 80.21% // No change to project coverage :thumbsup:

Coverage data is based on head (817ac1a) compared to base (2c3a3a4).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #36   +/-   ##
=======================================
  Coverage   80.21%   80.21%
=======================================
  Files          10       10
  Lines        1122     1122
=======================================
  Hits          900      900
  Misses        222      222

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Thanks @KronosTheLate


feat: Support conda in debian-based custom base image

Description

Message from the maintainers:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

What do you mean by on the base mirror? Do you mean put conda in the base image?

@VoVAllen I updated the titile.

fixed in https://github.com/tensorchord/envd/pull/1228

We will share some doc about this after #https://github.com/tensorchord/envd/pull/1272


Explicitly parseFloat in formattedNumber

#741

This issue would occur when n was "0.0". JavaScript's weakly typed derpyness is bleh.

In leaflet.geometryutil.js I changed the code. Where it was distance.toFixed or distanceStr.toFixed I changed it to parseFloat(distance).toFixed(2)  or parseFloat(distanceStr).toFixed(2). Seems to have solved my issue.


NUCLEO-L496ZG-P:   no nsh access

Hi,
i'm trying to flash default configuration for the NUCLEO-L496ZG-p board but the nsh console is stuck in readline (as if i wasn't able to send any data to feed the readline throught UART). Let me go in deeper.
i'm cloning current master nuttx and apps
nuttx commit: 881902d2cdf84902863cf848fb506be1613c8ac1
apps commit: 943df4cb6039072cbc2eb66c02311b6244bd1e95
Steps:
mkdir folder_test
cd folder_test
Cloning apps & nuttx repo
cd nuttx
./tools/configure.sh -l nucleo-l496zg:nsh
make oldconfig
make

st-flash write nuttx.bin 0x8000000
sudo screen /dev/ttyACM0 115200

Results:
The board blink correctly and is booting. I'm able to GDB in but i'm stuck in nsh_main readline().
It doesn't do temporary blue blinks like the last example i'hv done on the nucleo-144:f767-nsh (this one was working ez)
i tried screen command on the STLINKv2-1 USB directly and on the UART3 as mentionned in the README. But i'm unable to access the nsh
I don't have anymore to give except that the Nucleo board i'm using is totally brand new (just few plugs / no burn i promess)
Hope anyone can help me or give me advices. I'm know very well nuttx as PX4 user but not as new app creator. It seems that i'm not able to talk to the nsh process
Thanks you !

@TregliaRaphael Why are you using commit from master? Have you tried checking out releases/10.3 branch for both nuttx.git and apps.git?
Other than that I can only recommend checking GPIO pin mappings in your board.h and Kconfig options regarding USART and console selection. I don't have any relatives of STM32L4.


xwayland: xsurface commit

Not strictly necessary (yet) but might be one day, and makes it like the other shells.

I'm not sure about this: given how xwayland works, will we ever need it? State isn't double-buffered in X11.

After all, you're right. We should have a best-effort approach even if X11 doesn't really double-buffer state.

Until this actually does something meaningful let's not.

This actually does make things a bit easier now that I think about it. The xwayland surface is ephemeral so it means the user doesn't have to unsubscribe/resubscribe to the surface events on map and unmap.

The xwayland surface is ephemeral so it means the user doesn't have to unsubscribe/resubscribe to the surface events on map and unmap.

Yes, but the compositor still needs to add and remove the view from the desktop when it's mapped and unmapped. So I don't think it adds a lot of value (apart from saving one line of code).
In the end, other shells define particular semantics for the surface commit event, but xwayland doesn't. It makes sense not to add it, at least for now.

I think the ultimate solution here is for wlr-surface to have a special function for role surfaces to set that always runs before wlr-surface commit and get rid of all the role surface commit events.

Yeah, that makes sense since a surface can only have one role.


fixconvert to double if div decimal overflow

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 46.95 seconds
stream load tsv:          541 seconds loaded<PHONE_NUMBER>9 Bytes, about 131 MB/s
stream load json:         20 seconds loaded<PHONE_NUMBER> Bytes, about 112 MB/s
stream load orc:          66 seconds loaded<PHONE_NUMBER> Bytes, about 15 MB/s
stream load parquet:          31 seconds loaded 861443392 Bytes, about 26 MB/s
insert into select:          29.4 seconds inserted 10000000 Rows, about 340K ops/s
storage size:<PHONE_NUMBER>8 Bytes

run buildall

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 45.09 seconds
stream load tsv:          553 seconds loaded<PHONE_NUMBER>9 Bytes, about 129 MB/s
stream load json:         21 seconds loaded<PHONE_NUMBER> Bytes, about 107 MB/s
stream load orc:          65 seconds loaded<PHONE_NUMBER> Bytes, about 16 MB/s
stream load parquet:          32 seconds loaded 861443392 Bytes, about 25 MB/s
insert into select:          29.1 seconds inserted 10000000 Rows, about 343K ops/s
storage size:<PHONE_NUMBER>5 Bytes

run buildall

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 46.32 seconds
stream load tsv:          539 seconds loaded<PHONE_NUMBER>9 Bytes, about 132 MB/s
stream load json:         20 seconds loaded<PHONE_NUMBER> Bytes, about 112 MB/s
stream load orc:          65 seconds loaded<PHONE_NUMBER> Bytes, about 16 MB/s
stream load parquet:          32 seconds loaded 861443392 Bytes, about 25 MB/s
insert into select:          29.2 seconds inserted 10000000 Rows, about 342K ops/s
storage size:<PHONE_NUMBER>4 Bytes

run buildall

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 44.51 seconds
stream load tsv:          554 seconds loaded<PHONE_NUMBER>9 Bytes, about 128 MB/s
stream load json:         20 seconds loaded<PHONE_NUMBER> Bytes, about 112 MB/s
stream load orc:          66 seconds loaded<PHONE_NUMBER> Bytes, about 15 MB/s
stream load parquet:          31 seconds loaded 861443392 Bytes, about 26 MB/s
insert into select:          29.2 seconds inserted 10000000 Rows, about 342K ops/s
storage size:<PHONE_NUMBER>2 Bytes


Added slides (with new images). Fixed typos in tutorial.

Added slides for FNN, with some new images. The content of slides has already been reviewed. So, I guess its just the format that needs to be approved.
Also, fixed some typos in tutorial.
Thank you!

Revisions are pushed. Thanks @anuprulez

Hi @anuprulez
Could you please merge this if it looks ok now?
Thanks!

@anuprulez is busy the next days. This looks good to me and I think is a great first version. We can adjust slides until GCC if we wish. Thanks, everyone.

Thanks @bgruening good to know so we aren't waiting!

thank you all!


Use crypto and a fork of markle for SHA3

See commits for details. Note that rust-crypto is MIT or Apache licensed.

Well, this again breaks nix build because a git dependency. Any long-term solution for this? @sjmackenzie

Kinda annoying yes, clap likes to bump regularly. We could use a more slow moving docopts if you wish?
But once dependency version churn slows then we're good. Or we could pin clap at a specific vsn and be done with it. I'll fix this issue now.

https://crates.io/crates/clap (notice the 5 hours)

Also every time we change Cargo.lock expect that there are dependencies that are available on your local ~/.cargo/* that are not available on the nixpkgs rustRegistry hence we need to bump the rust registry over at https://github.com/sjmackenzie/nixpkgs/tree/rustRegistry_bump. Just nix offers us a nice way to do all sorts of out of band testing and etc. So to me this is a minor pain to endure.

Okay this is going to be bad: -> https://github.com/ethereumproject/sputnikvm/blob/master/Cargo.toml#L26
Nix really doesn't play well with git attributes in the Cargo.toml file. I'd prefer if we didn't do it this way.
Is it possible to not use git attributes in Cargo.toml?


Fix parsing issue when colon is directly after variable

I fixed an issue I had due to the syntax that I use for variable typing. The original parsing expects @export var name : type but I typically use @export var name: type. This edit supports both variants.

Thank you, useful and pretty clean!
...but what if it's var name:type?

Good point. I'll make an adjustment and update this PR.

Oddly enough, it works just fine. I wouldn't have expect it to though. Here is the test code that I have:
# @@buttons("Button 1", _test())
@export var test: int
# @@buttons("Button 2", _test())
@export var test2 : int
# @@buttons("Button 3", _test())
@export var test3 :int
# @@buttons("Button 4", _test())
@export var test4:int
# @@buttons("Button 5", _test())
@export var test5      : int

And here is the inspector:


Text of button overflows outside the button

The text of the button is visible outside the button.
Can this be clipped that it will not be written outside the button?
Version: 1.10.1
Part of log for full name of the device:

AV Start playing on Woonkamer - Sonos Beam Media Renderer - RINCON_542A1BDAB98001400 host=<IP_ADDRESS> port=1400 from <IP_ADDRESS> using AV Play
AV Stop playing on Woonkamer - Sonos Beam Media Renderer - RINCON_542A1BDAB98001400 host=<IP_ADDRESS> port=1400

I'll have a look at it, I suppose truncating at the end is OK?

Yes, that will not be a problem

Can you check if 1.10.2 is acceptable?
I could not get fltk to clip the text from the end, and I did not test with a very long player name, so I don't really know if this is acceptable to you.


Upstream dependency conflict

When installing this plugin, I get the following dependency error:
~/dev/my-project$ npm install strapi-plugin-publisher
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/react-router-dom
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@strapi/design-system
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!     node_modules/@strapi/admin
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!       node_modules/@strapi/strapi
npm ERR!         peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!         11 more (@strapi/plugin-graphql, @strapi/plugin-seo, ...)
npm ERR!     peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!     node_modules/strapi-plugin-menus
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! strapi-plugin-publisher@"*" from the root project
npm ERR!
npm ERR! Conflicting peer dependency<EMAIL_ADDRESS>npm ERR! node_modules/react-router-dom
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/strapi-plugin-publisher
npm ERR!     strapi-plugin-publisher@"*" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

Stapi version 4.3.6. Is this my setup or is it a problem with the plugin?

Most likely on the plugin side. I will have a look, probably needs a ^ prefix on a package version somewhere.
I believe if you install with npm install with the --legacy-peer-deps it should resolve this issue.

I've forked the project to do some research on my own. I am trying to get the plugin to work from a git repo clone but no luck yet. I am fairly new to Strapi and would like to contribute, but will take some time to get comfortable in the ecosystem.
Thanks for your hard work and hope this issue can be resolved.

Here is the full conflict on my end. Seems like there is a conflict with Strapi's design system library @strapi/design-system. Would it be possible to update react-router-dom to be compatible with Strapi's version?
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/react-router-dom
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@strapi/design-system
npm ERR!     peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!     node_modules/strapi-plugin-preview-button
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Conflicting peer dependency<EMAIL_ADDRESS>npm ERR! node_modules/react-router-dom
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/strapi-plugin-publisher
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

Sorry about leaving this issue for so long, the next version should fix this. Will release it over the weekend.

nice, thanks @ComfortablyCoding!

Just released 1.1.4 with the fix


Simplification rules defined by extensions are overwritten by default set

After writing a set of Boolean algebra simplification rules, I tried to include these by following the documentation on adding extensions. An error message occurred when the additional rules were used in a question, stating that the rules were not defined.
The cause appears to be the following line which executes after extensions have been processed and resets the scope rules to the built-in set:-
exam.js/line 94:	this.scope.rulesets = Numbas.util.copyobj(Numbas.jme.display.simplificationRules);
Bypassing this line in the debugger allows the rules to work, since this.scope.rulesets already contains the built-in rules prior to this line, plus any defined in extensions.

Can you send me your extension, please?

For sure:-
booleanlogic.zip
The question I am testing with is  "Boolean jme"
https://numbas.mathcentre.ac.uk/question/share/view/36ffa251-8e7e-4ae6-b359-6d3eb0ddfdfe

Yep, looks like that line was very old and not needed - the built-in rulesets are included in Numbas.jme.builtinScope. Not sure how I managed to write that bit of the documentation without encountering this problem.

Thanks Christian, that works well now. It might be good to have a function to add extension rulesets similar to the one for functions, though I’m probably the only person who would use it at the moment.
Kind regards,
Graeme Chester
Dr. E.G. Chester, School of EEE, Newcastle University
Tel: 0191 208 7325 Email: graeme.chester<EMAIL_ADDRESS>From: Christian Lawson-Perfect<EMAIL_ADDRESS>Sent: 18 January 2016 14:29
To: numbas/Numbas<EMAIL_ADDRESS>Cc: Graeme Chester<EMAIL_ADDRESS>Subject: Re: [Numbas] Simplification rules defined by extensions are overwritten by default set (#424)
Yep, looks like that line was very old and not needed - the built-in rulesets are included in Numbas.jme.builtinScope. Not sure how I managed to write that bit of the documentation without encountering this problem.
—
Reply to this email directly or view it on GitHubhttps://github.com/numbas/Numbas/issues/424#issuecomment-172540483.

Do you mean in the editor?
If you're talking about the extension .js file, what would you like it to look like? You can assume that extension.scope.rulesets is empty at creation, and you're free to override it, so you can miss out a few of the lines of boilerplate you've got in your extension.
Your code could go:

var rulesets = {
   'basic-logic': [ ... ],
   'double-negation': [ ... ],
   ...
}

var all = [];
for(var x in rulesets) {
   extension.scope.rulesets[x] = Numbas.jme.display.compileRules(rulesets[x]);
   all.push(x);
}
extension.scope.rulesets.allboolean = Numbas.jme.display.collectRuleset(all,rulesets);

Would you like something that does compileRules on a whole dictionary, missing out that for loop?
Should the all ruleset be added to each time you extend a Scope object, so it's always guaranteed to contain every rule in the scope?

I wasn’t thinking of the editor, just the extension .js file. I’ll probably tidy up my example extension when time permits, but I was thinking it would be easier to be able to write something along the lines of
var rulesets = { … }
extension.scope.addRuleset(rulesets,{includeAll:true});
which would do compileRules for everything and add it to the scope. I’m not sure if the rules should always be added to the all ruleset, probably they should  but it could be conditional on an argument to the function. If there were a need to use all rules except the extensions at some point, it would be awkward if they are automatically added; it would be very easy however to include the list all,extension in the rulesets when inclusion is needed.
Kind regards,
Graeme Chester
Dr. E.G. Chester, School of EEE, Newcastle University
Tel: 0191 208 7325 Email: graeme.chester<EMAIL_ADDRESS>From: Christian Lawson-Perfect<EMAIL_ADDRESS>Sent: 19 January 2016 10:34
To: numbas/Numbas<EMAIL_ADDRESS>Cc: Graeme Chester<EMAIL_ADDRESS>Subject: Re: [Numbas] Simplification rules defined by extensions are overwritten by default set (#424)
Do you mean in the editor?
If you're talking about the extension .js file, what would you like it to look like? You can assume that extension.scope.rulesets is empty at creation, and you're free to override it, so you can miss out a few of the lines of boilerplate you've got in your extension.
Your code could go:
var rulesets = {
'basic-logic': [ ... ],
'double-negation': [ ... ],
...
}
var all = [];
for(var x in rulesets) {
extension.scope.rulesets[x] = Numbas.jme.display.compileRules(rulesets[x]);
all.push(x);
}
extension.scope.rulesets.allboolean = Numbas.jme.display.collectRuleset(all,rulesets);
Would you like something that does compileRules on a whole dictionary, missing out that for loop?
Should the all ruleset be added to each time you extend a Scope object, so it's always guaranteed to contain every rule in the scope?
—
Reply to this email directly or view it on GitHubhttps://github.com/numbas/Numbas/issues/424#issuecomment-172811973.


Unused variable in gpu_particles_3d_editor_plugin.cpp

Godot version:
4.0.dev.custom_build. dd5485142
Issue description:
image2 is assigned but never used anywhere
also point_img2 is unused, because result is used only in image2
https://github.com/godotengine/godot/blob/6497a3fb50802d2a56f5d6a586a66da0f887dc04/editor/plugins/gpu_particles_3d_editor_plugin.cpp#L387-L393
also image variable is not used
https://github.com/godotengine/godot/blob/6497a3fb50802d2a56f5d6a586a66da0f887dc04/editor/plugins/gpu_particles_3d_editor_plugin.cpp#L359-L364

I am newbie here. I want to contribute here . can I work on this??

I'm not sure if junior job tag is proper.
Basing on logic, this images should be used(code have 4 years, so author probably doesn't remember what exactly should this look like).
Probably code should looks that
tex.instance();
tex.create_from_image(image);

and a little lower
tex2.instance();
tex2.create_from_image(image2);

You can open PR with this fixes

@qarmin shouldn't it be
tex->create_from_image(image);

and
tex2->create_from_image(image2);

?
I'm just starting contributing here, so I'm curious what this accomplishes? If that's all that needs to be done, I can submit a PR

I don't even know when to use . or -> because QtCreator itself inserts the correct character (in this case indeed ->).
I don't know this code very well, but it seems to calculate and set the texture of the emission.
The problem is that there is an unused variable, the removal of which would create another unused variable and would make it necessary to remove most of the code from the function.
Since this function seems to make sense, the only solution will be to link the data inside through the create_from_image function.
This should be enough, so PR can be created with this changes(someone more familiar with the code should check PR soon).

To clarify, the current code does nothing due to the lack of calls to tex->create_from_image(image);. Well not nothing, but it assigns empty textures instead of the images created before.
So to fix this, there's two options:

Add the calls to tex->create_from_image(image); to actually fill the textures. But then you need to actually see where this code is used in the editor and see if those textures are actually meant to be used, or if this bug which has never worked is meant for the trash can.
Remove all the unused code as the current editor seems to work without it, so this might have been WIP that was discarded.

To decide, the best is to do the first option, use the GPUParticles3D editor plugin, see what changed and if that's good or bad.
The code was written by @reduz, but @JFonS may be able to tell if it's needed or not.

Got it. Well I can wait for @JFonS or @reduz reply. Until then I’ll continue investigating

I would say it's just missing the create_from_image calls. But tomorrow I will double-check the rest of the code does what it's meant to do.

The create_from_image calls are present in 3.2, and it looks like @reduz removed them in 3f335ce3. We should investigate whether we can just add them back or there is an alternative way to achieve the same result.

I dont think that @reduz removed that.
I saw calls to create_from_image in his PR

I dont think that @reduz removed that.
I saw calls to create_from_image in his PR

@gxhamster If you check the commit I mentioned (3f335ce), in the editor/plugins/particles_editor_plugin.cpp file, the create_from_image() calls were removed.
It's probably just a mistake in the repetitive task of updating all create_from_image() calls, but someone needs to test if adding them back breaks anything.

Closing per @and-rad's comment.


Clicking on certain components crashes the browser tab in Safari 14

Describe the bug
Whenever I click on certain MWC components in Safari, the browser tab crashes. (It reloads and a message appears at the top saying "This webpage was reloaded because a problem occured.")
I ran into this problem when working on a personal project, but I can also reproduce it on the MWC demo Glitch app.
The problem happens when I click any of the following components:

<mwc-button>
<mwc-checkbox>
<mwc-radio>
<mwc-switch> (including the disabled ones)
<mwc-tab-bar> / <mwc-tab>
<mwc-textarea>
<mwc-textfield>

It does not happen if I click on any of the following components:

<mwc-formfield> (which triggers the associated <mwc-checkbox>, <mwc-radio>, or <mwc-switch>)
<mwc-icon-button>
<mwc-icon-button-toggle>
<mwc-list> / <mwc-list-item>

To reproduce
Steps to reproduce the behavior:

Go to https://mwc-demos.glitch.me/.
Click on any of the problem components.
The browser tab crashes.

Expected behavior
The browser tab does not crash.
Screenshots
If applicable, add screenshots to help explain your problem.
Browser version

OS: macOS Catalina 10.15.7 (19H2)
Browser: Safari 14.0

Additional context
I have checked for updates for Safari and macOS and verified that I am running the latest version available of both. The issue does not happen in Chrome or Firefox. It also does not happen in mobile Safari on my iPhone 11 Pro (iOS 14.2, 18B5061e).
If you can't reproduce the issue, I'm happy to collect and provide more debugging information; I'm just not sure what exactly would be helpful. I will happily follow directions to collect whatever would be helpful to diagnose the issue.

duplicate of https://github.com/material-components/material-components-web-components/issues/1720

closing as duplicate #1720


[3pt] CatFIM missing Action, Minor, and Major stages for multiple sites (Vlab #88988)

In the REV area, at least TRRN2, VISN2, WADN2, and STWN2 are missing all but Moderate flood stage in categorical FIM.
https://vlab.ncep.noaa.gov/redmine/issues/88988

trrn2 has action, minor, moderate, and major in fim_3_0_9_0_ms_c
visn2 has action, minor, moderate, and major in fim_3_0_9_0_ms_c
wadn2 has action, minor, moderate, and major in fim_3_0_9_0_ms_c
stwn2 has action, minor, moderate, and major in fim_3_0_9_0_ms_c


Domain Model Update

Should be good to go, could do with a look over @AndresVargas4

I changed createEvent() to getMarker(), as we already have createEvent() under event planner and I wasnt sure if we can have the
"same" methods over different classes. Let me know what you think

We have the same methods in other classes and were not docked points, however I like the method you replaced it with better @AndresVargas4 closing this issue


Add integration tests [WIP]

While not particularly extensive, this PR adds the first addr2line integration test. It compares the output of the system addr2line program with that of the library, and makes sure that whenever we give affirmative answers, our answers match that of the original addr2line. It also demonstrates how to write integration tests in a reasonably straightforward manner that also work on Travis, and actually exercises a surprising fraction of the code
Note that the tests currently fail on macOS, apparently because the debug_info section is missing from the compiled binary. Neither forcing clang nor -gdwarf-4 made a difference. Given that I don't have a macOS computer to test on, I'd appreciate it if someone who does could try to reproduce by running the tests locally.

Don't have time to read the code right now, cause I'm about to go to bed, but

Note that the tests currently fail on macOS, apparently because the debug_info section is missing from the compiled binary. Neither forcing clang nor -gdwarf-4 made a difference. Given that I don't have a macOS computer to test on, I'd appreciate it if someone who does could try to reproduce by running the tests locally.

On mac os, the debug info ends up split form the executable, so if you had path/to/executable, the debug info is going to be in something like path/to/executable.dSYM/Contents/Resources/DWARF/executable. Maybe a little different, that's from memory and I'm in Fedora right now.
Will check this out in more detail tomorrow -- thanks for doing this!

Coverage increased (+1.9%) to 2.881% when pulling bf434978b8876eda98cf0ac6fae00b2507b7e91b on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

Coverage increased (+1.9%) to 2.869% when pulling ef71e9e5d279a8af85f7ff8584158a4d158a3d9e on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

Coverage increased (+1.9%) to 2.857% when pulling 80cc0bec042b0075f4a40f3066af3a4763cd3482 on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

Coverage increased (+1.9%) to 2.869% when pulling 0fe9160d0d3f6653186f1027a1f693a123f8bd61 on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

@fitzgen no such luck with the path modification unfortunately. I'm heading to bed too. It'd be great if you could take a look when you get a chance. Whatever we find to be the solution we'll probably also want to include in the main addr2line command line tool. Come to think of it, we may also need to modify the tests on macOS to use atos instead of addr2line, which will require some changes.

Coverage increased (+1.9%) to 2.857% when pulling 6bdec721992fb4ec8a023009f06a23470f51e3b3 on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

Coverage increased (+74.9%) to 75.934% when pulling c97293ae4086402436e1bce9b2e904c78d2877ea on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

Coverage increased (+74.9%) to 75.934% when pulling 66e2c9435542e2425cbe114f45a17c781b1bf141 on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

Coverage increased (+75.4%) to 76.423% when pulling 045fa32496524fb3cdb2f76aeff3bccd65917c3e on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

Coverage increased (+75.4%) to 76.423% when pulling d7f468107831721c4ab81bbea0f324feb6cd6fc2 on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

Coverage increased (+75.8%) to 76.8% when pulling 56a6f8876b2e95a850e9547821b52832845d2c5a on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

@fitzgen finally figured it all out -- phew, that was a pain without a macOS computer to debug on! See inline code comments + commit message for details. Feel free to delete all the leftover coveralls comments (except, obviously, the last one). I've squashed all the debug commits I made, and the commit should now be ready for review.

Seems I spoke too soon -- macOS passes on stable, but beta and nightly both have an off-by-one on the line number... No idea what the best thing to do here is.

Also, for some reason, the kcov step on linux-nightly now times out (even though it didn't in earlier instantiations of the tests). Do you have any experience with this @fitzgen?

Also, for some reason, the kcov step on linux-nightly now times out (even though it didn't in earlier instantiations of the tests). Do you have any experience with this @fitzgen?

Interesting. I think @philipc knows a little bit more about kcov things than I do -- I've just been copying his coverage helper script around to new repos :P

Fixed that by skipping every fifth address output by nm (and thus significantly reducing test runtime).

Seems I spoke too soon -- macOS passes on stable, but beta and nightly both have an off-by-one on the line number... No idea what the best thing to do here is.

I think we can take an incremental approach, where we skip the tests on OSX and just ensure it builds, and try to fix the tests in follow ups.

Coverage increased (+76.05%) to 77.043% when pulling 74d66bc4277548b9a5e246ae583075e2ed77ffb8 on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

Coverage increased (+76.05%) to 77.043% when pulling 439be77cd7d1ee420b8ab13027669230b90e822a on jonhoo:integration-tests into 90038ab6b548573530ab06bdc645e70649146280 on gimli-rs:master.

@fitzgen done. ready for review.

Oh, also: could you squash the commits together? Thanks!

@fitzgen done and done.

Coverage increased (+77.0%) to 77.978% when pulling fa652a24d7b041f4b786f53e66955fd79b70402d on jonhoo:integration-tests into 2ce346721a322627f513f40d7f5d2bb9ef7bf48a on gimli-rs:master.


HCX-806 : Javascript HCX Integrator SDK - Enhance SDK to integrate the user's API access token generation

@KrutikaPhirangi - Update the documentation based on the new changes.
https://github.com/Swasth-Digital-Health-Foundation/integration-sdks/tree/main/javascript#readme


Cronjob monitoring

I wonder if cronjob/queue monitoring could be useful, as per
https://docs.sentry.io/platforms/php/crons/

Refs: https://github.com/LordSimal/cakephp-scheduler/issues/4

Sentry is initialized in https://github.com/LordSimal/cakephp-sentry/blob/3.x/src/CakeSentryInit.php#L43
which is called while bootstrapping the plugin https://github.com/LordSimal/cakephp-sentry/blob/3.x/config/bootstrap.php#L14
so in the end all a user has to do is call the namespaced functions from the PHP SDK and it should be fine.

We could add a Command.beforeExecute and Command.afterExecte event to the CommandRunner to at least capture the check-ins for before the command is started and after it has finished.
The heartbeat must be implemented by each command though I guess.


固定錯誤回傳值

共成功的結果提掉，失敗的攏改做錯誤
#32

Coverage remained the same at 96.933% when pulling 2011a9f11bbf881d419877ad934ee0bfd92f52f0 on 固定錯誤回傳值 into bdb7ff1670e5928051abd73bfe9e84a4af188d33 on master.

Coverage decreased (-0.06%) to 96.87% when pulling 2011a9f11bbf881d419877ad934ee0bfd92f52f0 on 固定錯誤回傳值 into bdb7ff1670e5928051abd73bfe9e84a4af188d33 on master.


No fixed versions for EF Core references

Hi,
I had an issue that prevented me to upgrade my application to EF Core 3.1.11 and in the package references I noticed that EFCoreSecondLevelCacheInterceptor was using version 3.1.10.
That is why changed the Versions of referenced assemblies to a version range, so they are more free.
Regards,
Jochen

Thanks.

Thanks.


Create WebSocket with null paramter make the app crash immediately RN 0.28-0.31 IOS

Pass null to create WebSocket is wrong, but the app crash immediately, without any error log.
let sockAddress = null;
new WebSocket(sockAddress);

@facebook-github-bot label Icebox

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/create-websocket-with-null-paramter-make-the-app-crash-immediately-rn-028-031-ios
ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub.
Also, if this issue is a bug, please consider sending a PR with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.

@facebook-github-bot close


Make remote start go away from HomeKit

Since the latest version I have a remote start button in HomeKit. I have never added it, I only use the climate control. I guess this is somehow linked though.
I specifically checked and the button is not enabled in the HomeKit configuration. I even enabled/disabled it with no luck.

You need to filter it via HA or Homekit.

Yes, but I am filtering it by not selecting the switch "remote start", yet it still appears in HomeKit.

I'm not sure what you think we can do here to solve that bug.

Just disable the entity in Tesla if it bothers you.

If I disable it, it still shows up in HomeKit. Just shown as not responding.
I removed the climate controls and it also removed the remote start. After adding the climate again remote start didn't show up again.
Seems fixed. Not sure where the bug originated.
Thanks for your help.


Rename .browserslintrc.txt to .browserslistrc

.browserslitrc.txt is not recognized by browserslist. The correct file name is .browserslistrc.
https://github.com/browserslist/browserslist#queries

.browserslistrc config file in current or parent directories.

Thank you for reviewing and merging.


Autoscaling group will not scale down to 0 instances when idle count is set to 0

I've recently integrated a self-hosted runner on AWS, but despite many permutations of settings, the manager will always keep at least 1 instance on standby and sometimes create many runners without terminating them despite extending far beyond the idle time
This is the same issue described here
It appears this was a known issue for v17.0.0 which they claim is resolved as of their latest update
I've attached the toml config and an example log where it encounters an error terminating an instance while launching a new one
I'm using version:
Version:      17.4.0
Git revision: b92ee590
Git branch:   17-4-stable
GO version:   go1.22.5
Built:        2024-09-19T11:11:17+0000
OS/Arch:      linux/amd64

// main.ts
new GitlabRunnerAutoscaling(runnerStack, "GitlabRunnerASG", {
  network: {
    vpc: vpcStack.vpc,
  },
  runners: [
    {
      token: token,
      configuration: {
        name: "tailscale-runner",
        docker: {
          privileged: true,
          capAdd: ["NET_ADMIN", "NET_RAW"],
          devices: ["/dev/net/tun"]
        },
        machine: {
          idleCount: 0, // only run the spot instance when a build is started
          idleTime: 300 // 5 minutes
        }
      },
      role: runnerRole,  // Attach the runner role with ECR access permissions
    },
  ],
  cache: { bucket: cache },
});

launching_new_instance_error.txt
gitlab-runner-config-toml.txt

I'm going to close this, it turns out the runners.machine.autoscaling config overrides the runners.machine settings

Closed. The issue is not in the library. Make sure you explicitly configure machine.autoscaling in the autoscaling stack


modules not loaded

I ran a composer update with "pingpong/modules": "2.0.*@dev", in my composer.json file.
But now no modules are getting loaded.
Did anything change ?

Maybe you forgot add Pingpong\Modules\Providers\BootstrapServiceProvider to your config ? Or there is a syntax error in your module.json file ?

Oh yeah! Forgot that one! :smiley:
Thanks.


Created folder is invisible if no items are added but keeps existing

Describe the issue that you're seeing. Any Loom videos or screenshots usually help a lot!
If you create a folder, but add not items Tina will add the folder on disk, but won't show it in the collection. This will prevent access to the folder via the UI and since the folder does exist makes it impossible to create another with the same name.
I don't think this issue is related to my code specifically.
Reproduction
https://github.com/tinacms/tinacms
Steps to reproduce

Create folder and instead adding an item go back to collection level. -> Folder will be invisible.
Try to make a folder with the same name. -> Error message

System Info
System:
    OS: macOS 14.5
    CPU: (12) arm64 Apple M3 Pro
    Memory: 65.23 MB / 18.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.20.2 - ~/.nvm/versions/node/v18.20.2/bin/node
    Yarn: 1.22.22 - ~/WebstormProjects/farsight-org/node_modules/.bin/yarn
    npm: 10.5.0 - ~/.nvm/versions/node/v18.20.2/bin/npm
    bun: 1.1.8 - ~/.bun/bin/bun
  Browsers:
    Chrome: 125.0.6422.176
    Edge: 126.0.2592.56
    Safari: 17.5
  npmPackages:
    @tinacms/cli: ^1.5.46 => 1.5.46
    tinacms: ^1.6.4 => 1.6.4

Validations

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug.

@nekdolan thanks for the report - pr for fix is linked above (cc @ncn-ssw @brookjeynes-ssw)


Grow note input by the content (support multiline for easier navigation)

As a user I want to see my complete text in the note input and the input field should grow by it's content. The plus icon should stay at the top while the input field is growing. The transition should be nicely animated.
This does not mean that we want to introduce multiline text and linebreaks should still not be available in the note input.


alm-core deploy using ansible-container.

Can one of the admins verify this patch?

CC @kbsingh
This is how I deployed alm-core using ansible-container.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

i believe the codebaes has moved far enough that we can close off this PR.


ez!pp removed from the firefox add-ons website

Everything is said in the title.

Any chance for an update?

Update queued, now waiting for a review on Mozilla's side.

Available once again: https://addons.mozilla.org/fi/firefox/addon/ezpp/