Add CustomDebugDescription conformance to AnyKeyPath

Implementation of this pitch, adds a conformance to CustomDebugDescription to AnyKeyPath. This will need an SE before it's merged.
I haven't modified api-digester yet, which I think I need to do...? I intended to see what the CI says first.

SE pull request: https://github.com/apple/swift-evolution/pull/1724
@jckarter tagging you here per the "how to contribute" doc in the swift compiler repo, as I assume you'll want to review this at some point

@swift-ci Please test

Oh, could it be possible to add the types in the subscript case? \Foo.subscript(_: Int, bar: String) reads very nicely (I don't remember if the type is fully realized in the demangling or if you can get a simple name for it).

Welcome! This looks pretty good! I just have a few nitpicks to hopefully make things a little easier to read. In general, the Swift project uses 2 space indentation instead of 4 both in the runtime and stdlib.

Thanks!
I believe the issues with indentation should be addressed at this point.

Oh, could it be possible to add the types in the subscript case? \Foo.subscript(_: Int, bar: String) reads very nicely (I don't remember if the type is fully realized in the demangling or if you can get a simple name for it).

Yes! I didn't notice this earlier, but the type is there based on the output of xcrun swift-demangle --tree-only, and I'm sure I can find a way to get it out. Actually, I think we might be able to combine this with _typeByName to get the actual arguments that were passed to the subscript, which could read even better in the case of a simple integer, or a lot worse if it's a very complex object being used.

@Azoy I believe that all of the issues you raised have been addressed.
I've been having issues building the full toolchain so I'm not sure if my changes to the api digester worked, but I do believe that the test failures on Windows and Linux should also be resolved.

@swift-ci test

One of the Linux CI failures appears unrelated, but the other one is real.

The Windows one also seemed like an infra issue to me when I saw it last night. For my context, is it common for the CI to be flaky?

@xwu I believe I've addressed all of your comments.
One thing I wanted to flag: currently, the availability of the new conformance is set to 5.7. Is there any chance that this makes it into 5.7, or should I change that to some other version?

Thanks!
@swift-ci test

One thing I wanted to flag: currently, the availability of the new conformance is set to 5.7. Is there any chance that this makes it into 5.7, or should I change that to some other version?

Ah, thanks for flagging this: we are past making it into 5.7, but in any case the availability version for newly added things on the main branch should be 9999, I believe.

One thing I wanted to flag: currently, the availability of the new conformance is set to 5.7. Is there any chance that this makes it into 5.7, or should I change that to some other version?

Ah, thanks for flagging this: we are past making it into 5.7, but in any case the availability version for newly added things on the main branch should be 5.8 (which expands to OS versions 9999). Let's let the CI run first though.

I will change to 5.8.
Looks like CI failed the API digester test on MacOS. Not sure where to go from here in terms of debugging that. Linux looks like it might be the same (presumably spurious) error from before, but I'm not sure. Windows passed though!

Wooo, yes I'm stumped by the API digester warning; it seems to me to be a false positive but I don't want to be hasty in suggesting that we add just add it to the list and call it aday; perhaps @Azoy can help here to verify.

@swift-ci test Linux platform

@swift-ci please test

I haven't investigated deeply, but if it's the same Linux test falling again, and other CI builds on main are successful, then it's not a spurious error and probably needs some PR tweaking...

I haven't investigated deeply, but if it's the same Linux test falling again, and other CI builds on main are successful, then it's not a spurious error and probably needs some PR tweaking...

Yeah, it looks like it's this Pr.
TL:DR I think the right approach is to add these symbols to the allowlist of the test. But I would like to confirm with the author of the test (@compnerd).
Long version:
My understanding is that the test lists all symbols in a binary, then diffs that output with a list of all strong symbols in the same binary. The goal is to ensure there are no weakly linked symbols at all. But there are two weakly linked symbols in the output:
--- /home/build-user/build/buildbot_linux/swift-linux-x86_64/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftCore-all.txt	2022-09-05 01:04:57.351384015 +0000
+++ /home/build-user/build/buildbot_linux/swift-linux-x86_64/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftCore-no-weak.txt	2022-09-05 01:04:57.507385347 +0000
@@ -13089,8 +13089,6 @@
<PHONE_NUMBER>52bb90 D $syyXfWV
<PHONE_NUMBER>52bae0 D $syyYjrcWV
<PHONE_NUMBER>52ba88 D $syycWV
-000000000044b360 W _ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_
-0000000000441690 W _ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EERKS8_SA_
<PHONE_NUMBER>60b10b B __bss_start
<PHONE_NUMBER>3e6d60 T __gnu_f2h_ieee
<PHONE_NUMBER>3e6d20 T __gnu_h2f_ieee

Demangling these, it looks like we caused a new version of std::operator+ and some massive, vector related template thing to be created.
Anyway, I think what is happening is that I used these in the impls of some of the functions I wrote, without realizing that they're brand new templates that have never been used before. C++ is instantiating (is that the right word?) these templates, and using weak linking, for whatever reason.
The test is filled with inverted matches which appear to be an allowlist, and based on the names it seems like they might also be templates. So the obvious, quick solution is to add the two functions there and move on.
But I'd like to understand why this Pr causes this; nothing has changed in the allowlist since April. So it feels like there's something different (and potentially unidiomatic/wrong) about how I'm using C++ in this Pr.

:sigh: libstdc++.  Yes, these two instantiations should be okay to add to the allowlist.  The problem here is that the GNU C++ runtime decorates the template bodies such that an instantiation will be weak as it is in global namespace and attributed so as to coalesce the copies requiring weak ODR semantics giving them weak global linkage.  This is an artifact of the implementation and we cannot control that even with -fvisibility=hidden -fvisibility-inlines-hidden nor any internal macro.  This also changes based upon the version of the runtime in use as these are internal details.  The new code uses + on std::string and causes a std::vector<std::string> to potentially be resized when inserting (plausibly a push_back).

:sigh: libstdc++. Yes, these two instantiations should be okay to add to the allowlist. The problem here is that the GNU C++ runtime decorates the template bodies such that an instantiation will be weak as it is in global namespace and attributed so as to coalesce the copies requiring weak ODR semantics giving them weak global linkage. This is an artifact of the implementation and we cannot control that even with -fvisibility=hidden -fvisibility-inlines-hidden nor any internal macro. This also changes based upon the version of the runtime in use as these are internal details. The new code uses + on std::string and causes a std::vector<std::string> to potentially be resized when inserting (plausibly a push_back).

Thanks! I've added them to the allowlist.

:sigh: libstdc++.

Are there suitably equivalent LLVM types that can be used here instead?

:sigh: libstdc++.

Are there suitably equivalent LLVM types that can be used here instead?

I don't believe so. I see two options in the llvm programmer's manual:

StringRef: this appears to be immutable, so not suitable for this use case
Twine: this initially looks promising as it's for "efficiently concatenating values together." But "its implementation relies on the ability to store pointers to temporary stack objects which may be deallocated at the end of a statement. Twines should only be used accepted as const references in arguments"

I think we could optimize the matchSequenceOfKinds function a little by switching to llvm::smallVector, because the size of the vector is known in advance. I can make that change if you like, but I'm pretty confident that it won't remove the need to modify the test.

@swift-ci test

I think we could optimize the matchSequenceOfKinds function a little by switching to llvm::smallVector, because the size of the vector is known in advance. I can make that change if you like, but I'm pretty confident that it won't remove the need to modify the test.

I'll defer to you and other reviewers :)

@swift-ci please test Linux platform

@swift-ci please test macOS platform

@swift-ci please test Windows platform

Looks like CI is green. Any other changes needed to the Pr?

Woooo, nice to see. Can you clang-format the .cpp files?

Done.

@swift-ci test

@Azoy How's it look to you?

Thanks so much! Super excited this is in finally.

Thanks so much! Super excited this is in finally.

Me too! Thanks @Azoy @xwu and @compnerd for all the help getting this landed!


[MGDOBR-236] Add perf scenario for creating multiple Bridges at once

Signed-off-by: Karel Suta<EMAIL_ADDRESS>MGDOBR-236
PR owner checklist
Please make sure that your PR meets the following requirements:

[ ] Your code is properly formatted according to this configuration.
Run mvn clean verify -DskipTests so that imports are correctly set.
[ ] Your commit messages are clear and reference the JIRA issue e.g: "[MGDOBR-1] - $clear_explanation_of_what_you_did"
[ ] The layers in the kustomize folder have been updated accordingly.
[ ] All new functionality is tested
[ ] Pull Request title is properly formatted: MGDOBR-XYZ Subject
[ ] Pull Request contains link to the JIRA issue
[ ] Pull Request contains link to any dependent or related Pull Request
[ ] Pull Request contains description of the issue
[ ] Pull Request does not include fixes for issues other than the main ticket

PR reviewer(s) checklist

[ ] Check if code and Github action workflows have been modified and if the modification is safe
[ ] If the modification is safe, add the safe to test label

How to trigger pipelines and use the bots:

Run the end to end pipeline
Annotate the pull request with the label: safe to test. If you want to run the pipeline again, remove and add it again.

Rebase the pull request
Comment with: /rebase.

Deploy BOT
Comment with `/deploy <dev,stable> when the PR has been merged to deploy to a target environment.

used for verification of https://github.com/5733d9e2be6485d52ffa08870cabdee0/sandbox/pull/920


Possibility to restrict the type of features you can select

See #3257 issue.
This PR includes samples and also an initial implementation based on a new filter property which accepts a ol.interaction.SelectFilterFunction invoked for each selected feature and that determines if the feature must be selected or not.

Updated PR with the @elemoine comments. Added documentation to the olx.js file too.
Although the ./build.py ci task runs fine I don't know why the apidoc doesn't show the new filter property.
In addition, I have added a second parameter to the ol.interaction.SelectFilterFunction that references the layers which feature belongs. By some comment on the list I think having a reference to the layer can help in some situations.

@acanimal, I don't think we need a new example for that new option.

I think sample can help to show how to use the property. Anyway the property is so trivial that can be removed. Simply confirm me and I will remove. I vote for not removing :)

@acanimal, yes, using the new filter option is trivial, and we can't add an example for every option we add. So I would remove the example.

Sample removed.

Did you see my other comments?

Strange, I didn't receive any notification to my email.
I just make the changes.

@ahocevar @elemoine Hi, what happened with this features? I though it would be merged in the 3.3 release :(
I don't know the the process must follow a PR to be accepted but this feature is important to me at work. Could you let me know some feedback?
Thanks.

@acanimal Sorry for that. Your pull request cannot be merged without conflicts, this is why it did not get merged yet. Also, it did not have a milestone assigned, so I did not wait for it when I created the release yesterday. But since we have a monthly release schedule, I'm assigning it the 3.4.0 milestone now. So if you are able to resolve the conflicts, we can merge your pull request and it will be in the next release.

I though the conflict was due the addition of #3018, ./build.py ci tasks runs fine and also travis report "green" result.
I will resolve and update the PR.
Thanks

@ahocevar Merge done

Have you seen @elemoine's last comment?

Sorry for the late reply. Yes, I just uploaded the modified code using this.filter_ property instead a local variable.

This feature is important for a project I'm currently working on. Very much looking forward to it being available in 3.4.0. Thanks to those involved.

@elemoine, are your concerns addressed now?

LGTM. I just think we should squash the commits into one before merging. I will do that myself this morning, and create a new PR.

Hi,
I'm "disconnected" from the project due time limitation but, why has been removed this PR from 3.5.0? I code it since 3.3 and never released.
Is there any other new functionallity in 3.5 to achieve the same result?
Cheers.

@acanimal it needs a rebase at least, not sure if there are any other reasons.

fixed with #3402 ?

fixed with #3402 ?

Yes.


Add a ClientController test utility

With StubClient the responsibilities for checking arguments and
stubbing return values are overloaded to an EqualityMap checking the
full content of the Uri and JSON payload and using it as a key to choose
a stubbed response. This is verbose; details are repeated in every test
that are not relevant to the test. It also has hard to diagnose
failures; when an argument is incorrect it surfaces as a missing key
with no hint about what value in the payload is wrong.
Add a ClientController class which more directly addresses stubbing
and argument checking individually. When only stubbing is necessary the
verifyRequest argument can be omitted, and any request gets the
stubbed response. Expectations checked against the request URI and JSON
payload can be as shallow or deep as necessary for the given test.
Add an arbitraryGenerateContentResponse variable to fill in for
responses where the parsed output isn't tested.

@devoncarew - WDYT about this approach? If it LGTY then I'll update the remaining tests.
I'm somewhat tempted to not make a distinction between the unary and stream in the API - the unary requests would need to always pass a list with a single element. Let me know if you think I should try that.
The Queue will let us test APIs that make multiple requests for automatic function calling. I'll add a checkRequests method that takes an Iterable of callbacks to verify each one.


GH-24 [flex] script & model

this component will not be done in one PR commit :-)  ( no dialog yet) on docs by:

making responsive configuration more complex (with an instanciation of it for docs in content,
added a FlexModel.getId, even if we might want to move this to some abstract model later,
fixed a few bad resource types here & there
got fore, back ground colors, gap container & minheight working,
introduced StyleService and added shadow & border that way

while this is growing, created https://github.com/adobe/htl-spec/issues/89 as it would have been nice for that one :-D

closing that one to open one against dedicated branch


changed seaborn theme to fit someones tase, who does not like grey ba…

…ckground

Codecov Report

Merging #8 into master will increase coverage by 0.07%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master       #8      +/-   ##
==========================================
+ Coverage   31.35%   31.42%   +0.07%
==========================================
  Files           9        9
  Lines         976      977       +1
==========================================
+ Hits          306      307       +1
  Misses        670      670

Impacted Files
Coverage Δ

datahandling/datahandling/datahandling.py
28.11% <100%> (+0.09%)
:arrow_up:

Continue to review full report at Codecov.

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


There seems to be a bug in TestSubtreeAvailability?

I think that bufferSize should be (1 + 4 + 16 + ...+ maxTiles) / 8.
For example,  for  3 levels tree, there are 21 tiles, bufferSize should be 3 NOT 2.

I think  std::ceil(maxTiles / 8)  is wrong too, it should be   std::ceil(maxTiles / 8.0)
8 -----> 8.0

Thanks @insar-dev, I agree. The 3DTILES_implicit_tiling spec has formulas that can be used to compute the necessary values:
https://github.com/CesiumGS/3d-tiles/tree/main/extensions/3DTILES_implicit_tiling#availability-bitstream-lengths
Would you be interested in opening a pull request with the fix?

@kring i have committed pull request.

Re-opening this until #588 is merged.


Feature Request: Button for selecting File for input

Summary
Right now, in order to import a file as input to CyberChef, you must drag and drop a file into the input box. This is pretty handy at times! However, it's:

Not clear to users that that's available as an option, and
Sometimes not user-friendly, particularly when one doesn't have a traditional Window Manager, for example if using i3wm.
It would be nice if there were a button along the input box that upon clicking would prompt a user to select a file (or files?) from their filesystem that they would like to import as input to CyberChef.

Example
File chooser prompt in Google Chrome on MacOS
Example File Chooser Button in CyberChef using 'input' as the icon

Closed in #478


Collapse consecutive, dictionary nodes with only one, outgoing edge

The path (a)->(b)->(c) should be collapsed as (abc).

This change would require the use of cursors that kept track of which node they were in, along with the index of the current character in that node.


Adding Application Insights Data Plane

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[X] The title of the PR is clear and informative.
[X] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[X] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[X] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[X] I have read the contribution guidelines.
[X] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[X] The spec follows the guidelines described in the Swagger checklist document.
[X] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

This commit was treated and no generation was made for Azure/azure-sdk-for-python

This commit was treated and no generation was made for Azure/azure-sdk-for-go

@alexeldeib thank you. Could you take a look at the model validation errors reported by CI.

Automation for azure-sdk-for-python

This commit was treated and no generation was made for Azure/azure-sdk-for-go

@anuchandy Sorry about that -- looks like I goofed when I ran OAV locally. I've made some adjustments. I see in the CI build jobs #8, 9 still fail but due to external issues.

@alexeldeib thanks for addressing the model error, yes please ignore the jobs 8 & 9.

This commit was treated and no generation was made for Azure/azure-sdk-for-go

Swagger to SDK encountered an unknown error: (Azure/azure-sdk-for-go)
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/github_tools.py", line 29, in exception_to_github
    yield context
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/restapi/github.py", line 180, in rest_handle_action
    return rest_pull_close(body, github_con, restapi_repo, sdk_pr_target_repo, sdkbase)
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/restapi/github.py", line 311, in rest_pull_close
    rest_pr.create_issue_comment("Was unable to create SDK %s PR for this closed PR.", sdkid)
TypeError: create_issue_comment() takes 2 positional arguments but 3 were given


Add 6.0 Known issue with ICU app-local feature

@rbhanda @ericstj could you please help review the change? Thanks!


2th Online Meeting with zoom.us

Shared what we studied.
@gimdongwoo mentor reviewed 'carbon' project. The 'carbon' project has a lot to reference point.

Nice yeah~


NullAway doesn't recognize @Nullable annotation in a different compilation unit

I've been migrating on of our projects to jspecify and noticed that NullAway reports nullability problems for passing null values to the @Nullable generic parameters in another compilation unit (main source set).
src/main/java:
public class Main {
    public static void main(String[] args) {
        // ok
        withFunction(x -> null);
    }

    public static void withFunction(Function<String, @Nullable String> f) {}
}

src/test/java:
class MainTest {
    public static void main(String[] args) {
        // error: [NullAway] returning @Nullable expression from method with @NonNull return type
        Main.withFunction(x -> null);
    }
}

Compiling the test class gives the following error:
nullaway-reproducer/src/test/java/com/github/gavlyukovskiy/MainTest.java:6: error: [NullAway] returning @Nullable expression from method with @NonNull return type
        Main.withFunction(x -> null);
                          ^
    (see http://t.uber.com/nullaway )
1 error

I've also tried extracting the expression into Function<String, @Nullable String> variable, but passing that gives slightly different error:
nullaway-reproducer/src/test/java/com/github/gavlyukovskiy/MainTest.java:11: error: [NullAway] Cannot pass parameter of type Function<String, @Nullable String>, as formal parameter has type Function<String, String>, which has mismatched type parameter nullability
        Main.withFunction(f);
                          ^
    (see http://t.uber.com/nullaway )
1 error

I've tried the same test but without generic parameters:
public static void with(@Nullable String v) {}

and both main and test source sets react to it correctly (both with and without @Nullable annotation), so the problems appears to be with generics.
I've tried reproducing the situation inside com.uber.nullaway.jspecify.GenericsTests, but as they're the same compilation unit it wasn't possible.
Reproducer: https://github.com/gavlyukovskiy/nullaway-reproducer (./gradlew build)
Versions:

org.jspecify:jspecify:1.0.0
com.google.errorprone:error_prone_core:2.29.2
com.uber.nullaway:nullaway:0.11.1
net.ltgt.errorprone:4.0.1

Hi @gavlyukovskiy, one caveat is that our JSpecify mode checks are still limited.  That said I think your specific test case should work.  You may be running into https://github.com/uber/NullAway/issues/1005.  Any chance you could try compiling using JDK 22 and see if that fixes the problem?

Hi @msridhar, thank you for looking into that. I've just tried temurin-22.0.2, but get the same error

This is very interesting, thanks for reporting.  I can reproduce the problem, even on JDK 22, and I've pushed a test case here.  This to me looks like a bug in javac.  NullAway gets the type for the lambda being passed as a parameter here:
https://github.com/uber/NullAway/blob/7c5edf7f35aa8d0a9a1b150fdbac27a49f7cc4f7/nullaway/src/main/java/com/uber/nullaway/NullAway.java#L927-L927
On JDK 21, this type is Function<String,String> with the type-use annotation missing (as expected).  On JDK 22, we see the type Function<@Nullable String,String>, which is also wrong; the @Nullable should be on the second type argument.  At the invocation of withFunction I see the type of the function as<EMAIL_ADDRESS>String,java.lang.String>)void which also has the type-use annotation in the wrong place.
@cushon @cpovirk do you agree this is potentially a bug in javac's reading of type-use annotations from bytecode?  Is this a known issue?

FWIW, here is what I see for the withFunction method when I run javap -v on the class file:
  public static void withFunction(java.util.function.Function<java.lang.String, java.lang.String>);
    descriptor: (Ljava/util/function/Function;)V
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=0, locals=1, args_size=1
         0: return
      LineNumberTable:
        line 8: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       1     0     f   Ljava/util/function/Function;
      LocalVariableTypeTable:
        Start  Length  Slot  Name   Signature
            0       1     0     f   Ljava/util/function/Function<Ljava/lang/String;Ljava/lang/String;>;
    Signature: #21                          // (Ljava/util/function/Function<Ljava/lang/String;Ljava/lang/String;>;)V
    RuntimeVisibleTypeAnnotations:
      0: #23(): METHOD_FORMAL_PARAMETER, param_index=0, location=[TYPE_ARGUMENT(1)]
        org.jspecify.annotations.Nullable

I'm pretty sure TYPE_ARGUMENT(1) means the second type argument.  Also, within NullAway if I call getRawTypeAttributes() on the MethodSymbol for withFunction I see the position of the @Nullable annotation as:
[METHOD_FORMAL_PARAMETER, param_index = 0, location = (TYPE_ARGUMENT(1)), pos = -1]

That's an interesting find. It seems like it already puts an annotation on the first argument as well for BiFunction or custom functional interface.

@gavlyukovskiy I've confirmed this is an issue in javac.  I'll put updates here as there is progress towards a fix.

Thank you @msridhar

I should say a bit more here. This test case exposes a new issue on JDK 22+. On JDK 21 and earlier the issue with not reading type annotations from bytecode was already known and is covered by #1105

There is now a PR https://github.com/openjdk/jdk/pull/20460 up to fix this issue.  Once a fix lands, it will have to get into a released JDK before NullAway users can benefit from it.  Thank you again for reporting this!  I will leave this issue open until a fix hits a release.

Small update here.  The above PR has landed and will ship with JDK 24.  There is a backport for JDK 23: https://github.com/openjdk/jdk23u/pull/67 Assuming the backport goes through, I think this would be fixed in the first patch release of JDK 23 (it's too late to make the GA release).

Thank you for the update @msridhar! It might be a wrong to ask, but is there any chance such a fix will be backported to jdk21u?

@gavlyukovskiy there is an effort to get related fixes for reading of type annotations from bytecodes backported to JDK 21 and possibly earlier.  See https://github.com/jspecify/jspecify/issues/365, https://bugs.openjdk.org/browse/JDK-8323093, and https://mail.openjdk.org/pipermail/compiler-dev/2024-July/027344.html.  At this point, I imagine that if that backport is approved, the fixes for this issue would be included.  /cc @cushon


Hide Object Id; update Applies label

link to demo deployment of your smk based app is
https://smk-svt-rt-b16795-dev.apps.silver.devops.gov.bc.ca
Verify that it looks good, if so merge the pull request which will trigger a prod deployment, otherwise close the pull request without merging
mentions / notifications: @michaelpnelson, @rustyjux

The Vanity URL for the prod deploy is https://smk-svt.api.gov.bc.ca
If this is a dev deploy,  verify that it looks good, then merge the pull request to trigger prod deployment.
If this is a prod deployment, view your prod deploy at the url above :)
mentions / notifications: @michaelpnelson, @rustyjux


Add support for point cloud back face culling

Fixes #10632
This PR adds support for pointCloudShading.backFaceCulling which culls back-facing points for point clouds that have normals.
Sandcastle example

@j9liu this PR is now ready for review!

@j9liu updated!

@ptrgags looks good, thanks!


16964 methods?? Seriously?

I checked Dbflow Method Count and it shows 16964. Is it true or some bugs in counting methods ?

Sorry, wrong repo


try push to branch

Description of the Change

Issue

Benefits

Possible Drawbacks

Usage Examples or Tests [optional]

Alternate Designs [optional]

Codecov Report

Merging #41 (8713890) into fix/iroha2-ci/dockerhub-login-coverage (9d7e476) will not change coverage.
The diff coverage is n/a.

@@                           Coverage Diff                           @@
##           fix/iroha2-ci/dockerhub-login-coverage      #41   +/-   ##
=======================================================================
  Coverage                                   66.99%   66.99%
=======================================================================
  Files                                         155      155
  Lines                                       28009    28009
=======================================================================
  Hits                                        18764    18764
  Misses                                       9245     9245

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 9d7e476...8713890. Read the comment docs.


hw-probe: fix for aarch64

Description of changes
cpuid is only compatible with i686 and x86_64, so only add it as a dependency on those platforms.
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

cc @rehno-lindeque.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/618


edit_bot: Fixed dropdown username capitalization and other bugs.

Fixes the bugs listed within #17311, mainly as:

Unwrapped the label tag from entire control group which also brings back the dropdown items to their default size.
Rectifies broken label tag having a misleading 'for' attribute.
Removed 'name' attribute from unlabelled span tag.

This is an updated pr for #17403 (which was later reverted in #17468), due to issues found within organization notification settings.(Sorry about that)
Screenshots:

@aryanshridhar have you tested all places that we use dropdown_list_widget?
@aero31aero @amanagr can one of you do a review of this?  We should be pretty careful since we caused a moderately bad regression changing this template already.

Yup @timabbott, I grep(ed) to look for places where dropdown_list_widget was being implemented within the templates folder.
Here's what all I checked :
$ grep -rnw . -e 'dropdown_list_widget'

./edit_bot.hbs:16:                {{> settings/dropdown_list_widget
./admin_bot_form.hbs:12:                    {{> settings/dropdown_list_widget
./settings/organization_settings_admin.hbs:103:            {{> dropdown_list_widget
./settings/organization_settings_admin.hbs:109:            {{> dropdown_list_widget
./settings/organization_settings_admin.hbs:198:                {{> dropdown_list_widget

This is great, merged, thanks @aryanshridhar!


display tactic/command/etc entries using mathlib command

https://github.com/leanprover-community/mathlib/pull/1963 replaces tactics.md, etc with a new command for adding doc information. This is the corresponding update on this side, extracting the information added in those commands:

Still to do: JavaScript filtering, to display only entries that have certain tags.
This should NOT be merged until the above PR lands and we migrate the doc entries from the md file to the new command.
cc @bryangingechen

This looks great overall though I haven't tried to run it locally yet. One thing to check (probably in the associated mathlib PR) is that linking between tactic docs is easy to do. From a first glance it looks like the URLs will be fairly predictable (something like tactic.html#decl_name) which is good. Another thing to do is to add some info about this new feature to the README.
Would it be possible to avoid hard-coding mathlib-specific docs / doc commands into print_docs.py and export_json.lean? I think this project has the potential to become usable for Lean repos outside mathlib, and keeping "data" separated from the code as much as possible now will be easier than extricating it in a refactor later on.

I think the things that are hardcoded in the tactic doc setup are:

the entry categories, e.g. tactic, command, hole command
import paths: we display either import tactic.core or import tactic.default, if either works, and the precise import where the tactic is defined

Do you see others?
There are other hardcoded things in the doc gen tool, mainly because it looks at paths to distinguish mathlib and core files, and it finds specific .md files in the mathlib repo. I think it would be easy enough to generalize this to core vs other repos.

I've updated this so it builds with https://github.com/leanprover-community/mathlib/pull/2114 . There are definitely some rough edges still. It needs header text for the attributes page, and I'd like to implement a way to filter tactic/command/attribute entries by tag.

FYI, this is what it looks like right now: https://robertylewis.com/mathlib_docs/tactics.html

Overall it looks nice!

I noticed that we're showing both the text above and below the horizontal rule in entries like this: https://robertylewis.com/mathlib_docs/tactics.html#rename'

Also, lack of linebreaks before --- led to weirdness here and a few other places; I've made some suggestions at the mathlib PR that I'll commit soon: https://robertylewis.com/mathlib_docs/tactics.html#suggest

Do you know what's going on here? https://robertylewis.com/mathlib_docs/commands.html#new cmd

Two thoughts for future PRs:

We should add syntax highlighting. It looks like we're already using the fenced-code-blocks extension for markdown2 and it supports highlighting via pygments. I guess we should revisit pygments anyways since it's still broken in Zulip.

It might be nice if we could click on the import statements (e.g. import tactic.XXX) to copy them to the clipboard. (I could hack this in later.)

(I was a little confused because the links in the sidebar redirect to the docs at leanprover-community.github.io instead of robertylewis.com, but that's not really relevant.)

Do you know what's going on here? https://robertylewis.com/mathlib_docs/commands.html#new cmd

The reassoc_axiom doc entry is missing so maybe something strange happened there?

Also, linarith is showing up in the commands, not the tactics... maybe you're using a different commit than I expected?

I noticed that we're showing both the text above and below the horizontal rule in entries like this: robertylewis.com/mathlib_docs/tactics.html#rename'

Oh, yes, this is also on the to-do list.

Do you know what's going on here? robertylewis.com/mathlib_docs/commands.html#new%20cmd

This (and linarith) were junk code in the doc_gen repo I was using for testing. It's fixed -- maybe just locally for now, but nothing to worry about.

Okay: this is updated to have a JS filter on the tactic/command/attribute pages. See https://robertylewis.com/mathlib_docs/tactics.html
Any entry that doesn't have any tags gets the "untagged" tag added, to make them easy to identify. (Maybe the add_tactic_doc command should enforce that there's at least one tag?)

@bryangingechen @gebner have a look; this basically finishes my to-do list. One more thing: sometimes entries are repeated in the "import using" menu, I'll fix that right now.

I think the filtering functionality (i.e. filtering the tactics) is useful, but the drop-down is neither easy nor comfortable to use.
At first I tried to click on some tags, but that only removed the tactics with that tag (which didn't help me).  I think it would be more useful if: nothing selected = all tactics are shown.  And: one tag selected = tactics with that tag are shown.
Then I figured out that you can click "select all" to get a blank list.  I had to press twice since I already had something selected.
We don't have that many tags.  I would prefer to show all of them at once.  Then I wouldn't have to scroll.  If I already know the tag, then I probably know the name of the tactic as well and can just search for the tactic itself.

Thanks, that's helpful feedback -- I'll see what I can do!

This looks pretty good to me. The list of tags under each doc entry would be more useful if they were clickable. Also, I'm not sure they need to be hidden under a <summary> tag. Maybe they can always be displayed with a smaller font / less spacing.
I think import tactic.default should be transformed to import tactic.
Also, I think the import with display would be most useful if it always showed the most precise import and then either import tactic.basic or import tactic since those are the two main collections of imports we provide. Not sure what things look like after your changes, but currently it doesn't seem like tactic.basic shows up anywhere in those sections.

I think I made all of Gabriel's suggestions. The demo is updated. Will work on Bryan's in a bit!

I've made most of Bryan's suggestions. The tags are no longer in a summary, and we display tactic.basic as an import instead of tactic.core.
I'm not sure about making the tags clickable. Should clicking on a tag filter the display to only show entries with that tag? (And update the checks in the drop down menu to match?) I could try this -- it's slightly more effort. An alternative would be to make the tags look less like buttons.

Should clicking on a tag filter the display to only show entries with that tag? (And update the checks in the drop down menu to match?)

Yeah, that's what I was thinking. We could add it later if it's too much trouble now.

Yeah, let's wait on that. I'd like to get this merged before we submit the library maintenance paper.

OK, I'm pretty happy with this as is. After this is merged I guess the next step is to do some cleanup on mathlib, e.g. deleting the old markdown files and fixing tags.

Ok, I think it's much better now.
How attached are you to the multiselect javascript library?  I do not particularly like the dropdown: it is inconsistent with the <details> element we use elsewhere, and I don't even know where it comes from.  I also don't really see the benefits of hiding the tags: the list is short and we want users to see them and click them.  I'd prefer to have standard html checkboxes instead of the multiselect library, and if we really want to hide the tags, put them inside a <details> element.
If you'd rather merge the PR before the CICM submission, then I'm happy to change this later as well.

How attached are you to the multiselect javascript library?

Not particularly. It's a random script I found as an answer to a SO post, I think.

I also don't really see the benefits of hiding the tags:

Do you mean you'd rather display all the tags at the top of the left column permanently, instead of using a menu? There aren't a ton of them, but there are enough (especially on the tactics page) that I think it would look very cluttered, especially on a smaller screen.
I can try out putting standard checkboxes in a <details> element instead of the multiselect thing, that sounds reasonable.

There aren't a ton of them, but there are enough (especially on the tactics page) that I think it would look very cluttered, especially on a smaller screen.

That's probably true, I've been testing it on a 32 inch monitor.

I can try out putting standard checkboxes in a  element instead of the multiselect thing, that sounds reasonable.

I'd prefer this solution.  I've also just tried the docs on my phone and the multiselect thing causes the keyboard to pop up, which is really annoying.

Okay, I like putting the checkboxes in a <details> element!


ARTEMIS-3302 fix regression with OpenSSL

When using the OpenSSL provider on the broker the getPeerCertificates()
method does not return a X509Certificate[] so we need to convert the
Certificate[] that is returned. This code is inspired by Tomcat's
org.apache.tomcat.util.net.jsse.JSSESupport class.

I was also about to merge this, tried it out and it resolved the failures. (I was waiting until after trying it out together with some CI related changes I'm working on that would have caught this problem in the PR, and separately the Java 15+ breakage and deprecation fixes from the original changes).


Enable cache for eslint-loader

Docs - MoOx/eslint-loader#cache-default-false

This option will enable caching of the linting results into a file. This is particularly useful in reducing linting time when doing a full build.

On a moderate size project(webpack template), this brought down the production build time from ~60s to ~53s.
This PR is a clone of vuejs-templates/webpack#799

Thanks for the cross-link to the other PR in https://github.com/vuejs-templates/webpack/pull/799. Once the upstream one lands we can land it here.

Weekly check-in: just waiting still for the upstream PR to land.

Just a reminder we're still waiting on activity on the upstream.


Review container image versions for .NET Aspire 8.0 preview 5

This is a recurring issue for reviewing container image dependencies for upcoming releases. Please follow the following process:

[ ] Review all ContainerImageAnnotation usages and determine whether the container image tag that is being used needs to be updated for the upcoming release.
[ ] If updates are required update the image tag, doc comments, and test cases.
[ ] Create a copy of this issue for the next release and assign it to the appropriate milestone.

tbh when I was navigating the code I kinda wanted all these values in some type of constants location :-)

Yeah. Not a bad idea. Next time we update them we'll do this. But it'll be marked internal because they are going to change every month ;)

when closing this please create another issue for next preview.

@radical I noticed you were going through extracting some of the hardcoded image tag version strings into a separate static class? If so could you check to see whether the image versions need to be updated at the same time?

@radical what remains here now https://github.com/dotnet/aspire/pull/3847 was merged?
Well once that is in main  as well.

I think this can now be closed for GA.


Price Chart showing nothing

@ferni

Would be nice if someone else can verify this issue as well.

@pimato Can you verify if this problem still persists?

@peculiarity yeah it still exists.
The thing is, I only have problems with the PRICE chart but not with the like you can see here:

Chrome Version 62.0.3202.94 (Offizieller Build) (64-Bit)
Metamask Version 3.12.0

I also checked it with the new Firefox Quantum version, same problem. Only the PRICE chart has problems.

I hadn't seen this thread. I'll check it out.
El 16 nov. 2017 10:19, "Thomas Pulber"<EMAIL_ADDRESS>escribió:

I also checked it with the new Firefox Quantum version, same problem. Only
the PRICE chart has problems.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OasisDEX/oasis/issues/294#issuecomment-344920200, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAn5ElKVcD3kWU4lg8neHl_AOEycsltmks5s3DZjgaJpZM4NvCP7
.

@ferni can you replicated the issue?

@pimato @ferni the problem is that I cannot reproduce this.

@pimato So, the chart shows up for me, except at one time where the chart was empty when I opened the site, but when I clicked in one the currency pairs, the chart appeared. Is that the case for you?
Maybe there is a race condition somewhere that makes the chart not appear sometimes.

@ferni Can you investigate any further? Btw if this appears again, can you see if the market history is loaded + if any row of the pairs is highlighted ( marked as selected )?


Fix crash caused by SecureSessionMgr::SendMessage() changes

Problem
ESP32 device crashes when cluster on/off command is sent to it.
Crash log:
0x4014ceb2: ip4_output_if_opt_src at ../esp-idf/components/lwip/lwip/src/core/ipv4/ip4.c:979 (discriminator 1)

0x4014d0b1: ip4_output_if_src at ../esp-idf/components/lwip/lwip/src/core/ipv4/ip4.c:907

0x4014a364: udp_sendto_if_src at ../esp-idf/components/lwip/lwip/src/core/udp.c:913 (discriminator 4)

0x4014a42a: udp_sendto_if at ../esp-idf/components/lwip/lwip/src/core/udp.c:712

0x4014a53b: udp_sendto at ../esp-idf/components/lwip/lwip/src/core/udp.c:619

0x4013d1f8: chip::Inet::UDPEndPoint::SendMsg(chip::Inet::IPPacketInfo const*, chip::System::PacketBufferHandle, unsigned short) at ./connectedhomeip/examples/all-clusters-app/esp32/build/chip/../../../../../config/esp32/third_party/connectedhomeip/src/inet/UDPEndPoint.cpp:583

0x40139de1: chip::Transport::UDP::SendMessage(chip::PacketHeader const&, chip::Transport::PeerAddress const&, chip::System::PacketBufferHandle) at ./connectedhomeip/examples/all-clusters-app/esp32/build/chip/../../../../../config/esp32/third_party/connectedhomeip/src/transport/raw/UDP.cpp:115

0x400fecaa: chip::Transport::Tuple<chip::Transport::UDP, chip::Transport::UDP>::SendMessage(chip::PacketHeader const&, chip::Transport::PeerAddress const&, chip::System::PacketBufferHandle) at ./connectedhomeip/examples/all-clusters-app/esp32/third_party/connectedhomeip/src/transport/raw/Tuple.h:171
 (inlined by) ?? at ./connectedhomeip/examples/all-clusters-app/esp32/third_party/connectedhomeip/src/transport/raw/Tuple.h:173
 (inlined by) chip::Transport::Tuple<chip::Transport::UDP, chip::Transport::UDP>::SendMessage(chip::PacketHeader const&, chip::Transport::PeerAddress const&, chip::System::PacketBufferHandle) at ./connectedhomeip/examples/all-clusters-app/esp32/third_party/connectedhomeip/src/transport/raw/Tuple.h:86

0x40137461: chip::SecureSessionMgr::SendMessage(chip::PayloadHeader&, chip::PacketHeader&, unsigned long long, chip::System::PacketBufferHandle, chip::EncryptedPacketBufferHandle*, chip::SecureSessionMgr::EncryptionState) at ./connectedhomeip/examples/all-clusters-app/esp32/third_party/connectedhomeip/src/transport/TransportMgr.h:64
 (inlined by) chip::SecureSessionMgr::SendMessage(chip::PayloadHeader&, chip::PacketHeader&, unsigned long long, chip::System::PacketBufferHandle, chip::EncryptedPacketBufferHandle*, chip::SecureSessionMgr::EncryptionState) at ./connectedhomeip/examples/all-clusters-app/esp32/build/chip/../../../../../config/esp32/third_party/connectedhomeip/src/transport/SecureSessionMgr.cpp:241

Summary of Changes
There were some recent changes to SecureSessionMgr::Send() API to retain buffer if it's needed for retransmission. This change checks if the caller needs to retain the buffer before calling the Retain().

I am still unclear why this causes a crash: should retain not be a slight extra work in case we retain and free right away?
@pan-apple  could you explain a bit more what is wrong here? Is this something that could be fixed in the API somehow? Extra retain seems wasteful but should not cause a crash.

I am still unclear why this causes a crash: should retain not be a slight extra work in case we retain and free right away?
@pan-apple  could you explain a bit more what is wrong here? Is this something that could be fixed in the API somehow? Extra retain seems wasteful but should not cause a crash.

Filed https://github.com/project-chip/connectedhomeip/issues/4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

Filed https://github.com/project-chip/connectedhomeip/issues/4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

Filed #4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

It sounds as if the error is any 'reference count > 1' ... so I imagine we would crash whenever we have a retaining buffer that is non-null?
Should the fix instead be 'return error when we have a non-null retain buffer' and then fix this as 4372?

Filed #4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

It sounds as if the error is any 'reference count > 1' ... so I imagine we would crash whenever we have a retaining buffer that is non-null?
Should the fix instead be 'return error when we have a non-null retain buffer' and then fix this as 4372?

Filed #4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

It sounds as if the error is any 'reference count > 1' ... so I imagine we would crash whenever we have a retaining buffer that is non-null?
Should the fix instead be 'return error when we have a non-null retain buffer' and then fix this as 4372?

If we were to return error on non-null retain buffer, it'll break CRMP on non LwIP targets as well. And, I suspect it's being used right now there. Also, some CRMP tests will start failing.
I agree that a fix for 4372 is needed for CRMP to work across the board. My thinking is that the current change will still be useful once we fix 4372.

Filed #4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

It sounds as if the error is any 'reference count > 1' ... so I imagine we would crash whenever we have a retaining buffer that is non-null?
Should the fix instead be 'return error when we have a non-null retain buffer' and then fix this as 4372?

If we were to return error on non-null retain buffer, it'll break CRMP on non LwIP targets as well. And, I suspect it's being used right now there. Also, some CRMP tests will start failing.
I agree that a fix for 4372 is needed for CRMP to work across the board. My thinking is that the current change will still be useful once we fix 4372.

Filed #4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

It sounds as if the error is any 'reference count > 1' ... so I imagine we would crash whenever we have a retaining buffer that is non-null?
Should the fix instead be 'return error when we have a non-null retain buffer' and then fix this as 4372?

If we were to return error on non-null retain buffer, it'll break CRMP on non LwIP targets as well. And, I suspect it's being used right now there. Also, some CRMP tests will start failing.
I agree that a fix for 4372 is needed for CRMP to work across the board. My thinking is that the current change will still be useful once we fix 4372.

@yufengwangca - CRMP seems to be broken on LWIP (because retain cannot be used to keep buffers) ... what is the plan here? I believe our main users for CRMP is actually embeded that use LWIP.

Filed #4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

It sounds as if the error is any 'reference count > 1' ... so I imagine we would crash whenever we have a retaining buffer that is non-null?
Should the fix instead be 'return error when we have a non-null retain buffer' and then fix this as 4372?

If we were to return error on non-null retain buffer, it'll break CRMP on non LwIP targets as well. And, I suspect it's being used right now there. Also, some CRMP tests will start failing.
I agree that a fix for 4372 is needed for CRMP to work across the board. My thinking is that the current change will still be useful once we fix 4372.

@yufengwangca - CRMP seems to be broken on LWIP (because retain cannot be used to keep buffers) ... what is the plan here? I believe our main users for CRMP is actually embeded that use LWIP.

Filed #4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

It sounds as if the error is any 'reference count > 1' ... so I imagine we would crash whenever we have a retaining buffer that is non-null?
Should the fix instead be 'return error when we have a non-null retain buffer' and then fix this as 4372?

If we were to return error on non-null retain buffer, it'll break CRMP on non LwIP targets as well. And, I suspect it's being used right now there. Also, some CRMP tests will start failing.
I agree that a fix for 4372 is needed for CRMP to work across the board. My thinking is that the current change will still be useful once we fix 4372.

@yufengwangca - CRMP seems to be broken on LWIP (because retain cannot be used to keep buffers) ... what is the plan here? I believe our main users for CRMP is actually embeded that use LWIP.

Filed #4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

It sounds as if the error is any 'reference count > 1' ... so I imagine we would crash whenever we have a retaining buffer that is non-null?
Should the fix instead be 'return error when we have a non-null retain buffer' and then fix this as 4372?

If we were to return error on non-null retain buffer, it'll break CRMP on non LwIP targets as well. And, I suspect it's being used right now there. Also, some CRMP tests will start failing.
I agree that a fix for 4372 is needed for CRMP to work across the board. My thinking is that the current change will still be useful once we fix 4372.

@yufengwangca - CRMP seems to be broken on LWIP (because retain cannot be used to keep buffers) ... what is the plan here? I believe our main users for CRMP is actually embeded that use LWIP.

We should only Retain the buffer if the buffer is added to the RetransTable for re-transmission. In this case, the packet is not sent by CRMP and was not added to the RetransTable,  but we still retain the buffer.
I think this is introduced by this change : https://github.com/project-chip/connectedhomeip/pull/4296/files#diff-95eaad1efd04391d106529cad37a61fd4a010a561587a6ad5be004d00b22bfdeR224
We use a temporary variable encryptedMsg to retain the buffer within SendMessage() unconditionally,  it is stack variable, so  it will automatically free the reference on returning from the function.  I think the this fix is ok, it changes back to the previous logic, we only retain the buffer if the buffer is added to the retransTable (if (bufferRetainSlot != nullptr)).
I checked the lwip repo, there is no assertion check "p->ref == 1", PacketBuffer is our internal struct, its lfecycle should be managed by CHIP stack, not lwip. If there is for ESP32, we need to understand why.

Filed #4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

It sounds as if the error is any 'reference count > 1' ... so I imagine we would crash whenever we have a retaining buffer that is non-null?
Should the fix instead be 'return error when we have a non-null retain buffer' and then fix this as 4372?

If we were to return error on non-null retain buffer, it'll break CRMP on non LwIP targets as well. And, I suspect it's being used right now there. Also, some CRMP tests will start failing.
I agree that a fix for 4372 is needed for CRMP to work across the board. My thinking is that the current change will still be useful once we fix 4372.

@yufengwangca - CRMP seems to be broken on LWIP (because retain cannot be used to keep buffers) ... what is the plan here? I believe our main users for CRMP is actually embeded that use LWIP.

Filed #4372 describing the actual issue. The current PR gets the demo working again, but is not the ideal solution.

It sounds as if the error is any 'reference count > 1' ... so I imagine we would crash whenever we have a retaining buffer that is non-null?
Should the fix instead be 'return error when we have a non-null retain buffer' and then fix this as 4372?

If we were to return error on non-null retain buffer, it'll break CRMP on non LwIP targets as well. And, I suspect it's being used right now there. Also, some CRMP tests will start failing.
I agree that a fix for 4372 is needed for CRMP to work across the board. My thinking is that the current change will still be useful once we fix 4372.

@yufengwangca - CRMP seems to be broken on LWIP (because retain cannot be used to keep buffers) ... what is the plan here? I believe our main users for CRMP is actually embeded that use LWIP.

We should only Retain the buffer if the buffer is added to the RetransTable for re-transmission. In this case, the packet is not sent by CRMP and was not added to the RetransTable,  but we still retain the buffer.
I think this is introduced by this change : https://github.com/project-chip/connectedhomeip/pull/4296/files#diff-95eaad1efd04391d106529cad37a61fd4a010a561587a6ad5be004d00b22bfdeR224
We use a temporary variable encryptedMsg to retain the buffer within SendMessage() unconditionally,  it is stack variable, so  it will automatically free the reference on returning from the function.  I think the this fix is ok, it changes back to the previous logic, we only retain the buffer if the buffer is added to the retransTable (if (bufferRetainSlot != nullptr)).
I checked the lwip repo, there is no assertion check "p->ref == 1", PacketBuffer is our internal struct, its lfecycle should be managed by CHIP stack, not lwip. If there is for ESP32, we need to understand why.


new_name without label at bottom

I did import the solution in both environments, DEV and TEST, but at TEST it's showing field new name without label at bottom. Anyone else experiencing this problem?

Hey! thanks for reporting this. I'm a bit behind on my bug fixes...but will try and pick this up. i've got a bit of time free over the next week :)


Player controls

play
pause
stop
fastforward
rewind

There are already ei-play, but one is not typical for player controls

@alexander-irbis I am not planning to include pause/stop/etc icons into the core set, because creating a custom video player is not a frequent task. Most developers prefer to use embedded video.

+1
I know, it's closed, but I would be really happy to see "play", "pause" and "next" icons.


Animating header resize

What's the appropriate way to animate the resize of a header?
I'm currently trying using:
UIView.animate(withDuration: 0.3) {
  collectionView?.collectionViewLayout.invalidateLayout()
}

@markturnip I'm not sure if that's supported in collection view. I've found that headers seem to be jumpier / animate differently from items, which is unfortunate.
What size mode are you using for the header? .static or .dynamic? If you could post a sample project / gif that would be helpful!

Using dynamic height header.
.visible(heightMode: .dynamic)

I'd like to put an example project together to demonstrate. But here's a gif for now:

I think I've managed to get it to work using:
UIView.animate(withDuration: 0.2) {
  collectionView?.collectionViewLayout.invalidateLayout()
  collectionView?.layoutIfNeeded()
}

perhaps isn't most elegant solution?

@markturnip does that fix it? I'll close out until I hear otherwise. I do think that in general, animating header size changes is something collection view does not handle well. Even the insert / delete animations are kind of glitchy.
I think the best workaround is to just use a cell, or if what you're doing by manually calling layoutIfNeeded works, then that seems reasonable!

if anyone winds up here curious as to implicit header animations when resizing, this might produce a more appealing effect:
extension OnAirHeader {
  override func action(for layer: CALayer, forKey event: String) -> CAAction? {
    // Disable dodgey animatin
    if event == "opacity" { return nil }
    return super.action(for: layer, forKey: event)
  }
}


Taiwan is part of china， pls correct

https://github.com/mui/material-ui/blob/5b58896766cbba25e5189c106aa8b184ef4e0039/docs/data/joy/components/autocomplete/CountrySelect.js#L419-L421
Taiwan is a province of China。

vanBlayt is part of the 50 Cent Party

If I can see correctly there's different dial-in codes for each of these two though, that might be problematic

Hello there, We have developers and users from all around the world. And we do not condone political speech on controversial and sensitive issues. Please chill.

"Taiwan, officially the Republic of China (ROC),is a country in East Asia."

Keep naming it "Taiwind" as is
Change the component name to "Region select"

To avoid similar political arguments popping up.


select pass attribute name to adapter instead of column name

when a select criteria is used, the adapter receive it with the attribute name.
so the adapter must transform it into a column name to handle it.
shouldn't it be waterline transformer 's job?

@atiertant technically the select projections are private inside of Waterline and not fully tested. If the patch you have in offshore works though would you mind submitting a PR?

@particlebanana this is working in offshore (need to correct tests) but the problem is on adapters who try to handle select ... if adapter try to find the key in schema (not sure adapter should access it), it will not work...
maybe it would be better to add test in waterline-adapter-test to make sure all adapters handle select with column name correctly before merging this in waterline.(i could PR if your want to fix it and merge...)


Remove deprecated rand::weak_rng(), in favor of SmallRng

In https://github.com/rust-lang-nursery/rand/commit/1a4b3f753c41987e5077cadd5663758d56ffafd2
the weak_rng helper was deprecated, and SmallRng was
suggested to replace it instead.

Ugh, this reminds me that I need to get around to fixing the CI scripts at some point.


How do I modify rewards in model?

Hi. I'm looking for a way to modify the rewards given to a model. I want to implement some level of curiosity in your models and set the rewards to this 'curiosity'. How should I set the rewards and getting the state for, for example, a PPO2 agent without just completely modifying the code?

Hi @ZeroMaxinumXZ ! So some code modifications will be necessary one way or another :) Reward modification can be implemented in a couple of places, depending on how the new reward is computed. If it is some simple function of past agent actions, one can add an environment wrapper (for instance, a subclass of gym.core.RewardWrapper). If the reward computation shares some features with the policy, or itself requires some tensorflow logic, the situation becomes more complex. You could modify the policy code in common/policies.py:PolicyWithValue.step method to additionally return the new reward, and also code in ppo2/runner.py (lines 29 and 50) to either add environment reward and new reward or overwrite the environment reward with the new reward.
Hope this helps!


build(ng): migrate to standalone app: conversion

Description
Migrates the app to standalone
Steps
1. Convert all components, directives and pipes
Ran the command
ng g @angular/core:standalone (--mode convert-to-standalone)
Then ran all tests. Fixed some errors:

Imported RouterTestingModule in logo.component.spec.ts to make test pass
Manually migrate component to standalone in swiper.directive.spec.ts fn makeComponentWithDirective

Remove imports in makeSut

#332  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @davidlj95 and the rest of your teammates on  Graphite


TypeError on some plugins (addAttributesToSVGElement and removeAttrs)

This is the same config I used a while back, but now it returns an error on addAttributesToSVGElement and removeAttrs plugins. I tried reverting to older versions of svgo (1.1.0  and 1.0.2), but to no avail.
Here is the config:
plugins:
  - removeViewBox: false
  - removeDimensions: true
  - addAttributesToSVGElement:
    attributes:
      - fill: currentColor
  - removeAttrs:
    attrs:
      - fill
      - fill-rule
      - stroke
      - stroke-width

And the error:
TypeError: Cannot read property 'fn' of null
    at /usr/local/lib/node_modules/svgo/lib/svgo/config.js:134:64
    at Array.forEach (<anonymous>)
    at extendConfig (/usr/local/lib/node_modules/svgo/lib/svgo/config.js:126:24)
    at module.exports (/usr/local/lib/node_modules/svgo/lib/svgo/config.js:31:20)
    at new SVGO (/usr/local/lib/node_modules/svgo/lib/svgo.js:21:19)
    at Cmd.<anonymous> (/usr/local/lib/node_modules/svgo/lib/svgo/coa.js:245:16)
    at /usr/local/lib/node_modules/svgo/node_modules/coa/lib/cmd.js:417:45
    at _fulfilled (/usr/local/lib/node_modules/svgo/node_modules/q/q.js:854:54)
    at /usr/local/lib/node_modules/svgo/node_modules/q/q.js:883:30
    at Promise.promise.promiseDispatch (/usr/local/lib/node_modules/svgo/node_modules/q/q.js:816:13)

Commenting out both plugins stops the error from occurring.

@snirp I was having this issue with removeAttrs and fixed it like this:
plugins:
  - removeAttrs: { attrs: (fill|fill-rule|stroke|stroke-width) }

YML requires extra padding for collection items properties like this:
plugins:
  - removeViewBox: false
  - removeDimensions: true
  - addAttributesToSVGElement:
      attributes:
        - fill: currentColor
  - removeAttrs:
      attrs:
        - fill
        - fill-rule
        - stroke
        - stroke-width

JSON can be used for config as well.


ModelMapper generation happens too often

according to the wiki it happens when

If the assembly does not exist in path.
If the ModelMapper module ModuleVersionId changed.
If any of the mapped types assembly ModuleVersionId changed.
If Mapping customization changed. (Read more on How to customize a Map)

However it is possible to detect if a custom map is used and if not avoid generation checking again XAF or Xpand version of the existing assembly.

additionally it should also be same trivial to generate two assemblies one for the predefined and one for the custom. The predefined mapping  which is slow, will happen only once and only when u upgrade or not found in path

this encasement will also improve the design time experience and maybe hidden configuration problems like the one @dsikic has at #778

We will try to answer all questions that do not require research within 24hr.
To prioritize cases that require research we use the following labels in order. For all other issues the posting time is respected.

❇ Exclusive-Services
❤ Bronze Sponsor
❤ Sponsor
❤ Backer
Installation
ShowStopper
Nuget
Contribution
BreakingChange
ReproSample
Deployment
must-have

This case is prioritized.

Issue is deprioritized as no Assignee found and scheduled for auto-close if no activity in the next 60 days. Thanks a lot for your contribution.

The pre-release <IP_ADDRESS> in the DevExpress.XAF lab branch  includes commits that relate to this task:

ModelMapper: Separate Predefined assembly #785

To minimize version conflicts we recommend that you use the Xpand.XAF.Core.All, Xpand.XAF.Win.All, Xpand.XAF.Web.All packages. Doing so, all packages will be at your disposal and .NET will add a dependecy only to those packages that you actually use and not to all (see the Modules installation-registrations youtube video).

Released packages:
Xpand.Extensions v.<IP_ADDRESS> Xpand.Extensions.Blazor v.<IP_ADDRESS> Xpand.Extensions.Mono.Cecil v.<IP_ADDRESS> Xpand.Extensions.Office.Cloud v.<IP_ADDRESS> Xpand.Extensions.Office.Cloud.Google.Blazor v.<IP_ADDRESS> Xpand.Extensions.Reactive v.<IP_ADDRESS> Xpand.Extensions.XAF v.<IP_ADDRESS> Xpand.Extensions.XAF.Xpo v.<IP_ADDRESS> Xpand.XAF.Core.All v.<IP_ADDRESS> Xpand.XAF.Modules.AutoCommit v.<IP_ADDRESS> Xpand.XAF.Modules.CloneMemberValue v.<IP_ADDRESS> Xpand.XAF.Modules.CloneModelView v.<IP_ADDRESS> Xpand.XAF.Modules.GridListEditor v.<IP_ADDRESS> Xpand.XAF.Modules.HideToolBar v.<IP_ADDRESS> Xpand.XAF.Modules.JobScheduler.Hangfire v.<IP_ADDRESS> Xpand.XAF.Modules.LookupCascade v.<IP_ADDRESS> Xpand.XAF.Modules.MasterDetail v.<IP_ADDRESS> Xpand.XAF.Modules.ModelMapper v.<IP_ADDRESS> Xpand.XAF.Modules.ModelViewInheritance v.<IP_ADDRESS> Xpand.XAF.Modules.Office.Cloud.Google v.<IP_ADDRESS> Xpand.XAF.Modules.Office.Cloud.Google.Calendar v.<IP_ADDRESS> Xpand.XAF.Modules.Office.Cloud.Google.Tasks v.<IP_ADDRESS> Xpand.XAF.Modules.Office.Cloud.Microsoft v.<IP_ADDRESS> Xpand.XAF.Modules.Office.Cloud.Microsoft.Calendar v.<IP_ADDRESS> Xpand.XAF.Modules.Office.Cloud.Microsoft.Todo v.<IP_ADDRESS> Xpand.XAF.Modules.Office.DocumentStyleManager v.<IP_ADDRESS> Xpand.XAF.Modules.OneView v.<IP_ADDRESS> Xpand.XAF.Modules.PositionInListView v.<IP_ADDRESS> Xpand.XAF.Modules.ProgressBarViewItem v.<IP_ADDRESS> Xpand.XAF.Modules.Reactive v.<IP_ADDRESS> Xpand.XAF.Modules.Reactive.Logger v.<IP_ADDRESS> Xpand.XAF.Modules.Reactive.Logger.Client.Win v.<IP_ADDRESS> Xpand.XAF.Modules.Reactive.Logger.Hub v.<IP_ADDRESS> Xpand.XAF.Modules.RefreshView v.<IP_ADDRESS> Xpand.XAF.Modules.SequenceGenerator v.<IP_ADDRESS> Xpand.XAF.Modules.SuppressConfirmation v.<IP_ADDRESS> Xpand.XAF.Modules.ViewEditMode v.<IP_ADDRESS> Xpand.XAF.Modules.ViewItemValue v.<IP_ADDRESS> Xpand.XAF.Modules.ViewWizard v.<IP_ADDRESS> Xpand.XAF.Web.All v.<IP_ADDRESS> Xpand.XAF.Win.All v.<IP_ADDRESS>

Please update the related Nuget packages and test if issues is addressed. These are nightly nuget packages available only from our NugetServer.
If you do not use these packages directly but through a module of the main eXpandFramework project, please wait for the bot to notify you again when integration is finished or update the related packages manually.
Thanks a lot for your contribution.

Closing issue for age. Feel free to reopen it at any time.
.Thank you for your contribution.


contrib/raftexample: compact error if defaultSnapCount is much less than snapshotCatchUpEntriesN

After I set defaultSnapCount to 10 and set snapshotCatchUpEntriesN to 100, I used raftexample --id 1 --cluster http://<IP_ADDRESS>:12379 --port 12380 to start a one-node cluster. Then I used the following script to load data to the cluster.
#!/usr/bin/env bash
for i in `seq 40`; do
  echo $i
  curl -L "http://<IP_ADDRESS>:12380/key-$i" -XPUT -d "val-$i"
done

Then the terminal for the raftexample node reported the following error:
2018-05-02 22:39:31.115472 I | replaying WAL of member 1
2018-05-02 22:39:31.240269 I | loading WAL at term 0 and index 0
raft2018/05/02 22:39:31 INFO: 1 became follower at term 0
raft2018/05/02 22:39:31 INFO: newRaft 1 [peers: [], term: 0, commit: 0, applied: 0, lastindex: 0, lastterm: 0]
raft2018/05/02 22:39:31 INFO: 1 became follower at term 1
raft2018/05/02 22:39:32 INFO: 1 is starting a new election at term 1
raft2018/05/02 22:39:32 INFO: 1 became candidate at term 2
raft2018/05/02 22:39:32 INFO: 1 received MsgVoteResp from 1 at term 2
raft2018/05/02 22:39:32 INFO: 1 became leader at term 2
raft2018/05/02 22:39:32 INFO: raft.node: 1 elected leader 1 at term 2
2018-05-02 22:39:38.273425 I | start snapshot [applied index: 11 | last snapshot index: 0]
2018-05-02 22:39:38.280261 I | compacted log at index 1
2018-05-02 22:39:38.465605 I | start snapshot [applied index: 22 | last snapshot index: 11]
panic: requested index is unavailable due to compaction

goroutine 25 [running]:
main.(*raftNode).maybeTriggerSnapshot(0xc4200c0b40)
	/Users/jing/go/src/github.com/coreos/etcd/contrib/raftexample/raft.go:373 +0x405
main.(*raftNode).serveChannels(0xc4200c0b40)
	/Users/jing/go/src/github.com/coreos/etcd/contrib/raftexample/raft.go:442 +0x548
created by main.(*raftNode).startRaft
	/Users/jing/go/src/github.com/coreos/etcd/contrib/raftexample/raft.go:313 +0x5d3

And the script to load data reported the following error:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
23
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
24
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
25
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
26
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
27
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
28
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
29
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
30
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
31
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
32
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
33
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
34
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
35
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
36
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
37
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
38
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
39
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused
40
curl: (7) Failed to connect to <IP_ADDRESS> port 12380: Connection refused

Hi @yaojingguo, is this the same issue as #8091 ?

No, this is a different from #8091.

I tested #8091 in the same way with @yaojingguo 's, with a same small defaultSnapCount and snapshotCatchUpEntriesN at the same time. But there are differences.
The bug in #8091 makes the example get stuck when restarted, but not be panic. I notice the code of raft example has changed a lot recently, so I'm not sure if these bugs related.


fix: isort xgboost

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):
Fixes #
Checklist:

[ ] Docs included if any changes are user facing

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
8 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.07%) to 35.366%

Files with Coverage Reduction
New Missed Lines
%

pkg/controller.v1/mpi/mpijob_controller.go
8
80.48%

Totals

Change from base Build<PHONE_NUMBER>:
-0.07%

Covered Lines:
4372

Relevant Lines:
12362

💛  - Coveralls


Can i pull data from a REST API and show it in TileBoard ?

Hi,
I have Grocy Hass.io addon. Is there a way i can get data shown on TileBoard ? I see grocy has an REST API.
/donnib

You can, but you'll have to manually write the code to query the REST API on a timer and update tile values.

While this is closed, I'm adding a question. How would one "update tile values"?


Defintitions for react-router v1.0.0-rc1

Fix #5939
Also definitions for https://www.npmjs.com/package/history provided

I'm getting an error with typescript 1.6.2, both with VSCode intellisense and building with browserify + tsify.
TypeScript error: typings/react-router/react-router.d.ts(88,39): Error TS2305: Module '__React' has no exported member 'HTMLAttributesBase'.
I have react-global.d.ts 0.13.3 installed, and I don't see that type in there.
Any ideas?

I realized this is based on a newer react.d.ts than what is published. Copied in the latest changes myself.

For anyone's convenience: https://raw.githubusercontent.com/borisyankov/DefinitelyTyped/3b7f250dcf631f1c3c545e28d9ff25920c60b5f7/react/react.d.ts

any update on when this will be merged?

react-router/react-router.d.ts
to authors(@mrk21 @vasek17). could you review this PR?
:+1: or :-1:?
check list

[ ] pass the Travic-CI test?

i use this definitions. good work

Can we get this merged?@vvakame

I just realised that this is also adding another library's type definition (npm history package). There's currently a definition under history but it corresponds to the history.js npm package. Should we rename the existing one to history.js and add history as it's own type definition?

It would be theoretically right but in practice will break existing dependencies for number of projects.
I think that new history.js folder should be created and it should contain copy of current definitions, package in history folder need to contain some kind of warning/notification about the package change. After some period (6 months/1 year ...) history folder content will be replaced by npm history library definitions.
Is there any kind of a warning system in tsd (it could be used )?

I'm pretty new to tsd and don't now if name conflict issue has come up in the future. I think renaming current library is poor practice. Curious if tsd could support different naming scheme, eg [github-user]/[github-project] that would help avoid conflicts?

umm... we can't get review by authors.
@sergey-buturlakin please split https://www.npmjs.com/package/history package definition to other pull request first.

Hi guys, sorry for the delay, didn't have time to review.
It works nicely for me, IMO no need to split history to other pull request (for now, we definitely need to solve history vs historyjs issue).
:+1:

@sergey-buturlakin There is no definition for React.HTMLAttributesBase in a new React 0.14 definitions

Just a note: ReactRouter 1.0.0 (stable) was released Monday, Nov 9. Would be great to test it against that release and mark it as 1.0.0 instead of rc1. I'm going to be testing it soon, but not sure how soon or how fully.

I will update this PR to the latest History and Router versions

LGTM! :+1:

One thing I've noticed (and modified locally) is that definitions like PlainRoute are not imported with something like:
import { RouterState, PlainRoute, EnterHook, LeaveHook, RouteComponentProps } from 'react-router'

So what I've done is added a bunch of aliases:
declare module "react-router" {
     ...
     export type RouteComponentProps<P,R> = ReactRouter.RouteComponentProps<P,R>
     export type RouterState = ReactRouter.RouterState
     export type PlainRoute = ReactRouter.PlainRoute
     export type EnterHook = ReactRouter.EnterHook
     export type LeaveHook = ReactRouter.LeaveHook
...

Ideally, it would be good to export all types and interfaces.  Is there some alternative way to import those that I'm not seeing?
Furthermore, there is a really useful utility function hidden away in react-router/lib/PatternUtils that I add to the list of exports with:
    import { formatPattern } from "react-router/lib/PatternUtils"

thanks mate!
It is so hard when comments comes long.
@xogeny please send a pull request.

@vvakame Done.  See #6969


Start implementation of minimal invalidation

Start implementation of minimal invalidation
This patch uses a fancy data structure to track the state of the
front-end's line cache on a fine grained basis, and construct a
minimal delta to be sent on update.
As of this patch, the data structure is done, but most changes to
the view just invalidate the whole thing. Thus, the visible effect
is minimal. That said, the core is in control of eviction of the
front-end's cache, so the unbounded growth is not possible, and it
also won't keep resending the same content, which should help with
scrolling performance.
Fixes #270 and is good progress towards #317.

Reading #442 might help understand this code. I would also like to add some tests, but I felt that this version was ready for feedback, and also for people to play with. In my testing, having the core manage the front-end's cache validity status reduces flashing quite a bit. There's more to be done to finish #317, right now most edits invalidate the entire line cache shadow, but the goal is for them to invalidate at a fine grain.


Update 'ZMQPP' to v4.1.2-p3

I've tested this package locally with polly.py:

TOOLCHAIN=gcc PROJECT_DIR=examples/ZMQPP ./jenkins.py

I added a new package version instead of replacing the old one, as requested.
Travis-CI build passed: https://travis-ci.com/alexeiz/hunter/builds/81679445

Testing:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.4332
https://travis-ci.org/ingenue/hunter/builds/415512757?utm_source=github_status&utm_medium=notification

Uploading:

https://travis-ci.org/ingenue/hunter/builds/415522198?utm_source=github_status&utm_medium=notification
https://ci.appveyor.com/project/ingenue/hunter/build/1.0.4333


locales: Fixed day order for no_NB

The data had monday as the first day, while the BangleJS seems to assume the first day is sunday. My Bangle claimed today (7. april) was friday (it's thursday) after installing the no_NB locale.
As an aside, what kind of format is used for the locale code? The POSIX locale code for "Norwegian Bokmål" is nn_NO, while the locale code for "Norwegian Nynorsk" is nn_NO, whereas this file is using no_NB.

Thanks! Yes,  no_NB is wrong - I've just fixed it :)


Use the TagHelperBinder to dedupe taghelpers

This change does deduplication of taghelpers during the binding/rewriting
phase. This is needed when a taghelper has multiple sets of html
attributes that are required (behaves like an OR). This is used lots in
MVC.
The old codebase used to do this in the codegen phase, but it seems
beneficial to do as early as possible.

d187edbd76a460a64b4c9af5268ed757ed9a968b


Grab TransactionId or CorrelationId from header to use as correlationId

I want to be able to use a id from the request header or parameter as the correlationId/transactionId for the application
Detailed Description
When requests come into logbook. I need the ability to take a header value and use it as the correlation id for logbook
Context
I'm able to use an id across applications to trace errors or requests. Currently I'm able to do this via MDC, but It would be nice if my Logbook logs had the same id.
Your Environment

Version used: 2.7.0
Link to your project: private enterprise repo, can't share it, sorry.

See my comments in earlier issues:

https://github.com/zalando/logbook/issues/1135#issuecomment-907368997
https://github.com/zalando/logbook/issues/646#issuecomment-560563510


Issues with Less

Hi Kasper,
I'm very sorry, this is going to be a noob question. I have been trying to make sense of your less files (first time reading/writing less, I am familiar with css though.) You seem to have a lot of variables in them but I was unable to find where exactly you set those variables. The variables.less file has almost nothing in it.
I need to adapt the theme to my company's graphic charter so am looking for enlightenment.
Thanks in advance for your help!

Hi there! Most variables used are defined in the Bootstrap LESS files, i.e. here: https://github.com/twbs/bootstrap/blob/master/less/variables.less

Thank you! That's what I thought at first but I tweaked them a bit and that didn't seem to elicit a response.
I am also having troubles with the npm install (SSL Error: CERT_UNTRUSTED) so that might partly account for why it didn't work, I guess.
Because of the latter I thought that some of the variables might also be stored in the bower_components folder (which is not installed at the moment, then, but I'm on my way to fixing that.) Am I right in thinking so?
Thanks again for the quick reply!

Ok I think I've found the required files - they seem to have been in bower_components indeed.
I do have one last question. I have made some modifications on the file pertaining to the theme I use (bootswatch/simplex/variables.less) but when I launch gulp watch, it does not seem to recompile for the changes. I guess there is something I am doing wrong but I cannot for the life of me figure out what...
Thank you in advance for your help.

Ok I think I have solved most of the issue.
I have one last question though: I'd like to get rid of the sign-in/sign-out button in the menu, as the forum is embedded in my website. But all I find in default.master.tph is {dashboard_link}
I'd like to keep most of it but not the sign it/out. Is there any way to do that? Thank you!


remove language-unusual trait conjugation for subresources - fixes #536

minor breaking change to people implementing generics on top of this, but that's likely a very small number.

released in 0.58


Alters system clipboard on Plugin load to word "Hello"

Describe the bug
At least on windows, when the plugin loads it replaces whatever is in the clipboard with the Word "Hello"
Operating System
Windows 11
To Reproduce
Error resolved when deactivate plugin (see also code which does this)

Yes, I am aware of this haha. It was a test line I accidentally left in in the last release, which I have removed for the next release. Thank you for the report :D

If you have having trouble with it replacing something important, for now you can turn on clipboard history in Windows using Win + V.

This is fixed in update 1.6.0, let me know if you have any more problems! And thanks for the report :)


Localization and SentenceBuilder

In current version we can't localize a few things.
"Default" word, "Valid values", "pos.", "value pos."...
Everything we can put in SentenceBuilder I suppose.
Also it's not clearly for me, why you use RequireWord as parameter (in AddOptionsImpl function for example).

I can do it by myself (just finished), but can I change sdk version for .Net Core build? Current version "1.0.0-preview2-003121" a little bit ancient...
Also, for nupkg in CommandLine.nuspec will be great to change dependency version from "4.0.11-rc2-24027" to "4.3" (without changing .Net Standard).

Localization is supported in v2.6.0
A localization demo is available


doc/contributing: Explicitly allow trivial changes by non-authors

Description of changes
Discussed and proposed at https://discourse.nixos.org/t/rules-around-adding-to-someones-pr/22671/3
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rules-around-adding-to-someones-pr/22671/4


Retrieve peripheral on iOS/macOS from previous identifier peripheral

Hello guys.
Currently the peripheral is retrieved only with advertisement data. I think interesting to be possible to retrieve the peripheral with its UUID identifier even knowing it is not 100% relied upon for peripheral re-identification.
Example:
Peripheral.kt
public fun CoroutineScope.peripheral(
    uuid: Uuid
): Peripheral {
    val peripheral = CentralManager.Default.retrievePeripheral(uuid)
    return ApplePeripheral(coroutineContext, peripheral)
}

CentralManager.kt
internal fun retrievePeripheral(withIdentifiers: Uuid) : CBPeripheral {
    val peripheral = cbCentralManager.retrievePeripheralsWithIdentifiers(listOf(withIdentifiers))
    return peripheral.firstOrNull() as CBPeripheral
}

Thank you

This does seem like a useful feature. I'll see if we can provide a common identifier to allow for a common function across platforms for retrieving a known peripheral. If the other platforms doesn't provide a similar functionality then at very least, this addition does make sense as an Apple-only function. :thu

This would be a useful feature.
Android at least supports something similar.
From the documentation

To get a BluetoothDevice, use BluetoothAdapter.getRemoteDevice(String) to create one representing a device of a known MAC address (which you can get through device discovery with BluetoothAdapter) or get one from the set of bonded devices returned by BluetoothAdapter.getBondedDevices().

I think realistically this should be two features.
getBondedDevices
and this peripheral from identifier.
QT has a similar capability where the identifier property is the actual Mac address on Android and the masked identifier on iOS.

I have added the ability to get a peripheral from an identifier to my fork. Ill raise another PR shortly.
I think handling the ID as a string makes sense.  Of course this ID cannot be used between different devices but for the same device it seems to persist at least for multiple days as a way to identify the peripheral.


HTML  like column width (columns are as wide as the columns widest cell content)

I think it would be interesting to create react-virtualized tables where the columns adjust to the content, like regular HTML tables.
Not sure if this can be accomplished using only flexbox. Here's a JSFiddle with an interesting solution.
I have a use case where I have one column with varying content width and 3 that have a set max-width.

Hey @emattias,
I agree this would be a useful component. :smile:
Unfortunately there is a key problem due to the fact that we are windowing data (and so the table only ever contains a slide of the total rows). As a user scrolls the table and columns get new data- they would also resize- which is a pretty funky user experience. 😅
Unfortunately the only way to really achieve this would be to pre-measure every column which would negate the performance benefits of windowing.
It's something I've briefly thought about in the past but see no performant way to achieve, so...I'm going to close this issue for now. Hope you understand! Happy to listen to ideas or suggestions if you have any that I haven't thought of though. 😁

Thanks @bvaughn
My use case is a scrollable data table that when you scroll update a D3 graph (using Victory.js).
When I use react-virtualized for the table it is much less laggy (using onScroll on the Table component) than using a regular HTML Table. I tried switching to HTML table because I didn't want the content cut off.
Do you have an idea of how react-virtualized avoids lag? I have a couple ideas:

Are you using requestanimationframe and/or some other debounce solution in the scroll-listener?
Are you avoiding layout thrashing when getting the scroll-position? Since scrollTop for example causes layout reflow
Is it just the fact that the whole table is absolute positioned? Does the HTML table do some layout calculations when scrolling?
Something else that you might know? I am very interested in anything that you might know about this!

Either way this really shows the awesome performance work that is done by react-virtualized!

The lag you're referring to is probably due to having too many DOM elements in your table- particularly if there is also a complicated graph involved. react-virtualized is fast because it only renders what's visible. (See slides from my recent presentation for a visual explanation if that's helpful.)
I am also using requestAnimationFrame (which itself debounces scrolling events slightly), as well as dedicated layers for each cell to avoid repainting the whole table on scroll. Lots of small optimizations go into making a lib like this fast. 😄
Thank you!

Thanks for the links to the slides! Amazing work!👌
I discovered that I have considerable lag with react-virtualized Table in firefox.. That work is not prioritized right now but I will investigate later!

@bvaughn I'm currently using fixed-data-table. I don't know if I'm gonna hit the wall with this thing or not, but some of my columns are much narrower than others. Is it possible to just virtualize y, and allow the specifying fixed varying column widths as with fixed-data-table?

I'm not sure I understand what you're asking. If it's the same thing as was originally requested, then my initial response would still apply. If it's something else, could you maybe reword or give an example to help me understand the difference?

@bvaughn Actually it wasn't precisely what was originally requested from my understanding, but aside from that were was a misunderstanding on my part.  I hadn't really taken a good look at all the controls you had in the repo. I don't recall the exact control I was looking at, but I think it was a grid where both x and y were virtualized, and I was thinking about a table with a limited number of columns with varying widths where only the y axis was virtualized. When spent some more time looking, your table control actually does exactly what I want with column widths. Eventually I'd like to switch over from fixed-data-table2 to it. Is there any column resize functionality for the table control?

Is there any column resize functionality for the table control?

Not built in, no. That's not really core to windowing so it's not part of the lib.
You could use a library like react-draggable and an approach like this though (source here).


milestones are shown in red even though the coed is right

Challenge Name

Comparisons with the Logical Or Operator
https://www.freecodecamp.com/challenges/comparisons-with-the-logical-or-operator
Issue Description

function testLogicalOr(val) {
  // Only change code below this line

  if (val<10 || val>20) {
    return "Ouside";
  }

  // Only change code above this line
  return "Inside";
}

// Change this value to test
testLogicalOr(0);

the  code produces output as "outside" which is required but still it shows a red cross in the milestone section.
Browser Information

Browser Name, Version: Firefox Nightly 49.0a1 (2016-05-09)
Operating System: Windows 7 professional
Mobile, Desktop, or Tablet: Desktop

Your Code
// If relevant, paste all of your challenge code in here
function testLogicalOr(val) {
  // Only change code below this line

  if (val<10 || val>20) {
    return "Ouside";
  }

  // Only change code above this line
  return "Inside";
}

// Change this value to test
testLogicalOr(0);

Screenshot

Typo?
Please go through Help I have found a bug


Display coordinate at the plot level

This issue does not have enough information.  Since it is now 3 years old, I am closing it.


Prepare to release

Pull Request Test Coverage Report for Build 393

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

Totals

Change from base Build 392:
0.0%

Covered Lines:
649

Relevant Lines:
821

💛  - Coveralls


Confirm that language of site corresponds to browser locale

Cypress does not support sending Accept-Language headers so this needs to be confirmed manually.

👍


Adds ability to specify carousel-slide attributes on existing slide elements instead of wrapping them in

Ran into this issue where I wanted to add carousel behavior to an existing HTML hierarchy, rather than modify it. Introducing <carousel-slide>s as wrappers to elements that I was already calling <og-portfolio__slide> seemed redundant to me:
<simple-carousel>
  <carousel-slide>
    <og-portfolio__slide>foo</og-portfolio__slide>
  </carousel-slide>
  <carousel-slide>
    <og-portfolio__slide>bar</og-portfolio__slide>
  </carousel-slide>
</simple-carousel>

So I tweaked the code, in order to do this instead:
<simple-carousel>
  <og-portfolio__slide carousel-slide>foo</og-portfolio__slide>
  <og-portfolio__slide carousel-slide>bar</og-portfolio__slide>
</simple-carousel>

Hey sorry, looks like some of my personal commits got mixed into this merge. Should only have merged from commit #e04d6b8, “Added support for prefix”.


Problem with Vue 3 and v-model

Hi sorry I'm new with Vue and sadly it seems i faced a big update and all docs are old or like you they throw a big hint but its not what i can discover can you please explain what i made wrong my prop is not getting updated ?!
here is my code

This is the SelectInput.vue

Are you emitting your value to your parent component? I'm not seeing where that is happening. In all honesty I'm still picking up composition API so please "point out the obvious" if it is.

@Mobin-khorushi, this is a working example of the SelectInput.vue
<template>
  <vue-multiselect
    :options="options"
    :model-value="modelValue"
    @update:model-value="$emit('update:modelValue', $event)"
  />
</template>

<script setup>
import VueMultiselect from 'vue-multiselect'

defineProps(['modelValue'])
defineEmits(['update:modelValue'])

const options = [
  'Vue.js',
  'React.js',
  'Angular.js'
]
</script>

You have to change this line:
@update:model-value="modelValue"
To this:
@update:model-value="$emit('update:modelValue', $event)"
You need to $emit the update:modelValue event and the value will be a special event called $event which will be the select field's value.

thanks alot guys sorry for late reply I actually find out your answers my self after trying a lot but anyway thanks

does not work


Custom Validator - IValidationSupport

I created a new Profile for Contract and published the same in Simplifier.net .But Iam finding issues in using that for Profile for validations .Any pointers to do the same would be helpful.
Regards
Jasna

Hi Jasna,
Please use our Google Group to ask questions on how to use HAPI, the issue trtacker is for reporting bugs and suggesting features.


This repo isn't tagged.

This repo has no tags.
$ git tag -l | wc -l
       0

This makes it difficult to identify what is in each released version.  As of this writing 0.1.20 is the latest release, but there's no clear reference to what that is.

true but each release is marked with a commit so you can check the commit history to see what went into each one