DOC: Remove mistake from ImageRegion::IsInside(region) documentation

Reverted commit a872710c63ab223e78f45de8d3e4bc435172867d
"STYLE: Documenting the behavior of the IsInside() method when the argument region has zero size in any of its dimensions" by Luis Ibanez (@luisibanez), 18 December 2009
Unlike the original documentation, ImageRegion::IsInside(region) may in some cases return true, even when the argument region has zero size!
Examples:
using RegionType = ImageRegion<2>;
using IndexType = RegionType::IndexType;
using SizeType = RegionType::SizeType;

const RegionType currentRegion1(IndexType::Filled(-1), SizeType::Filled(2));
const RegionType zeroSizedRegion1{};

EXPECT_TRUE(currentRegion1.IsInside(zeroSizedRegion1)); // OK: returns true!

const RegionType currentRegion2(SizeType::Filled(2));
const RegionType zeroSizedRegion2(IndexType::Filled(1), SizeType{ { 0 } });

EXPECT_TRUE(currentRegion2.IsInside(zeroSizedRegion2)); // OK: returns true!

Simplified the implementation of ImageRegion::IsInside(const Self &), assuming that it may return true for a zero-sized region as argument, when the index (start corner position) of this zero-sized region is inside the current region.

Discussion topic at discourse.itk.org: What bool value should imageRegion.IsInside(zeroSizedRegion) return?

Please note that the second commit, "PERF: Simplify ImageRegion::IsInside(const Self &)" does introduce a very small behavior change, compared to the old code. The old code considered zero-sized regions to be inside the current region when their index (their start corner position) would be inside the current region, except when such an index would be at the left or top border of the current region!
The commit "PERF: Simplify ImageRegion::IsInside(const Self &)" does not make such an exception. With this commit, zero-sized regions are considered inside the current region whenever their index is inside the current region.
This little behavior change did not cause any test regression error.

If the outer region has an upper left corner (0, 0) and is size (10, 10) then its lower right corner is (9, 9), right?  I didn't check the old code, but with the new code any region with corner (x, y) and size (0, 0) will be inside so long as x, y ∈ {0, 1, ..., 10}.  In particular, (x, y) = (10, 10) is inside.  Is this what we want?  Regardless of what we want it to be, if it doesn't already, the documentation should probably mention the behavior for this case.
In a more purely mathematical sense, I would think that if any dimension is zero then the region has no pixels; and all the pixels -- all zero of them -- are in the bigger region (even if it too has zero pixels).  So, we could return true in that case regardless of the corner.  But that's math not image analysis.  We should do what image analysis demands, and probably document any differences from this mathematical approach in the documentations.

If the outer region has an upper left corner (0, 0) and is size (10, 10) then its lower right corner is (9, 9), right? I didn't check the old code, but with the new code any region with corner (x, y) and size (0, 0) will be inside so long as x, y ∈ {0, 1, ..., 10}. In particular, (x, y) = (10, 10) is inside. Is this what we want?

That certainly is not what I expect! In your case, any region with index (10, 10) should be considered outside the outer region, according to both the original and the proposed new code.
Is the following what you mean?
using RegionType = ImageRegion<2>;
using IndexType = RegionType::IndexType;
using SizeType = RegionType::SizeType;

const RegionType outerRegion(IndexType{ { 0 } }, SizeType::Filled(10));
const RegionType zeroSizedRegion(IndexType::Filled(10), SizeType{ { 0 } });

EXPECT_FALSE(outerRegion.IsInside(zeroSizedRegion));

EXPECT_FALSE(outerRegion.IsInside(zeroSizedRegion));

I don't know the use case for this code, so I don't know what the right answer should be for this zero-sized region, or for zero-sized regions generally.  The current code in this pull request will give true.  However, if that's wrong then, yes, your code is the correct test.
If the mathy approach described above is correct and we should be returning true whenever otherRegion has zero pixels, then the source code could be
bool
IsInside(const Self & otherRegion) const
{
  const auto otherIndex = otherRegion.m_Index;
  const auto otherSize = otherRegion.m_Size;

  // If otherRegion has zero pixels then every pixel -- all zero of them -- are inside the current region.
  for (unsigned int i = 0; i < ImageDimension; ++i)
  {
    if (otherSize[i] == 0)
    {
      return true;
    }
  }

  for (unsigned int i = 0; i < ImageDimension; ++i)
  {
    if (otherIndex[i] < m_Index[i] ||
        otherIndex[i] + static_cast<IndexValueType>(otherSize[i]) > m_Index[i] + static_cast<IndexValueType>(m_Size[i]))
    {
      return false;
    }
  }
  return true;
}

The comment deleted by this pull request
  /** Test if a region (the argument) is completely inside of this region. If
   * the region that is passed as argument to this method, has a size of value
   * zero, then it will not be considered to be inside of the current region,
   * even its starting index is inside. */

indicates the opposite of my mathy example: that is, if otherRegion has zero pixels then always return false.  If that is our goal then the code can go back to using one loop:
bool
IsInside(const Self & otherRegion) const
{
  const IndexType otherIndex = otherRegion.m_Index;
  const SizeType  otherSize = otherRegion.m_Size;

  // If otherRegion has zero pixels or is not wholly inside then return false.
  for (unsigned int i = 0; i < ImageDimension; ++i)
  {
    if (otherSize[i] == 0 || otherIndex[i] < m_Index[i] ||
        otherIndex[i] + static_cast<IndexValueType>(otherSize[i]) > m_Index[i] + static_cast<IndexValueType>(m_Size[i]))
    {
      return false;
    }
  }
  return true;
}

EXPECT_FALSE(outerRegion.IsInside(zeroSizedRegion));

I don't know the use case for this code, so I don't know what the right answer should be for this zero-sized region, or for zero-sized regions generally. The current code in this pull request will give true. However, if that's wrong then, yes, your code is the correct test.

I did not realize before that my proposed adjustment would consider a zero-sized region with index (10, 10) inside your outer region of size 10x10, so thanks for the heads up, Lee! 😮
So now I'm not entirely sure anymore.  I do like the relative simplicity of having just a single for loop and a single if statement, as currently in this PR:
if ((otherIndex[i] < m_Index[i]) || ((otherIndex[i] + static_cast<IndexValueType>(otherSize[i])) >
                                      (m_Index[i] + static_cast<IndexValueType>(m_Size[i]))))
{
  return false;
}

I don't really like to have extra code, just for the very specific case of a zero-sized region. Especially because in practice, the return value does not seem to matter much for a zero-sized region as argument. On the other hand, I don't want the result to be counterintuitive 🤔
The original code treated the left and the upper border positions of the outer region different from the rest of the outer region, when used as the index of a zero-sized region as argument. That did not seem intuitive either, did it?

The comment deleted by this pull request
  /** Test if a region (the argument) is completely inside of this region. If
   * the region that is passed as argument to this method, has a size of value
   * zero, then it will not be considered to be inside of the current region,
   * even its starting index is inside. */

indicates the opposite of my mathy example

@Leengit Indeed! That's my alternative for this pull request: #3110 "BUG: region.IsInside(zeroSizedRegion) should always return false"  😄

I don't have time to read this whole thread. There is a mixing of documentation changes, behavioral changes, performance changes and style changes.
Please keep the current behavior, add test to ensure that it is preserved. It is very likely some code inside or outside ITK relies on the current behavior. Perhaps the ITK test still passes, because it is not correctly checking the results. Or code outside ITK, is not part to ITK regressions checks.
Again please keep the current behavior.

@blowekamp

I don't have time to read this whole thread
...
Again please keep the current behavior.

Please take your time to read the issue, Bradley. The current version is both unnecessary slow and inconsistent, with respect to zero-sized regions. I think it must be fixed one way or the other.
I can imagine that we leave the old (slow and inconsistent) behavior behind an #if LEGACY, though.

Correct me if I am wrong. You encountered a discrepancy between behavior and documentation. I support correcting the documentation to what the community has been using for over a decade. You have a theoretical ( not measured ) performance improvement, that is also not driven by improvement to a particular application.
I don't find it worth the risk for breaking the communities code, and waisting their time tracking down the bug for these theoretical reasons. People can move for other tool kits when frustrated with breaking and unpredictable changes in a toolkit.
And no mater what the file change is the behavior should be correctly documented in the methods doxygen string, and a test added for this special case.

To be clear the behavior of the old code is as follows.  With InputRegion.IsInside(QueryRegion) for an InputRegion that has index (0, 0) and size (10, 10) and a QueryRegion that has index (x, y) and size (1, 1), the method returns true exactly when x, y ∈ {0, 1, ..., 9}.  That's normal.
If instead QueryRegion has index (x, y) and size (0, 0) then the method returns true exactly when x, y ∈ {1, ..., 9}.  That is, the top row and left column are now excluded.  I am thinking that the relevant question is whether it is likely that there is code out there that is depending on this behavior.

For a paleontological perspective, when the documentation commit was made in 2009 was when I was working on the initial IO streaming making heavy use of regions and region splitters.
Thank you for the clear example @Leengit, looks like some good cases for some tests.

@N-Dekker since Jon Haitz is taking a break, I feel obliged to point this out: it would be good if you added the various examples from this PR's discussion as test cases in the code.

it would be good if you added the various examples from this PR's discussion as test cases in the code.

@dzenanz  Just added a unit test, with my latest force-push Hope you like it  😃

I like it. Can we test some indices which are outside?

Thanks @dzenanz. Yes, we can test some indices outside the outer region, but then, what would you expect for a zero-sized region?  Or would it be OK to you to just do this test for non-zero-sized regions (and then, expect IsInside to always return false, of course.)

The more tests, the better. Ideally test both zero-sized and non-zero-sized regions with start indices outside of the main region.

After the discussion here, I now prefer the other solution, PR #3110.

I just merged #3110, so I am closing this competing PR.


Arrow load leads to incorrect results in omnisci core

Steps to reproduce:
import pyarrow as pa
import pandas as pd

conn.execute("CREATE TABLE wam_dates_arrow(a date)")

s = pd.Series([date(2018, 12, 31), None, date(2000, 1, 1)])
arr = pa.array(s)

conn.load_table('wam_dates_arrow', pd.DataFrame(arr.to_pandas()))
conn.select_ipc("select a from wam_dates_arrow")

This is a small issue with core side, I am opening a PR there to fix this, opening an issue here to document this.

Update: PR https://github.com/omnisci/mapd-core-internal/pull/3220 has been merged, test and validated. Arrow imports should be good now.

Did this make it to 4.6 @wamsiv? If so, should probably close

Yes, it did, forgot to close this. Thank you.


Retain operation level parameters over path level ones

Motivation
Fixes https://github.com/apple/swift-openapi-generator/issues/168.
Modifications
Previously, an operation's parameters were returned as a concatenation of the parameters from the path item level with those at operation level.
However, this is incorrect according to https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#fixed-fields-7.

A list of parameters that are applicable for all the operations described under this path. These parameters can be overridden at the operation level, but cannot be removed there. The list MUST NOT include duplicated parameters.

With this change, we are merging the two arrays of parameters using a unique identifier of the location + name of parameters. If duplicate parameters exist, only the parameters from the operation level are preserved.
Result
After this change, an operation's parameters won't contain any duplicate.
Test Plan
[Describe the steps you took, or will take, to qualify the change - such as adjusting tests and manual testing.]

The change looks good, just a few minor style suggestions.
For testing, you can create a new unit test file Tests/OpenAPIGeneratorCoreTests/Translator/Operations/Test_OperationDescription.swift, follow the style seen e.g. in Tests/OpenAPIGeneratorCoreTests/Translator/Content/Test_ContentType.swift, and create an OperationDescription with duplicated params in the path and operation in the unit test and verify that allParameters returns just the unique ones.

Thank you for the nice review, I applied all suggestions! 🙂
I'll add a test shortly and mark this as ready for review.

@swift-server-bot add to allowlist


Cluster Upgrade stuck if EKS Cluster was updated manually

What kind of request is this (question/bug/enhancement/feature request): bug
Steps to reproduce (least amount of steps as possible):

Create EKS Cluster with Rancher(use a previous version to be able to upgrade ot the newest one)
Manually Update the EKS Cluster via AWS Console
Edit the Cluster in Rancher and set k8s Version to the most recent one

Result:
Cluster is stuck in upgrade process:
InvalidParameterException: Unsupported Kubernetes minor version update from 1.14 to 1.14 status code: 400, request id: 0ccda22c-e6ad-47ba-a0e4-4bdbf1b0f4ce
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):

Cluster was initially created with Rancher 2.2.x
Updated the Cluster with Rancher 2.3.2 to k8s Version 1.14

Installation option (single install/HA): HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): EKS
Machine type (cloud/VM/metal) and specifications (CPU/memory): c5.4xlarge (16/32G)
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"archive", BuildDate:"2019-08-29T18:43:18Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.6-eks-5047ed", GitCommit:"5047edce664593832e9b889e447ac75ab104f527", GitTreeState:"clean", BuildDate:"2019-08-21T22:32:40Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a215d7133c34aa18e3b72b4a21fd0c6136
 Built:             Mon Mar  4 21:25:41 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a/18.06.1-ce
  Built:            Mon Mar  4 21:27:07 2019
  OS/Arch:          linux/amd64
  Experimental:     false

This discrepancy can also occur during EKS version deprecation, where clusters are automatically updated out of band.
As such, an enhancement could be to sync the current EKS version with DescribeCluster. This could be periodically, before an update, or when handling this exception to alleviate looping on the UpdateCluster API call.

@dkeightley what you described is a separate issue. As far as rancher is concerned, the version has not changed, so it will not communicate anything to EKS. In the first case mentioned, the version has changed and rancher attempts to communicate an update to EKS, which ends returns an errors because eks is already on that version.

Created backport issue, this will be used to track master, the other will be for 2.4. There is no milestone for 2.5 yet, so it will stay as 2.4.

Validated in master-2689-head commit id d18a0b6b4
Scenario 1:

Upgrading purely through Rancher is successful and updates the cluster to the selected version in AWS

Scenario 2:

Upgrading through AWS UI upgrades the cluster in AWS but does not communicate the upgrade to Rancher
Edit cluster through Rancher UI to sync the version to be what it is in AWS UI is successful

NOTE: Remember that when updating the cluster whether with Rancher or AWS, it does not automatically upgrade the nodes, so those must be done separately. This can be done through CloudFormation by changing at minimum the AMI that is used.

Validated in v2.4-2696-head (commit id 04159d027)
Performed the same scenarios as above. For scenario 2, I waited a bit longer before editing the cluster, and AWS did communicate properly to Rancher. It appears the sync just takes a little bit of time (my rough guess looks like approx. 5-15 minutes)


Address lexical variable internationalization issues

This PR addresses two issues. First, event parameters are not properly internationalized when switching between projects. Second, while testing the first change I noticed that the 'global' keyword in variable names isn't internationalized, so I took care of that. There will be a separate PR that addresses some larger issues I also encountered.
Fixes #708

Note that I can also split this into two separate PRs if that's preferable.

@josmas That was intentional to handle the renaming of lexical variables within an event handler. Today, if you do so in a non-English language, the name collision will detect a collection with the translated name but not the code name. This can result in people writing code where they create an inner variable that shadows the out variable even though the names in the blocks are distinct, e.g., nombreDeFuncion and functionName. You can create a variable called functionName that doesn't collide with the translated name but shadows the real code name because the Spanish name is only presentational, not semantic. The declaredNames function is called to get all of the declared names that a block defines, which for most variable blocks will just be the code name. In the case of event handlers, it returns the set of both translated and untranslated names to correctly handle name collisions.


Git Sync behaviour is broken

Expected Behavior
I should be able to pull, push , and resolve conflicts if there are any.
Actual Behavior
It's showing uncommitted changes when i see in document

when i try to see changes , it shows no changes

when i tried to pull, it shows no conflict supported

So basically, I am blocked as I can not do any actions , Please suggest how to fix this.
Reproduction Steps

Sync Document with git repository
Add API Spec
Add API collections
Add Tests

Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No response
Insomnia Version
10.1.0-beta.2
What operating system are you using?
macOS
Operating System Version
15.0.1
Installation method
download from insomnia website
Last Known Working Insomnia version
NA

Also getting error when tried to fetch
An internal error caused this command to fail. Please file a bug report at https://github.com/isomorphic-git/isomorphic-git/issues with this error message: Index file is empty (.git/index)

When i dropped the document and tried to resync, it loaded very slowly, and after making some changes, when I tried to revert the changes, the Rollback action was not working

We are about to push an large amount of improvements on Git next week in v10.1.
cc @gatzjames

Hey @shubhendu-enable we have made some significant updates to the Git UX in the app in the latest beta if you want to try it out and let us know how it works for you.
It will be available soon in the next patch release

@gatzjames
I upgraded to Version: Insomnia 10.1.0
Some observations on git sync behaviour:

First, the UI interface for git commit is much better now, Thanks for updating this commit experience.
Performance perspective git sync is still slow and has some unexpected behavior,

Once I click on commit changes - it takes between 1-2 min to load changes and shows Stage Changes and Changes
If I click on any of the changes to see the difference, it again takes around 1 min to see the difference
Next, i want to stage some changes, this process also takes around 1 min to reflect on the staged changes section and in between this process other actions on the screen became unresponsive
I tried to rollback some changes from the Changes Section, but instead of rolling back that change, the application routed back to Collections.


Recursive strategies do not shrink by depth as "expected"

While trying to improve the definition of Strategy for Recursive<..> in PR #40 I later realized that IndFlatten was being used, so the input strategy (bool::Weighted) is never shrunk, and so the depth of a recursive type is never shrunk as "expected" (at least by users of QuickCheck in asorted languages?). In other words, the following test holds:
#[test]
fn test_recursive_depth_shrink() {
    #[derive(Clone, Debug)]
    enum Nat { Z, S(Box<Nat>) }
    impl Nat {
        fn size(&self) -> usize {
            if let Nat::S(ref nat) = *self { 1 + nat.size() } else { 0 }
        }
    }

    let strat = Just(Nat::Z).prop_recursive(4, 1, 1,
        |strat| strat.prop_map(|nat| Nat::S(Box::new(nat)))
    );

    let mut runner = TestRunner::default();
    for _ in 0..::std::u16::MAX {
        let mut vt = strat.new_value(&mut runner).unwrap();
        let curr = vt.current().size();
        while vt.simplify() {}
        assert_eq!(curr, vt.current().size());
    }
}

while you could reasonably expect that the following should hold instead:
        let mut runner = TestRunner::default();
        for _ in 0..::std::u16::MAX {
            let mut vt = strat.new_value(&mut runner).unwrap();
            while vt.simplify() {}
            assert_eq!(0, vt.current().size());
        }

that is, if you shrink a Nat maximally, you should always end up with 0 as size (which is the same as the depth in this case).
We could of course change IndFlatten to Flatten in which case it does hold, but then you get into complicate_regen_remaining and such...
I think in any case, we should document the shrinking behavior that is used... But is the current behavior right?

Thanks for bringing this to my attention. I think prop_recursive() predates unions supporting weights, so it had an inline implementation of IndFlatten that was later changed to IndFlatten itself.
As of 0.5.1, it uses prop_oneof! with weights , so it now shrinks correctly.


deleteMin appears to be O(n); not O(log(n)) as expected from a balanced binary tree.

deleteMin calls remoteAt(0). This code
https://github.com/google/btree/blob/master/btree.go#L153
makes it look like every deleteMin will therefore be O(n) in the size of the tree n, as it does a full copy of the entire tree.
This is really, really, not what I would expect from a balanced binary tree implementation. Deleting the entire tree becomes an O(n*n) operation.

Incorrect, but I can see how you got there. :)
The items field is used to store items within a single node.  The https://github.com/google/btree/blob/master/btree.go#L153 function removes an element from that node.  items will have a length determined by the degree of the tree, so the function will run in O(degree), not O(n).
The actual delete (and associated O(logn) tree traversal) is at https://github.com/google/btree/blob/master/btree.go#L380.  It does an O(logn) to find the node, then the O(degree) to remove from that node's items list.

Whew.


Experiment with monomorph CreateRunner

Description
Get rid of the generic parameter to CreateRunner, to unify with the other scheduler runnables, and to target a suggestion in #2485. I want to see if this has any impact on generated code size, first.
Checklist

[x] This is just an experiment for now

How did this experiment go, in your opinion? It looks fine to me, from the binary size changes.
I tried replacing Box<dyn Runnable> for fields in Scheduler with their concrete types but CreateRunner blocks that. Do you think we should pursue this path?

Binary size change is small enough (and should be repeated with the nightly optimizations on, anyway). But I don't like the increased code complexity as much. I think it's fine to leave this scheduled runnable for now as a Box::new(), the other events should happen more often anyway.


Update txType in private message schema

Signed-off-by: Gabriel Indik<EMAIL_ADDRESS>

For some endpoints the Swagger is not dynamically generated, but instead it relies on a fixed schema. In the case of private messages, it looks like the data structure has been changed but the schema has not been updated accordingly. This PR updates the schema. Once the dynamic generation covers all endpoints, these updates won't be required.

Codecov Report

Merging #637 (ede5ef7) into main (0e10191) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##              main     #637      +/-   ##
===========================================
- Coverage   100.00%   99.98%   -0.02%
===========================================
  Files          311      311
  Lines        18860    18882      +22
===========================================
+ Hits         18860    18879      +19
- Misses           0        2       +2
- Partials         0        1       +1

Impacted Files
Coverage Δ

...ternal/apiserver/route_post_new_message_private.go
100.00% <ø> (ø)

pkg/wsclient/wsclient.go
98.36% <0.00%> (-1.64%)
:arrow_down:

internal/config/config.go
100.00% <0.00%> (ø)

internal/txcommon/txcommon.go
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


Support English translation or more

I'm submitting a...

[ ] Bug report
[x ] Feature request
[ ] Documentation issue or request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Support request => Please do not submit support request here

Current behavior
At the moment, all components support only Chinese language
Expected behavior
Components should support at least Chinese and English language
What is the motivation / use case for changing the behavior?
A more people can use the library then now. I suggest looking towards ngx-translate https://github.com/ngx-translate/core
P/S For React components there is a LocaleProvider https://ant.design/components/locale-provider/

@zverbeta
thanks for your feedback, supporting other language is on our plan. we are working on it.


doesn't work

ubuntu 20.04
vscode lastest.
command: background-selectImage
nothing changed

for me as well

Please update Zhang


Add SIG Node Spotlight

Add the SIG Node spotlight interview.
The contributor-site article has been reviewed:  https://github.com/kubernetes/contributor-site/pull/498 ; this is a copy of the lastest version, with minor changes due to the different formats.

Hi @fsmunoz, thanks you for your contribution.
Could you please sign the CLA before the PR can be reviewed.
You can follow the steps documented here: https://git.k8s.io/community/CLA.md

Deployment preview : https://deploy-preview-46454--kubernetes-io-main-staging.netlify.app/blog/2024/05/21/sig-node-spotlight-2024/

Hi @fsmunoz, thanks you for your contribution. Could you please sign the CLA before the PR can be reviewed. You can follow the steps documented here: https://git.k8s.io/community/CLA.md

I have already signed it yesterday.

/easycla

Looks like this is missing a CLA for one of the listed coauthors.

/check-cla

/hold
pending CLA issues being cleared on https://github.com/kubernetes/contributor-site/pull/498 and for this PR
Also, don't remove the hold if the listed publication date is in the past

per https://github.com/kubernetes/contributor-site/pull/498
We'll need to push the publication date back further. I suggest mid-June (let's say the 14th) and then we see if we can get a review on the two blog article PRs ahead of that date.

@fsmunoz - did you mean to close this?

@sftim no, side-effect of deleting my website fork to be able to fork the other one... I'll reopen this one after I'm done with that (or try to at least).
I'll take care of the missing CLA afterward.

/reopen


controllers stop keystroke propagation instead of entire GUI

e.stopPropagation() used to be called for every keyup/down triggered within the GUI's DOM tree. Now that's applied per controller. Should fix #69.
Folders headers will still "eat" keystrokes if the keystroke is Space or Enter (used for toggling open/close).

note to self: i'm not sure why the folder headers are  instead of  — we wouldn't have to rewrite the enter/space logic and some of the aria attributes can go away


Problem SharePoint Online - Display Traffic Light JSON (Chrome vs Edge)

Hi,
On our Sharepoint site, we have columns that appear differently depending on the browser (Chrome vs Edge). For example, in the same column, we will see a green indicator (normal behavior) in MS Edge while the green indicator will not be showing in Chrome.
Here is the code :
{
    "$schema": "http://columnformatting.sharepointpnp.com/columnFormattingSchema.json",
    "debugMode": true,
    "elmType": "div",
    "children": [
        {
            "elmType": "span",
            "style": {
                "width": "14px",
                "height": "14px",
                "border-radius": "14px",
                "background-color": {
                    "operator": "?",
                    "operands": [
                        {
                            "operator": "==",
                            "operands": [
                                {
                                    "operator": "toString()",
                                    "operands": [
                                        "@currentField"
                                    ]
                                },
                                "Oui"
                            ]
                        },
                        "#2dc937",
                        {
                            "operator": "?",
                            "operands":[
                                {
                                    "operator": "==",
                                    "operands": [
                                        {
                                            "operator": "toString()",
                                            "operands": [
                                                "@currentField"
                                            ]
                                        },
                                        "N/A"
                                    ]
                                },
                                "#e7b416",
                                {
                                    "operator": "?",
                                    "operands":[
                                        {
                                            "operator": "==",
                                            "operands": [
                                                {
                                                    "operator": "toString()",
                                                    "operands": [
                                                        "@currentField"
                                                    ]
                                                },
                                                "Non"
                                            ]
                                        },
                                        "#cc3232",
                                        ""
                                    ]
                                }
                            ]
                        }
                    ]
                }
            }
        }
    ]
}

Thank you !!

Is this still an issue for you? I have used your sample and have no problem seeing the traffic lights in Chrome.
If this is still occurring, a screenshot (just paste it in the reply) would really help. Thanks!

I'm closing this issue for now due to inactivity, but feel free to reply or reopen once you are able. Thanks!


Missing Release Notes

Current release notes are missing information on New Features, Fixes, and Breaking Changes. An overview of these changes would help developers understand changes in the repo without running through the commit history or compare releases/tags.
A suggested format:
New Features

name of feature (commit link)
etc

Fixes

idem

Breaking Changes

idem

Notes are added


[UsePythonVersionV0] Add GitHub authentication

Task name: UsePythonVersionV0
Description: Current implementation will hit the download limit: https://github.com/microsoft/azure-pipelines-tasks/pull/15820#issuecomment-1059761030. Need to add GitHub token auth.
Tool-lib PR for custom auth support needs to be merged first for these changes to work.
Documentation changes required: No
Added unit tests: No
Checklist:

[x] Task version was bumped - please check instruction how to do it
[x] Checked that applied changes work as expected

Closing in favor of PR from fork due to permission loss


fix bug in build file for gradle template

when metadata generator starts to generate .dat files it needs the output directory to be created beforehand or else it blows up
put quotes(") instead of apostrophe(') because when you want to use "$rootDir/..." syntax you can't use apostrophe

:+1:


feature: add clusterctl tool to arkade

Signed-off-by: Carlos Panato<EMAIL_ADDRESS>
Description
Add clusterctl tool (https://github.com/kubernetes-sigs/cluster-api) to arkade
Motivation and Context

[ ] I have raised an issue to propose this change, which has been given a label of design/approved by a maintainer (required)

How Has This Been Tested?
build this branch and then run
$ ./arkade get clusterctl
Downloading: clusterctl
2021/11/12 09:54:15 Looking up version for clusterctl
2021/11/12 09:54:16 Found: v1.0.0
Downloading: https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.0.0/clusterctl-darwin-amd64
51.10 MiB / 51.10 MiB [------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------] 100.00%
/var/folders/cz/_mkxxyx97n38b5p0hs3n2j2m0000gn/T/clusterctl-darwin-amd64 written.
2021/11/12 09:54:18 Looking up version for clusterctl
2021/11/12 09:54:18 Found: v1.0.0
2021/11/12 09:54:18 Copying /var/folders/cz/_mkxxyx97n38b5p0hs3n2j2m0000gn/T/clusterctl-darwin-amd64 to /Users/cpanato/.arkade/bin/clusterctl

Tool written to: /Users/cpanato/.arkade/bin/clusterctl

# Add arkade binary directory to your PATH variable
export PATH=$PATH:$HOME/.arkade/bin/

# Test the binary:
/Users/cpanato/.arkade/bin/clusterctl

# Or install with:
sudo mv /Users/cpanato/.arkade/bin/clusterctl /usr/local/bin/

Are you a GitHub Sponsor (Yes/No?)

[x] Yes
[ ] No

Types of changes

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

Documentation

[x] I have updated the list of tools in README.md if (required) with ./arkade get -o markdown
[ ] I have updated the list of apps in README.md if (required) with ./arkade install --help

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I've read the CONTRIBUTION guide
[x] I have signed-off my commits with git commit -s
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

[ ] I have tested this on arm, or have added code to prevent deployment

/assign @alexellis

Approved
But, we need to regenerate the README text instead of editing it manually, because it includes a count of CLIs that needs to go up.

I've run the ./arkade get -o markdown and paste the out put in the readme have anything else to do?


OS X El Capitan displays wrong OS version number in error message

Live Share requires MacOS Sierra or better (due to .NET Core 2.0). The error message in VSCode under OS X El Capitan is confusing because an error message displayed (when on El Capitan) cites the wrong version of the OS.

Product and Version [VS/VSCode]: VSCode 1.21.1
OS Version [macOS/Windows]: MacOS 10.11.6
Live Share Extension Version: 0.2.163
Target Platform or Language [e.g. Node.js]: N/A
Steps to Reproduce / Scenario:

Have OS X El Capitan as operating system
Install VS Live Share extension in VSCode
Witness error notification stating "Your version of MacOS (incorrect version number here) is not compatible with this version of Visual Studio Live Share.

This one was resolved in 0.2.399.

@Haddassah El Capitan is not supported, but the version number in the message was corrected. If the error message is still wrong, it might have regressed.


RC test: Natural Selection 1.4.0-rc.2

@KatieWoe, @kathy-phet, @amanda-phet, natural-selection/1.4.0-rc.2 is ready for RC testing.
Document issues in https://github.com/phetsims/natural-selection/issues and link to this
issue.
This is a spot-check, with no specific platforms that need testing.
Assigning to @kathy-phet and @KatieWoe for prioritization.

General RC Test

What to Test

Click every single button.
Test all possible forms of input.

Test all mouse/trackpad inputs.
Test all touchscreen inputs.

If there is sound, make sure it works.
Make sure you can't lose anything.
Play with the sim normally.
Try to break the sim.
Test all query parameters on all platforms. See QA Book for a list of query parameters.
Download HTML on Chrome and iOS.
Make sure the iFrame version of the simulation is working as intended on all platforms.
Make sure the XHTML version of the simulation is working as intended on all platforms.
Complete the test matrix.
Don't forget to make sure the sim works with Legends of Learning.
Test the Game Up harness on at least one platform.
Check this LoL spreadsheet and notify AR or AM if it not there.
If this is rc.1 please do a memory test.
When making an issue, check to see if it was in a previously published version
Try to include version numbers for browsers
If there is a console available, check for errors and include them in the Problem Description.
As an RC begins and ends, check the sim repo. If there is a maintenance issue, check it and notify developers if there is a problem.

Issues to Verify

[x] https://github.com/phetsims/natural-selection/issues/291
[x] https://github.com/phetsims/natural-selection/issues/299

These issues have the "status:ready-for-qa" label. Check these issues off and close them if they are fixed. Otherwise, post a comment in the issue saying that it wasn't fixed and link back to this issue.

Link(s)

Simulation
iFrame
XHTML
Test Matrix

PhET-iO RC Test

What to Test

Make sure that public files do not have password protection. Use a private browser for this.
Make sure that private files do have password protection. Use a private browser for this.
Make sure standalone sim is working properly.
Make sure the wrapper index is working properly.
Make sure each wrapper is working properly.
Launch the simulation in Studio with ?stringTest=xss and make sure the sim doesn't navigate to youtube
For newer PhET-iO wrapper indices, save the "basic example of a functional wrapper" as a .html file and open it. Make sure the simulation loads without crashing or throwing errors.
For an update or maintenance release please check the backwards compatibility of the playback wrapper. Here's the link to the previous wrapper.
Load the login wrapper just to make sure it works. Do so by adding this link from the sim deployed root:/wrappers/login/?wrapper=record&validationRule=validateDigits&&numberOfDigits=5&promptText=ENTER_A_5_DIGIT_NUMBER

Further instructions in QA Book
Conduct a recording test to Metacog, further instructions in the QA Book. Do this for iPadOS + Safari and one other random platform.
Conduct a memory test on the stand alone sim wrapper (rc.1).
Test one platform combination with ?phetioDebug on the Studio and State wrapper.
If Pan/Zoom is supported, make sure that it works when set with PhET-iO State.
If filled in by issue creator, please test the diff wrapper against version 1.3.1
Test that the sim works offline:

Go to https://phet-dev.colorado.edu/html/natural-selection/1.4.0-rc.2/phet-io/natural-selection-phet-io-1.4.0-rc.2.zip
download it
unzip it to a spot locally
Open index.html by double clicking it on your desktop or in a finder-view.
It should look like the standalone version of the sim in PhET-iO brand.

Issues to Verify

[x] https://github.com/phetsims/natural-selection/issues/278
[x] https://github.com/phetsims/natural-selection/issues/288
[x] https://github.com/phetsims/natural-selection/issues/295
[x] https://github.com/phetsims/natural-selection/issues/296
[x] https://github.com/phetsims/natural-selection/issues/297
[x] https://github.com/phetsims/natural-selection/issues/298
[x] https://github.com/phetsims/natural-selection/issues/300

These issues have the "status:ready-for-qa" label. Check these issues off and close them if they are fixed. Otherwise, post a comment in the issue saying that it wasn't fixed and link back to this issue.

Link(s)

Wrapper Index
Test Matrix

FAQs for QA Members

There are multiple tests in this issue... Which test should I do first?
Test in order! Test the first thing first, the second thing second, and so on.

How should I format my issue?

We typically assign the developer who opened the issue in the QA repository.

My question isn't in here... What should I do?
You should:

Consult the QA Book.
Google it.
Ask Katie.
Ask a developer.
Google it again.
Cry.

Spot check is done

Thanks @KatieWoe and QA team. We will unfortunately need another RC iteration, to fix https://github.com/phetsims/natural-selection/issues/298 and https://github.com/phetsims/natural-selection/issues/300.  Leaving this issue assigned to me until we can proceed with that next RC.

2 PhET-iO issues faild to verify in this RC.  1 new PhET-iO issues was created, see phetsims/natural-selection#300.
The next RC has been published, see #674. Closing.


Resizing 9 patched images cause problem with transparency on image

This morning when we imported a batch of 9 patch in xxxhdpi to xxhdi -> mdpi, a light grey shadow was merged with the main image that was mostly white.
I have to find some time to look into this deeper.
Thanks for your lib it saves us so much time, our designers loves it :)

Yeah scaling 9-patches is basically not 100% reliable, due to the difference in scaling algorithms for the border and the main image. You need to check the different images afterwards..


mips_siflower

mips_siflower

Is this a new architecture request?

Yea Please. It is for GL-iNet SFT1200 OPAL

mips_siflower is already a supported architecture: https://github.com/lanrat/openwrt-tailscale-repo/blob/main/build.sh#L15
https://lanrat.github.io/openwrt-tailscale-repo/packages/19.07/tailscale_1.68.0_mips_siflower.ipk


Saving thumbnail position between sessions

Thumbnail positions are not being saved between sessions.
I have Track client locations set to true, and am running the program as administrator on Win10.

So, the thumbnail location is saved per character.
Once you login to each character, the thumbnails should snap back to their last location.


UI bugs

I use Messenger reduced to one-third of my screen size, and I noticed a few bugs.
Broken typing indicator

Account information not visible (a messenger.com bug)

Settings icon missing entirely, and compose icon overlapping window buttons

A few of these have been reported before; I just wanted to consolidate.

Just what I was going to report... It's sad that this app and Goofy (another messenger client) seems abandoned now

I was using Messenger for Desktop, then tried Goofy for a few hours, and then tried this. Each have their share of bugs. So I just switched back to mobile for now.

I have made a pull requests containing fixes for at least the compose icon. It's been a while though and I don't know if the project is abandoned or not. The settings icon is removed on purpose to give the app a more native look, you can access the settings as usual on macOS (CMD+, or Preferences in menu bar).
As you said the account information is a messenger bug but the typing indicator does not happen in the browser so that is a bug specific to this app I guess. However I have no idea how to fix it in the mess of HTML we get to hack here :) I would just make the window a tiny bit bigger for now.

There's a settings icon on the release I downloaded (latest one).
It's being overlapped by the default Mac window buttons.

@amulya-b could you post an image?
If you guys are down (@hampustagerud) we could fork this and hopefully maintain these UI fixes on our own?

@amulya-b My pull request is not merged and therefore not in any release yet.
@shahzeb1 I agree that this project does not seem to be very active anymore, which is too bad. I could maintain my fork with some help but that would require quite a lot from the new maintainers. We would need a new server for sparkle updates and everyone who is using this software would need to download the new release. Not to mention that all developers would need to know where to send pull requests.
Also I don't really feel comfortable just taking @rsms work and re releasing it as a new software without him actually giving it an OK or announcing that he is no longer maintaining his repo.
Another solution would be if @rsms added more maintainers because as far as I know he is the only one. This would require access to the sparlek server or he would still need to compile and upload every release. All current users would still be able to use their software and developers could just use the base repo.
This question is maybe better discussed as a new issue?


In need of some clarity regarding how neighbouring solutions are generated for ATSP?

I am using OR-tools to solve an asymmetric travelling salesman problem. It seems to be working well as the problem is not too big (about 300 nodes), however I have a very basic question, I understand that neighbouring solutions are generated and then some kind of small change is made to generate neighbours which are then evaluated through say Simulated Annealing, What I am not certain of is how this neighbouring solutions are generated, are two edges randomly swapped or is it something else? I realise the question is quite basic but any help would be appreciated.

Please use the mailing list.

Not sure for simulated annealing but for LNS you can see here the list of operators:
https://github.com/google/or-tools/blob/45770b833997f827d322e929b1ed4781c4e60d44/ortools/constraint_solver/routing_parameters.proto#L91-L335

Thank you Mizux ended up finding that after I posted, just in case someone else sees this, the manual has more detail of how the operators are cycled through (http://www.lia.disi.unibo.it/Staff/MicheleLombardi/or-tools-doc/user_manual/manual/ls/ls_operators.html).


Bonjour constructor options type does not match mDNS options type (missing interface field)

mDNS can be bound to a specified network interface via the interface property in its Options type (see https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/multicast-dns/index.d.ts#L58). This field is not present in the ServiceConfig type, and so we're not able to bind Bonjour to a particular adapter.
This could be fixed in one of two ways:

add an interface field to ServiceConfig (though I'm not sure this is applicable to bonjour services)
create a new options type for configuring Bonjour itself (ServiceConfig may not be the appropriate type, but perhaps rather mDNS:Options)

it turns out that Node.js doesn't appear to receive multicast messages on UDP sockets bound to particular adapters, so the need to specify an adapter becomes irrelevant. This issue can probably close for that reason.


Force the use of spcaes for tabs for emacs and vi

Do we (still) need this?  It looks like Python mode is taking care of this as is.

I'll assume python mode, whatever that is, takes cars of this, and if I end up editing this file again I'll find out.


Aggregation without group by not parsed correctly

eg.
select count(*) from worksheet;
select sum(account) from worksheet;

https://github.com/cch123/elasticsql/commit/5304f3de03bc242c1fe16075f92557ae24415221


New management command

This PR adds a simple management command for denying applicants for reasons not specified in the standard admin UI.

haha! Sure. Thought I thought "denial special" sounded like something tasty you could get in a dimly-lit diner off the interstate.

sounds... yummy.......

all right - new communicative, albeit lengthy command name


remove prep argument

In #4756 : https://github.com/PennyLaneAI/pennylane/pull/4756
the prep keyword argument was removed from QuantumScript, completing its deprecation cycle. Now state prep should be placed at the beginning of the ops queue.

Codecov is failing expectedly because MPI coverage is lacking.


Fix/sign

ensures that tbDEX signature jws header kid includes absolute did url.
surface web5 sdk so that devs don't have to install find and install an additional dependency especially given that it's a hard dep.


Where to see password of the players in the plugin's folder

Is there somewhere where you can see the player information (password) in the plugin folder in the plugin folder?

No.
The passwords are stored hashed. to protect the user's digital identity.
See: https://en.wikipedia.org/wiki/Cryptographic_hash_function
If you need to reset a player's password, use /lac


Attempt decomission of  component

Task
In house component <data-table /> is currently used for components TablePools.vue and TableTokens.vue lets see if we can stop using this component and instead use the Bootstrap Vue provided component <b-table /> instead, this migration has already been started with it's use in TableTransactionsNew.vue as an example of what it might look like.
Background
<data-table /> was used in the name of extra flexibility but has come at the cost of further in house logic to maintain the component, know props and lack of documentation, we're attempting a move back to <b-table /> for more consistency, less code in the app and free documentation / maintenance of the component.
Requirements

Migration to <b-table /> must retain the same aesthetics it has in it's present form.

Bonus, if TableTransactions.vue is no longer in use because it's been replaced by TableTransactionsNew.vue please just delete TableTransactions.vue and rename TableTransactionsNew.vue to TableTransactions.vue in replacement.

this is done and can be reviewed. Two small visual aspects are not supported by the native <b-table /> component:

the sort icon can only be placed to the left or right of the table column. This restrictions is due to the way the icon is implemented by bootstrap-vue. The icon is set as CSS background and the CSS doesnt know how wide the column header text is in order to place the icon next to it.

Pagination isnt 100% as mockups show, there might be more options to get it closer to the anticipated design. We also might want to change the mockups to a more functional design. Like go to first/last page buttons. Which I think are pretty usefull.

I also created an optional wrapper for the native <b-table /> component to further reduce overhead and speed up future usage of this specific table. Usage examples can be found in TableTransactionsNew.vue or DataDetailsPool.vue

Waiting on me.

@Velua is this done?

Still determining strategy, #390 has prompted a change the current component/strategy does not allow.
Reviewing what our options are, if at the worst we'll just write it ourselves. Just cleaner if we're able to re-use things.
Priority wise I'd say this is on the back burner compared to current priorities.
@pingustar I know it's a long shot, but can you hop on their repo or whatever chat they may have and see if anyone there has an idea before we go with plan B?

@pingustar how did this go?

Bailing out on <b-table /> and going with an inhouse maintained component, should we not receive an update in 48 hours.

Change of course, now writing the component in house
@pingustar lets try replicate the original props/API as much as we can unless we've got a good reason to deviate.
Reach out to me either during design or once complete with a PR to review.
Once done we'll give @H34D the low down so he can clear up existing roadblocks posed here.

Current status:
I was able to replicate the original features using dynamic slots for the cells. Next up applying the learned knowledge to do the same with the table head.
Will let you know when I am done @Velua for review. Once review passed, I will replace all old tables with the new ones.

Awesome stuff! @pingustar

Component is done and ready for review.

Cheers @pingustar

merged to staging. PoolTable on data page is updated as reference. The other tables are following quickly now.

As much as I wanna keep this closed and move on with life, I want to make sure we don't half complete the job.
@pingustar Have we finished migrating all the tables?
Otherwise do some

[ ] Dot
[ ] points.

In a new comment on this issue and we'll finish the struggle.

@Velua all tables are migrated except for the vote proposal tables. They are giving me a hard time with vuex mutation errors. Still working on a fix.

Alright, if this is still a thing when you sign off for today leave a detailed comment of what's going on and I can take a look at it if you like.

escalated vuex mutation errors to @Velua

This component is now only used in DoneProposals

is done proposals utilized? When do proposals move over to the done tab?

is done proposals utilized? When do proposals move over to the done tab?

not yet, but should be a quick one, maybe we can open a specific issue for it and remove the old one afterwards?

https://github.com/bancorprotocol/webapp/issues/755
created an issue with both tasks - so once 755 is closed ... we can finally close this issue here too. fingers crossed ;)

@pingustar can we close this?

@pingustar can we close this?


Playback and Compare modes are broken for chats where system prompt is set in "role" : "system" in json

EPAM AI DIAL chat version
0.6.0
What happened?

Please import the following jsons
epam_ai_dial_-_development_chat_conversation_3-6 (1).json
epam_ai_dial_-_development_chat_conversation_3-6.json
Create Playback chat -> note that the order of user message and response is incorrect -> bug
Open imported file in compare mode with "normal" newly created chat -> note that the order of messages is incorrect -> bug

Expected result: correct order of messages
Confidential information

[X] I confirm that do not share any confidential information

Verified on staging and UAT servers successfully


APIGOV-27238 - fix single usage report granularity

Thinking about this issue a bit today, want @vivekschauhan's opinion too.
When the actual report sending is done we are sending from the time of the first report to the end time of the last report. Not necessarily the time of the first report to the time the send is happening.
With that said...should we additionally execute the metric collection job prior to this send? That way the usage is up to date to the execution time of the report sending?
The gap could be anywhere for 0-15 minutes if we do not do this.

Thinking about this issue a bit today, want @vivekschauhan's opinion too.
When the actual report sending is done we are sending from the time of the first report to the end time of the last report. Not necessarily the time of the first report to the time the send is happening.
With that said...should we additionally execute the metric collection job prior to this send? That way the usage is up to date to the execution time of the report sending?
The gap could be anywhere for 0-15 minutes if we do not do this.

@vivekschauhan agreed, we should call execute on the collector prior to publishing the metrics.


I was banned from the psych engine server, in my description, I had put my age wrong.

Describe your problem here.
Can someone put me on the server again? I put my age wrong in my description on my discord profile.
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No

wuts ur username i can prolly try and appeal for you

ok
My userName: phrgamerbr1692


Investigate and fix 500s when writing to Dynamo

We are getting a fairly constant stream of 500s from Dynamo when we attempt to write to it (~3-4qps on dev).
We should understand what's causing this & fix it. https://github.com/weaveworks/monitoring/issues/12 will help.

Might be related to #61, but too early to say.

According to loggly, 90% of the log lines (and therefore errors) are ProvisionedThroughputExceededException.

Write capacity was set to 400/s, which we're almost always trying to do more.  Tuning chunk size (#11) should help, but in the mean time I'll make it 1k/s.

That seems to have had a small temporary reduction, but then back to usual - we're still being throttled.  I suspect we're just trying to write to much, and the change in provisioned capacity just reset some throttling counter.

Now the ongoing deployment is done, the number of 500s has dropped dramatically (and the dynamodb latency is much improved).  So this did have an effect:

Fixed by #85


Update ESA-CCI readers (LDT & LIS) to read combined product versions >2.2

Description
Add support to LDT & LIS ESA-CCI readers to read combined product versions >2.2. Users can now use any version after 2.2. Additional supports for (possible) future ESA-CCI version > 10.0 are also included (if the product still uses this format for the future version, otherwise the code can be edited).
Testcase
The same LDT and LIS configs can be used, e.g.,
LDT
ESA CCI soil moisture observation directory: ./CCI_SM_v03.2/data/combined
ESA CCI soil moisture version of data:       3.2
LIS
ESA CCI soil moisture data directory:      ./CCI_SM_v03.2/data/combined
ESA CCI soil moisture data version:        3.2

Hi @ntangdam,
Can you point me to the config files you mentioned above? And some example target output? I don't have a testcase handy.

Hi @bmcandr,
Thanks. I have testcases + outputs at /discover/nobackup/ntangdam/pub/testcases/esacci_v3.2. Please feel free to let me know if you have any trouble accessing the files.

Hi @ntangdam,
The code changes look good and I was able to successfully reproduce the target outputs you provided. I will go ahead and merge. Thanks!


Support for nested folder determine-folder option

Our project has a number of endpoints which are nested by their endpoint name grouping.  The secondLastFolder option flattens this out, and the name chosen is not descriptive enough to show its original position in our API.
Therefore a new CLI folder option to maintain the folder and sub-folder structure of our endpoints would be very useful.
AC:
Pass in --determine-folder nestedFolders in the CLI.
Using the example test data in this project with one extra level, the output in Insomnia/Postman would look like:

A PR for this will be welcome but it is unlikely that I will invest time into this any time soon.

I have this working, but can't push the branch it seems.

If you fork this repository, you can push a branch and then open a pull request against this repository. See https://help.github.com/en/articles/creating-a-pull-request-from-a-fork

Thanks for having a look then.  Really liked how this library worked immediately without any problems.

Support was added in https://github.com/fbenz/restdocs-to-postman/pull/17


When using dev containers on docker+wsl2, inotify events are not raised

Issue Type: Bug
1- Install docker for windows
2- Create a devcontainer.json + dockerfile (or docker-compose)
3- Reopen your folder in your devcontainer
4- Create a simple react app and start it (or anything that can detect file-changes and reload itself)
5- Change the contents of a file
Expected:

inotify event should be raised and changes detected followed by a rebuild (for example)

Actual:

nothing happens

Workaround:

Enable WSL2 integration
Build your docker image manually and configure your folder as a mounted volume from the WSL2 side + expose the ports you need directly in docker-compose
Start your container
Use Remote-Containers extension to connect to it and work inside it

VS Code version: Code - Insiders 1.43.0-insider (13d7b3066ab6e8993f12c28b0ced297781055ffc, 2020-02-19T17:43:05.977Z)
OS version: Windows_NT x64 10.0.19041
Remote OS version: Linux x64 4.19.84-microsoft-standard

System Info

Item
Value

CPUs
AMD Ryzen Threadripper 2990WX 32-Core Processor (64 x 3000)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
127.89GB (48.25GB free)

Process Argv

Screen Reader
no

VM
25%

Item
Value

Remote
Container devcontainer (…

OS
Linux x64 4.19.84-microsoft-standard

CPUs
AMD Ryzen Threadripper 2990WX 32-Core Processor (64 x 3000)

Memory (System)
100.52GB (96.94GB free)

VM
0%

Extensions (7)

Extension
Author (truncated)
Version

better-comments
aar
2.0.5

bracket-pair-colorizer-2
Coe
0.0.29

remote-containers
ms-
0.101.1

remote-wsl
ms-
0.42.3

material-icon-theme
PKi
3.9.3

code-settings-sync
Sha
3.4.3

ayu
tea
0.18.0

@Stefan-Z-Camilleri That sounds like a limitation of Docker for Windows. Does it work when you start the container yourself with a bind mount to the Windows filesystem? It seems the events are missing in this case whereas they are issued when using a volume mount.


Testing strategy

So, currently there are no tests at all, really need to come up with a strategy for CI, per platform and per browser if possible, with a reasonable range of versions.
Saucelabs might be an option.

Input on this is very welcome :8ball:

Since console redirection is now a thing, it doesn't have to be that hard to do integration tests of the CLI. Having them automated is still a bit of an unsolved issue however.

Would prefer having it automated, but for now basic smoke tests will have to suffice.

Conclusion for now

Appveyor CI for Windows.
Circle CI for Linux.
Nothing for OSX


Update KerbalAircraftExpansion.netkan

Adding Epoch to fix new version sorting and install example craft now that we can do that. Other exclusions have been removed from download.

See also KSP-CKAN/CKAN-Meta#911

From what I see, we're already offering the correct version KAX_v<IP_ADDRESS>. I don't see a need for an epoch bump.

The Max KSP is listing as 1.0.4, though.

Oh I see what you're talking about: we have a 1.0.5-compatible version but the "Max KSP Version" column incorrectly displays the compatibility from a previous version. Basically this is https://github.com/KSP-CKAN/CKAN/issues/1327 emerging again. We should probably disable that column until the issue is resolved. I'll merge this and https://github.com/KSP-CKAN/CKAN-meta/pull/911 as a bandaid fix.

Yep. I've been steadily working through applying bandaids for that issue.

Instead of bandaid epoch bumps that make version numbers harder to discern for users and contributors alike, I'd much rather fix the problem with the column itself, disabling it in the interim if necessary. Realizing now what all your previous PRs were doing I wish I had rejected them and disabled the column from the start.

They aren't all for that reason.

Well, that find_regexp works partially. It only installs one of the Example Craft, but correctly puts the craft file into the SPH folder. Looks like we have to do separate finds for each craft. I'm surprised that setting find_matches_files true doesn't allow multiple files with a find_regexp.

I do think that an epoch bump is called for when a modder changes the version string system they use, which keptin has certainly done in this case.

Ok, I've reverted the Example Craft installation and will make that a separate change (if I can get it working in a sane way)

Spec_ver increase limits CKAN version compatibility unnecessarily and the added comment is inaccurate. For simplicity, created https://github.com/KSP-CKAN/NetKAN/pull/2907 which closes this.

Thanks.


gscan2pdf: 2.5.5 -> 2.5.6

Motivation for this change
Updating gscan2pdf to the latest version.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

@GrahamcOfBorg build gscan2pdf

The build of a transitive dependency (gcj) seems to fail on aarch64-linux on ofborg.
Should I disable this package (gscan2pdf) for this architecture?
This package otherwise builds and runs fine on x86_64_linux.

@pacien gcj should be marked as broken on aarch64 instead.


Inconsistency on Different Devices

Hi,
I am in need of help from fellow developers
I have created a component called Curve Header that pretty much creates a header in a shape of a svg. I successfully created one for Pixel 4 phone, however, When I tried to open the component in a Pixel 2 Screen it is out of scale and I couldn't figure out what is wrong with it.
Picture below is what the header component should look like:

However, I received this result on a Pixel 2 phone

import Svg, {Path, Text, } from 'react-native-svg';
import colors from "../config/colors";
import {
    StyleSheet,
    View,
    StatusBar,
    TouchableOpacity
} from "react-native";
import { Icon } from "react-native-elements";
const SAFE_STATUS_BAR = Platform.select({
    ios: 44,
    android: StatusBar.currentHeight,
  });

function CurveHeader(props){
    return(
        <View style={styles.container}>
            <Svg viewBox="0 0 100 44">
                <Path stroke={colors.primary} d="M0 0 h100 v40 q-50 -20, -100 0 Z" fill={colors.primary}></Path>
                <Text x="50%" y="45%" textAnchor="middle" alignmentBaseline="middle" fontSize="7" fill="white" fontWeight="bold" letterSpacing="0.1">{props.title.toUpperCase()}</Text>
            </Svg>
            {
                props.showBackButton ?
                <View style={styles.backButton}>
                    <TouchableOpacity onPress={() => props.returnFunction()}>
                        <Icon
                        name="arrow-left"
                        type="font-awesome-5"
                        size={30}
                        iconStyle={{ color: "#fff" }}
                        />
                    </TouchableOpacity>
                </View>
                : <View style={styles.backButton}></View>
            }
        </View>
    );
};

const styles = StyleSheet.create({
    container: {
        // paddingTop: SAFE_STATUS_BAR,
        // flex: 1,
        height: '22%'
    },
    backButton: {
        flex: 1,
        alignItems:"flex-start",
        marginHorizontal:20,
        marginVertical:55,
        elevation:3,
        position: 'absolute'
    }
})

export default CurveHeader;

Can someone please help me figure out what is wrong?
Thanks

You probably need to change the view box with the width of the device, or scale the entire SVG up. This does not seem like a bug with the React Native SVG library.

Hello @aswinputra,
As @jupdike mentioned, this problem is not related to react-native-svg.
However, if you continue to experience any issues, please feel free to open a new one.
Thank you.


[Bug]: cibuildwheel failing to compile wheel for py11

PyBaMM Version
develop
Python Version
3.11
Describe the bug
  -- Generating done (0.0s)
        -- Build files have been written to: /project/build/temp.linux-x86_64-cpython-311
        ---------- Building idaklu module ----------------------------------------
        [ 12%] Building CXX object CMakeFiles/idaklu.dir/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp.o
        In file included from /project/pybind11/include/pybind11/attr.h:13,
                         from /project/pybind11/include/pybind11/pybind11.h:45,
                         from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /project/pybind11/include/pybind11/cast.h: In function ‘std::string pybind11::detail::error_string()’:
        /project/pybind11/include/pybind11/cast.h:446:36: error: invalid use of incomplete type ‘PyFrameObject’ {aka ‘struct _frame’}
          446 |                 "  " + handle(frame->f_code->co_filename).cast<std::string>() +
              |                                    ^~
        In file included from /opt/_internal/cpython-3.11.1/include/python3.11/Python.h:42,
                         from /project/pybind11/include/pybind11/detail/common.h:124,
                         from /project/pybind11/include/pybind11/pytypes.h:12,
                         from /project/pybind11/include/pybind11/cast.h:13,
                         from /project/pybind11/include/pybind11/attr.h:13,
                         from /project/pybind11/include/pybind11/pybind11.h:45,
                         from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /opt/_internal/cpython-3.11.1/include/python3.11/pytypedefs.h:22:16: note: forward declaration of ‘PyFrameObject’ {aka ‘struct _frame’}
           22 | typedef struct _frame PyFrameObject;
              |                ^~~~~~
        In file included from /project/pybind11/include/pybind11/attr.h:13,
                         from /project/pybind11/include/pybind11/pybind11.h:45,
                         from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /project/pybind11/include/pybind11/cast.h:446:75: error: expected primary-expression before ‘>’ token
          446 |                 "  " + handle(frame->f_code->co_filename).cast<std::string>() +
              |                                                                           ^
        /project/pybind11/include/pybind11/cast.h:446:77: error: expected primary-expression before ‘)’ token
          446 |                 "  " + handle(frame->f_code->co_filename).cast<std::string>() +
              |                                                                             ^
        /project/pybind11/include/pybind11/cast.h:448:29: error: invalid use of incomplete type ‘PyFrameObject’ {aka ‘struct _frame’}
          448 |                 handle(frame->f_code->co_name).cast<std::string>() + "\n";
              |                             ^~
        In file included from /opt/_internal/cpython-3.11.1/include/python3.11/Python.h:42,
                         from /project/pybind11/include/pybind11/detail/common.h:124,
                         from /project/pybind11/include/pybind11/pytypes.h:12,
                         from /project/pybind11/include/pybind11/cast.h:13,
                         from /project/pybind11/include/pybind11/attr.h:13,
                         from /project/pybind11/include/pybind11/pybind11.h:45,
                         from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /opt/_internal/cpython-3.11.1/include/python3.11/pytypedefs.h:22:16: note: forward declaration of ‘PyFrameObject’ {aka ‘struct _frame’}
           22 | typedef struct _frame PyFrameObject;
              |                ^~~~~~
        In file included from /project/pybind11/include/pybind11/attr.h:13,
                         from /project/pybind11/include/pybind11/pybind11.h:45,
                         from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /project/pybind11/include/pybind11/cast.h:448:64: error: expected primary-expression before ‘>’ token
          448 |                 handle(frame->f_code->co_name).cast<std::string>() + "\n";
              |                                                                ^
        /project/pybind11/include/pybind11/cast.h:448:66: error: expected primary-expression before ‘)’ token
          448 |                 handle(frame->f_code->co_name).cast<std::string>() + "\n";
              |                                                                  ^
        /project/pybind11/include/pybind11/cast.h:449:26: error: invalid use of incomplete type ‘PyFrameObject’ {aka ‘struct _frame’}
          449 |             frame = frame->f_back;
              |                          ^~
        In file included from /opt/_internal/cpython-3.11.1/include/python3.11/Python.h:42,
                         from /project/pybind11/include/pybind11/detail/common.h:124,
                         from /project/pybind11/include/pybind11/pytypes.h:12,
                         from /project/pybind11/include/pybind11/cast.h:13,
                         from /project/pybind11/include/pybind11/attr.h:13,
                         from /project/pybind11/include/pybind11/pybind11.h:45,
                         from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /opt/_internal/cpython-3.11.1/include/python3.11/pytypedefs.h:22:16: note: forward declaration of ‘PyFrameObject’ {aka ‘struct _frame’}
           22 | typedef struct _frame PyFrameObject;
              |                ^~~~~~
        In file included from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /project/pybind11/include/pybind11/pybind11.h: In function ‘pybind11::function pybind11::detail::get_type_override(const void*, const pybind11::detail::type_info*, const char*)’:
        /project/pybind11/include/pybind11/pybind11.h:2291:49: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘frame’; did you mean ‘cframe’?
         2291 |     PyFrameObject *frame = PyThreadState_Get()->frame;
              |                                                 ^~~~~
              |                                                 cframe
        /project/pybind11/include/pybind11/pybind11.h:2292:41: error: invalid use of incomplete type ‘PyFrameObject’ {aka ‘struct _frame’}
         2292 |     if (frame && (std::string) str(frame->f_code->co_name) == name &&
              |                                         ^~
        In file included from /opt/_internal/cpython-3.11.1/include/python3.11/Python.h:42,
                         from /project/pybind11/include/pybind11/detail/common.h:124,
                         from /project/pybind11/include/pybind11/pytypes.h:12,
                         from /project/pybind11/include/pybind11/cast.h:13,
                         from /project/pybind11/include/pybind11/attr.h:13,
                         from /project/pybind11/include/pybind11/pybind11.h:45,
                         from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /opt/_internal/cpython-3.11.1/include/python3.11/pytypedefs.h:22:16: note: forward declaration of ‘PyFrameObject’ {aka ‘struct _frame’}
           22 | typedef struct _frame PyFrameObject;
              |                ^~~~~~
        In file included from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /project/pybind11/include/pybind11/pybind11.h:2293:14: error: invalid use of incomplete type ‘PyFrameObject’ {aka ‘struct _frame’}
         2293 |         frame->f_code->co_argcount > 0) {
              |              ^~
        In file included from /opt/_internal/cpython-3.11.1/include/python3.11/Python.h:42,
                         from /project/pybind11/include/pybind11/detail/common.h:124,
                         from /project/pybind11/include/pybind11/pytypes.h:12,
                         from /project/pybind11/include/pybind11/cast.h:13,
                         from /project/pybind11/include/pybind11/attr.h:13,
                         from /project/pybind11/include/pybind11/pybind11.h:45,
                         from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /opt/_internal/cpython-3.11.1/include/python3.11/pytypedefs.h:22:16: note: forward declaration of ‘PyFrameObject’ {aka ‘struct _frame’}
           22 | typedef struct _frame PyFrameObject;
              |                ^~~~~~
        In file included from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /project/pybind11/include/pybind11/pybind11.h:2296:18: error: invalid use of incomplete type ‘PyFrameObject’ {aka ‘struct _frame’}
         2296 |             frame->f_locals, PyTuple_GET_ITEM(frame->f_code->co_varnames, 0));
              |                  ^~
        In file included from /opt/_internal/cpython-3.11.1/include/python3.11/Python.h:42,
                         from /project/pybind11/include/pybind11/detail/common.h:124,
                         from /project/pybind11/include/pybind11/pytypes.h:12,
                         from /project/pybind11/include/pybind11/cast.h:13,
                         from /project/pybind11/include/pybind11/attr.h:13,
                         from /project/pybind11/include/pybind11/pybind11.h:45,
                         from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /opt/_internal/cpython-3.11.1/include/python3.11/pytypedefs.h:22:16: note: forward declaration of ‘PyFrameObject’ {aka ‘struct _frame’}
           22 | typedef struct _frame PyFrameObject;
              |                ^~~~~~
        In file included from /opt/_internal/cpython-3.11.1/include/python3.11/Python.h:38,
                         from /project/pybind11/include/pybind11/detail/common.h:124,
                         from /project/pybind11/include/pybind11/pytypes.h:12,
                         from /project/pybind11/include/pybind11/cast.h:13,
                         from /project/pybind11/include/pybind11/attr.h:13,
                         from /project/pybind11/include/pybind11/pybind11.h:45,
                         from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /project/pybind11/include/pybind11/pybind11.h:2296:30: error: invalid use of incomplete type ‘PyFrameObject’ {aka ‘struct _frame’}
         2296 |             frame->f_locals, PyTuple_GET_ITEM(frame->f_code->co_varnames, 0));
              |                              ^~~~~~~~~~~~~~~~
        In file included from /opt/_internal/cpython-3.11.1/include/python3.11/Python.h:42,
                         from /project/pybind11/include/pybind11/detail/common.h:124,
                         from /project/pybind11/include/pybind11/pytypes.h:12,
                         from /project/pybind11/include/pybind11/cast.h:13,
                         from /project/pybind11/include/pybind11/attr.h:13,
                         from /project/pybind11/include/pybind11/pybind11.h:45,
                         from /project/pybind11/include/pybind11/numpy.h:12,
                         from /project/pybamm/solvers/c_solvers/idaklu/common.hpp:30,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.hpp:4,
                         from /project/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp:1:
        /opt/_internal/cpython-3.11.1/include/python3.11/pytypedefs.h:22:16: note: forward declaration of ‘PyFrameObject’ {aka ‘struct _frame’}
           22 | typedef struct _frame PyFrameObject;
              |                ^~~~~~
        gmake[2]: *** [CMakeFiles/idaklu.dir/pybamm/solvers/c_solvers/idaklu/casadi_functions.cpp.o] Error 1
        gmake[1]: *** [CMakeFiles/idaklu.dir/all] Error 2
        gmake: *** [all] Error 2
        error: can't copy '/project/build/temp.linux-x86_64-cpython-311/idaklu.cpython-311-x86_64-linux-gnu.so': doesn't exist or not a regular file
        [end of output]

    note: This error originates from a subprocess, and is likely not a problem with pip.
    ERROR: Failed building wheel for pybamm
    Running setup.py clean for pybamm
  Failed to build pybamm
  ERROR: Failed to build one or more wheels

Steps to Reproduce
run publish to pypi action
Relevant log output
see above

The wheels are building, see PR #2922


Version bump

Codecov Report
Patch and project coverage have no change.

Comparison is base (6a025d7) 60.00% compared to head (0d8606e) 60.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #39   +/-   ##
=======================================
  Coverage   60.00%   60.00%
=======================================
  Files          20       20
  Lines         105      105
  Branches       18       18
=======================================
  Hits           63       63
  Misses         37       37
  Partials        5        5

Impacted Files
Coverage Δ

src/Header.js
100.00% <ø> (ø)

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

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


#112 migrate project.json to csproj

@thiennn Which tooling are using for these migrations?

VS 2017. Worked fine on local but the new sdk haven't been supported on appveyor and travis

@thiennn which version of VS2017?

@thiennn please read this blog post very important : https://blogs.msdn.microsoft.com/dotnet/2017/02/07/announcing-net-core-tools-updates-in-vs-2017-rc/

@MaherJendoubi thanks, aready read that and also http://www.natemcmaster.com/blog/2017/01/19/project-json-to-csproj/.
I use the latest version of VS2017 and .NET Core SDK RC4

@thiennn Excellent :) but you forget this one http://www.natemcmaster.com/blog/2017/02/01/project-json-to-csproj-part2/ ;-)


Improve documentation for kubernetes.io/enforce-mountable-secrets

Fixes #40727
Update the description on ServiceAccount.
1.Expanded the description to clearly explain the actual enforcement behavior, highlighting not just the mounting of secrets, but also their references in envFrom and imagePullSecrets.
2. Emphasized the need to ensure all referenced secrets are correctly specified in the ServiceAccount to avoid potential issues

/lgtm

We avoid Markdown in commit messages
/retitle Improve documentation for kubernetes.io/enforce-mountable-secrets

We could also edit https://kubernetes.io/docs/concepts/security/service-accounts/ to mention this annotation and link to the section about its effect.

@sftim Yes, I'd like to edit the documentation too.Can I edit this on this PR?

@tengqm Yes, I'm working on it now.

/label tide/merge-method-squash
/lgtm

@sftim I've updated, please review:pray:

/sig security

@chansuke
Could you please squash your commits: https://kubernetes.io/docs/contribute/new-content/open-a-pr/#squashing-commits

I'm happy with the changes since https://github.com/kubernetes/website/pull/42741#issuecomment-1694634155
/lgtm
/remove-label tide/merge-method-squash

@sftim Thank you so much for your support.


Implement association as it's own thing

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe
Right now, association is internally implemented as a field, with a magic :assocation option.
Describe the feature you'd like to see implemented
I'd implement association as a proper class internally, similar to Field.
    def self.association(method, options = {}, &block)
      validate_blueprint!(options[:blueprint], method)

      make_association(
        method,
        options.merge(
          extractor: options.fetch(:extractor) { AssociationExtractor.new }
        ),
        &block
      )
    end

Describe alternatives you've considered
No response
Additional context
No response

Happy to discuss this in more detail, and elaborate more.

Friendly ping @lessthanjacob @njbbaer @ritikesh
If you think this is a reasonable suggestion, let me know! If so, I'd propose these steps:

I'll flesh out the proposed change in some more detail (written, in this issue)
You get another chance to provide more feedback, and if you're happy we'll open a PR

For reference, there are also a few other issues that I've opened, where I'd also be happy to get your input.
Full list

https://github.com/procore-oss/blueprinter/issues/403
https://github.com/procore-oss/blueprinter/issues/404
https://github.com/procore-oss/blueprinter/issues/405
https://github.com/procore-oss/blueprinter/issues/406
https://github.com/procore-oss/blueprinter/issues/407

Friendly ping @lessthanjacob @njbbaer @ritikesh
Happy to hear your thoughts on this!

What would the responsibilities be of this Association class outside of how it's being handled within the ViewCollection/View contexts today?

It would be a sibling class next to Field. It would work just the same as the Field class does today.
Mostly just seemed like a design that's easier to comprehend, because right now an association is a field with the "magic" option called :association with value true.
That said, I don't feel strongly about this.
An alternative would be to turn it into a property on the field (similar to what's proposed for the other magic options in https://github.com/procore-oss/blueprinter/issues/405).

They do behave similarly. It's just a readability thing with no major functional differences barring associations having their own blueprinter/view based rendering.

An alternative would be to turn it into a property on the field (similar to what's proposed for the other magic options in https://github.com/procore-oss/blueprinter/issues/405).

At this point, I'm not strongly for/against this one either. But the trend seems to be in the direction of major rewrites and as long as there's no/little impact to the consumers, this should still be ok.
@jmeridth / @njbbaer - any thoughts from your side?

in fact, many fields have additional options too - like date_time formatter (which we're planning to get rid off too in favour of extractors). If we're able to achieve consistency in terms of the options that required for defining a field and an association with them being unique to their own types, then I think this might make more sense.

Not stale

I didn't link this issue, but I recently started down this path with #414, albeit in a very rudimentary way for the time being.
https://github.com/procore-oss/blueprinter/blob/2150b9282e5352ba9a01ee947fd8f1e700171a4a/lib/blueprinter/association.rb#L1-L33
This makes the interface a bit more explicit/clearer, but there's room to take this further, since it's mostly functioning as a facade around Field.new anyway.

This makes the interface a bit more explicit/clearer, but there's room to take this further, since it's mostly functioning as a facade around Field.new anyway.

That's great!

Not stale

Not stale


Fix copy/paste for inline code

Problem
If you copy from the Mynah card with inline code and paste it into another place, it will contain new line breaks around inline code text.
The problem is described in more details in related issue: https://github.com/aws/mynah-ui/issues/98
Solution
Avoid using block elements for inline code.
Before:

After:

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

This change was verified in web, but still needs to be verified in IDEs.


remove duplicate line in code example

remove duplicate line in code example

Please see CONTRIBUTING.md for guidelines


HTML Bugfixes

Bugfixes.

Earlier if an attribute value was empty, it wasn't editable in block mode. Now you can edit it.
EDIT: Fixed another bug where some blocks were not reparsing corrrectly due to lack of context information.
Little cleanup on parser.coffee#L221

Looks good to me.


feat: add layer0 preset

🔗 Linked issue

❓ Type of change

[ ] 📖 Documentation (updates to the documentation or readme)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[x] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
Extracterd from @layer0/nuxt3. Currently based on node presrt and generates additional .output/server/prod.cjs with layer0 format and CommonJS wrapper.
Try with:

Clone repo and follow contribution guide to setup
Switch to feat/layer0-preset branch
Build with NITRO_PRESET=layer0 yarn nitro build examples/hello-world and check examples/hello-world/.output

Questions:

What would be deploy and preview commands for this?
How we can detect running in Layer0 CI/CD to automatically enable preset? (see this. providers usually expose a distrinct environment variable)

/cc @tristanlee85
Future improvements:
Looking at routes.js, we can potentially auto genere this file from nitro route caching rules for edge-caching. I need more details how it works :)
📝 Checklist

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

Questions:

What would be deploy and preview commands for this?
How we can detect running in Layer0 CI/CD to automatically enable preset? (see this. providers usually expose a distrinct environment variable)

/cc @tristanlee85

Deploy command: Since this will have been built already with Nitro, it can be deployed with layer0 deploy --skipFramework to skip the framework build.
Preview command: I assume you are just wanting to run the production build locally? If that is the case, the command would be layer0 run --production.
I did try this locally, but got hung up on some error that I've been trying to debug:
 nitro git:(feat/layer0-preset) NITRO_PRESET=layer0 yarn nitro build examples/hello-world
✔ Generated public examples/hello-world/.output/public          nitro 13:41:39
start Building server...                                        nitro 13:41:39
start Writing server bundle...                                  nitro 13:41:39
✔ Server built                                                  nitro 13:41:39
  ├─ examples/hello-world/.output/server/package.json (346 B) (200 B gzip)
  ├─ examples/hello-world/.output/server/index.mjs (10.6 kB) (3.52 kB gzip)
  └─ examples/hello-world/.output/server/chunks/hello.mjs (133 B) (123 B gzip)
Σ Total size: 414 kB (105 kB gzip)
TypeError: input.replaceAll is not a function
    at rewriteRelativePaths (/Users/tristanlee/Projects/nitro/src/build.ts:156:18)
    at _build (/Users/tristanlee/Projects/nitro/src/build.ts:159:61)
    at async main (/Users/tristanlee/Projects/nitro/src/cli.ts:35:5)

@tristanlee85 That should be now resolved, by https://github.com/unjs/nitro/pull/42. (Or you can use node 16 until you upgrade.)