Perhaps parser rules should be treated as fragments when used as fragments.

For example, suppose I have this:
ArrowFunctionExpression:
	Parameters (":" ReturnType)? "=>" body=(ArrowReturnExpression | Block);

If I try to do this, the parser will incorrectly detect an async arrow function (() => {}) to be an arrow function:
ArrowFunctionExpression:
	Parameters (":" ReturnType)? "=>" body=(ArrowReturnExpression | Block);

AsyncArrowFunctionExpression:
	"async" ArrowFunctionExpression;

To get around the issue, I can duplicate the code:
ArrowFunctionExpression:
	Parameters (":" ReturnType)? "=>" body=(ArrowReturnExpression | Block);

AsyncArrowFunctionExpression:
	"async" Parameters (":" ReturnType)? "=>" body=(ArrowReturnExpression | Block);

or I can split the shared code to an actual fragment:
fragment ArrowFrag:
	Parameters (":" ReturnType)? "=>" body=(ArrowReturnExpression | Block);

ArrowFunctionExpression:
	ArrowFrag;

AsyncArrowFunctionExpression:
	"async" ArrowFrag;

It seems intuitive and natural to want to use a parser rule in the same manner as a fragment. I'm not sure if there are any reasons why not to do it.
For now making a fragment is the path I go and is simple enough, but I wanted to share the feeling my intuition had.

I don't really see this as a useful feature, or rather: It invites more trouble than it is worth. Unassigned subrule calls have clear semantics depending on the target rule: Parse and return the resulting object in case of a normal rule, or inline for fragment rules. Muddling these two together is arguably not a good idea.
Note that in your case I would recommend to just add a flag isAsync?='async' to the arrow function rule. I don't see a lot of benefit to intrpduce a separate rule/type for that.

I'll close this for now. I think both usages of unassigned subrules have their clearly defined use cases as outlined in our documentation. See here and here.


Added a new folder and a documentation for Email Infrastructure and S…

…ecurity under the Blue Team folder.
Please check the following - and then delete this message:

If you are creating a new page, does it contain the following value at the top, with x being the position in the folder?

---
sidebar_position: x
---

If you are creating a new sub-folder, does it have a _category_.json file with the appropriate descriptive information?
Are all your images / videos named appropriately and in the correct location ("image1.png" e.g. will not be accepted)
Are all your code blocks properly closed off?
Does your file have an appropriate and descriptive file name, and main header?
Ensure all files are referenced correctly (They are case sensitive - if you save "image.png" you cannot reference "Image.PNG")

Failure to include these will result in your request not being reviewed.

Hey @bg-11! Thanks for the detailed email infrastructure documentation. There's a small issue with the build - we need to remove the package-lock.json file since this project uses Yarn as the package manager. Could you:

Delete package-lock.json
Run yarn install to update yarn.lock
Commit and push these changes

This should resolve the build error. Let me know if you need any help! 😊

Thank you for fixing the issue !


add Wiki 文档“配置的优先级”存在容易混淆的表述 #1874

对比上述文档描述，对lssues提出的问题进行了修改

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


ICU-653 Stopped filtering out join/leave messages about the current user

Redux PR: https://github.com/mattermost/mattermost-redux/pull/392
Ticket Link
https://mattermost.atlassian.net/browse/ICU-653
Checklist

Added or updated unit tests (required for all new features)
Has redux changes (please link)

Build failures

It's just failing because it's not picking up the redux changes for some reason. I'll try to fix it after those are merged


[skip ci] don't run Cirrus on tags

flutterfire version for https://github.com/flutter/plugins/pull/2396

@fkorotkov Could you take a look at this :)

LGTM. Should've add [skip ci] right away to actually skip CI. 😅

@fkorotkov yeah, didn't know about it until the release. :/

The Ci failure is caused by cancellation. We don't need to run all the tests for this PR since it is just a cirrus script change. Planning to merge it on red.


Fix usage of FindGzOGRE2 on Windows when pkg-config is available

🎉 New feature
Summary
On Windows  when pkg-config is available and Ogre-Next is available (for example on conda-forge), the code that currently is under if(NOT WIN32) works fine. To permit to use it without interfering with the case in which pkg-config is not installed, I change the if(NOT WIN32) to if(PkgConfig_FOUND).
Test it
I tested that this works correctly with ogre-next installed by conda-forge, but I wonder if there is an easy way to ensure that this does not break the build of gz-rendering with ogre2/ogre-next installed by vcpkg (as done in CI jobs).
Checklist

[x] Signed all commits for DCO
[ ] Added tests
[ ] Added example and/or tutorial
[x] Updated documentation (as needed)
[x] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if the library has them)
[ ] codecheck passed (See contributing)
[x] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

I tested that this works correctly with ogre-next installed by conda-forge, but I wonder if there is an easy way to ensure that this does not break the build of gz-rendering with ogre2/ogre-next installed by vcpkg (as done in CI jobs).

There's a relatively easy way to test this branch with the gz-rendering7 windows jenkins job by modifying the gazebodistro/gz-rendering7.yaml file in a branch on the origin of gazebodistro (not a fork) and specifying that branch name in the GAZEBODISTRO_BRANCH parameter of the build.

I tested that this works correctly with ogre-next installed by conda-forge, but I wonder if there is an easy way to ensure that this does not break the build of gz-rendering with ogre2/ogre-next installed by vcpkg (as done in CI jobs).

There's a relatively easy way to test this branch with the gz-rendering7 windows jenkins job by modifying the gazebodistro/gz-rendering7.yaml file in a branch on the origin of gazebodistro (not a fork) and specifying that branch name in the GAZEBODISTRO_BRANCH parameter of the build.

let's try it:

https://github.com/gazebo-tooling/gazebodistro/commit/c0728769c82a21612941f4d71f18ca97f54cb59f
 https://build.osrfoundation.org/view/ign-garden/job/ign_rendering-gz-7-win/69/

Thanks @scpeters !

let's try it:

gazebo-tooling/gazebodistro@c072876
 https://build.osrfoundation.org/view/ign-garden/job/ign_rendering-gz-7-win/69/

I've compared this test build with the prior build, and ogre2 is not found in either case; perhaps ogre2 is not installed on these machines? At any rate, the find logic appears to have changed as there is much more output in the test using this branch
from reference build:
-- Looking for GzOGRE - found

CMake Warning (dev) at C:/J/workspace/ign_rendering-gz-7-win/ws/install/gz-cmake3/share/cmake/gz-cmake3/cmake3/GzFindPackage.cmake:456 (message):
   -- THIS MESSAGE IS INTENDED FOR GZ-RENDERING AUTHORS --
      (IF YOU SEE THIS, PLEASE REPORT IT)

  Could not find pkg-config information for GzOGRE.  It was not provided by
  the find-module for the package, nor was it explicitly passed into the call
  to gz_find_package(~).  This is most likely an error in this project's use
  of gz-cmake.
Call Stack (most recent call first):
  CMakeLists.txt:86 (gz_find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found Boost: C:/vcpkg/installed/x64-windows/include (found version "1.78.0")
-- Looking for GzOGRE2 - not found

CMake Warning at C:/J/workspace/ign_rendering-gz-7-win/ws/install/gz-cmake3/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:68 (message):
   CONFIGURATION WARNINGS:
   -- Ogre 1.x versions greater than 1.9 are not officially supported.
   -- The software might compile and even work but support from upstream
   -- could be reduced to accepting patches for newer versions
Call Stack (most recent call first):
  CMakeLists.txt:188 (gz_configure_build)

-- Configuring library: gz-rendering7

from this branch's build:
-- Looking for GzOGRE - found

CMake Warning (dev) at C:/J/workspace/ign_rendering-gz-7-win/ws/install/gz-cmake3/share/cmake/gz-cmake3/cmake3/GzFindPackage.cmake:456 (message):
   -- THIS MESSAGE IS INTENDED FOR GZ-RENDERING AUTHORS --
      (IF YOU SEE THIS, PLEASE REPORT IT)

  Could not find pkg-config information for GzOGRE.  It was not provided by
  the find-module for the package, nor was it explicitly passed into the call
  to gz_find_package(~).  This is most likely an error in this project's use
  of gz-cmake.
Call Stack (most recent call first):
  CMakeLists.txt:86 (gz_find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found Boost: C:/vcpkg/installed/x64-windows/include (found version "1.78.0")
-- Looking for OGRE using the name: OGRE2
--   ! OGRE2 not found
CMake Warning (dev) at C:/J/workspace/ign_rendering-gz-7-win/ws/install/gz-cmake3/share/cmake/gz-cmake3/cmake3/FindGzOGRE2.cmake:228 (set):
  Only the first value argument is used when setting an environment variable.
  Argument
  'C:\J\workspace\ign_rendering-gz-7-win\ws\install\gz-common5\lib\pkgconfig'
  and later are unused.
Call Stack (most recent call first):
  C:/vcpkg/scripts/buildsystems/vcpkg.cmake:782 (_find_package)
  C:/J/workspace/ign_rendering-gz-7-win/ws/install/gz-cmake3/share/cmake/gz-cmake3/cmake3/GzFindPackage.cmake:243 (find_package)
  CMakeLists.txt:116 (gz_find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Looking for OGRE using the name: OGRE-Next
--   ! OGRE-Next not found
CMake Warning (dev) at C:/J/workspace/ign_rendering-gz-7-win/ws/install/gz-cmake3/share/cmake/gz-cmake3/cmake3/FindGzOGRE2.cmake:228 (set):
  Only the first value argument is used when setting an environment variable.
  Argument
  'C:\J\workspace\ign_rendering-gz-7-win\ws\install\gz-common5\lib\pkgconfig'
  and later are unused.
Call Stack (most recent call first):
  C:/vcpkg/scripts/buildsystems/vcpkg.cmake:782 (_find_package)
  C:/J/workspace/ign_rendering-gz-7-win/ws/install/gz-cmake3/share/cmake/gz-cmake3/cmake3/GzFindPackage.cmake:243 (find_package)
  CMakeLists.txt:116 (gz_find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Looking for GzOGRE2 - not found

CMake Warning at C:/J/workspace/ign_rendering-gz-7-win/ws/install/gz-cmake3/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:68 (message):
   CONFIGURATION WARNINGS:
   -- Ogre 1.x versions greater than 1.9 are not officially supported.
   -- The software might compile and even work but support from upstream
   -- could be reduced to accepting patches for newer versions
   -- Failed to get pkg-config search paths
   -- Failed to get pkg-config search paths
Call Stack (most recent call first):
  CMakeLists.txt:188 (gz_configure_build)

-- Configuring library: gz-rendering7

Actually for some reason this version of the fix does not work out of the box, and some other changes are necessary for conda-forge build, see https://github.com/conda-forge/gz-rendering-feedstock/pull/14 .  However, I am not sure how this changes affect other possible builds of gz-rendering. Probably we can close for now and for the time being keep this change as patch in conda-forge build.

I think I found a safer way: #384 .


Expose docs for io and ops package

I had do modify the docstrings to use Napoleon NumPy style, because Napoleon Google Style doesn't support multiple return arguments.

Codecov Report

Merging #1189 into master will increase coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1189      +/-   ##
==========================================
+ Coverage   65.64%   65.72%   +0.08%
==========================================
  Files          79       79
  Lines        5827     5827
  Branches      889      889
==========================================
+ Hits         3825     3830       +5
+ Misses       1731     1728       -3
+ Partials      271      269       -2

Impacted Files
Coverage Δ

torchvision/io/video.py
72% <ø> (ø)
:arrow_up:

torchvision/ops/boxes.py
94.73% <ø> (ø)
:arrow_up:

torchvision/transforms/functional.py
71.38% <0%> (+1.44%)
:arrow_up:

Continue to review full report at Codecov.

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


Fix lists - Migrate from semicolon to comma as separator

Close: #130

[x] update all lists
[x] update all scripts

@koppor , @Siedlerchr
Hi, thanks for your work, as issue #130 , I have completed csv migration from semicolon to comma with csv file and all scripts, please review the code. Thanks!

Needed to update the update scripts also to use " everywhere. Done at https://github.com/JabRef/abbrv.jabref.org/pull/145.


Make it possible to always show loadingView

For UITableViewControllers or actually any other view controllers that display content that is fetched from the network StatefulViewController is great already.
In my project I have some different ones. In my login and registration flow I want to use StatefulViewController to display loading indicators. However, overriding hasContent is unlogical for those view controllers as they always show the same buttons and textfields that are static. I could just override hasContent and return false, but that seems wrong to me as in reality my view controllers do have content (the forms and buttons).
I added a new property to StatefulViewController and StatefulViewControllerImplementation named alwaysShowLoadingView. The default for this property if false, so everything behaves as before. When the property is set to true the loading view will be displayed regardless the return value of hasContent.

Is there any update on this? Does this need additional work?

Sorry it took so long to get back to this, pretty busy lately.
While I certainly understand your point of view, I'd rather not add this change, because it adds additional complexity to the API. I have personally just overridden hasContent to return false in similar cases. Although it does not semantically seem to fit, I think this use case is rather an edge case that does not justify an overall change to the API's surface.
:sparkles:


Potential vulnerability: topic names from ROS parameters

Hi,
We notice that you are using topic names from ROS parameters at the following locations:
https://github.com/ROBOTIS-GIT/open_manipulator_with_tb3/blob/1dd99f5742171af41f8284446d167effd990143e/open_manipulator_with_tb3_tools/nodes/pick_and_place_state_machine#L36
https://github.com/ROBOTIS-GIT/open_manipulator_with_tb3/blob/1dd99f5742171af41f8284446d167effd990143e/open_manipulator_with_tb3_tools/nodes/pick_and_place_state_machine#L94
https://github.com/ROBOTIS-GIT/open_manipulator_with_tb3/blob/1dd99f5742171af41f8284446d167effd990143e/open_manipulator_with_tb3_tools/nodes/pick_and_place_state_machine#L152-L154
For security reasons detailed below, we strongly suggest avoiding the usage of strings from parameters as topic names.
Although parameters are usually set in parameter files, they can also be changed by nodes. Specifically, other nodes in the same ROS application can also change the parameters listed above before it’s used, either by accident or intentionally (i.e., by potential attackers). If the pick_and_place_state_machine/robot_name parameter is changed, the pick_and_place_state_machine node will subscribe to wrong topics to get the input, and send control commands to wrong topics, which disable the movement of the robot arm. If an attacker exists, she can even take full control of the robot arm by first fooling the pick_and_place_state_machine node to subscribe and publish to wrong topics by changing the ~robot_name parameter, and then forward the messages between the wrong topics and the correct one after modifying the contents as she wants. In this way, the attacker can move the robot arm to arbitrary positions, and even cause harm to the robot arm or even surrounding humans. Because ROS is an OSS (open-source software) community, third-party nodes are widely used in ROS applications, usually without complete vetting of their behavior, which gives the opportunity to potentially malicious actors to inject malicious code (e.g, by submitting hypocrite commits like in other OSS systems [1]) to infiltrate the ROS applications that use it (or software supply chain attacks, one of the primary means for real-world attackers today [2]).
We understand that using parameters to set topic names brings flexibility. Still, for the purpose of security, we strongly suggest that you avoid such vulnerable programming patterns if possible. For example, to avoid the exposure of this specific vulnerability, you may consider alternatives like remapping, which is designed for configuring names when launching the nodes.
[1] Q. Wu and K. Lu, “On the feasibility of stealthily introducing vulnerabilities in open-source software via hypocrite commits,” 2021, https://linuxreviews.org/images/d/d9/OpenSourceInsecurity.pdf.
[2] Supply chain attacks are the hacker’s new favourite weapon. and the threat is getting bigger. https://www.zdnet.com/article/supply-chain-attacks-are-the-hackers-new-favourite-weapon-and-the-threat-is-getting-bigger/.

Hi there, I wanted to follow up on this security vulnerability. Could you please let me know if there have been any updates or concerns regarding this issue? Thanks


⚠ Bofrost.be has degraded performance

In 6bce86f, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1136 ms

Resolved: Bofrost.be performance has improved in d9565d7.


OurDB-Database with oauth?

Hi all.
1. Idea
A crazy idea I had would be to authenticate who uses the OurDB-Database with oauth.
2. question/feedback
What do you all think of the idea?

Hi,
This is a great idea. I really appreciate it. But before OAuth it needs to add schemas.
I am putting this issue open so we can have more discussion. so, we could do more to develop this.

Thank You so much for your interest @degaur. I really appreciate your help in this repo. On the OAuth2 topic, I also need to figure out how it will gonna compatible with C++ code and on what structure we need to implement this. But in the main time if you want to contribute you can start contributing your code to this project. 🙏🏽


Item Protection

Describe it
Items drop on death. This may not be that bad in singleplayer, however it should definetely be disabled in the server or else people can steal your items when you die or kill you for them (Should also disable friendly fire if its on)

Describe it
Items drop on death.

But I may try to allow it so when you go to your body you can only claim your own and not other people's


feat: Add dracula smooth theme color

feat: Add dracula smooth theme color

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Does this consider Icons within the navigation?

Discussed in https://github.com/teamnovu/statamic-unused-assets/discussions/3

Originally posted by arcs- October  5, 2023
I have a setup where users can add an Image to each navigation point but this plugin considers those as unused, have you noticed something like this before?

Here's a poc PR: https://github.com/teamnovu/statamic-unused-assets/pull/6


Inserting multiple characters of a variant at once.

In Julia, we can type \^123<tab> to get ¹²³. It would be nice to support this as well.

This could also be used for transliteration, e.g. \greek{abc}  ⟶ αβγ


Struct array hashing

Fixes https://github.com/0xs34n/starknet.js/issues/260 as well as generation of the type hash with struct array dependencies.
Hashes an array of structs like so:
// struct s
a = [s1, s2, ..., sn]

// hash each struct individually to get a list of hashes(felts)
[H(s1), H(s2), ..., H(sn)]

// hash list of felts as per usual (computeHashOnElements in starknet.js)
H(a) = H(...H(H(H(s1), H(s2)), H(s3)), ..., H(sn))

thank you fir your first contribution! 🙂 Very solid and it got tests, appreciated!


[POC] Add basic tracing to ember client

Proof of concept.
Add very basic spans (basically no attributes) for connections and requests within ember client.

cc @rossabaker


When fine-tuning and using query_instruction_for_retrieval should document instruction be blank?

If I followed the fine-tuning instructions and added a query_instruction_for_retrieval, should I use the same, different, or blank ("") instruction for the document ingestion part?

The query_instruction_for_retrieval will be added to query during fine-tuning.
If you set this hyper-parameter, you should add it to query during inferencing.
There is no need to add this instruction to document.


Helm chart for QAT Intel Device Plugin

nodeSelector field was commented out to be able to install QatDevicePlugin resource on existing node.

Codecov Report

Merging #1072 (17e56ca) into main (aefdc3f) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1072   +/-   ##
=======================================
  Coverage   53.01%   53.01%
=======================================
  Files          40       40
  Lines        4350     4350
=======================================
  Hits         2306     2306
  Misses       1917     1917
  Partials      127      127

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Prompt for /edit with Llama3 contains undefined

Before submitting your bug report

[X] I believe this is a bug. I'll try to join the Continue Discord for questions
[X] I'm not able to find an open issue that reports the same bug
[X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
- OS: Arch Linux 6.8.7-arch1-2
- Continue: v0.8.25
- IDE: VSCode 1.88.1
- Model: Ollama v0.1.32

Description
/edit on some code gives template like
...
[INST] ```undefined
undefined<START EDITING HERE>
...

Removing ~/.continue and reinstalling extension does not fix this
Prompt for "Claude 3 Sonnet (Free Trial)" contains correct prefix

Suspected cause

The template code is here, otherData.language and otherData.prefix seems to be undefined
The caller is here, otherData has filePrefix but not prefix, it does not include language as well
Can be fixed by passing required data to the caller

Rename all prefix to filePrefix (because some user templates contains filePrefix, reference)...
Or just pass prefix and filePrefix at the same time?

To reproduce

Download extension
Setup Ollama with model llama3 (others might be able to reproduce as well, but I haven't tried)
Select some code and type Ctrl + L to add it to chat
Type /edit
Submit
Check Output section, you'll find undefined in it

Log output
==========================================================================
==========================================================================
Settings:
contextLength: 4096
model: llama3
maxTokens: 2048
stop: <|start_header_id|>,<|end_header_id|>,<|eot_id|>
raw: true

############################################

[INST]
undefined<START EDITING HERE>
Lib::Add1(x) => write!(f, "add({:.3})", x),
            Lib::Sub1(x) => write!(f, "sub({:.3})", x),
            Lib::Mul1(x) => write!(f, "mul({:.3})", x),
            Lib::Div1(x) => write!(f, "div({:.3})", x),
            Lib::Mod1(x) => write!(f, "mod({:.3})", x),
            Lib::Lt1(x) => write!(f, "lt({:.3})", x),
            Lib::Le1(x) => write!(f, "le({:.3})", x),
            Lib::Gt1(x) => write!(f, "gt({:.3})", x),
            Lib::Ge1(x) => write!(f, "ge({:.3})", x),
<STOP EDITING HERE>
```

Please rewrite the entire code block above, editing the portion below "<START EDITING HERE>" in order to satisfy the following request: "change precision to 4". When you get to "<STOP EDITING HERE>", end your response.
 [/INST]Sure! Here's the entire code block, including the rewritten portion:
```undefined
undefined<START EDITING HERE>
```

Fixed by #1216


Support creating signed urls for Cloud CDN

Is your feature request related to a problem? Please describe.
We want to implement signed urls that go through the load balancer with Cloud CDN, this library does not yet expose a method that can be used to generate those urls.
Describe the solution you'd like
An method that will generate these urls for us.
Describe alternatives you've considered
Create the custom code inside the application itself.
Additional context
Would be awesome if this could be integrated inside the library as now everyone who needs this needs to figure it out themselves (As the Google Cloud docs does not have an example for node) and create their own solution.

Hi @TriPSs ,
Can you please elaborate a bit further on your use case? What would be the difference between this function and file.getSignedUrl()? You mention that the google cloud docs page doesn't have an example for node. Are there examples in other languages? What docs page are you referencing?

I mean this, if  I understood it correctly you need to create a custom "URL signing key" for the load balancer and use that one when creating the signed url so Cloud CDN / Load Balancer can accept it. Or is this incorrect?

Hi @TriPSs ,
Thanks for calling out the missing sample! I filed an issue in the samples repo and will move this discussion there. This repo hosts Storage samples only.


init fails with common existing files

Bug Report
What did you do?
Tried to create a new project with: operator-sdk init --domain egeria-project.org --license apache2 --owner 'Contributors to the Egeria project' --project-name 'egeria-k8s-operator' --repo 'github.com/odpi/egeria-k8s-operator' into a nearly empty github project
What did you expect to see?
Iniitalized skeleton project being created
What did you see instead? Under which circumstances?
A failure message -
FATA[0000] failed to initialize project: unable to run pre-scaffold tasks of "base.go.kubebuilder.io/v3": target directory is not empty (only go.mod, go.sum, LICENSE, README.md, and files and directories with the prefix "." are allowed); found existing file "CODEOWNERS"

CODEOWNERS is a well established github file which may be created in the early stages of project creation
I didn't check, but other typical files may include those under .github -- these aren't just for building code but may be, for example, for stale issue management workflow
Environment
Operator type:

</language go>

Kubernetes cluster type:
OpenShift
$ operator-sdk version
operator-sdk version: "v1.6.1", commit: "e6981d812a759442a583d8ee2fae269507c408d4", kubernetes version: "1.19.4", go version: "go1.15.5", GOOS: "darwin", GOARCH: "amd64"
$ go version (if language is Go)
go version go1.15.11 darwin/amd64
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T21:16:14Z", GoVersion:"go1.16.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0+d46d32f", GitCommit:"d46d32fbc3f0c35d2855a4589062aaf6335acd48", GitTreeState:"clean", BuildDate:"2021-03-11T01:16:36Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.21) and server (1.19) exceeds the supported minor version skew of +/-1
Possible Solution

Additional context

I had the same issue with a few other files - DEVELOP.md, NOTICE, SECURITY.md, doc (this was a subdirectory of design docs), and finally 'old' (where I had moved the old operator code to)
I understand the need to be building a clean project, but the current approach does seem a little too limiting - it would (IMO!) be more appropriate if only selected subdirectories were tested, along with key top level files that are being checked. Additionally reporting the errors one file at a time is painful vs providing a failed-validation list.
Another option of course is to build into a subdir, yet many of the files created are appropriate to a top level dir in any case
With files removed th

I think that would be OK to add CODEOWNERS as an exception as well. Would you like to collab with it? This change needs to be done in Kubebuider. See;
https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugins/golang/v3/init.go#L175-L179
As a workaround, you can move the file to the scaffold and after came back that as well.

I'd be happy to give making a PR a go if you're not in a rush .. I've not built kubebuilder before but it would be good practice :-)
Any thoughts on the other files? I know projects do vary...
There is perhaps the broader question of handling existing files - which would be more of a design change

@planetf1 I would say any capitalized files name (in addition of LICENSE pr e.g) or containing a .md extension.

The related PR has been merged.


Add subresourceMethod parameter to create action

I had the following scenario:
Imagine you have three models: Model1, Model2 and User.
Model1 and Model2 have a belongsTo(User, ...)-attribute.
Everytime a user opens the website, I fetch all Model1 and Model2 instances from the server and use the create action to insert them into the ORM. (e.g. store.dispatch('entities/model1/create', { data: dataFromServer })).
This works fine until I try to do that with Model2, because the create action on Model2 will override the Users from Model1.
This PR adds an subresourceMethod property to the create action.
store.dispatch('entities/model2/create', {
  data: response.data,
  subresourceMethod: 'insert'
});

This will use create on the Model2 model and insert on all related models.
Maybe this should be discussed and when there is a final prototype, tests should be written.

Oh well yeah, you got a good point. This is a pitfall. Thank you so much for your PR!
Maybe we would want to have a more flexible way of handling this? For instance, when saving multi related data, such contains user, posts, and comments, and want to create user and post but want to insert comments.
One idea came to me is to create a new generic method like save or add and pass create and insert option with the relationship.
// `create` users and posts but `insert` comments.
store.dispatch('entities/users/save', {
  data: response.data,
  create: ['users', 'posts'],
  insert: ['comments']
})

Then we can use this method underneath and add similar option to create and insert as well.
store.dispatch('entities/users/create', {
  data: response.data,
  insert: ['comments']
})

store.dispatch('entities/users/insert', {
  data: response.data,
  create: ['posts']
})

What do you think?

Yes, I really like this save thing!

Great! Do you want work on with this PR? I could tackle this when I finish up my many to many relationship I'm currently working on : )

Will do so! :smile:

Yeah 🍺

I will open a new PR for this because I forgot to create a new branch... :man_facepalming:

😃

By the way, good method name persist. I love it.

Follow-up: #67


inference time

Thank you for your excellent work. The paper mentions inference time per image, can you provide the code for reference, thanks!

Hi,
I show the code below. You need to import time at the beginning.
                tsince = int(round(time.time()*1000))
                outputs_img = self.inpaint_model(images, masks)
                ttime_elapsed = int(round(time.time()*1000))-tsince
                print('test time elaspsed {}ms'.format(ttime_elapsed))

I also update in the ./src/HINT.py
Cheers.


Fix the scopes option for gce instances create command

Hi,
The option scopes for the command gcloud compute instances create has changed from
--scopes=default,SCOPE to --scopes=SCOPE

thank you


[transition] Allow more accurate PropTypes

As discussed here: https://github.com/callemall/material-ui/pull/8785 setting children and in props as optional should be brought back to allow using transitions as a props in other components e.g. Snackbar.
I did not add any new tests, I believe there are no tests for checking types.
Breaking change
This breaking change increases the consistency of our API. Also, it's allowing a more strict typing definition that can help spotting issues. One important thing to notice is that the component creation needs to be outside of the render method. Otherwise, a new instance will be created and the animation will lose his state.
-    <Dialog transition={<Slide direction="left" />} />;
+    const Transition = props => <Slide direction="left" {...props} />
+    <Dialog transition={Transition} />;

-    <Snackbar transition={<Slide direction="left" />} />;
+    const Transition = props => <Slide direction="left" {...props} />
+    <Snackbar transition={Transition} />;

Do we need the same change for flow?

probably yes. I never worked with flow but..
https://github.com/callemall/material-ui/blob/v1-beta/src/internal/transition.js - there are not TransitionProps here.
So I'm guessing you mean type information in concrete transitions like here:
https://github.com/callemall/material-ui/blob/v1-beta/src/transitions/Slide.js#L78
The only problem I see is this line: https://github.com/callemall/material-ui/blob/v1-beta/src/transitions/Grow.js#L200
For some reason Grow gets style from children element which now can be optional. Do you know why is this needed? Other transitions don't extend style prop of children.

@apieceofbart I'm continuing the PR. I'm gonna simplify the current situation by only accepting a component. This should make things more consistent with the other components and be more accurate.

Sure, go ahead. Let me know if I can help

@apieceofbart I hope this change address your issue too.

@oliviertassinari thanks for the change but I think this PR didn't include the changes in props typings - namely TransitionProps require children and in props (https://github.com/callemall/material-ui/blob/3e9da458ee69788de85093672f7a334dd80ef641/src/internal/transition.d.ts#L16) while all the examples show self-closing components (so children is missing)

while all the examples show self-closing components (so children is missing)

Sounds like an issue on the examples side. Where have you seen them?

https://material-ui-next.com/demos/snackbars/ in the Transition section:
function TransitionLeft(props) {
  return <Slide direction="left" {...props} />;
}

function TransitionUp(props) {
  return <Slide direction="up" {...props} />;
}

function TransitionRight(props) {
  return <Slide direction="right" {...props} />;
}

function TransitionDown(props) {
  return <Slide direction="down" {...props} />;
}

@apieceofbart This looks good to me.

hmmm but Slide (or any other Transition components) requires children:
https://github.com/callemall/material-ui/blob/3e9da458ee69788de85093672f7a334dd80ef641/src/transitions/Slide.js#L78
Those examples clearly don't pass children, right?

If you ask me the best solution would be to leave adding transition to developer. I would then pass my component wrapper with Transition as children to Snackbar. I'm not sure how will the scale to other use cases though.

Those examples clearly don't pass children, right?

The Snackbar component do pass the children property. I don't get were is the issue. Do you have a codesandbox I can have a look at?

The Snackbar does but the Slide don't. Here you are returning a Slide component with missing children:
return <Slide direction="left" {...props} />;
Maybe this works somehow but Typescript won't compile this code and I guess flow will also have issues.
I will create an example repo.

The children is a property like another. It will be spread.

Yeah you're right, sorry for that! I was working with wrong example without {...props}.


Removes duplicated 2.2.0 changelog description

Coverage remained the same at 63.273% when pulling c21192e87ef67291039f59a2d843f86e7ccff86f on YuriHeupa:patch-1 into 711fcafb35d1ba0bb1fb6a7b646110afa9824088 on roughike:master.

Closing as outdated, please reopen if needed.


Create INFERENCE CALCULATOR.py

fixes #

Checklist:

[ ] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[ ] Add or update relevant docs, in the docs folder and in code.
[ ] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[ ] Add .. versionchanged:: entries in any relevant code docs.
[ ] Run pre-commit hooks and fix any issues.
[ ] Run pytest and tox, no tests failed.

Please do not use out public repo to learn how to use Flask, Git, or GitHub. Please provide feedback to whatever teacher or tutorial told you to do this that they are being disruptive.

Apologies Adrian , that was a mistake on my end . Taking it down
On Wed, Jun 28, 2023 at 12:35 Adrian @.***> wrote:

Do not use other people's repos for testing and learning how to use
Git/GitHub.
—
Reply to this email directly, view it on GitHub
https://github.com/pallets/flask/pull/5178#issuecomment-1611748916, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/A5JCJFDD3PANYTXRT5JMKBLXNRMOBANCNFSM6AAAAAAZXK6FOI
.
You are receiving this because you authored the thread.Message ID:
@.***>


feat(app node): register csi nodes to control plane

App Node: Represents a CSI node or a node where io app/initiator would be situated.
Changes in this PR:
- This adds the registration logic for csi-node to control-plane via rest api.
- This csi-node info would be used to issue FIFREEZE and FITHAW via csi-controller.
- Moves the rest api client to the common csi-driver library to be used by both csi-controller and csi-node.

bors try

bors try

bors merge


gcsfs: remove subtree once new release becomes available

dd610280df78e5d2b2351cb95dd0395963154541 adds gcsfs as a subtree to pull in some needed upstream bug fixes, and make them available for dataflow jobs.
This commit can be reverted once gcsfs v2021.04.1 is released, and the dataflow jobs updated to use this new release.

Closed by #1258


StorScore fails with error - invalid parameter under certain conditions

StorScore seems to have an assumption that the drive(s) under test are using a small sector size.
As an example, storscore tries to execute this command, and it fails to start threads due to error 87 (invalid parameters)
DiskSpd.exe -w100 -si -b1K -t4 -o64 -a0,2,4,6,8,10,12,14,16,18,20,22,1,3,5,7,9,11,13,15,17,19,21,23 -L -h -d300 -Z20M,"C:\StorScore\entropy\0_pct_comp.bin" D:\testfile.dat
When I investigated the scenario, the logical sector size was 4K, but Diskspeed was using a stripe size of 1K, which would not have worked.  Changing the command line to use a block size and stripe size of 4K permitted the test to run.
Can anything be done to validate the parameters against the test devices logical and physical characteristics to prevent logs reporting failures?

This is a good idea for an enhancement.  My guess is that it wouldn't be too hard.
We could probably add a helper function in util.pm that gets the device sector size with WMIC or something, and then reflect this into the Target.pm object itself, as we do with is_ssd() and others.
After we parse the recipe, we could emit a big scary warning if any of the tests include block sizes < the sector size.


smallfile requires the --top directory to be mounted on driver

This is new behavior (version : 3.1) that doesn't seem correct. I've never had to have the target directory mounted on the driver used to run smallfile tests on remote clients.
# ./smallfile_cli.py --host-set "gprfc001" --response-times N --same-dir N --stonewall N --top /mnt/cephfs/smf/ --network-sync-dir /smfnfs/sync/ --threads 1 --files 256 --files-per-dir 1000 --file-size 4 --file-size-distribution exponential --operation create

ERROR: you must ensure that shared directory /mnt/cephfs/smf is accessible from this host and every remote host in test

on baremetal RHEL 7.5 (3.10.0-862)

@wilkins11 reproduced, found root cause, fix is on the way

this commit should fix it, @wilkins11

closing due to lack of feedback


datatype: al_international_phone phone number fields confused some testers

In user testing, a couple people have gotten confused by the placeholder text in these datatype: al_international_phone phone number fields. They thought they were already filled in. I wonder if having<PHONE_NUMBER> would be better instead of what looks like a real phone number?

Agreed, this has confused me too. @plocket do you know if this is a hardcoded feature or something we can turn off? I know we mostly just adapted an existing library...

I found it--autoPlaceholder
https://github.com/jackocnr/intl-tel-input#demo-and-examples

https://github.com/jackocnr/intl-tel-input#initialisation-options

Reading the docs, AL actually doesn't need to change anything at all. A dev can just set the attribute hint: to override the unwanted number. For example, if you want it to appear as if there is no placeholder number, use a space:
question: |
  Contact info
fields:
  - Your number: phone_number
    datatype: al_international_phone
    hint: " "

Made #205 to add this to the demo file

If the hint isn't provided, should and can the default change? I'm not sure the placeholder is ever helpful for people.

Do you want me to try to turn it off completely? I believe it's possible.

I think it's worth turning off, yeah. This is the research I've previously seen on this: https://www.nngroup.com/articles/form-design-placeholders/


Add generateApis and generateModels options

Many thanks for submitting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:
Fix #802

[x] You have read the contributors guide
[x] Your code is properly formatted according to our code style
[x] Pull Request title contains the target branch if not targeting main: [0.9.x] Subject
[x] Pull Request contains link to the issue
[ ] Pull Request contains link to any dependent or related Pull Request
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-quarkus2 to backport the original PR to the quarkus2 branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.
If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

Thanks @andybarilla nice contribution! Could you add a documentation about it?

Docs have been added

@andybarilla did you had the chance to see my comments?

@andybarilla did you had the chance to see my comments?

Just saw them now. Yeah, I can add some integration tests.

LGTM. @andybarilla, could you please squash the commits?

@hbelmiro anything else to add?