Cypress Tests for Session Entry Automation

Description

Write E2E Cypress tests for #364 Session Entry Automation.
Possible Implementation

Check for automatic character entry for a player after session start time
Check for GM entry for a GM after session start time

Please add your planning poker estimate with ZenHub @pascwhale

Hey team! Please add your planning poker estimate with ZenHub @bcobo341 @IanjhPhillips @JasonGadoury @luigibesani @willyyhuang

Due to the nature / functionality of this feature, it will be impossible to have an E2E test that runs for this without being flaky. I vote we close this issue.

I agree, this would be hard to test.


Access indicators values

Hi!
Can t find a way to get the indicator values 😅 is there a method for that please?
Thanks

getTechnicalIndicatorInfo

You did it?
For me it only returns:
{name: "MA", series: "price", calcParams: Array (1), precision: 4, styles: {…}}

You did it?
For me it only returns:
{name: "MA", series: "price", calcParams: Array (1), precision: 4, styles: {…}}

No sorry ... Finally I made my own api with all talib and tulind indicators running on node then override indicators in klinechart with the values.. maybe i ll share it later could be  nice if we can get a big indicator bank for this lib with custom calcparams etc etc🤘

the only way I managed to get to the value was this
chart._chartPane._candlePane._technicalIndicators[0].result[chart._chartPane._candlePane._technicalIndicators[0].result.length-1]

No sorry ... Finally I made my own api with all talib and tulind indicators running on node then override indicators in klinechart with the values.. maybe i ll share it later could be nice if we can get a big indicator bank for this lib with custom calcparams etc etc

sounds fantastic, it's be awesome if you shared your implementation

the only way I managed to get to the value was this
chart._chartPane._candlePane._technicalIndicators[0].result[chart._chartPane._candlePane._technicalIndicators[0].result.length-1]

Where 0 is the index of the indicator in the indicator array

No sorry ... Finally I made my own api with all talib and tulind indicators running on node then override indicators in klinechart with the values.. maybe i ll share it later could be nice if we can get a big indicator bank for this lib with custom calcparams etc etc

sounds fantastic, it's be awesome if you shared your implementation

I will 😅 my goal is to make a graphql api just by asking ticker/timeframe/array of indicators with calcparams for each... This lib is very nice to draw the indicators but need a way to change the calcparms more easily... Actually we have to override the whole indicator just for that... :( Very very nice lib but support/replies are not as good (sorry to say that but just the truth).

The future version of getTechnicalIndicatorByPaneId will return the calculation results of technical indicators.


For detailed instructions, please refer to Demo usage examples.

Demo usage examples not found?

I need to integrate it into flutter now, but I have no idea.

This is our Flutter plugin, currently only supporting WeChat Pay and Alipay.


Autotune searchSpace has duplicate tunables

Autotune searchSpace has duplicate tunables. Applied multiple container configs with the same tunable name (cpuRequest) with different values. Both these are picked as two different layers (container layer & my container layer) and finally the searchSpace has two cpuRequests listed as tunables. Can searchSpace have duplicate tunables?
Output of listAutotuneTunables:
[
    {
        "layer_level": 0,
        "tunables": [
            {
                "value_type": "double",
                "lower_bound": "150M",
                "name": "memoryRequest",
                "upper_bound": "300M"
            },
            {
                "value_type": "double",
                "lower_bound": "1.0",
                "name": "cpuRequest",
                "upper_bound": "3.0"
            }
        ],
        "layer_name": "container",
        "layer_details": "generic container tunables"
    },
    {
        "layer_level": 0,
        "tunables": [
            {
                "value_type": "double",
                "lower_bound": "250M",
                "name": "mymemoryRequest",
                "upper_bound": "500M"
            },
            {
                "value_type": "double",
                "lower_bound": "2.0",
                "name": "cpuRequest",
                "upper_bound": "4.0"
            }
        ],
        "layer_name": "mycontainer",
        "layer_details": "mycontainer tunables"
    },
    {
        "layer_level": 0,
        "tunables": [{
            "value_type": "double",
            "lower_bound": "512M",
            "name": "javaheap",
            "upper_bound": "1000M"
        }],
        "layer_name": "openj9",
        "layer_details": "openj9 tunables"
    }
]

Output of searchSpace has two cpuRequest tunables:
[
    {
        "application_name": "petclinic-sample-0-75884c5549-9qvwq",
        "objective_function": "transaction_response_time",
        "tunables": [
            {
                "value_type": "double",
                "lower_bound": "150M",
                "name": "memoryRequest",
                "upper_bound": "300M"
            },
            {
                "value_type": "double",
                "lower_bound": "1.0",
                "name": "cpuRequest",
                "upper_bound": "3.0"
            },
            {
                "value_type": "double",
                "lower_bound": "250M",
                "name": "mymemoryRequest",
                "upper_bound": "500M"
            },
            {
                "value_type": "double",
                "lower_bound": "2.0",
                "name": "cpuRequest",
                "upper_bound": "4.0"
            },
            {
                "value_type": "double",
                "lower_bound": "512M",
                "name": "javaheap",
                "upper_bound": "1000M"
            }
        ],
        "sla_class": "response_time",
        "direction": "minimize"
    }
]

@ShishirH - I don't see this fixed with latest build too

@rbadagandi - Can you please paste the results for reference here.  Thanks.


[Feature] TextEditor - Option to set tab width

Stale issue. The IDE needs a release version and the issues are cluttered. I want to focus on getting high priority items listed and low priority items listed.
This would aid in anyone who has interest in the Luthetus.Ide project, what the triage is looking like for v1


Rename readme.md to README.md

Q
A

Bug fix?
YES

What's in this Pull Request?
Please describe the changes in this PR. Sample description or details around bugs which are being fixed.
Guidance
You can delete this section when you are submitting the pull request.

Please update this PR information accordingly. We'll use this as part of our release notes in monthly communications.
Please target your PR to Dev branch.

Hi @DevArvindsa, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

thx Arvind,
we'll go through rest of the readme files with the team.


How to delicately remove the nipple?

First, kudos for this tool!
I have a need to create 2 nipples, on the same el, the second after shutting down the first, with some other parameters. Or maybe there is a way to change a nipple size after initialisation?

Thanks a lot !
I'm not sure to understand your setup.
You have an element, on which you'd like to instantiate 2 nipples.
Each one activated via multitouch I guess? 1 finger, 1 nipple. (:smile: this name makes some funny conversation...)
If you need to create 2 nipples on the same element, maybe you could create two zones inside this element, and then create one nipple on each zone?
Be aware that there are still bugs with the multitouch, that I have to tackle.

That's not my issue sorry I did not explain it very well.
I have 2 needs, both I though could be resolved by destroying the instance.
1/ I create a nipple instance on an element but after a certain user action I need to remove that instance. Totally. Forever.
2/ On another case, totally different from the 1st, I create a nipple instance but after a certain event I need to increase it's size. Which I managed differently by updating the options.size. I did not know that updating options after the instance was creating works, that's why I though about destroy / re-create.

Ok, that's a fair point.
I'll push this into the milestone and find a way to deal with this.
Instances will be more explicit and controllable.

Thank you :)

@yoannmoinet I just tested your 0.4.x release, I'm sorry but issue 2/ is worse with it :(
To sum it up

I create a joystick (which is now a manager) with a specified size
Some times the size is not correct because other things happens and I need to set a new size.
With 0.3.0 I just had to update joystick.options.size and it worked
With 0.4.0 I do not have access to size so I call .off on old manager and create a new one with the new size.
Kitten dies: nipple show me a force Infinity. I suppose this was because sometimes my first size is 0. But since I create a new manager with a new correct size (like 600), why on earth the old size would influence the new manager (and new nipples).

Fond a tail: old manager is still bind to move events. The same old manager that have size to 0. How can I cleanly destroy the manager so all events are unbind?

If you need to dynamicly update the size options on the manager we could add its nippleOptions to its exported signature.
Would this fix your issue? At least we'd go back to where we were in the 0.3.0. And you'd be able to modify any new nipple instanciated.
What do you think?
We still need your .destroy() method though. It's a great feature.


feat: zerops preset

🔗 Linked issue

❓ Type of change

[x] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
Adding a zerops deployment guide

📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

Thanks for PR.

Please target it to v1 branch (i think creating new one is easiest)
We need to create a preset in src/presets
Either preset has a unique environment variable we can auto detect or we should mention in docs to use NITRO_PRESET=zeroops

Thanks 😸


Add changed block

This block detects when the variable in its slot changes, it will be true for one frame when this happens.
I have added this to the Sensing Expansion extension.

pretty sure this is already a core block?

pretty sure this is already a core block?

Is it? I didn't see one, I apologize if it is.

oh I didnt realize it was a boolean


Single VM: Fully qualify ciao-cli

The ciao-cli was not fully qualified in some cases.
Using fully qualified paths ensures we are testing against
what was built vs what is installed on the system.
Signed-off-by: Manohar Castelino<EMAIL_ADDRESS>

Coverage decreased (-0.05%) to 65.912% when pulling c496868d448f730c69dcf42beae5e3fac7b82726 on mcastelino:single_vm_tls_fix into e147d5d685253ff1d7ce368e7b4578527e363b51 on 01org:master.


DBZ-3171 Use Apicurio 2

https://issues.redhat.com/browse/DBZ-3171

Ok, so I'll push a new image 1.6-devel to DockerHub with this change.


Fix flake when test output contains timing info

Got failures when integration tests output some test: OK (0.04s), so we'll strip out all the timing information

Codecov Report

Merging #7 (9e657b9) into main (acc5f1b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #7   +/-   ##
=======================================
  Coverage   78.08%   78.08%
=======================================
  Files           5        5
  Lines          73       73
  Branches        4        4
=======================================
  Hits           57       57
  Misses         15       15
  Partials        1        1

Continue to review full report at Codecov.

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


misc: Allow to install shared lib gflags on centos9

This pr just reverts one line of change by #10732. I think it is not necessary to fully align gflags build with velox build. It means we must set BUILD_SHARED_LIBS=ON for gflags when VELOX_BUILD_SHARED=ON, but it is not necessary to set BUILD_SHARED_LIBS=OFF for gflags when VELOX_BUILD_SHARED=OFF. We can just make the shared lib always be produced, as I also note setup-ubuntu.sh always installs shared gflags from package (see https://github.com/facebookincubator/velox/blob/main/scripts/setup-ubuntu.sh#L120).
Related discussion on this issue: https://github.com/facebookincubator/velox/pull/10732#issuecomment-2295588282

Hi @assignUser, could you take a look?

Hi @kgpai, could you merge this small patch if you have no comment?


Make the info command interactive for parent groups.

Could you make /lp user <user> info parent groups section the same as /lp user <user> parent info so you can click on them and directly execute the commands 😄

I'll be honest, I don't think it's worth the effort.
To do this, the whole message would need to be split up and sent individually. Parent groups only form a small part of the output, and is really just there for convenience. If you want to see the full list, you should use the parent info command.


V2 fails to prevent invalid wgsizes from launching

If we try to launch the benchmark with an non existent kernel WGSIZE, the program actually gives you an invalid result instead of reporting this and terminating early:
miniBUDE:
compile_commands:
   - "/opt/nvidia/hpc_sdk/Linux_x86_64/23.5/compilers/bin/nvcc -forward-unknown-to-host-compiler -DCUDA -DMEM=MANAGED -DUSE_PPWI="1\\,2\\,4\\,8\\,16\\,32\\,64\\,128" --options-file <OUT>/includes_CUDA.rsp  -std=c++17 -forward-unknown-to-host-compiler -arch=sm_61 -use_fast_math -restrict -keep   -DNDEBUG -std=c++17 -O3 -march=native -x cu -c <SRC>/main.cpp -o <OUT>/src/main.cpp.o"
vcs:
  commit:  e7339d6cd9b832f0ba59ed73d2bc406e4345d495*
  author:  "Tom Lin (tom91136@gmail.com)"
  date:    "2023-10-02 15:21:22 +0100"
  subject: "Prevent NVHPC from optimising away task barrier (likely a bug)"
host_cpu:
  ~
time: { epoch_s:1698373309, formatted: "Fri Oct 27 02:21:49 2023 GMT" }
deck:
  path:         "../data/bm1"
  poses:        65536
  proteins:     938
  ligands:      26
  forcefields:  34
config:
  iterations:   8
  poses:        65536
  ppwi:
    available:  [1,2,4,8,16,32,64,128]
    selected:   [64]
  wgsize:       [512]
device: { index: 0,  name: "NVIDIA TITAN X (Pascal) (12189MB;sm_61)" }
# Device and kernel cc: sm_61
# Verification failed for ppwi=64, wgsize=512; difference exceeded tolerance (0.025%)
# Bad energies (failed/total=58671/65536, showing first 8):
# index,actual,expected,difference_%
# 0,0,865.523,100
# 1,0,25.0715,100
# 2,0,368.434,100
# 3,0,14.6651,100
# 4,0,574.987,100
# 5,0,707.354,100
# 6,0,33.947,100
# 7,0,135.588,100
# (ppwi=64,wgsize=512,valid=0)
results:
  - outcome:             { valid: false, max_diff_%: 100.000 }
    param:               { ppwi: 64, wgsize: 512 }
    raw_iterations:      [3.50847,0.00114,0.00047,0.00039,0.00041,0.00038,0.00036,0.00037,0.00034,0.00039]
    context_ms:          0.635100
    sum_ms:              0.003
    avg_ms:              0.000
    min_ms:              0.000
    max_ms:              0.000
    stddev_ms:           0.000
    giga_interactions/s: 4111361.976
    gflop/s:             124067012.898
    gfinst/s:            102784049.389
    energies:
      - 0.00
      - 0.00
      - 0.00
      - 0.00
      - 0.00
      - 0.00
      - 0.00
      - 0.00
best: { min_ms: 0.00, max_ms: 0.00, sum_ms: 0.00, avg_ms: 0.00, ppwi: 64, wgsize: 512 }

We also need to add a hint in the error such that the missing WGSIZE can be added.
Thanks to @jhdavis8 for discovering this.

Update: it's CUDA's wgsize (propagates to threads per blocks) that's failing, PPWI is the one that's define at compile time.


npm i facenet fails

This is because the Stable for Production release has an invalid URL for a dependency.
See https://github.com/huan/node-facenet/blob/f2847bbbff97e8b2977ca6a67e263824cb9d0fd6/package.json#L11
npmjs.org has a stable version.

Thanks for creating this issue!
I'd like to accept a PR to fix that.

No PR needed. This has already be fixed on the upstream. How to release a new version?

Sounds good.
In order to release a new version, we need to update the repo by submitting a PR to update the package.json


How to get the NetworkCIFAR ?

Hi!
i want to run the search_relax/train.py, but there is no model/NetworkCIFAR.
I don't know how to get it. So can you upload the NetworkCIFAR.py file?
Thanks!

@ZengYaoJ did you resolve this problem

any guys resolve this problem now？


Non-constant IconData message is not what was intended

The code tries to print the following message when there's non-constant IconData during a release build: Avoid non-constant invocations of IconData or try to build again with --no-tree-shake-icons.
However, this is what it actually looks like:
ianh@burmese:~/dev/rfw$ flutter build appbundle lib/client.dart

💪 Building with sound null safety 💪

Running Gradle task 'bundleRelease'...
This application cannot tree shake icons fonts. It has non-constant instances of IconData at the following locations:
  - file:///home/ianh/dev/rfw/lib/core_widgets.dart:398:10

FAILURE: Build failed with an exception.

* Where:
Script '/home/ianh/dev/flutter/packages/flutter_tools/gradle/flutter.gradle' line: 1005

* What went wrong:
Execution failed for task ':app:compileFlutterBuildRelease'.
> Process 'command '/home/ianh/dev/flutter/bin/flutter'' finished with non-zero exit value 1

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 34s
Running Gradle task 'bundleRelease'...                             34.8s
Gradle task bundleRelease failed with exit code 1
ianh@burmese:~/dev/rfw$

cc @dnfield

you can avoid build error using "--no-tree-shake-icons"


Add project deployments on newer OP-stack chains

What is it?
In addition to ionic, there are likely other projects that have deployments on other OP stack chains that have recently been indexed. We should do another scan of the projects files and add them to OSSD.

Currently blocked on https://github.com/opensource-observer/oso/issues/2552


Error when creating structured config with untyped Tuple

Describe the bug
OmegConf.create raises the following omegaconf.errors.ConfigIndexError: tuple index out of range when applied to a structured config to a field with type Tuple (i.e., an "untyped" Tuple).
To Reproduce
from dataclasses import dataclass
from typing import Tuple

from omegaconf import OmegaConf

@dataclass
class TupleConfig:
    a_tuple: Tuple[int, int] = (1, 2)

@dataclass
class UntypedTupleConfig:
    a_tuple: Tuple = (1, 2)

# Works as expected.
tuple_config = OmegaConf.create(TupleConfig)
print(tuple_config.__dict__)

# Raises omegaconf.errors.ConfigIndexError: tuple index out of range
untyped_tuple_config = OmegaConf.create(UntypedTupleConfig)

Output
{'a_tuple': [1, 2]}
Traceback (most recent call last):
  File "hydra_bugs/tuple_issue.py", line 22, in <module>
    untyped_tuple_config = OmegaConf.create(UntypedTupleConfig)
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/omegaconf.py", line 175, in create
    flags=flags,
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/omegaconf.py", line 861, in _create_impl
    format_and_raise(node=None, key=None, value=None, msg=str(e), cause=e)
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/_utils.py", line 741, in format_and_raise
    _raise(ex, cause)
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/_utils.py", line 719, in _raise
    raise ex.with_traceback(sys.exc_info()[2])  # set end OC_CAUSE=1 for full backtrace
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/omegaconf.py", line 838, in _create_impl
    flags=flags,
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/dictconfig.py", line 113, in __init__
    format_and_raise(node=None, key=key, value=None, cause=ex, msg=str(ex))
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/_utils.py", line 821, in format_and_raise
    _raise(ex, cause)
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/_utils.py", line 719, in _raise
    raise ex.with_traceback(sys.exc_info()[2])  # set end OC_CAUSE=1 for full backtrace
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/dictconfig.py", line 97, in __init__
    self._set_value(content, flags=flags)
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/dictconfig.py", line 638, in _set_value
    raise e
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/dictconfig.py", line 635, in _set_value
    self._set_value_impl(value, flags)
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/dictconfig.py", line 665, in _set_value_impl
    data = get_structured_config_data(value, allow_objects=ao)
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/_utils.py", line 445, in get_structured_config_data
    return get_dataclass_data(obj, allow_objects=allow_objects)
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/_utils.py", line 370, in get_dataclass_data
    parent=dummy_parent,
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/omegaconf.py", line 1047, in _maybe_wrap
    ref_type=ref_type,
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/omegaconf.py", line 981, in _node_wrap
    element_type = get_list_element_type(type_)
  File "/home/ec2-user/anaconda3/envs/mscale/lib/python3.7/site-packages/omegaconf/_utils.py", line 618, in get_list_element_type
    if ref_type is not List and args is not None and args[0]:
omegaconf.errors.ConfigIndexError: tuple index out of range
    full_key:
    object_type=None

Expected behavior
One would expect omegaconf to handle the UntypedTupleConfig's field a_tuple like a Tuple[Any, ...].
Note that the error comes from the function omegaconf._utils.get_list_element_type function. I think that this function should return the element_type Any.
Additional context

[ ] OmegaConf version: 2.1.1
[ ] Python version: 3.7.12
[ ] Operating system: macOS 12.2.1

The error arises as follows. At some point, omegaconf calls the function omegaconf._utils.get_list_element_type to determine the type inside of Tuple. This function looks as follows:
def get_list_element_type(ref_type: Optional[Type[Any]]) -> Any:
    args = getattr(ref_type, "__args__", None)
    if ref_type is not List and args is not None and args[0]:
        element_type = args[0]
    else:
        element_type = Any
    return element_type

It gets called with ref_type = typing.Tuple. The problem is that getattr(ref_type, "__args__", None) returns () (and not None). Hence the second line if ref_type is not List and args is not None and args[0]: fails because of args[0], which is an out of range access.
Instead, my guess is that the author of this function expected getattr(ref_type, "__args__", None) to return None in this case, in which case there wouldn t have been any problems, and the output of the function would be Any, as expected.

At this time Tuple annotations are only partially supported by OmegaConf.
Issue #392 tracks improvement to Tuple support.

Yes thanks. However, most of the improvements targeted by issue #392 go much further than just correcting what looks like a small bug in get_list_element_type. One would only need to adjust the first or second line there. Other than that, the function seems to be designed to handle a conversion from Tuple to Tuple[Any]. So I think that it could be done independently of the bigger refactor that issue #392 will need.

@cjsg Would you be interested in opening a PR to make such a change to get_list_element_type?

Other than that, the function seems to be designed to handle a conversion from Tuple to Tuple[Any].

The function was primarily designed to parse the arguments to a List[...] annotation.
Support for Tuple was added later.

Would you be interested in opening a PR to make such a change to get_list_element_type?

Yes, I can give it a try this week or next one.

I had a quick look. In get_list_element_type, changing
def get_list_element_type(ref_type: Optional[Type[Any]]) -> Any:
    args = getattr(ref_type, "__args__", None)
    if ref_type is not List and args is not None and args[0]:
        element_type = args[0]
    else:
        element_type = Any
    return element_type

to
def get_list_element_type(ref_type: Optional[Type[Any]]) -> Any:
     args = getattr(ref_type, "__args__", tuple())                       # CHANGED HERE
     if ref_type is not List and args != tuple() and args[0]:        # CHANGED HERE
        element_type = args[0]
    else:
        element_type = Any
    return element_type

works, because getattr(typing.Tuple, "__args__") returns tuple() too. Will do a proper PR later.
However, what I do not understand is why on earth we have the if ref_type is not List condition in the original function. For example, why would you want to return Any as element_type if ref_type=List[float]? Wouldn't you want to return float, i.e. args[0]? I somehow have the feeling that this might be a bug too. Can you confirm this?
2 more comments:

even though just changing the 2 above lines seems to fix the bug, I think that it would be cleaner to also add an if is_tuple_annotation(type_): condition in omegaconf._utils._resolve_forward below the if is_list_annotationcondition. Otherwise, we would get a mismatch at the node creation (in omegaconf._node_wrap, the line starting with node=ListConfig(...)) between element_type, which would beAny, and ref_type, which would beTuple instead of getting case to Tuple[Any] (which would be consistent with what happens when you replace Tuple by List) . Let me know if you have any comments on that.
I also noticed that the omegaconf._utils.is_generic_list function, reproduced below for convenience, doesn't do what its doc says (neither before nor after my changes to get_list_element_type): typing.List returns True (the doc says False). I think that if we follow the logic of its output condition, then get_list_element_type(ref_type)should return None when ref_type is list, typing.List or typing.Tuple. This is currently not the case (returns typing.Any in all 3 cases), and returning None would actually break many other things. So probably one should probably re-think the logic of is_generic_list function. (But probably not high priority, since this function seems to play little role in the code elsewhere).

Apologies for the delayed reply.

However, before that, what I do not understand is why on earth we have the if ref_type is not List condition in the original function.

It is because List[float] is not List :)
>>> ref_type = List[float]
>>> ref_type is not List
True

Th

* I also noticed that the `omegaconf._utils.is_generic_list` function, ... doesn't do what its doc says ... (But probably not high priority, since this function seems to play little role in the code elsewhere).

Hmm 🤔
I agree with your comments about is_generic_list.
I have been thinking that it would be convenient to replace a lot OmegaConf's type inspection logic with calls to typing.get_args and typing.get_origin (or typing_extensions.{get_args,get_origin}, when using older versions of Python).
For example, is_generic_list could be cleanly as:
def is_generic_list(type_: Any) -> bool:
    return get_origin(type_) is list and not get_args(type_)

it would be cleaner to also add an if is_tuple_annotation(type_): condition in omegaconf._utils._resolve_forward below the if is_list_annotationcondition. Otherwise, we would get a mismatch at the node creation ...

That sounds good to me!


implicit conversion error 'unsigned int'  to 'long' in Sema.cpp

Windows 10 MSYS 2, LLVM version 17.0.6:

C:/msys64/home/rute/dev/oberon-lang/src/sema/Sema.cpp:659:112: error: implicit conversion changes signedness: 'unsigned int'
to 'long' [-Werror,-Wsign-conversion]
659 |                 assertInBounds(dynamic_cast<const IntegerLiteralNode *>(index.get()), 0, array->getDimension() - 1);
|                 ~~~~~~~~~~~~~~                                                           ~~~~~~~~~~~~~~~~~~~~^

I've added an explicit type cast in the hope that this problem disappears. Unfortunately, it does not occur with any of my platforms/compilers and, therefore, I am flying a bit blind here.

I am guessing this is a bug/regression on the MSYS2 platform.
Maybe just encapsulate this in:

#if defined(MINGW32)
and add a note about possible bug and I can try again in future releases of CLANG.

How can I install the MSYS2 platform to test whether my work-around works?

Download the installer at : link
Open the shell for CLANG64 : C:\msys64\clang64.exe

pacman -S mingw-w64-clang-x86_64-toolchain
pacman -S mingw-w64-clang-x86_64-boost
pacman -S mingw-w64-clang-x86_64-cmake
pacman -S mingw-w64-clang-x86_64-python
pacman -S mingw-w64-clang-x86_64-python-pip
pacman -S make
pacman -S git
pip3 install --user lit
pip3 install --user filecheck
For me this install files to C:\Users\rute.local.
Move this files to ~/.local and  ~/.local/bin to path:
export PATH="$PATH:~/.local/bin"
git clone https://github.com/zaskar9/oberon-lang.git
cd oberon-lang/
mkdir cmake-build-release
cd cmake-build-release
cmake .. -G "MSYS Makefiles"
make
make test

I was thinking now that the unittest is up and running the above step and similar
steps for other platforms could be added as a CI Workflow.
I can look at this if you agree this would be useful.

New similar error in the latest updates:

C:/msys64/home/rute/dev/oberon-lang/src/codegen/llvm/LLVMIRBuilder.cpp:996:23: error: comparison of
integers of different signs: 'long' and 'unsigned int' [-Werror,-Wsign-compare]
996 |             if (value >= arrayTy->dimensions()) {
|                 ~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Hopefully, this is fixed in the latest pull-request that I just merged. But let me know if new problems of this type have popped up. This feels a bit like playing "whack-a-sign-error". 😎
The major change of the latest pull-request is support for CHAR (and dropping support for STRING). This was a major operation, due to silly design choices (e.g., not distinguishing syntactically between string and character literals or having the LEN built-in procedure for arrays). Arrays are now stored as structs { length, vector[] } and code is generated to initialize all the length values. The compiler now also has an option to enable array bound checks (-fenable-bound-checks). This will generate code to check indexes at run-time, if they cannot be checked at compile-time. The length of the array is only read from the struct as a last resort, if the compiler cannot get it from type information. All-in-all, this pull-request brings significant changes to all components of the compiler, but I hope that it is more or less production-ready nevertheless. Note that the standard library will need to be recompiled. Out.String no longer uses printf! The level of platform independence is rising!
The pull request also brings the failing unit tests down to only 5. 🎉

This is excellent.
I will add some further unittests covering the new features added lately.
With regards to bounds check it could be possible to utilize the same infrastructure as CLANG uses.
e.g. call __ubsan_handle_out_of_bound for full reporting or just llvm.ubsantrap for trap behaviour with error code.
I looked a bit into diffs of what CLANG does add here and it could be an idea to implement something similar?
The LLVM documentation is a bit sparse in this area.
I found a blog with a nice write-up of this : link

Thanks for this information! I suspected LLVM had something like that, but wasn't able to quickly find it. The LLVM documentation is not just sparse in this area, it's generally sparse when things become interesting! 😵💫 The best thing is often to write C code that simulates the desired Oberon behavior and then inspect the LLVM IR that clang generates.
However, I will keep this in mind as a possible improvement! For the time begin, I am happy with the current solution, in particular that it can be turned off as it makes the IR unreadable. 😎 Since Oberon has the LEN built-in procedure, I need to wrap arrays in a struct and carry the length information around anyway. So, I have this information around to check bounds, if I'm looking at an open array. I was also thinking of adding C-style arrays (that do not support LEN) back in for performance reasons, using the syntax v: INTEGER[256]. Again, that's an idea for the future.
Another issue here is that the trap numbers that the Oberon standard assigns to certain conditions (26.7. Run-time traps in: https://people.inf.ethz.ch/wirth/Oberon/Oberon.ARM.Compiler.pdf) do not align at all with POSIX signals. My plan is to be POSIX compliant and, for example, raise SIGSEGV when an array is accessed out of bounds, rather than 1, which in POSIX terms would be SIGHUP and thus very confusing for the developer.


Destination not cleared when navigation back on macOS

Description
When using NavigationStack on macOS navigating back doesn't clear the destination breaking further navigation.
Checklist

[ ] I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
[ ] If possible, I've reproduced the issue using the main branch of this package.
[ ] This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior
The destination to be nil.
Actual behavior
The destination is still set to .child().
Steps to reproduce
Use the code below, and run on macOS.

Click the button
Click the back button in the toolbar
Note that the button in first window won't work a second time

import ComposableArchitecture
import SwiftUI

struct MacNavReducer: Reducer {
  struct State: Equatable {
    @PresentationState var destination: Destination.State?
  }

  enum Action {
    case destination(PresentationAction<Destination.Action>)
    case showChildButtonTapped
  }

  struct Destination: Reducer {
    enum State: Equatable {
      case child(Child.State)
    }

    enum Action: Equatable {
      case child(Child.Action)
    }

    var body: some Reducer<State, Action>{
      Scope(state: /State.child, action: /Action.child) {
        Child()
      }
    }
  }

  var body: some Reducer<State, Action> {
    Reduce { state, action in
      switch action {
      case .showChildButtonTapped:
        state.destination = .child(.init())
        return .none
      case .destination:
        return .none
      }
    }
    .ifLet(\.$destination, action: /Action.destination) {
      Destination()
    }
  }
}

struct Child: Reducer {
  struct State: Equatable { }
  enum Action: Equatable { }
  var body: some Reducer<State, Action> {
    EmptyReducer()
  }
}

@main
struct MacNavApp: App {
  let store: StoreOf<MacNavReducer> = .init(initialState: .init(), reducer: MacNavReducer())

  var body: some Scene {
    WindowGroup {
      WithViewStore(store) { viewStore in
        NavigationStack {
          VStack {
            Button(action: {
              viewStore.send(.showChildButtonTapped)
            }, label: {
              Text("Click me!")
            })
            if viewStore.destination != nil {
              Text("viewStore.destination is not cleared and you can no longer navigate")
            }
          }
          .navigationDestination(
            store: self.store.scope(
              state: \.$destination, action: MacNavReducer.Action.destination
            ),
            state: /MacNavReducer.Destination.State.child,
            action: MacNavReducer.Destination.Action.child
          ) { store in
            Text("Click back in toolbar!")
          }
        }
      }
    }
  }
}

The Composable Architecture version information
a4d371e8adc9d081d616f988fb0f089b479e9553 (current prerelease/1.0 branch)
Destination operating system
Ventura 13.4.1 (22F82)
Xcode version information
Version 14.3.1 (14E300c)
Swift Compiler version information
> xcrun swiftc --version
swift-driver version: 1.82.2 Apple Swift version 5.9 (swiftlang-<IP_ADDRESS>.10 clang-15<IP_ADDRESS>)
Target: arm64-apple-macosx13.0

It has been addressed in https://github.com/pointfreeco/swift-composable-architecture/issues/2182, so consider this a duplicate, but might be handy to have the sample code.


Fix ECDSA failing when the hash is all-bits-zero

Description
Fix function mbedtls_ecp_mul_shortcuts() to skip multiplication when m
is 0 and simply assignt 0 to R. Additionally fix ecjpake_zkp_read() to
return MBEDTLS_ERR_BAD_INPUT_DATA when r length is 0 and ecjpake
test to expect that.
Fix #1792
Status
READY
Requires Backporting
Yes
Migrations
NO
Todos

[ ] Tests
[ ] Documentation
[ ] Backported

Steps to test or reproduce
Please check: #1792

Thanks Manuel, works like a charm.

I think this should be backported to 2.16 since it's a bug, but given how much of a corner case it is, I'd be ok with not doing the backport.

It was my mistake, when I saw this test failing I assumed r == 0 was forbidden (probably reasoning by analogy with ECDSA which does forbid it), but actually I should have read the description of the test better: what's forbidden is for the length of the encoded version of r to be zero.

@mpg Wouldn't it make sense to add an explicit test for ECJPAKE with r == 0, since it's apparently easy to run afoul of this corner case?

Wouldn't it make sense to add an explicit test for ECJPAKE with r == 0, since it's apparently easy to run afoul of this corner case?

I think that would be a nice addition if it can be done* but I don't think it's important enough to block this PR. This case if very unlikely to happen at random, and if an attacker forced it, the worst that could happen is that we reject the message for the wrong reason.
*I didn't check for NIZP, but for ECDSA r == 0 is forbidden (the signature generation function should re-try with a fresh ephemeral key when it happens) but that's one part of your signature generation routine that you just can't test without solving a discrete log on the curve, which in practice means you need to have a weak curve available in your library if you want to test this... One of the many things that are annoying with ECDSA. Again I didn't check how it is with NIZP, so perhaps there it's possible to generate a valid ZKP with r == 0 for testing. I you feel like checking, I'm curious to know what you find, but unfortunately I don't have time to investigate myself now.


Ignore Sendable conformances in PrintAsClang

PrintAsClang previously tried to print Sendable conformances, which tripped an assertion and failed. Skip them instead.
Fixes rdar://95241184.

@swift-ci please smoke test


Bug: Deadline publish job fail because of collect kitsu credentials

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior:
Openpype publish job fails to get 'KITSU_LOGIN' and 'KITSU_LOGIN'
2023-08-10 19:48:57:  0: STDOUT: ERROR:pyblish.plugin:Traceback (most recent call last):
2023-08-10 19:48:57:  0: STDOUT:   File "C:\Program Files (x86)\OpenPype\3.16.0\dependencies\pyblish\plugin.py", line 527, in __explicit_process
2023-08-10 19:48:57:  0: STDOUT:     runner(*args)
2023-08-10 19:48:57:  0: STDOUT:   File "C:\Users\Mustafa Taher\AppData\Local\pypeclub\openpype\3.16\openpype-v3.16.3-nightly.1\openpype\modules\kitsu\plugins\publish\collect_kitsu_credential.py", line 17, in process
2023-08-10 19:48:57:  0: STDOUT:   File "C:\Users\qam\.pyenv\pyenv-win\versions\3.9.7\lib\os.py", line 679, in __getitem__
2023-08-10 19:48:57:  0: STDOUT: KeyError: 'KITSU_LOGIN'
2023-08-10 19:48:57:  0: STDOUT: Traceback (most recent call last):
2023-08-10 19:48:57:  0: STDOUT:   File "C:\Program Files (x86)\OpenPype\3.16.0\dependencies\pyblish\plugin.py", line 527, in __explicit_process
2023-08-10 19:48:57:  0: STDOUT:     runner(*args)
2023-08-10 19:48:57:  0: STDOUT:   File "<string>", line 17, in process
2023-08-10 19:48:57:  0: STDOUT:   File "C:\Users\qam\.pyenv\pyenv-win\versions\3.9.7\lib\os.py", line 679, in __getitem__
2023-08-10 19:48:57:  0: STDOUT: KeyError: 'KITSU_LOGIN'
2023-08-10 19:48:57:  0: STDOUT: !!! ERR: 2023-08-10 19:48:57,122 >>> { CLI-publish }: [ Failed CollectKitsuSession: 'KITSU_LOGIN' -- ('C:\\Users\\Mustafa Taher\\AppData\\Local\\pypeclub\\openpype\\3.16\\openpype-v3.16.3-nightly.1\\openpype\\modules\\kitsu\\plugins\\publish\\collect_kitsu_credential.py', 679, '__getitem__', '') ]
.
.
.
.
2023-08-10 16:16:38:  0: STDOUT: <class 'C:\Users\Mustafa Taher\AppData\Local\pypeclub\openpype\3.16\openpype-v3.16.3-nightly.1\openpype\modules\kitsu\plugins\publish\other_kitsu_log_out.py.KitsuLogOut'>
2023-08-10 16:16:38:  0: INFO: Process exit code: 1
2023-08-10 16:16:38:  0: Done executing plugin command of type 'Render Task'

Expected Behavior:
Expected behavior that deadline job should be able to get "KITSU_LOGIN" and "KITSU_PWD"
or simply we can submit them as EnvironmentKeyValue in job parameters like other env vars.
Version
3.16.3-nightly.5
What platform you are running OpenPype on?
Windows
Steps To Reproduce:

Get Kitsu installed (I have 0.16.12)
Publish any job from deadline

Are there any labels you wish to add?

[X] I have added the relevant labels to the bug report.

Relevant log output:
No response
Additional context:
No response

This problem no longer exists for some reason I don't know, Maybe there was something wrong with my OP's settings

This problem no longer exists for some reason I don't know

Yeah, because I accidentally turned off kitsu module 🤦♂


Updated Service Locator Instancing and Veifications

Overview
Fixed Service Locator instancing and added parent/child verification.
Updated test suite with new names.
Changes

Fixes: #3097
Fixes: #3091

@keveleigh  Sorry found a typo.
Ping @SimonDarksideJ for a refresh


[WIP] HIVE-21456: addendum: Improvements in Thrift over HTTP for Hive MetaStore

What changes were proposed in this pull request?

This PR is a follow up of HIVE-21456. In our internal testing, we found the following issues and this PR fixes them:

Http thread pool name was not getting set in Jetty server
Found an issue in which PersistenceManager object was not getting cleaned up after the completion of a http request. Fixed it by adding a listener in Jetty's connector. The listener listens for the completion of Http request and then closes the RawStore (a thread local entity). The RawStore, in turn, cleans up PersistenceManager.
Added jetty's dependency in metastore pom.xml. Earlier this dependency was getting honored from hadoop-common.
Fixed a unit test  testJDOPersistanceManagerCleanup() in TestHiveMetaStore

Why are the changes needed?

To fix issues described above
Does this PR introduce any user-facing change?

No
How was this patch tested?

Fixed an existing test i.e testJDOPersistanceManagerCleanup. The failure in the test was unrelated to thrift over http patch. After the test is fixed, it was failing for HiveMetaStore in HTTP mode. This patch address that

Leave a minor comment, others look good to me, +1.


icon_color don‘t work anymore with ha 0.110

Checklist

[ x] I'm running the latest version of CustomUI (Update guide) or using a specific release that is not marked as "Broken".
[x ] I tried to force-refresh (Ctrl+Shift+R / Ctrl+F5) the browser
[ x] (Optional, but recommended) I'm using Chrome or tried to reproduce the feature on Chrome.

Browser + Version:
Safari, Chrome

CustomUI version:
20190518
Home Assistant release (hass --version):
0.110.0b0
Problem-relevant configuration.yaml entries:

  icon_color: >
    if (state === 'on') return '#FF0000';
    if (state === 'off') return '#00FF00';
    return icon_color;

Problem-relevant Home Assistant log entries:

Any errors from browser Javascript console:

no sure about the format you use, (and not in 110 yet) but did you try
  icon_color: >
    if (state == 'on') return '#FF0000';
   return '#00FF00';

assuming this is an entity being either 'on' or 'off' (and you did have custom-ui working before ?)
if not that would be a huge breaking change on HA.... Hope this isn't true.

It was working with ha version 0.109.
With ha version 0.110 this don’t work anymore.
Not sure what you mean with the format.
This is one of the entries in the customize.yaml
binary_sensor.couchsensor:
  device_class: vibration
  templates:
    icon_color: >
      if (state === 'on') return '#FF0000';
      if (state === 'off') return '#00FF00';
      return icon_color;

seems core HA changes the way it treats icons, so all custom cards using icons the 'old' way are touched by this. Since @andrey-git is no longer here, it seems this deprecates custom-ui even further, (was still only using icon and icon_color templates myself)...

Yes, your template is shorter. But if the entity is 'unavailable' it is also '#00FF00'.

this is now solved, Ive created a PR, but the fix is explained here:
https://github.com/home-assistant/frontend/issues/5892#issuecomment-630910390
hurray!

I have tried to replace my state-card-custom-ui.html with the one in your branch but the icon_color is still not functioning correctly.  Do i need to do anything else other than replace the file with the edited one and clear the cache on my browsers ?
Thanks for taking this on, you are right that without the ability to apply colours to icons and other Custom UI tricks the frontend is a little bland.

not really....
only issue I have found just a few moments ago is with the iPhone Safari browser. Unless you're talking about that, the other installs should work.
Ive tested Mac Desktop Safari, Chrome and Firefox: all work
Chrome Iphone: works
Safari iPhone: doesnt (yet) color icons
Hope it to be a cache issue. Fear it is a iOS thing though, as there are other issues reported also concerning HA on iPhone.

No problem for me with iPhone safari browser.

what iOs firmware version are you on? things went awol since 13.4 I believe

same problem
0.109 is ok.
binary_sensor.pir_*:
templates:
icon: >
if (state == 'on') return 'mdi:motion-sensor';
return 'mdi:walk';
icon_color: >
if (state == 'on') return 'red';
return 'green';

same problem
0.109 is ok.
binary_sensor.pir_*:   templates:     icon: >       if (state == 'on') return 'mdi:motion-sensor';       return 'mdi:walk';     icon_color: >       if (state == 'on') return 'red';       return 'green';

same problem
0.109 is ok.
binary_sensor.pir_*:   templates:     icon: >       if (state == 'on') return 'mdi:motion-sensor';       return 'mdi:walk';     icon_color: >       if (state == 'on') return 'red';       return 'green';

@Mariusthvdb do you mean a lag if you open homeassistant in safari?
The app is smooth. No lag or delay. I think there is a little 'animation' on the icon if the state changes.

Lag on icon change. Could be called animation.... Ha, Lets wait and see what the effect in my production setup is, which has quite some more custom-ui

same problem
0.109 is ok.
binary_sensor.pir_*: templates: icon: > if (state == 'on') return 'mdi:motion-sensor'; return 'mdi:walk'; icon_color: > if (state == 'on') return 'red'; return 'green';

Did you edit the state-card-custom-ui.html?

same problem
0.109 is ok.
binary_sensor.pir_*: templates: icon: > if (state == 'on') return 'mdi:motion-sensor'; return 'mdi:walk'; icon_color: > if (state == 'on') return 'red'; return 'green';

Did you edit the state-card-custom-ui.html?

Yes,i did.
https://github.com/home-assistant/frontend/issues/5892#issuecomment-630910390

any errors in inspector?

this is now solved, Ive created a PR, but the fix is explained here:
home-assistant/frontend#5892 (comment)
hurray!

I have tried to replace my state-card-custom-ui.html with the one in your branch but the icon_color is still not functioning correctly. Do i need to do anything else other than replace the file with the edited one and clear the cache on my browsers ?
Thanks for taking this on, you are right that without the ability to apply colours to icons and other Custom UI tricks the frontend is a little bland.

I have resolved my issue.
I removed all files from www/custom_ui and only left the modified version of
state-card-custom-ui.html and
state-card-custom-ui-es5.html
this seems to have resolved my issues and i now have icon_color working as it should on 0.110.0
thanks all.

this is now solved, Ive created a PR, but the fix is explained here:
home-assistant/frontend#5892 (comment)
hurray!

I have tried to replace my state-card-custom-ui.html with the one in your branch but the icon_color is still not functioning correctly. Do i need to do anything else other than replace the file with the edited one and clear the cache on my browsers ?
Thanks for taking this on, you are right that without the ability to apply colours to icons and other Custom UI tricks the frontend is a little bland.

I have resolved my issue.
I removed all files from www/custom_ui and only left the modified version of
state-card-custom-ui.html and
state-card-custom-ui-es5.html
this seems to have resolved my issues and i now have icon_color working as it should on 0.110.0
thanks all.

0.110.1 is ok
thanks all.

Making the changes in 6028 fixed everything for me :D

I did the exact same thing before, and kept receiving errors in inspector about this https://github.com/home-assistant/frontend/issues/6028#issuecomment-633531546
will test again, because that would really be the best solution.


Default generated app should not fail ng test

Versions

Angular CLI: 6.0.3
Node: 8.11.1
OS: darwin x64
Angular: 6.0.3
... animations, cli, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.6.3
@angular-devkit/build-angular     0.6.3
@angular-devkit/build-optimizer   0.6.3
@angular-devkit/core              0.6.3
@angular-devkit/schematics        0.6.3
@ngtools/webpack                  6.0.3
@schematics/angular               0.6.3
@schematics/update                0.6.3
rxjs                              6.2.0
typescript                        2.7.2
webpack                           4.8.3

Repro steps

ng new my-dream-app
cd my-dream-app
ng test

Observed behavior
AppComponent should render title in a h1 tag FAILED
	Expected ' Welcome to app! ' to contain 'Welcome to my-dream-app!'.
	    at UserContext.<anonymous> src/app/app.component.spec.ts:25:54)

Desired behavior
By default the generated app should not error

I find it cool that the tests are acutally failing in a new app, thus I know that the tests are run and the the assertions are executed. Often enough I've had projects were tests are running, but the assertions don't cause the build to fail so I've missed valuable feedback.

I've just created a new project and I have the same problem. Moreover, i can't navigate to the file by clicking on it in the chrome console, and the page is not reloaded when the file is edited.
I want to learn unit testing with angular to my team, but 'as-is', there is too many problems :(

I have the same issue. Also fails on e2e test

Same here, but I\m not worrying, guys are going to fix it eventually.

Your html page does not have h1 tag.
comment this line from app.component.spec.ts
//expect(compiled.querySelector('h1').textContent).toContain('Welcome to app!');

The html page does in fact have an h1 tag, the problem is that on a stock-standard brand-new app, the h1 tag display the title of the app, which is App (As is should be according to the second test). So unless you make a change to the brand-new app, it fails.


Is the poll/send-receive/phy_wait pattern ok?

Hi, I'm finishing the writings of the SmolTCP Cpp interface (https://github.com/lucaszanella/smoltcp_cpp_interface) and there's something I need to consider.
On all examples of usage of SmolTCP, I've seen this pattern
poll

socket send/receive

phy_wait

polling simply takes the contents of the socket buffers and writes to tun/tap, and reads from tun/tap and put data into socket buffers
socket send/receive sends to socket buffer or reads from socket buffer
phy_wait waits for data to be available in the tun/tap device be it for read or write
For me it looks like, after poll, if we send a small ammount of data, let's say a TCP connect request , it'll get into the socker buffer. Then we wait with phy_wait, but there's no sense in waiting for anything from the file descriptor because we didn't even send anything yet. Then the phy_wait timeouts and poll is called again, which sends the connect request we had in the socket buffer.
Should we really do things like this? It doesn't look that phy_wait is doing real great here, it simply delays the polling up to the timeout.
For me it makes more sense to first write/read from sockets, then poll to 'commit' those changes, then wait for data with phy_wait, but even then I have my doubts.

On all examples of usage of SmolTCP, I've seen this pattern

IIRC, I didn't put a great amount of thought into it--it was just something to get the examples working.

Any thoughts on how to handle an interface such as a virtio vring where packets arrive asynchronously and should be pushed into the lower part of the stack at that point? In my case, I dont have an fd to select on in the phy_wait style.
I'm fairly new to rust, so probably still have a 'c' mindset, where we get the interrupt, marshall the buffers and then pass them to the next later up with some reference to the source interface...

Any thoughts on how to handle an interface such as a virtio vring where packets arrive asynchronously and should be pushed into the lower part of the stack at that point? In my case, I dont have an fd to select on in the phy_wait style.

It depends on the overall structure of your application. Something as simple as busy-waiting on a virtio empty flag would work, but you probably want to integrate that with scheduling of any other work your application does.

Hello! As part of issue cleanup I'm closing inactive or already-answered "question" issues, since they're not actionable.
Note this doesn't mean questions aren't welcome. They still are! It's just that they shouldn't stay open forever.


Feature/render

[Update]
Updated to 4 types of shading modes: Default, Shadeless, Smooth and Flat shading
Added a background for the viewer, reading the temp image file "/models/doge.jpeg"
Updated lights to be relative to camera

Okay. Can merge!


Set the Key Source field for 802.15.4 Key ID Mode 2.

Fixes the issue described in #816.

Current coverage is 72.31% (diff: 71.05%)

Merging #821 into master will decrease coverage by 0.96%

@@             master       #821   diff @@
==========================================
  Files           107        106     -1
  Lines         16111      16129    +18
  Methods        2195       2193     -2
  Messages          0          0
  Branches       1923       1923
==========================================
- Hits          11807      11664   -143
- Misses         3668       3822   +154
- Partials        636        643     +7

Powered by Codecov. Last update 3ea74a1...b0181ee

LGTM 👍  Harness can parse the MLE announce correctly secured with MAC key id 2 now. Please also remove  (void)aChannel; in SendAnnounce(). I will close #816. Thanks for addressing this.

@xiaom-GitHub, thanks for validating this PR!


Add labels to pod created via kubectl debug

What would you like to be added?
Currently when a pod is brought up using kubectl debug command, labels from existing pod are not copied to pod brought up by kubectl debug. Any way we can create debug pod with required labels via kubectl debug command . Something like below
kubectl debug -it pod_name --copy-to debug_pod --share-processes --image busybox: --label "app=demo"
Why is this needed?
There are some apps which checks whether a pod has particular label present or not. Since kubectl debug creates a pod that doesn't inherit labels, this is resulting in crashloopbackoff for the actual container that is meant to be debugged

Although it is intentional, I think it would be beneficial to introduce a flag to keep labels(only work for --copy-to). That request can also be extended to keeping annotations as well.
/transfer kubectl

Thanks @ardaguclu. Although like @liggitt suggested , having all labels transferred to debug pod, the traffic may get routed to it which could be dangerous .
Instead a feature where there is an option to pass specific labels manually to kubectl debug command would be great. I believe that would ensure only labels required for app to come up in debug pod would be added

I don't know about copying existing labels, but a new registered label to mark debug pods could be useful.

+1 to new label to mark debug pods

Another usecase where we could see issue in --copy-to mode is, this impacts setting ENV variables as well in debug pod yaml. Attaching sample for reference
env:
- name: Region
valueFrom:
fieldRef:
fieldPath: metadata.labels['Region']
Since env variables are dependent on labels in above case, we may not see correct value assigned to it

@verb what is your opinion about this?. Thanks.

I run into the same issue (https://github.com/kubernetes/kubernetes/issues/115679), in my case the debug clone was not useful because all network traffic was blocked as it has not the same labels as the pod I wanted to sniff.
Happy to provide a pr to label the clone on the fly if this is a wanted feature.

Indeed we strip labels by design to be "safe by default", but there are several interesting use cases here.
Crashloop from missing labels: That's not something we anticipated. @Indresh-Prakash was this because of the broken label reference in env that you mentioned, or something else?
Missing environment variable: That's interesting. Maybe we shouldn't stripped labels that are referenced by other fields. There's no way to know if that label was used for traffic assignment, though, so this might not be safe by default.
Adding a new label: I like this idea. It seems useful to be able to match for pods created/modified by kubectl debug. @sftim were you thinking of an automatic static label or something user modifiable?
network traffic blocked: This is working as designed. The intention here was that one would established a debug session and the add the labels that deliver traffic. @raffis  Does this not work?
There are a lot of good ideas here, but I think we have to give the UI some thought to avoid flag creep.

@sftim were you thinking of an automatic static label or something user modifiable?

The key should be fixed (maybe an option to disable it, though I can't see why you'd need it). The value could either be "true" or some relevant detail.

network traffic blocked: This is working as designed. The intention here was that one would established a debug session and the add the labels that deliver traffic. @raffis Does this not work?

Sure I can label it afterwards, but it's annoying. Also a user would need to exactly know which labels are needed. (Or just add all labels from the origin pod).
I'm starting to think that a flag which would copy all the labels is the preferred solution. There are various scenarios where all labels are wanted (but it should not be default).

network traffic blocked: This is working as designed. The intention here was that one would established a debug session and the add the labels that deliver traffic. @raffis Does this not work?

Sure I can label it afterwards, but it's annoying. Also a user would need to exactly know which labels are needed. (Or just add all labels from the origin pod). I'm starting to think that a flag which would copy all the labels is the preferred solution. There are various scenarios where all labels are wanted (but it should not be default).

I agree to @raffis. Keeping labels and even annotations via some kind of flags might be really useful for some cases. As @verb stated, we need to prevent flag creep and only to add required ones. In my opinion, these would be useful.

@verb ENV variable issue and  Crashloopback from missing labels are different
For Crashloopback issue, the app checks whether a label is present or not before proceeding with actual application logic. SInce labels are not present in debug pod, this is resulting in crashloopback as the app is expecting particular label to be present

/assign @ardaguclu

Thanks to the participants for dropping their comments.
Rather than introducing a specific way to just modify labels, we need a generic way to customize debug pods in terms of security context, labels, annotations, etc.
As we discussed earlier with @verb, we need to extend debug command profiling with custom profiling ability in addition to static profiles. This feature can be tracked in https://github.com/kubernetes/enhancements/issues/1441.
I'm closing this issue.
/close


Image is wrong in values.yaml

The image in values.yaml is using the default values described in https://quarkus.io/guides/container-image#container-image-options

If we compare with the generated kubernetes.yaml, it uses the correct values provided via
quarkus.container-image.registry
quarkus.container-image.group

Expected: image: docker.my-internal-registry.com/my-group/project-name:1.0.0-SNAPSHOT
Current: image: antonio.silva/project-name:1.0.0-SNAPSHOT
The container-image.name is working as expected but the registry and group are not being considered.

Thanks for reporting! I will investigate it further and provide a fix in Quarkus upstream.

I think this issue is duplicated with https://github.com/quarkiverse/quarkus-helm/issues/41. If not, please feel free to reopen it.


Autoformat on save not working for .ts and .tsx files.

First of all, I really appreciate all the hard-work that went into this amazing plugin, as it has made my life at work tremendously easier.
Issue: Autosave works just fine on .js files, but not .ts and .tsx files.
Here are some of my configurations from my .vimrc:
call plug#begin('~/.vim/plugged')

    " TypeScript
    Plug 'leafgarland/typescript-vim'

    " CoffeeScript
    Plug 'kchmck/vim-coffee-script'

    " JavaScript
    Plug 'pangloss/vim-javascript'
    Plug 'maxmellon/vim-jsx-pretty'

    " Prettifier
    Plug 'prettier/vim-prettier', {
      \ 'do': 'yarn install',
      \ 'for': ['javascript', 'typescript'] }
call plug#end()

" vim-prettier
let g:prettier#autoformat = 1
let g:prettier#autoformat_require_pragma = 0

Manually calling the command :Prettier works just fine, but unfortunately I can't get that to run automatically on save. Any ideas?

For anyone else experiencing this issue, here is my hacky fix:
autocmd BufWritePre *.tsx,*.ts Prettier

For anyone else experiencing this issue, here is my hacky fix:
autocmd BufWritePre *.tsx,*.ts Prettier

 Plug 'prettier/vim-prettier', {
      \ 'do': 'yarn install',
      \ 'for': ['javascript', 'typescript', 'typescriptreact', 'javascriptreact'] }

I think you also need to include typescriptreact and javascriptreact in your plug begin. You might need to reinstall vim-prettier to install these missing plugins

I confirm that adding javascriptreact and typescriptreact solved the problem for me.
Was this changed recently? Because I never had those before and .tsx always worked fine for me.
Maybe this should be mentioned in the documentation; I was pulling my hair out trying to figure out why it stopped working.

I confirm that adding javascriptreact and typescriptreact solved the problem for me.
Was this changed recently? Because I never had those before and .tsx always worked fine for me.
Maybe this should be mentioned in the documentation; I was pulling my hair out trying to figure out why it stopped working.

Worked like a charm. Thank you!

Maybe we can close this issue then?

The VSCode integration repo has a helpful list of supported languages. Can we add something similar to vim-prettier's documentation? As it is, it's not obvious at all how to make it work for .jsx / .tsx files.


add serialized functions

this adds the new functions constructs for rmw_connext_dynamic_cpp.
However, the current master of this package does already not build. There, I am not running CI on this one.

Cross referencing https://github.com/ros2/system_tests/pull/284#issuecomment-398091171


[Refactor] Remove ENTER CLUSTER statement

What type of PR is this：

[ ] bug
[ ] feature
[ ] enhancement
[ ] refactor
[ ] others

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

[FE PR Coverage check]
:heart_eyes: pass : 0 / 0 (0%)


Suggested change to https://obds-training.github.io/Help/docs/linux/files-and-directories/links/

Never create hard links. Ever!
Please do explain what they are, but please prominently tell everyone to only ever use "ln -s" and make symbolic links. If you think you need a hard link, contact us first to enquire please :)

Not stale


Add support for pattern/regex matching of operator namespaces/denyNamespaces

What is missing?
Currently the operator allows setting namespaces or deny-namespaces to configure the list of NSs watched.
In dynamic environments where the NS are dynamic and require multiple operator instances to be run it would be useful to specify these parameters as patterns/regex and not statically.
Why do we need it?
This allows:

disjoint/non-overlapping set of namespaces watched by different instances of the operator
manage dynamic set of namespaces

The problem with something like this is that there is no such support in the Kubernetes API for doing something like this, so all we could do is list all, and then filter, which we already allow with Kubernetes native mechanisms like label selectors.

manage dynamic set of namespaces

This is very non trivial. The prometheus operator heavily relies on not changing this at runtime, it would be a massive refactoring to change this. I'm not opposed to it, but it's a lot of work.

@brancz

The problem with something like this is that there is no such support in the Kubernetes API for doing something like this, so all we could do is list all, and then filter

Makes sense.
My use-case is the following: I want to run two prometheus-operator instances: one watching all namespaces (global/catch-all) and one configured to watch a single ns via --namespaces. The label selector works for all prom resources except Prometheus CR itself which when created in the namespace watched by both operators is acted upon by both operators.
Would it make sense to add a prometheusLabelSelector to prometheus operator so we can have a finer control on this behaviour? i.e. we can keep the allow/deny namespaces watching but there is an extra label selector that can further filter out Prometheus CRs at runtime.

Nevermind :) - I see https://github.com/coreos/prometheus-operator/pull/2615 implemented the support for the exact use-case above. Awesome

Are we ok closing this then? :)

yup - thanks!


feat: rename pages

Prerequisites:

[x] Unless it is a hotfix it should be merged against the dev branch
[x] Branch is up-to-date with the branch to be merged with, i.e. dev
[x] Build is successful
[x] Code is cleaned up and formatted

Summary
changes the title of the pages according to the new "explore" scheme, see also counterpart in www-main soon

Nav looks good.  I think we need to decide on "INDICATOR: {Indicator Name}" vs. "Explore an INDICATOR", i.e. what the H1 title should be on both the location and indicator pages.


Better error detection in gdscript editor

As it stands, the gdscript misses more errors than it detects. This results in longer iteration cycles as you end up missing a lot of things that should be easily caught before running the game. There are a couple options to improve this that I can think of:

Live interpretation - If we interpret the code asynchronously as we type (or even just do it on file save), we can catch a lot more stuff.
Code indexing - In #20902, I suggested indexing for autocompletion purposes, but this index can also be used to provide better code inspection, allowing us to catch many errors that would normally be detected at compile time by compiled languages.

CC @vnen @bojidar-bg

@akien-mga @vnen @bojidar-bg Any other discussion that can be had here or is this pretty much DoA?

Well, it is a pretty complicated topic to discuss, and since both I and vnen don't seem to want to bikeshed about it, discussions have been pretty low.
That being said, researching how such code analysis can be implemented within the current frame of GDScript, or how other languages and linters do it, can be helpful to the discussion.

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


[5.6] Add New Collection::filterKeys Method

Introduces new Collection method named filterKeys which accepts a list of keys.
It returns new filtered Collection that matches the given keys.

$collection = new Collection(['a' => 'foo', 'b' => 'bar', 'c' => 'baz']);
$filteredCollection = $collection->filterKeys(['a', 'c']);
echo $filteredCollection->toArray(); // ['a' => 'foo', 'c' => 'baz'];

Doesn't only method do the same?

As @decadence pointed out, the only() method already does exactly that: https://laravel.com/docs/5.5/collections#method-only

Oh. Thanks guys for pointing out. Will close this PR.


Fix errata

/cc @vladimirvivien PTAL

What is preventing this from being merged?

I think it just needs review
/cc @tsenart

... and possibly a rebase

just rebased and pushed

address review comments, @tsenart PTAL

LGTM


how to set tensor_info/fc_info for FullyConnectedLayer

Output of 'strings libarm_compute.so | grep arm_compute_version':
arm_compute_version=v23.02.1 Build options: {'standalone': '1', 'embed_kernels': '0', 'gemm_tuner': '0', 'build': 'cross_compile', 'build_dir': './0417-full', 'Werror': '0', 'logging': '1', 'debug': '0', 'asserts': '1', 'neon': '1', 'opencl': '0', 'os': 'bare_metal', 'cppthreads': '0', 'openmp': '0', 'arch': 'armv8a', 'estate': '32', 'toolchain_prefix': 'xxx//arm-none-eabi-'} Git hash=b'd8bf9b53752a4f573120cf51b31055de8b3c7d29'
Platform: cortex-A32
Operating System: freertos

Problem description:
when  use acl NEFullyConnectedLayer（QASYMM8_SIGNED） for tflite-micro optimization,  I got  a wrong result in GEMMLowp mm32 result. The input demision  [40],  weight demision of [512, 40], out demision of [512],   the TensorInfo shows below,
auto src_info = arm_compute::TensorInfo(
arm_compute::TensorShape(40), 1,
arm_compute::DataType::QASYMM8_SIGNED,
arm_compute::QuantizationInfo(1,0));
auto weight_info = arm_compute::TensorInfo(
arm_compute::TensorShape(512, 40), 1,
arm_compute::DataType::QASYMM8_SIGNED,
arm_compute::QuantizationInfo(1,0));
auto       dst_info = arm_compute::TensorInfo(
arm_compute::TensorShape(512), 1,
arm_compute::DataType::QASYMM8_SIGNED,
arm_compute::QuantizationInfo(scale, zero_point));

input
18 | 1 | 9 | 11 | 8 | 1 | 11 | -3 | -11 | -7 | -26 | -10 | 4 | -5 | -2 | -15 | -9 | -22 | -18 | -3 | -12 | -3 | 0 | 3 | -6 | -19 | -20 | -13 | -11 | -4 | -6 | -2 | -7 | -1 | -1 | -1 | -2 | -7 | -10 | -17
weight-1st-row
-16 | -30 | 51 | 59 | -7 | -3 | -16 | -4 | 1 | 2 | -1 | -4 | 0 | 2 | -1 | 0 | -2 | -1 | -1 | 3 | -2 | -2 | -1 | 1 | -1 | -4 | 4 | -1 | -2 | 4 | -3 | 1 | -2 | -1 | 0 | -3 | 1 | -2 | -1 | 0

**the dot-product should be 759, but vector_matrix_multiply_s8 got 159.**
so I got wrong result ， do i need to set transpose_weights=false?
I don't know where the setting is wrong, I need your help.

when change the  weight shape, to tensorShape(40, 512), and transpose it,  get correct fc result.
But it's slow than tflite-micro reference implementation.

Please help to see where is the problem
Thanks

Hi @shiyuanren
Could you please share the output of the command file build/libarm_compute.so ? You seem to have built a 32 bit binary? If so could you please try with a 64 bit build, the performance is better for aarch64
Hope this helps.


Tkterminal interprets output without newline as part of next command

Steps to Reproduce:

Run printf Hello in a tkterminal instance (I'm using shell=True)
The output is: Hellotkterminal$
Now press Return

Expected Behavior:
The output should be empty because no command was typed.
Actual Behavior:
/bin/sh: Hellotkterminal$: command not found
Possible Solutions:
1- Distinguish the output of a command from subsequent commands
2- Avoid the problem altogether by adding a newline to the end of each output that doesn't contain it already, and preferably also a terminator character to indicate the lack of an original newline. Sample output from macOS Terminal.app:

By using subprocess.check_output, I think I've found the problem: printf does not add a new line character (\n), but echo does.
What to do here is check if the output endswith \n, then everything would be okay.
>>> import subprocess
>>> subprocess.check_output(["printf", "hello"])
b'hello'
>>> subprocess.check_output(["echo", "hello"])
b'hello\n'
>>>


Implement addition of annotation values on single cells in grid editor

Pull request checklist
Please check if your PR fulfills the following requirements:

[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been reviewed and added / updated if needed (for bug fixes / features)
[ ] The Unreleased section in CHANGELOG.md has been amended to reflect the changes in this PR
[x] Build (mvn verify) was run locally and any changes were pushed
[x] The pull request is against the correct branch (master for bug fixes, develop for new functionality)

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: #94
What is the new behavior?

When merged, this PR fixes #94:

Annotations can now be added to single empty cells, both for token annotations and for span annotations

Does this introduce a breaking change?

[ ] Yes
[x] No

Does this introduce new dependencies?

[ ] Yes
[ ] No

If this introduces new dependencies:

[ ] Dependencies and citation templates have been updated where necessary

Other information

Checklist for maintainers
Releases

[ ] Do NOT push the green merge button on GitHub.
Follow the latest version of the developer/maintainer docs for making releases.
[ ] License and citation information for dependencies are complete (each dependency has a folder in /THIRD-PARTY/).

This should be good to go now. I've scoped it as well. The next PRs should be smaller I think.

Weird, the GitHub diff seems to be broken. I currently see 23 changed files in the PR, but only 17 locally:
stephan@stephan-Latitude-E7470:~/src/hexatomic$ git diff --name-status develop
M       bundles/org.corpus_tools.hexatomic.grid/src/main/java/org/corpus_tools/hexatomic/grid/GridEditor.java
M       bundles/org.corpus_tools.hexatomic.grid/src/main/java/org/corpus_tools/hexatomic/grid/configuration/GridLayerConfiguration.java
M       bundles/org.corpus_tools.hexatomic.grid/src/main/java/org/corpus_tools/hexatomic/grid/data/Column.java
M       bundles/org.corpus_tools.hexatomic.grid/src/main/java/org/corpus_tools/hexatomic/grid/data/GraphDataProvider.java
A       bundles/org.corpus_tools.hexatomic.grid/src/main/java/org/corpus_tools/hexatomic/grid/layers/NodeSpanningDataProvider.java
D       bundles/org.corpus_tools.hexatomic.grid/src/main/java/org/corpus_tools/hexatomic/grid/style/EmptyCellLabelAccumulator.java
M       bundles/org.corpus_tools.hexatomic.grid/src/main/java/org/corpus_tools/hexatomic/grid/style/LabelAccumulator.java
M       bundles/org.corpus_tools.hexatomic.grid/src/main/java/org/corpus_tools/hexatomic/grid/style/StyleConfiguration.java
M       docs/user/src/usage/grid-editor/README.md
M       docs/user/src/usage/grid-editor/editing.md
A       docs/user/src/usage/grid-editor/editing.png
A       docs/user/src/usage/grid-editor/grid-editor.png
D       docs/user/src/usage/grid-editor/grid-viewer.png
M       tests/org.corpus_tools.hexatomic.grid.tests/src/main/java/org/corpus_tools/hexatomic/grid/data/TestColumn.java
M       tests/org.corpus_tools.hexatomic.grid.tests/src/main/java/org/corpus_tools/hexatomic/grid/data/TestGraphDataProvider.java
M       tests/org.corpus_tools.hexatomic.grid.tests/src/main/resources/org/corpus_tools/hexatomic/grid/overlapping-spans/corpus/doc.salt
M       tests/org.corpus_tools.hexatomic.it.tests/src/main/java/org/corpus_tools/hexatomic/it/tests/TestGridEditor.java

Botched the history on this PR. Will roll back and create another PR. :frowning_face:

Also found a nasty side-effect. Will fix and create a new PR from https://github.com/hexatomic/hexatomic/tree/feature/grid-editor-add-annotation-value-CLEAN.


remove !necesario from fields in MX SP

MX log in:

MX account creation:

also bizarre that birthday doesn't have it, because birthday is also required
also this doesn't appear to be happening for BR PT

Created a new PR #5483 to remove the problematic items causing above issue from the POT file. But also need to clean up POEditor to remove from there as well. Thus the following checklist:

[x] Remove offending string from POT file.
[ ] Remove offending string from POEditor.

I updated Thor too. Once we push POT stuff to Prod it should be fine since the string has been removed from POEditor :)


Add secondary nav (always visible) to album gallery page

The album gallery page doesn't have navigation elements afforded to the album info page, namely the sidebar, which includes a track list (collapsed by default) and "info boxes" for each group the album belongs to. The track list would be redundant since the gallery is functionally an ultra-expanded track list by its nature, but navigation within or to groups is lacking here. It would be nice to be able to access those navigation links on the album gallery page, without intruding on the space and visual focus the track artworks are meant to take here. (Thanks to Makin for the comment about lacking navigation on this page.)
A possible solution would be to reuse the "secondary nav" element, which is intended to substitute the functionality of the sidebar when there isn't enough screen width available to show it. See an example below:

It's currently only used for relatively thin screens (e.g. tablets in portrait mode, phones), but since it's built to stand in when the sidebar is unavailable, it feels like it would fit pretty naturally in here on a gallery page — regardless the screen width. (The gallery page's secondary nav would have the same contents as the info page, i.e. just the group names and previous/next links.)

It should go without saying but the previous/next links will go to the respective album's gallery page (if extant), of course.
Group links will probably be to their galleries, as well. There's going to be a slight incongruency here because following prev/next links will bring to album galleries, but clicking actual grid items in the group gallery will bring to album info pages... but I think that's an acceptable trade-off for the increased navigability. Group galleries are essentially HSMusic's version of Bandcamp artist/group "index" or "album grid" pages, and are a major part of how you explore albums - so I don't want group galleries to link to album galleries instead of album info pages.
(It's technically possible to perform client-side magic, detecting that you started navigating from an album gallery, and accordingly adjusting grid items to link to album galleries instead of info pages. But it feels a little too unpredictable - for the user - so I don't think that in particular is worth pursuing. Grid items just always linking to info pages feels more important to reinforce, and not conditionally - i.e, as far as the user is concerned, magically - betray.)


Addition of Read_Capacity_10 and Start/Stop

Please review @famz @agrover

Hi @bgly, I'm very positive about these improvements and fixes, thank you. Could you please add Signed-off-by lines to each commit? Also, please put the READ_CAPACITY_16 fix in its own commit? Thanks again!

Will do. Also the File Optical Stuff we are still waiting on approval to push up so, hopefully that will come soon.


Interpolator with ElementVector

import numpy as np
from skfem import *

mesh = MeshTri()
basis = Basis(mesh, ElementTriP1())
basis.interpolator(basis.zeros())(np.array([[[0, 0]]]).swapaxes(0, -1))

works, but
import numpy as np
from skfem import *

mesh = MeshTri()
basis = Basis(mesh, ElementVector(ElementTriP1()))
basis.interpolator(basis.zeros())(np.array([[[0, 0]]]).swapaxes(0, -1))

doesn't.
ValueError: row, column, and data array must all be the same length

This should be fixed first:
basis.probes(np.array([[0], [0]]))

which leads to the same error.

Obviously fixing this requires detection of the tensorial order of the output in Basis.probes. This is kind of already done in Basis.refinterp by passing test values to Element.gbasis and checking the shape of the output. This should be moved to Basis._detect_tensor_order and used both in Basis.refinterp and Basis.probes.
Nevertheless, fixing this requires some thorough thinking how Basis.probes should be generalized. Since Basis.probes returns a matrix and the different elements in the range of the linear operator described by the matrix are already describing the different points passed to Basis.probes, perhaps Basis.probes needs to return multiple matrices instead?

Another option is to use Basis._detect_tensor_order already in Basis.interpolator and skip the reuse of Basis.probes if the output of Basis._detect_tensor_order is higher than scalar field, and rely on a different implementation.


ansible: Update iptables

Add two new marist machines, remove old windows machines, cleanup

@fredg02 - Some ansible linter things to fix?

@fredg02 - Some ansible linter things to fix?

None of the linter warnings/errors are related to my changes.


Improve documentation for capture groups

This conversation on reddit gives some good feedback we should take into account when improving this part of the documentation: http://www.reddit.com/r/Clojure/comments/2xa6f1/specter_data_manipulation_library/
It might be time to restructure the docs generally too. It seems like we've tacked on more and more stuff without refactoring...

ping @crisptrutski @piranha

Yeah, capture groups documentation is a bit confusing - and I still haven't used them. I think that I may use instar more in the near future, so then I might tackle that with understanding. :)

Not my finest documentation :3
Like the idea of introducing the capture operators by simply breaking own examples into

What is captured by each group
What the path resolves to
How the captures are passed to the transform function

We have an example showing resolving-capture and one involving interaction between multiple capture, should also have an example with just non-resolving-capture.
Re: the docs more generally being lifted up, did you have any ideas?

One note on spectre vs instar, is the tree-walking aspect over that it has over instar. This is definitely a super power that I would leverage in my use :)

Hmm.. am I reading this correctly that spectre paths match all the way out into the value of maps. So the instar path [:a :b] is similar to the spectre path [:a :b ALL]?

So the resolving vs. non-resolving dichotomy is more prevalent in Specter.
Here we see vector paths have mostly the same semantics, [ALL :a] is the same as [* :a] (ie. you wouldn't put [ALL :a ALL]`)
(update [ALL :a] inc [{:a 1} {:a 2} {:a 4} {:a 3}]) ;; [{:a 2} {:a 3} {:a 5} {:a 4}]

Confusion comes in with predicates being able to apply to the current "value", rather than keys, and that it is "non resolving", so that's probably what confused you:
(update [ALL :a even?] inc [{:a 1} {:a 2} {:a 4} {:a 3}]) ;; [{:a 1} {:a 3} {:a 5} {:a 3}]
```.

This is more general, and means that some of the cases for our #13 and #14 have natural solutions. The `filterer` wrapper gets closer to Instar behaviour, ie. runs against keys, but still does not resolve (hence `ALL` **is** required)

```clojure
(update [(filterer even?) ALL] inc [1 2 3 4 5]) ;; [1 3 3 5 5]

This adds more power because multiple levels of filtering (or richer things, like tree walking) can be composed, eg:
(update [(filterer even?) LAST] inc [1 2 3 4 5]) ;; [1 2 3 5 5]

To continue the parallels, val-selector and val-selector-one are the same as resolving capture in Instar, except the later one throws exceptions if more than 1 path is resolved.
VAL is like applying capture to the previous terms (so nice for composing).
There's no concept of non-resolving capture.
In terms of our outstanding tasks, #13 and #14 would permit solutions in terms of their StructurePath protocol. The protocol approach is quite interesting, although it does slow things down. The compiled paths then are an interesting feature to turn this around completely.

The walker StructurePath is the big one for me, doing a lot of pattern based transformation in one project.
Consider this contrived example of wanting to clean up user names:
(defn truncate [x] (if (> (count x) 7) (str (.substring x 0 4) "...") x))
(update [(walker :name) :name] truncate
             [{:name "James", :friends [{:name "Really long Name"}]},
              {:name "Another long name", :hobbies "Things with long names"}])
;; What I get
;; [{:name "James", :friends [{:name "Really long Name"}]}
;;  {:name "Anot...", :hobbies "Things with long names"}]

;; What I'd want
;; [{:name "James", :friends [{:name "Real..."}]}
;;  {:name "Anot...", :hobbies "Things with long names"}]

(oh, turns out the walking doesn't work the way I'd expect, it doesn't repeat paths when they are deep - I guess because that could create cases when more than one pattern transforms the same value? might take it up with Nathan)
Changing data so that parent does not match lets the child match:
(update [(walker :name) :name] truncate [{:-name "James", :firends [{:name "Really long Name"}]}, {:name "Another long name", :hobbies "Things with long names"}])
[{:-name "James", :firends [{:name "Real..."}]} {:name "Anot...", :hobbies "Things with long names"}]

Interesting. Seems like it should be possible to steal a log of good ideas from Spectre. Although I guess we'd have to introduce a backwards incompatible 2.0 or a new function (transform2)  :(
Leaving that aside though.. do you think a picture like this might help explain the capturing stuff?

Not so sure backwards incompatible changes are needed - a "double splat"  ** operator for example could compete with `walker. Anyway, back to the docs.
Really like the use of colour - and perhaps animating the appearance of the colours would help even further. What do you think about also including the "resolved path" as an extra line below, so it's clear which terms update that, and how.

Extra lines I guess, expanding to [:users 0] and [:users 1] when the wildcard shows up.

Feedback from reddit:
freshhawk 1 point 11 hours ago

That use of colour works great, even better than it worked in my head.
as crisptrutski points out, the other part of my initial confusion would be to resolved with some kind of extra lines tracking the path after each step.
So after blue the path is still at the root, after red it's :users, after yellow it's :users * or :users 0,1 (clearly representing the path post-wildcard is a bit tricky).
Definitely on the right track from my perspective.
As an aside, I also really like the idea of a double spat operator doing walking.
I would have commented on github, but I'd rather not link those two online identities, sorry about splitting the conversation.

Lets go for it :) How do you feel about animating? Happy to help out with labour there

I'm open to it... I don't have a clear idea of how that would look, so please give it a shot if you do!
It might look super weird to suddenly have a gif animation in the README or whatever but if it helps explain it's probably worth it :P

Underestimated how much I'd suck at making a GIF, but here's the idea at least

Note that I left off highlighting the terms in the body of the function, as that doesn't really interact with the capture mechanism.
Sorry for letting this potato cool!

I don't like the GIF... I mean, I like the frames but it seems like it must be possible to step through them one by one, the animation just makes it stressful to see all the data.

Definitely see how it could be stressful - the first time through you're trying to understand what all those labels mean and associate the colours together. Perhaps it could be improved with better layout and timing, or maybe it's just too dense for an automated animation. I'm quite used to seeing GIFs in repos these days (although usually with better execution) for example for explaining more byzantine emacs/vim plugins, but won't push the suggestion any further.
The key problem seems to be the user not being able to take their own pace, so maybe linking out to an interactive example (even a slideshow) is perhaps the answer. Or just showing frame after frame with guiding text between. Or just getting good copy and using a single image (like yours, except I'd drop the colours in the transform function's body)
Your call

Can you try posting that same gif animation at half speed? And maybe instead of "capture: yes"/"capture: no" you can write "capturing!" when it does capture and just white pixels when it's not? (same with "resolve")?
Maybe that will be fine. I find it hard to imagine an animation at half speed :P

@boxed apologies for letting this rot. If there's still steam here I have some time to try GIFinating again, just wanted to gauge interest first.

I still like the idea :P


Question about comments in databank.py

Hi, thanks for your amazing work!
While reading your code, I have discovered comments contained a link:
https://github.com/subercui/scGPT-release#the-data-structure-for-large-scale-computing
Since I am curious about how to handle large scale data, I clicked the link but found nothing.I wonder if this link leads to a private repo or it's just outdated, therefore brings up this issue.
Thank you in advance for your attention to this. I am looking forward to hearing from you soon.🥺

Hi, we tried to write some notes when designing the scBank data structure. The link originally pointed to that. Now, I have put the notes in discussion #112 . Hopefull, it can help further explain the current implementation for you. We proposed some desired features in the notes for handling large single-cell data, and have implemented the core functionalities. We indeed hope to continuously expand the features and also sincerely welcome community efforts.


Added Hotstar Clone

Closes:   #793

Title:  Hotstar clone
Name:  Aditi
Idenitfy yourself:  gssoc ext and hacktiberfest

Describe the add-ons or changes you've made 📃
Screenshots 📷

https://github.com/user-attachments/assets/6a441029-53d2-4253-917f-7aa295b3d232
Type of change ☑

What sort of change have you made:

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

Checklist: ☑

[x] My code follows the Contributing Guidelines & Code of Conduct of this project.
[x] This PR does not contain plagiarized content.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly wherever it was hard to understand.
[x] My changes generate no new warnings.

Note to reviewers 📄

@Avdhesh-Varshney made the changes


improve card layout for mobile

Before (left), After (right)

Hey @maracuja-juice,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: e391f920-7277-11e9-b281-3561ffbb4722


Feature: Allow accepting HTML as a string in a POST request body

Hi!
First of all, thanks to amazing team and amazing software. It's a great tool. It solved so much problems for my team.
Context
We are looking to use Gotenberg to generate reports from HTML string, not only from HTML files.
Problem
It's tricky to push HTML string from server to Gotenberg's API as a file. Requires a lot of boilerplate for no specific reason.
Proposal
Add another endpoint that will accept pure HTML string. Doesn't matter body field as a json or just pure raw body text.
Thanks.

Hey @NGorco 👋
Thanks for the kind words.
Regarding your issue, it’s actually quite simple to do from the client side. For instance, this is how I do it in the PHP client:
Gotenberg::chromium($apiUrl)
    ->pdf()
    ->html(Stream::string('
Hello, world!
'));

Here is another example in node.js:
const htmlBuffer = Buffer.from('
Hello, world!
')
const formData = new FormData()
formData.append('files', htmlBuffer, {
    filename: 'index.html'
})

I don’t want to create another endpoint as I think it not worth the hassle. The solution is quite easy to implement from the client side, whatever the language.

Yup, we are doing exactly what you mentioned with Node.js. But for me it feels controversial to push string as a file, while task of an API (in general) is to generate PDF from a string, not from HTML file.
What if I'd put a PR for review? I think it would simplify setup and make it more clear, since pushing string with POST request is a most basic concept it could possibly be.

Problem is you will start with the index.html file, then some people will ask for being able to send assets as string too and I will end up with an unmaintainable code on the server side.
multipart/form-data requests are natively able to send files, and using a buffer/stream to create a form file is a totally valid use case.
I really don’t see the substantial gains a new route or form field could add comparing to the current solution. And to be totally honest, I think there is none 😅


how to enable/disable the menu dynamically

Add Hide / Show too

There is a parameter called "enabled", which accepts a function or boolean. Just make sure the function returns false if you want to disabled something based on some condition.


[TASK] add required building block in contribution

Description
Please update the list of available building blocks in Contributions BB to include these:
Admin
App Config
Content
Core
Events
Groups
Learning Management System
Locations
Logs
Notifications
Polls
Rewards
Sports
Talents
Transportation
Acceptance Criteria
The required building blocks list is updated.

Is it okay if I make above selections only in catalog's code? Or should I also add this values to yaml as well? If we add this to yaml as well, it will be good that yaml will make an error when the weird values comes in, but when we need to edit the list, we have to edit both code and yaml. I think that if we make this list as full down in the code, we probably don't need to add these values to yaml... ? What do you think?

I will get back in 30 mins or something like that. I was thinking to update the BB first. Thanks.

This will be implemented using the separated json file that contains the list of the building blocks. Also, the endpoint for showing the list of building blocks using the Json file should be added in this issue.


Restore the testing of the font option when switching to camel 3.1.0

We should be able to restore the font option in PdfResource.createFromText "pdf:create?fontSize=6&pageSize=PAGE_SIZE_A5&font=Courier" when upgrading to camel >= 3.1.0 as CAMEL-14452 should fix the NPE.

If you'd like to test against Camel master, this is the most up to date branch ATM: https://github.com/apache/camel-quarkus/pull/698

I've applied the change & verified that this works fine on the camel-master branch.


Migrate Scala tests for swagger-jaxrs module

Rework tests from Scala to Java
Please look at the main issue #1203

Related to #804.


feat: add GitHub Action to remove pending-response label

Description of changes

add GitHub Action to remove pending-response label when the author responds to the thread
Issue #, if available

n/a
Description of how you validated changes
https://github.com/aws-amplify/amplify-cli/actions/workflows/issue-pending-response.yml
Checklist

[x] PR description included

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

closing in favor of #890


RDKTV-11877: timezone interface

Reason for change: ITimeZone interface for
get/set timezone (ex. in a file).
Test Procedure: Builds.
Risks: Low
Signed-off-by: Nikita Poltorapavlo<EMAIL_ADDRESS>

Blackduck scan failure details
Summary: 0 violations, 0 files pending approval, 1 file pending identification.

Protex Server Path: /home/blackduck/github/ThunderInterfaces/122/rdkcentral/ThunderInterfaces

Commit: a5b8f5c983477963985a771a4795c705fef87286

Report detail: gist

Blackduck scan failure details
Summary: 0 violations, 0 files pending approval, 1 file pending identification.

Protex Server Path: /home/blackduck/github/ThunderInterfaces/122/rdkcentral/ThunderInterfaces

Commit: 3289d1609b8e3473f52e0eb540b902c5d56a486a

Report detail: gist

Thanks Nikita

@pwielders - Pls help merge this PR.

@npoltorapavlo - Pls bring this to R2 branch.

#128

@mhughesacn - Confirming that we are good with these changes and can be brought to R2 branch.