[SPARK-28224][SQL] Aggregate sum large decimals

What changes were proposed in this pull request?

Currently sum in aggregates for decimal type can overflow and returning null.

Sum expression codegens arithmetic on sql.Decimal and the output which preserves scale and precision goes into UnsafeRowWriter. Here overflowing will be converted to null when writing out.
It also does not go through this branch in DecimalAggregates because it's expecting precision of the sum (not the elements to be summed) to be less than 5.
https://github.com/apache/spark/blob/4ebff5b6d68f26cc1ff9265a5489e0d7c2e05449/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/Optimizer.scala#L1400-L1403

This PR adds the check at the final result of the sum operator itself.
https://github.com/apache/spark/blob/4ebff5b6d68f26cc1ff9265a5489e0d7c2e05449/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/aggregate/interfaces.scala#L372-L376

https://issues.apache.org/jira/browse/SPARK-28224
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

Added an integration test on dataframe suite

cc @mgaido91 @JoshRosen

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

PS Please add [SQL] to the PR title.
Honestly, I don't consider this a followup to #25010. This was actually a bug leading to weird behaviors, such as show prints an output, while collect returns null. And this is independent from the PR you linked.

ok to test

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/12405/
Test PASSed.

Test build #107252 has started for PR 25033 at commit 01174be.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/12408/
Test PASSed.

Test build #107258 has started for PR 25033 at commit b668d6f.

@mgaido91, thank you for the review! I made the updates.
To your original question on SQL server behavior, there seem to be different outcome among sql versions. From fiddle here:
Sql5.6 would arbitrarily loose precision even on integral parts with rounding. [0]
Sql MS Sql Server107 would show error Data truncation [1]
Aiming for a least-surprise behavior, do you think sum here should be treated the same as other arithmetic operations on fixed precisions?
A larger question here is perhaps if there are other operations on fixed precision that could result in overflow. And supposed we are okay with this PR fix, does it mean we should patch for all such operators? A non-issue here is pow operator with Double type.
[0] http://sqlfiddle.com/#!9/676c31/1
[1] http://sqlfiddle.com/#!18/0baa5/1

Test build #107252 has finished for PR 25033 at commit 01174be.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/107252/
Test PASSed.

Thanks for your work. Regarding SQLServer, I also checked its behaviour. The main difference with our current behaviour is that it always returns the max precision, instead of our formula 10 + precision. So I submitted a PR for that.
LGTM

Test build #107258 has finished for PR 25033 at commit b668d6f.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/107258/
Test FAILed.

jenkins retest this please

jenkins retest this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/12555/
Test PASSed.

Test build #107419 has started for PR 25033 at commit 4094335.

Test build #107419 has finished for PR 25033 at commit 4094335.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/107419/
Test PASSed.

hi @dongjoon-hyun, @cloud-fan. Just would like to follow-up on this PR please.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/14348/
Test PASSed.

Test build #109280 has started for PR 25033 at commit 67a956e.

Test build #109280 has finished for PR 25033 at commit 67a956e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/109280/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/14375/
Test PASSed.

Test build #109312 has started for PR 25033 at commit 4497576.

Test build #109312 has finished for PR 25033 at commit 4497576.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/109312/
Test FAILed.

Test build #109353 has started for PR 25033 at commit 49c97d8.

Build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/14419/
Test PASSed.

Test build #109353 has finished for PR 25033 at commit 49c97d8.

This patch fails to build.
This patch does not merge cleanly.
This patch adds no public classes.

Build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/109353/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/14420/
Test PASSed.

Test build #109356 has started for PR 25033 at commit db2d9a5.

Test build #109356 has finished for PR 25033 at commit db2d9a5.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/109356/
Test PASSed.

Thanks! Merged to master.


UDAP dynamic client registration

https://www.udap.org/udap-dynamic-client-registration.html

being worked on in tiered-oauth branch

TODO fix current error:
Alert: UDAP registration failed - error: invalid_client_metadata - description: Client registration metadata malformed or invalid.

FIXED tiered-oauth branch now implements UDAP Dynamic Client Registration

Done with PR #28


Add originating request IP

I need this, and this is probably generally useful.  It would also be pretty reasonable to say all uploaded dumps should always store the originating IP, regardless of whether the user adds a parameter for this to their config.

I agree. I think I would rather have this as a default property since it's pretty useful across the board.

Cool, I'll refactor things to do that by default.

Updated, simpler now =)

:+1:
Now we have to figure out how to do migrations of the database to add this when we release to avoid bumping the major version every time we make a schema update to the database.


Test for duplicate symbols/macros

We've had a few cases where we accidentally include the same symbol or macro definition in both macros.js and symbols.js.  This new test automatically detects these scenarios during Jest testing.
As a test, I reversed these changes and I got the following errors:
  ● Symbols and macros › macro \llbracket should not shadow a symbol

    expect(received).toBeFalsy()

    Received: {"font": "main", "group": "open", "replace": "⟦"}

       6 |         it(`macro ${macro} should not shadow a symbol`, () => {
       7 |             for (let kind in symbols) {
    >  8 |                 expect(symbols[kind][macro]).toBeFalsy();
         |                                              ^
       9 |             }
      10 |         });
      11 |     }

      at Object.toBeFalsy (test/redundancy-spec.js:8:46)

  ● Symbols and macros › macro \rrbracket should not shadow a symbol

    expect(received).toBeFalsy()

    Received: {"font": "main", "group": "close", "replace": "⟧"}

       6 |         it(`macro ${macro} should not shadow a symbol`, () => {
       7 |             for (let kind in symbols) {
    >  8 |                 expect(symbols[kind][macro]).toBeFalsy();
         |                                              ^
       9 |             }
      10 |         });
      11 |     }

      at Object.toBeFalsy (test/redundancy-spec.js:8:46)

  ● Symbols and macros › macro ⟦ should not shadow a symbol

    expect(received).toBeFalsy()

    Received: {"font": "main", "group": "open", "replace": "⟦"}

       6 |         it(`macro ${macro} should not shadow a symbol`, () => {
       7 |             for (let kind in symbols) {
    >  8 |                 expect(symbols[kind][macro]).toBeFalsy();
         |                                              ^
       9 |             }
      10 |         });
      11 |     }

      at Object.toBeFalsy (test/redundancy-spec.js:8:46)

  ● Symbols and macros › macro ⟧ should not shadow a symbol

    expect(received).toBeFalsy()

    Received: {"font": "main", "group": "close", "replace": "⟧"}

       6 |         it(`macro ${macro} should not shadow a symbol`, () => {
       7 |             for (let kind in symbols) {
    >  8 |                 expect(symbols[kind][macro]).toBeFalsy();
         |                                              ^
       9 |             }
      10 |         });
      11 |     }

      at Object.toBeFalsy (test/redundancy-spec.js:8:46)

Codecov Report

Merging #1955 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1955      +/-   ##
==========================================
- Coverage   94.92%   94.91%   -0.01%
==========================================
  Files          79       79
  Lines        4843     4839       -4
  Branches      845      845
==========================================
- Hits         4597     4593       -4
  Misses        222      222
  Partials       24       24

Flag
Coverage Δ

#screenshotter
89.48% <ø> (-0.01%)
:arrow_down:

#test
86% <ø> (-0.02%)
:arrow_down:

Impacted Files
Coverage Δ

src/macros.js
97.6% <0%> (-0.03%)
:arrow_down:

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 6bb312f...e3460a3. Read the comment docs.


Fix all_day recognition

Fix type check for all_day flag as suggested in issue #22 .
Fix description copying for recurring events (see #13 ).

@dlichtistw if you fix the test I will merge your pull request.

FAIL: test_event_attributes (test.test_icalevents.ICalEventsTests)
Traceback (most recent call last):
File "/home/travis/build/irgangla/icalevents/test/test_icalevents.py", line 43, in test_event_attributes
self.assertFalse(ev.all_day)
AssertionError: True is not false

Hm, not sure why this test checked for all_day == False. I told it to expect True.

You are right, I think the test was wrong.


pdfrx may be slow in some cases

I found that in some cases, pdfrx's speed of loading page images would be slower.
For example:

Trying to open a large PDF file, let's call it PDF A.
Opening a regular PDF file, let's call it PDF B.
Attempting to render a page from PDF B.

In this scenario, rendering the page from PDF B is slower than usual, especially after having tried to open the larger PDF A. Only after PDF A has finished loading, PDF B will start to load.
I found that pdfrx uses a BackgroundWorker  internally to handle all tasks, which is essentially a single-threaded worker that handle asynchronous behavior.
Can we change this situation, for example, using a separate BackgroundWorker for each PDFDocument?

1.0.58 fixes concurrency issues caused by misunderstanding of pdfium threading model.
And the fix synchronizes all the pdfium API calls even if they are not for the same PDF document.
In your case, PDF A loading process blocks loading of PDF B loading. The loading of the documents does not run concurrently.
It's a pdfium limitation. Not a pdfrx limitation.
We should consider some kind of out of process PDF loading model but it's too complex and not easily realized.


Add vddk settings in Provider

Short description:
The location in the vddk image has changed in MTV 2.3 and it is now going in the provider cr
More details:
What this PR does / why we need it:
Which issue(s) this PR fixes:
Special notes for reviewer:
Bug:

/verified

/verified

/verified


Service definition for kubernetes

Coverage increased (+0.07%) to 94.0% when pulling 926f99e1a71910f191e6b640477d3c44e7ce554b on service-definition into c749cf1d1a148ed4ca12ed409febea42b48b71c8 on master.

Coverage increased (+0.07%) to 94.0% when pulling 5f9274091a21935a65babe6006398d1d7ae28229 on service-definition into c749cf1d1a148ed4ca12ed409febea42b48b71c8 on master.

Coverage increased (+0.07%) to 94.0% when pulling 5f9274091a21935a65babe6006398d1d7ae28229 on service-definition into c749cf1d1a148ed4ca12ed409febea42b48b71c8 on master.

Coverage increased (+0.07%) to 94.0% when pulling 752ff64954615179b675548cb887096156745816 on service-definition into c749cf1d1a148ed4ca12ed409febea42b48b71c8 on master.

No issues from my side


[BUG]: image build failure

Describe the bug
when I run docker-compose build to build the docker image, I got an error
Details
Conductor version: latest
Workflow definition:
Task definition:
Event handler definition:
To Reproduce
Steps to reproduce the behavior:

Go to docker
Run `docker compose build

Expected behavior
image should be built
Screenshots
log
$ docker-compose build
dynomite uses an image, skipping
elasticsearch uses an image, skipping
Building conductor-server
[+] Building 84.8s (11/16)
 => [internal] load build definition from Dockerfile                                                                                0.1s
 => => transferring dockerfile: 902B                                                                                0.0s
 => [internal] load .dockerignore                                                                                0.1s
 => => transferring context: 57B                                                                                0.0s
 => [internal] load metadata for docker.io/library/openjdk:11-jre                                                                          2.6s
 => [internal] load metadata for docker.io/library/openjdk:11-jdk                                                                          3.0s
 => [auth] library/openjdk:pull token for registry-1.docker.io                                                                             0.0s
 => [internal] load build context                                                                                0.6s
 => => transferring context: 24.57MB                                                                                0.6s
 => [stage-1 1/6] FROM docker.io/library/openjdk:11-jre@sha256:b25d05fbe423b5b0f88fc2f253d5464e07210d061c5538de4766a1a3f2cfb70f            0.0s
 => => resolve docker.io/library/openjdk:11-jre@sha256:b25d05fbe423b5b0f88fc2f253d5464e07210d061c5538de4766a1a3f2cfb70f                    0.0s
 => [builder 1/4] FROM docker.io/library/openjdk:11-jdk@sha256:369854afc795005451787f24e455daa8f409ecf3b1f67c3c1395359adf8a10a8           10.9s
 => => resolve docker.io/library/openjdk:11-jdk@sha256:369854afc795005451787f24e455daa8f409ecf3b1f67c3c1395359adf8a10a8                    0.0s
 => => sha256:6ebb70c7b4c9c490e11b57114624bfa16e12ccf974339fb25d6b64d322f4ebb0 1.79kB / 1.79kB                                             0.0s
 => => sha256:e782567c0965aa75bd3f25766422b8023ce77ae542064a56d9d9aec285dbec01 6.26kB / 6.26kB                                             0.0s
 => => sha256:bf76209566d0c8d78df205b09e6e5b52ff7f10cb4e1c03d9336ed7dd2decd919 51.84MB / 51.84MB                                           2.7s
 => => sha256:f10db7ba7580dd43abbf34313aab51dae288a6ef8dcd1b60860a97679c47942d 5.29MB / 5.29MB                                             0.9s
 => => sha256:369854afc795005451787f24e455daa8f409ecf3b1f67c3c1395359adf8a10a8 1.04kB / 1.04kB                                             0.0s
 => => sha256:5b2f970878fad14882553683f35f608f8e510c8886959085d5c5b43947104abe 210B / 210B                                                 0.4s
 => => sha256:ed434bfebf18b6bcb8ae2c5552ff4319f726cbfa5006cd890d8c044403fee7fb 203.13MB / 203.13MB                                         6.1s
 => => extracting sha256:bf76209566d0c8d78df205b09e6e5b52ff7f10cb4e1c03d9336ed7dd2decd919                                                  2.5s
 => => extracting sha256:f10db7ba7580dd43abbf34313aab51dae288a6ef8dcd1b60860a97679c47942d                                                  0.2s
 => => extracting sha256:5b2f970878fad14882553683f35f608f8e510c8886959085d5c5b43947104abe                                                  0.0s
 => => extracting sha256:ed434bfebf18b6bcb8ae2c5552ff4319f726cbfa5006cd890d8c044403fee7fb                                                  4.5s
 => [builder 2/4] COPY . /conductor                                                                                1.1s
 => [builder 3/4] WORKDIR /conductor                                                                                0.0s
 => ERROR [builder 4/4] RUN ./gradlew build -x test                                                                                68.8s
------
 > [builder 4/4] RUN ./gradlew build -x test:
#12 0.476 Downloading https://services.gradle.org/distributions/gradle-6.8.3-bin.zip
#12 1.304 ..........10%..........20%..........30%...........40%..........50%..........60%..........70%...........80%..........90%..........100%
#12 4.970
#12 4.971 Welcome to Gradle 6.8.3!
#12 4.971
#12 4.972 Here are the highlights of this release:
#12 4.972  - Faster Kotlin DSL script compilation
#12 4.972  - Vendor selection for Java toolchains
#12 4.972  - Convenient execution of tasks in composite builds
#12 4.972  - Consistent dependency resolution
#12 4.972
#12 4.972 For more details see https://docs.gradle.org/6.8.3/release-notes.html
#12 4.972
#12 5.151 Starting a Gradle Daemon (subsequent builds will be faster)
#12 34.42
#12 34.42 > Configure project :conductor-azureblob-storage
#12 34.42 Inferred project: conductor, version: 0.1.0-SNAPSHOT
#12 49.82
#12 49.82 > Task :processResources NO-SOURCE
#12 49.82 > Task :compileJava NO-SOURCE
#12 49.82 > Task :classes UP-TO-DATE
#12 49.92 > Task :createPropertiesFileForJar
#12 50.02 > Task :writeManifestProperties
#12 50.02 > Task :jar
#12 50.62 > Task :startScripts
#12 50.62 > Task :distTar
#12 50.62 > Task :distZip
#12 50.62 > Task :assemble
#12 50.62 > Task :check
#12 50.62 > Task :conductor-azureblob-storage:processResources NO-SOURCE
#12 50.62 > Task :conductor-common:processResources NO-SOURCE
#12 59.58
#12 59.58 > Task :conductor-common:compileJava
#12 59.58 Note: /conductor/common/src/main/java/com/netflix/conductor/common/jackson/JsonProtoModule.java uses or overrides a deprecated API.
#12 59.58 Note: Recompile with -Xlint:deprecation for details.
#12 61.78
#12 61.78 > Task :conductor-core:processResources
#12 65.48
#12 65.48 > Task :conductor-core:compileJava
#12 65.48 Note: Some input files use or override a deprecated API.
#12 65.48 Note: Recompile with -Xlint:deprecation for details.
#12 67.48
#12 67.48 > Task :conductor-azureblob-storage:compileJava FAILED
#12 67.48
#12 67.48 FAILURE: Build failed with an exception.
#12 67.48
#12 67.48 * What went wrong:
#12 67.48 Execution failed for task ':conductor-azureblob-storage:compileJava'.
#12 67.48 > Could not resolve all files for configuration ':conductor-azureblob-storage:compileClasspath'.
#12 67.48    > Could not find com.azure:azure-storage-blob:12.2.0.
#12 67.48      Required by:
#12 67.49          project :conductor-azureblob-storage
#12 67.49 > Failed to resolve the following dependencies:
#12 67.49     1. Failed to resolve 'com.azure:azure-storage-blob:12.2.0' for project 'conductor-azureblob-storage'
#12 67.49
#12 67.49 * Try:
#12 67.49 Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
#12 67.49
#12 67.49 * Get more help at https://help.gradle.org
#12 67.49
#12 67.49 BUILD FAILED in 1m 7s
#12 67.49 9 actionable tasks: 9 executed
#12 67.58
#12 67.58 Publishing build scan...
#12 68.08 https://gradle.com/s/xhft4o7yedxdq
#12 68.08
------
executor failed running [/bin/sh -c ./gradlew build -x test]: exit code: 1
ERROR: Service 'conductor-server' failed to build : Build failed

Additional context
It used to work, but somehow start to fail recently

@yangzhang21 Thanks for reporting it. azure-storage-blob:12.2.0 is not available in Maven Central. Upgraded the library to its latest, 12.13.0.

If you are in China, you can try to use maven{ url 'http://maven.aliyun.com/nexus/content/groups/public/'} in root build.gradle to solve this problem

use 12.7.0 ,

i still see the issue after changing zaure-storage-blob to 12.13.0. 12.7.0 works for me :)

yeah.. 12.13.0 have other change. i will cause some compile error.  the 12.7.0 is the smallest change we can get now. it seems like any version below 12.7.0 is 404 in mavencentral now.

i still see the issue after changing azure-storage-blob to 12.13.0. 12.7.0 works for me :)

I wonder if you could help specifying which files you made this change. I had the same issue.

i still see the issue after changing azure-storage-blob to 12.13.0. 12.7.0 works for me :)

I wonder if you could help specifying which files you made this change. I had the same issue.

update the     revAzureStorageBlobSdk = '12.2.0' to 12.7.0  inhttps://github.com/Netflix/conductor/blob/main/dependencies.gradle
delete the file https://github.com/Netflix/conductor/blob/main/azureblob-storage/dependencies.lock otherwise the above change won't apply.

hope it will help....


shift  + < for maximising terminal ... :) how am I supposed to do arrow functions?

shift  + < for maximising terminal ... :) how am I supposed to do arrow functions?
Good thing you have a shortcut editor... that also renders all old settings to being reset after update...

I'm not sure I understand the issue? Are you saying shift+< maximizes the terminal/panel? Please provide some more info.

I can't find this keyboard shortcut... having it would be desirable. yes.


severe early-onset pulmonary alveolar proteinosis due to MARS deficiency

severe early-onset pulmonary alveolar proteinosis due to MARS deficiency MONDO:0014206
References that need to be fixed:
Orphanet:370088 (Acute infantile liver failure-multisystemic involvement syndrome) a different condition.
0000-0019310-0163
Thank you, Gioconda

Orphanet:370088 is equivalent to 'infantile liver failure syndrome 1' (MONDO:0024568)
It is "related", and NOT equivalent to 'severe early-onset pulmonary alveolar proteinosis due to MARS deficiency' *=(MONDO:0014206).
The OLS page might be confusing because it shows both Orphanet, but one needs to click on the i icon to know one is "related"


Consumer: ram & swap overeating when prometheus tries to collect data from karton-system with 20k+ tasks in run

Hello,
I met a problem with karton-dashboard when I try to collect /vars using prometheus every 5 secs with more than 10k tasks.
Karton-dashboard exceeds 5s limit (context deadline exceeded prometheus error) and tries to collect data again - and karton-dashboard prepares two reports at the same time, using two cpu cores, but the second request exceeds 5s limit too, the third request will be born - and it looks like deadlock of requests.
CPU exhaust ia a bad news, but it is bearable. Every such request consumes a lot of ram, so soon the server will have no ram, this way I have no possibility even to kill karton-dashboard)

This issue wrote just for acknolegement about the situation with a lot of tasks - I think it is a architecure issue and probably it is fixable if we will use less resouce-consuming stats obtaining.

Identified: ~10 of tasks had 500+ mb in redis, it will cause such problems


5GB size limit

Hello, first of all thank you for the alternative actions-cache. I use it to control when to restore and save cache.
Recently I started hitting 5GB limit when uploading cache. However Github has increased cache size limit to 10GB. https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#usage-limits-and-eviction-policy

Hey, glad to hear you find this useful. I don't know when I'll have time to merge the changes from upstream into this repository. If you require this change soon, please consider opening a PR. I reckon it was this commit that increased the limit: https://github.com/MartijnHols/actions-cache/commit/eb0698d1c508f8573fddfe25566f10a4b1344504

I just merged all changes up to 3.0.11 of actions/cache into the repository, so this should now be included.


Feature request:  Condition.innerText() / Condition.innerHtml()

The problem
Our company uses https://pusher.github.io/chameleon/ as a front end component library. The problem with it, is that it wraps a lot of elements that are unfortunately not handled by Selenide.
For some elements, it becomes really problematic, example a checkbox becomes a chameleon-checkbox.
I do not expect, you to support that (it would be an endless task to support every framework).
For some elements though, there are some possible workaround:
a p is often replaced by a chameleon-typography element. Unfortunately the condition.text always Yields "" and consequently fails.
Asserting on innerText() works on the other hand.
Details
What I would like is to support the innerText() and innerHtml() methods on the Conditions.xxx class.

@dacloutier-logmein Yes, we can add condition $.shouldHave(innerText("foo")) - similar to ownText we already have.
But do we really need $.shouldHave(innerHtml("foo"))? We don't usually verify html in tests. It would make our tests very fragile.
P.S. By the way, doesn't ownText already solve your problem?

@dacloutier-logmein Could you please write few examples, say, for site https://pusher.github.io/chameleon/components/forms/?
I am trying to understand what problems you have with these components.
For example, usual Selenide methods work with that checkbox without problems:
  @Test
  void canSetCheckbox() {
    open("https://pusher.github.io/chameleon/components/forms/");
    $("#hello").shouldBe(checked);
    $("#hello").click();
    $("#hello").shouldNotBe(checked);
  }

Found a page where we can see sample component:
https://chameleon-design-system.netlify.app/?path=/docs/components-form-elements-checkbox--default

 class chameleonWebTest
{

  private final static SelenideElement iFrame = $("#storybook-preview-iframe");
  private final static SelenideElement checkbox = $("chameleon-checkbox");
  private final static SelenideElement exampleSection = $("#story--components-form-elements-checkbox--default");

  @Test
  void checkbox()
  {
    open("https://chameleon-design-system.netlify.app/?path=/docs/components-form-elements-checkbox--default");
    switchTo().frame(iFrame);
    exampleSection.should(exist);
    checkbox.shouldBe(checked);
    checkbox.click();
    checkbox.shouldNotBe(checked);
  }
}

this yields:
Element should be checked {chameleon-checkbox}
Element: '<chameleon-checkbox checked label></chameleon-checkbox>'
Actual value: unchecked
Screenshot: file:~/Documents/IdeaProjects/chamelon-web-tester/chameleon-web-tester/build/reports/tests/1679399827689.0.png
Page source: file:~/Documents/IdeaProjects/chamelon-web-tester/chameleon-web-tester/build/reports/tests/1679399827689.0.html
Timeout: 4 s.
Element should be checked {chameleon-checkbox}
Element: '<chameleon-checkbox checked label></chameleon-checkbox>'
Actual value: unchecked

@dacloutier-logmein Thank you for the example!
Wait, but this checkbox is not clickable... How your test can uncheck it?
Anyway, I see this component uses Shadow DOM. Selenide has methods for working with shadow dom:
private SelenideElement checkboxValue = $(shadowCss("input[type=checkbox]", "chameleon-checkbox"));
private final SelenideElement checkbox = $("chameleon-checkbox");

checkboxValue.shouldBe(checked);
checkbox.click();
checkboxValue.shouldNotBe(checked); // It's OK: it fails because checkbox is not really clickable

Working with the shadow dom, worked !
Thanks!
Think we can close.


Improving date parsing

Making date parsing more flexible to accept non-standard dates.
Added unit tests for new date parsing code.
Improved some comments.

I pushed a change and tagged a new release that should address this. If it does not, please open a new issue.


Add NetApp E-Series exporter

Adds link for NetApp E-Series exporter.

I've not direct experience of NetApps. Looking at the readme does this apply to only this model, or all NetApps? Is this more of a "SANtricity Web Services Proxy" exporter? Is there a way to get these metrics without that proxy? I'd like to make sure that if we list something it's appropriately named so users can find it.
Some comments to help you improve your exporter:

If no timeout is defined the default is 10.

Prometheus passes the scape timeout in as a header, you might be able to use that rather than requiring the user to configure it.
The exporter.use-cache flag should be removed, the correct action when data collection fails is to fail the entire scrape - not silently serve stale or partial data.
Some metrics have inconsistent and non-base units, for example milliseconds, millibits, and percentages. You should use seconds, bytes, and ratios everywhere.
Several metrics appear to be calculated gauges, if the raw counters are available from the API it'd be better to use them instead.
read_iops is listed as a gauge, but sounds like a counter. If it is a counter it should end in _total.
drive_status seems to be mixing different types of information in one metric - the status should not be both a label and the metric value which will be difficult for users to use correctly. Based on the help string, I think the correct way to handle this is to remove the status label as there's only 0&1 states. storage_system_status looks to have the same issue.
The system-statistics appear to have an id label across all of them, which indicates it is actually a target label which it is the responsibility of Prometheus's service discovery to deal with. If you wish to expose this, it should be on a single info metric. Similarly for systemid.

I've not direct experience of NetApps. Looking at the readme does this apply to only this model, or all NetApps? Is this more of a "SANtricity Web Services Proxy" exporter? Is there a way to get these metrics without that proxy? I'd like to make sure that if we list something it's appropriately named so users can find it.

The web service is just a proxy to the API exposed by the E-Series.  The NetApp E-Series is a type of storage.  So this works by querying the E-Series API via the SANtricity proxy.  NetApp does not document how to talk to E-Series API directly.
This would not work on all NetApp like we have NetApp ONTAP systems of various models and those have entirely different methods for collecting data and actually deploy different exporter for that entirely different system.
As for models supported, that's a good question and not sure on that one.  I think the Proxy support matrix may determine what E-Series models work and NetApp has lots of support matrix pages.

Some comments to help you improve your exporter:

If no timeout is defined the default is 10.

Prometheus passes the scape timeout in as a header, you might be able to use that rather than requiring the user to configure it.

I have tended to use my own timeouts to kill off collection before the exporter gets marked down, so I can actually have a metric exposed that tells me about a timeout and so I can alert when the code times out vs the exporter being down.  This gives me insight as to when exporters are timing out vs totally down.

The exporter.use-cache flag should be removed, the correct action when data collection fails is to fail the entire scrape - not silently serve stale or partial data.

I realize this breaks norms but it was done for very specific reason.  If I have an alert that tells me when an E-Series has a failed drive, and the E-Series has a hickup and returns no data, Prometheus and alertmanager interrupt no data as the alert being resolved and I get a resolved email.  That's very bad when a team of people are responsible for hardware and if they see a resolved email they may not take action to address the thing that's still a problem.  I have not found another way to avoid false resolves other than caching data that is more about state and not about performance metrics.  Using absent() is far from ideal given the vast number of things we monitor and how absent() works does not lend itself to large installations and would still not get around the false resolve as best as I've been able to find.
Unless I was overly aggressive with caching, the caching should only be for things that are state, like if a drive is healthy.  The things like bytes read or IOPS will not be cached.  This was more geared towards caching things that would likely be alerts.

Some metrics have inconsistent and non-base units, for example milliseconds, millibits, and percentages. You should use seconds, bytes, and ratios everywhere.
Several metrics appear to be calculated gauges, if the raw counters are available from the API it'd be better to use them instead.

The units I used were whatever comes out of the E-Series API.  Also I am browsing code and everything as best I can remember is just taking JSON data from API and maybe adding labels for context around the value and then making that the Gauge. I am not finding where calculations are taking place but I haven't looked at this code in a bit of time so maybe I missed in my scan.

read_iops is listed as a gauge, but sounds like a counter. If it is a counter it should end in _total.

Based on way this data looks in Grafana, it's a rate from the raw source so just showing eseries_system_read_iops shows ups and downs so I do not believe these are actual counters, so my guess is the E-Series data is doing it's own rate calculations.

drive_status seems to be mixing different types of information in one metric - the status should not be both a label and the metric value which will be difficult for users to use correctly. Based on the help string, I think the correct way to handle this is to remove the status label as there's only 0&1 states. storage_system_status looks to have the same issue.

The status label is important as it can be many things and putting that status into an alertmanager alert gives myself and others on my team a quick way to know what actually has gone wrong.  Would it be better to keep the status label and have the metric be more like storage_system_status_info with the value always being 1?  I have seen that pattern in several exporters.

The system-statistics appear to have an id label across all of them, which indicates it is actually a target label which it is the responsibility of Prometheus's service discovery to deal with. If you wish to expose this, it should be on a single info metric. Similarly for systemid.

The ID value is coming from the E-Series API.  I'd want to keep that ID on all things so I could do something like this:
eseries_system_write_iops{id="e5660-02"}

The value for ID is what's used to actually configure the Web Proxy to make API calls so I did this for example:
curl -X POST -u admin:PASSWORD "http://localhost:8080/devmgr/v2/storage-systems" -H  "accept: application/json" -H  "Content-Type: application/json" -d "{  \"id\": \"e5660-02\",  \"controllerAddresses\": [    \"<IP_ADDRESS>\" , \"<IP_ADDRESS>\"  ],  \"acceptCertificate\": true,  \"validate\": false,  \"password\": \"OMIT\"}"

That added my E-Series to the web proxy service so I could make API calls.  It happens to be the value for target in Prometheus configs, so are you suggesting using Prometheus configs to add that label vs exporting it from exporter?

So this works by querying the E-Series API via the SANtricity proxy.

The APIs you're hitting don't have "e series" in their paths, so I suspect this may be more broadly applicable.

Prometheus and alertmanager interrupt no data as the alert being resolved and I get a resolved email.

That indicates a fragile alert that needs fixing, not a reason to go against best practices and make an exporter much harder to use correctly generally. See https://www.robustperception.io/alerting-on-gauges-in-prometheus-2-0

That's very bad when a team of people are responsible for hardware and if they see a resolved email they may not take action to address the thing that's still a problem.

That's a different problem, see https://www.robustperception.io/running-into-burning-buildings-because-the-fire-alarm-stopped
Suboptimal alert handling practices shouldn't determine exporter design, exporters should provide the best metrics they can.

This gives me insight as to when exporters are timing out vs totally down.

That's generally not very interesting, as an exporter being down is very rare - particularly if you've a supervisor. It's generally best to keep it simple. If scrapes are regularly failing, you have bigger problems.

The units I used were whatever comes out of the E-Series API. Also I am browsing code and everything as best I can remember is just taking JSON data from API and maybe adding labels for context around the value and then making that the Gauge.

That would be an acceptable tradeoff if you were treating all the API attributes in bulk, however given that each metric already has a few lines of code dedicated to it including specifying the exact metrics name you may aswell get this right while you're at it.

I am not finding where calculations are taking place but I haven't looked at this code in a bit of time so maybe I missed in my scan.

It's not uncommon unfortunately that devices don't provide raw counters, if they don't then there's not much we can do about it here.

Would it be better to keep the status label and have the metric be more like storage_system_status_info with the value always being 1?

Info metrics shouldn't change their labels over time, as you want to avoid series appearing and disappearing. How many potential status values are there, and do you know them a-priori?

That added my E-Series to the web proxy service so I could make API calls.

Definitely a target label rather than an instrumentation then, however it also sounds like it's equivalent to the instance label in identity terms so should be an info metric at most. However that's not what I'm seeing in the code, it never makes post requests.
If you want this on all metrics, the only way to do that correctly is in Prometheus as otherwise you'll miss it on up. Thus this is a matter for service discovery and relabelling, not something an exporter should be deciding for users.

The APIs you're hitting don't have "e series" in their paths, so I suspect this may be more broadly applicable.

I am almost certain the API and the structure of the JSON returned is specific to E-Series. The proxy itself might be able to return other device data and the URL paths exposed by the proxy don't include model specific strings but the JSON structure in documentation is specific to E-Series, eg: https://library.netapp.com/ecmdocs/ECMLP2860209/html/index.html, at the top:
Documentation for the RESTful API provided for management and monitoring of E-Series storage-systems.

That indicates a fragile alert that needs fixing, not a reason to go against best practices and make an exporter much harder to use correctly generally. See https://www.robustperception.io/alerting-on-gauges-in-prometheus-2-0

I wish I had come across that when I initially ran into the issues with gauge values doing false resolves. I think the use of avg_over_time should solve my problems and allow me to remove all caching, which I'm working on.

That's generally not very interesting, as an exporter being down is very rare - particularly if you've a supervisor. It's generally best to keep it simple. If scrapes are regularly failing, you have bigger problems.

The main reason I like error and timeout metrics is it allows Prometheus to tell me if something is failing to collect data without me having to use a separate system like Splunk to scrape the logs.  We have had times in the past with this exporter where the exporter was still running but the network connection to E-Series was lost so we got alerts about errors collecting data and timeouts vs just the exporter being down. Had only the exporter down alerts fired we would have begun troubleshooting the wrong thing.

That would be an acceptable tradeoff if you were treating all the API attributes in bulk, however given that each metric already has a few lines of code dedicated to it including specifying the exact metrics name you may aswell get this right while you're at it.

I will work to get the units of the various metrics standardized.

Info metrics shouldn't change their labels over time, as you want to avoid series appearing and disappearing. How many potential status values are there, and do you know them a-priori?

I believe the statuses are known ahead of time, as the API documentation for a Drive for example documents all the possible statuses.  https://library.netapp.com/ecmdocs/ECMLP2860209/html/index.html#_drive
Given the statuses are known, what's the right pattern to take?   Have like eseries_drive_status_info{status="<status string>"} for each possible status and just set the value of 1 for the status that is currently reported by the API and 0 for all others?  I believe I've seen that pattern with SNMP exporter.

If you want this on all metrics, the only way to do that correctly is in Prometheus as otherwise you'll miss it on up. Thus this is a matter for service discovery and relabelling, not something an exporter should be deciding for users.

I'll move the ID label to Prometheus configs relabeling and just document in README how to add to Prometheus configs.

Had only the exporter down alerts fired we would have begun troubleshooting the wrong thing.

It's pretty obvious which is the case from the Prometheus target page, but in general alerts should be symptom based rather than than telling you exact causes as that's ultimately more maintainable and covers more failure modes. It should also be apparent what the issue is when you manually visit the /metrics. As I said, it's very rare that it's the exporter itself will be broken - so only a quick check that it isn't is required before continuing on with debugging the target.

for each possible status and just set the value of 1 for the status that is currently reported by the API and 0 for all others?

There's 10 states, so that should be okay. I saw the pattern used correctly in one of your exporters.

@brian-brazil  I think I've made all the necessary changes.  I removed all caching, removed ID related labels, and standardized units for all metrics.  Some of the things like bytes_per_second is necessary because the raw value is actually MB/s per docs so just converted to bytes.  Some metrics that are percents had to stay percents because that's what the API provides and those metrics are useful in their current form, like percent of IO that is random as reported by E-Series.  I did remove the _ops metrics because I think their rate was based on a configuration value on the proxy for some intervals and no way to query that value plus they were redundant to _iops metrics.  Also made all status metrics always show all possible statuses (plus unknown) and set the one reported to value of 1 and all others to 0.

Some metrics that are percents had to stay percents because that's what the API provides and those metrics are useful in their current form, like percent of IO that is random as reported by E-Series

The point is more that percentages are not base units, ratios are, so they should be adjusted accordingly. I note that there seem to be both  writeBytesTotal and fullStripeWritesBytes counters in the docs, so those should be exposed instead of FullStripeWritesBytesPercent as raw data is preferable. Nor is a ratio of counters since the machine started particularly useful.

The point is more that percentages are not base units, ratios are, so they should be adjusted accordingly. I note that there seem to be both writeBytesTotal and fullStripeWritesBytes counters in the docs, so those should be exposed instead of FullStripeWritesBytesPercent as raw data is preferable. Nor is a ratio of counters since the machine started particularly useful.

It looks like I need to refactor where I pull metrics from, which I'm working on right now.  The API endpoints I'm currently using are analyzed metrics rather than raw counters.  So right now I will hit .../analysed-drive-statistics but there is also a .../drive-statistics API endpoint that exposes the raw counters.  There are a few analyzed metrics I can't see how to derive from raw counters so I will keep those but none of those are percents, the percents can all be replaced by raw counters.

Yeah, many of them seemed to be lacking raw unfortunately but best to use raw where you can.

I think I've made the necessary adjustments. One of the really useful looking API endpoints of /live-statistics does not exist with the 2 newest versions of the SANtricity web proxy API so some of the raw counters for entire systems were only accessible with queries to something like /historical-statistics/raw?type=storageSystem&start=$(date +%s)&length=60000 and I didn't want to do something that complicated or something that looked to be pulling historical numbers.  I instead added controller counters.  On my systems each system is made of 2 controllers so in theory the sum of controller metrics will give you system metrics.  The current metrics that are gauges are the only metrics I could not find raw counters for, everything else was moved to a counter.  I did remove all percentages as could replace them all with raw counters.

I just see some small things that could be improved. In system-statistics cpu_max_utilization would be a better name, as it's going from least to most specific and also matches cpu_avg_utilization. The unit of ratio should also be mentioned (and divide if they're being reported as percentages).
Similarly over in controller-statistics, and there's also an inconsistency between avg and average. max_possible_throughput is lacking a unit. Units go at the end, so raidX_transferred_bytes_total.

I've made the requested adjustments.  The documentation indirectly makes me believe CPU utilizations are reported as percents between 1-100 so just divided those values by 100 and mentioned ratios are 0.0-1.0 in HELP.

Giving it a quick once over:
For the various time counters in drive-statistics, the unit should be in the name. From the docs it looks to be microseconds, so will need conversion.
The utilization metrics in system and controller-statistics should have a _ratio unit.

I made the necessary adjustments.  I am not 100% sure the time metric counters are microseconds, the docs that describe some of them as microseconds are for InterfaceStatistics and not DiskIOStats type but it seems reasonable that if one set of raw counters uses microseconds, the others would too.  Once I deploy this this code I should be able to compare Prometheus rates of those counters with the analyzed stats from API to see if things line up.

You forgot to add seconds for the 4 _time_total metrics in drive-statistics.

I fixed those time metrics to include the seconds unit in name.

Thanks!


CSS

CSS
User Story
As a boot camp student
I want the prepwork notes to be structured on the webpage
So I can easily find and read the information
Acceptance Criteria
GIVEN a Prepwork Study Guide website
WHEN I view the study guide
THEN I see the dark blue header and footer, and four boxes with a shadow

CSS has been added


Create package.json

@pgoldrbx we will need to publish this to cn private registry
verify is this configuration is correct

otherwise, good to merge!


replace singleMachine worker with semaphore thread management

The current way of artificially shrinking the worker pool is expensive (more so when multiprocessing is used) and it defeats the purpose of having a pool of long running worker threads. We can achieve the same goal—that of preventing workers from using a core if another worker is running a task requiring more than one core—at a much reduced cost by blocking worker threads on a semaphore. By adding a slight tweak—using an overflow counter—we can also eliminate a flaw of the current implementation. The flaw prevents a task with cpu=3 from utilizing two cores, if only two are currently available, thereby wasting two cores until all three cores are available.
However, we didn't think about the memory and disk space constraints. While CPU is a soft constraint, memory and disk space aren't. We therefore don't need the overflow logic that we use for CPU. OTOH, we can't use semaphore since we would have to acquire() and release() individual units of memory one by one. Luckily, we can use Condition objects (https://docs.python.org/2/library/threading.html#condition-objects) to model memory and disk space. Conditions are more general than semaphores (semaphores can be implemented using conditions) by allowing for arbitrary conditions on arbitrary state. A semaphore is limited to a counter variable N as state and N > 0 as the condition.

Tentatively implemented -- all methods from singleMachine now pass abstractBatchSystemTest.  Will schedule code review with Hannes prior to committing.


Support default values for optional fields

Hi again :D,
I am opening this issue to request support for default values for optional fields. My use case involves defining fields as optional (Option<T>) while also assigning a default value. This is useful for scenarios where some fields can be left undefined but still have sensible defaults.
Example Use Case:
#[derive(Builder)]
struct Text {
    name: String,
    #[builder(default = Some(capitalize(&name)))]
    label: Option<String>,
}

Currently, handling such case would requires additional boilerplate code or might be not possible? (I gave it quick try and failed). It would be great if Bon natively supported this functionality.
I also have some challenges when I use field with default value like this:
#[derive(Builder)]
struct Text {
    #[builder(field = Some(capitalize(&name)))] // here I cannot use name value to construct the default value
    label: Option<String>,

    name: String,
}

A note for the community from the maintainers
Please vote on this issue by adding a 👍 reaction to help the maintainers with prioritizing it. You may add a comment describing your real use case related to this issue for us to better understand the problem domain.

Hi, could you show an example of the builder API that you'd like to achieve?
I believe you could just do this:
#[derive(Builder)]
struct Text {
    name: String,
    #[builder(default = capitalize(&name))]
    label: String,
}

You need to define label as a regular String, and use #[builder(default = ...)] to make the field optional in the builder API. Is there any reason to keep the field as Option<String> in your case>

Is there any reason to keep the field as Option in your case?

Thank you for your question!
The reason for keeping the field as Option<String> is to support flexibility in our SSR UI components crate, which is used by my team. Some components, such as Text, have an optional label.
By default, the label is initialized as Some(capitalize(&name)), as the label often mirrors the name field but is capitalized. This default behavior ensures most use cases are streamlined without requiring extra input from the user.
However, we also allow users to opt out of using a label entirely. They can call a method like maybe_label(None) (or in my implementation, no_label() for convenience) to explicitly indicate that no label is needed. Here's an example of how this works:
Text::builder()
    .name("email")
    .no_label() // Or .maybe_label(None)
    .build()

This design provides flexibility while keeping sensible defaults for common use cases.

Note that maybe_label(None) will explicitly use the default value (specified via #[builder(default = ...)]), which is by design. maybe_label(None) is always equivalent to just not calling any setters label/maybe_label at all, which allows you to dynamically decide whether you want to use the default or not by passing an Option<_> value at runtime.
Thus, maybe_label won't set the label to None in the resulting Text, it will set it to Some(capitilize(&name)) instead.
If you want to achieve the threestatae behavior of explicit Some, explicit None, explicit/implicit default Some(capitilize(&name)), you need to expose the nested Option<Option<_>> in the setters.
To do that we you can use #[builder(required)] to disable the special handling for Option<_> type, and the #[builder(default)] attribute to assign a custom default for it.
#[derive(bon::Builder)]
struct Text {
    name: String,

    #[builder(required, default = Some(capitalize(&name)))]
    label: Option<String>,
    // In this case the following setters are generated:
    //
    // label(Option<String>) - never uses the default value. `None` means real `None` in the `label`
    // maybe_label(Option<Option<String>>) - here  `None` means the default value
    //                                       while Some(None) means the real `None` in the `label`
}

fn main() {
    // Here label is `Some("Hello")`
    let _ = Text::builder()
        .name("hello".to_string())
        .build();

    // Here label is `Some("world")`
    let _ = Text::builder()
        .name("hello".to_string())
        .label(Some("world".to_string()))
        .build();

    // Here label is `None`
    let _ = Text::builder()
        .name("Hello".to_string())
        .label(None)
        .build();

    // Here label is `Some("Hello")`
    let _ = Text::builder()
        .name("Hello".to_string())
        .maybe_label(None)
        .build();

    // Here label is `None`
    let _ = Text::builder()
        .name("Hello".to_string())
        .maybe_label(Some(None))
        .build();
}

fn capitalize(s: &str) -> String {
    "TODO: impl".to_owned()
}

What I am looking for is the following API:

fn label(String); overwrite the default value.
fn maybe_label(Option<String>);  overwrite the default value as well.

If none of these methods get called, it mean we want to use the default value.
If I want the default value I would not call label/maybe_label, if I want to set a label I would call label("Hello"), if I don't want label at all I would call maybe_label(None).

Is that possible ?

Yeah, it's possible to achieve with the custom setters. This has to use custom setters because otherwise the semantics of maybe_{member}(None) is already taken to mean the default value. However, you can write your custom setters
#[derive(bon::Builder)]
pub struct Text {
    name: String,

    #[builder(
        required,
        default = Some(capitalize(&name)),
        // Make the setters private under a different name. We'll define our own
        setters(vis = "", name = label_internal),
    )]
    label: Option<String>,
}

use text_builder::{IsUnset, SetLabel, State};

impl<S: State> TextBuilder<S> {
    pub fn label(self, label: String) -> TextBuilder<SetLabel<S>>
    where
        S::Label: IsUnset,
    {
        self.maybe_label(Some(label))
    }

    // `None` means the resulting label will be `None`. The default value can be used only if you don't call any setters
    pub fn maybe_label(self, label: Option<String>) -> TextBuilder<SetLabel<S>>
    where
        S::Label: IsUnset,
    {
        self.label_internal(label)
    }
}

Thanks, I'll give this try! for me this is more than enough since this case doesn't come very often in my codebase.

I'm confident the solution above should fit your use case. If not, feel free to reopen, create a new issue or message me on https://bon-rs.com/discord


Expose createMappedSelectorCreator to api

I want to be able to specify a custom equality function to avoid rerunning my subselectors when the value doesn't change as it will create a lot of work for react to recompute the state tree. To do this I would like to be able to do the following
import Immutable from 'immutable';
import { createMappedSelectorCreator, mapMemoize } from 'reselect-map';

const createImmutableMapSelector = createMappedSelectorCreator(
  mapMemoize,
  Immutable.is
);

I merged this with some changes here. Exposing createMappedSelectorCreator directly would have been difficult to type correctly, so I created a selector creator for each memoization function. Hope this works for you!

That works for my use case thanks!


substraTEE-node demo in SGX

Do you want to keep this issue open? I propose to set it to 'wontfix' for now and re-open at a later stage (if needed)

This issue is closed in favour of the proposed architecture containing the substraTEE-worker (see https://github.com/scs/substraTEE for the high-level architecture)


Non-native DateTimePicker reinitializes without time

Package
filament/filament
Package Version
v3.0.2
Laravel Version
v10.17
Livewire Version
v3-beta
PHP Version
8.2
Problem description
Screencast from 08-02-2023 10:18:03 AM.webm
As we can see from the video, the DateTimePicker display different date-time in even click.. means, at first it display correct but second time wrong data.. third time correct and wrong data in fourth and so on..
If ->native(false) is not used then it's correct
Expected behavior
Show the correct date-time when using ->native(false)
Steps to reproduce
Clone
Install
migrate --seed
Check user resource
Reproduction repository
https://github.com/valpuia/v3-datetimepicker-bug
Relevant log output
No response

Cannot reproduce using the repo
https://github.com/filamentphp/filament/assets/41773797/431de7c0-5bec-4069-92f9-4004d1b03610


CPU Inferences Possible?

Is it possible to use CPU (without GPU) for performing inferences on images using the pre-trained model? Such as for SRGAN?

Also, does mmsr work with the SRGAN model that is tagged with Tensorflow not pyTorch?

Thank you!

For the first question, the answer is yes. I've tried and verified it on ESRGAN. There are 3 things you need to do.

In your inference option file (e.g. test_ESRGAN.yml), remove the line containing "gpu_ids: [0]"
In codes/options/options.py, remove the following lines in function "def parse(opt_path, is_train_True)"
 gpu_list = ','.join(str(x) for x in opt['gpu_ids'])
 os.environ['CUDA_VISIBLE_DEVICES'] = gpu_list
 print('export CUDA_VISIBLE_DEVICES=' + gpu_list)
In codes/models/SRGAN_model.py, remove the following lines inside function "def init(self, opt):"
 if opt['dist']:
   self.netG = DistributedDataParallel(self.netG, device_ids=[torch.cuda.current_device()])
 else:
     self.netG = DataParallel(self.netG)

But remember, running on CPU is very slow.

@zhangcl Hi, thanks for your reply. But how can I compile DCN without GPUs?(See "Dependencies and Installation" in the README, Deformable Convolution). Or you build this project on a machine with GPUs and migrate it to a machine without GPU?

@EnJiang  Yes, I use a computer with GPU on it.
To compile DCN, you don't need to have a GPU. All you need is the nvcc compiler, whch is included in CUDA. So installing CUDA should fix your problem.

@EnJiang  I did try it today without GPU. It failed. The error is as follows:

RuntimeError: cuda runtime error (38) : no CUDA-capable device is detected at

In that case, you will have to have a GPU in your system.

@zhangcl I agree.
This is how I did it on tencent cloud:

Start a GPU VM instance with a NVIDIA V100 GPU.
Compile DCN and make sure relative code can run on GPU.
Change the code accordingly as @zhangcl  suggested. Make sure the code runs on CPU only (nvidia-smi to make sure the process is not using GPU)
Make an Image/Snapshot of this VM.
Start a CPU machine with the mentioned Image/Snapshot.

But I do get a memory leak problem. That is, the more samples I run the more memory the model uses and finally I get a OOM error.
I wonder can you guys reproduce it?


Conformance command: Add mime_type check

Logic to check mime_types in styleguide and match with mime_type of the spec
Fixes https://github.com/apigee/registry/issues/427

This is obsolete. Created this instead: https://github.com/apigee/registry/pull/430


Add figures for subscript numbers

What are your thoughts on adding figures for subscript numbers? They display well on all environments:
Ubuntu 20.10, Gnome terminal:

Windows 10, cmd.exe (CP850):

I checked on macOS default terminal, and it looks good too :+1:

👍

Fixed by #63.


Only build one target by default

Closes https://github.com/rust-lang/docs.rs/issues/343.
:warning: :warning: DO NOT MERGE :warning: :warning:  until we've (at the minimum):

made an 'Inside Rust' blog post saying that we won't be building all targets anymore
linked to that post on every page that will be affected (or every page globally if that's easier)
left the warning up for at least a few weeks

Most of the following comments are related to https://github.com/rust-lang/docs.rs/pull/550 and can be safely ignored.

I forgot to check if this works with a default other than x64-linux, not at my computer right now but I don't think it will.

Ok yeah this is broken for a different default target because cargo puts files in target/:target/doc when you cross compile. Maybe it would be simplest to just move that whole directory to target/doc?

Pushed a fix.

So, I think having a separate PR to avoiding building the default target twice is better: we should announce breaking changes on the main blog, and doing so is a big ask from a marketing angle. In late February or March I plan to make another breaking change, so we could bundle them together.
The separate PR removing the double build for the default target would help mitigating the build cost without visibly affecting users, while we could defer deploying this until next year.

Drafted a blog post, feedback is welcome: https://github.com/rust-lang/blog.rust-lang.org/pull/603,

https://github.com/rust-lang/team/pull/1051


AerBackend().backend_info.gate_set is missing some gates

There are some gates that are (correctly) accepted by the backend's GateSetPredicate, but are missing from its backend_info. Namely: Barrier, RangePredicate, Measure, Reset, and Unitary1qBox.

Is it in general the case that the GateSetPredicate and backend_info.gate_set should contain the same gates? If so, the code, as it is, is very confusing

I can't think of a reason why it would not be the case. Some of this code dates back a long way (certainly since before there were any predicates), so feel free to make less confusing if you can!

Should the rebase_pass contain these gates as well?

Should the rebase_pass contain these gates as well?

Ideally yes, though Measure and Reset are automatically added I think.

Here (https://github.com/CQCL/pytket-qiskit/blob/develop/pytket/extensions/qiskit/backends/aer.py#L91) is a list of required gates. Is there a reason these gates are required?
I'm asking because, after some refactoring, this line of test code fails, because AerBackend(simulation_method="stabilizer") doesn't contain the "required" u1-u3 gates. This wasn't failing before because the required gate check was happening before setting the simulation_method to "stabilizer", so that the gates available from simulation_method=automatic were being used for the check, which seems like a bug to me. But now the "required" gates check fails so I'm not sure what to do...

Here (https://github.com/CQCL/pytket-qiskit/blob/develop/pytket/extensions/qiskit/backends/aer.py#L91) is a list of required gates. Is there a reason these gates are required?

I don't know why those particular gates should be required -- indeed for stabilizer backends the u1-u3 shouldn't be required. Does anything break if we remove this check?

Hmmm, other tests don't break but now in this line, instead of getting an AttributeError from within qiskit when trying to retrieve the result, we now get a CircuitNotValidError when validating the circuit:
pytket.backends.backend_exceptions.CircuitNotValidError: Circuit with index 0 in submitted does not satisfy GateSetPredicate

Which actually seems much better...


update field mapping attribute on ModelSerializer class

Looks like an API change on the ModelSerializer class in django-rest-framework, I updated the attribute name and it cleared the has no attribute error. This was using django 1.8a so I'm not sure how the Travis CL build thing will work.

which django-rest-framework version are you using in your development environment?

master.

ok I see now, this is the commit you're mentioning: https://github.com/tomchristie/django-rest-framework/commit/75e81b82545704bac8afdf3270ba9f6c8da09c27
The solution you proposed is not good enough because it breaks compatibility with the current DRF version, some try except blocks or similar solutions would be better.


Add latest npm version to 1.1.7 and remove stale 1.1.2

Latest NPM release and update version to 1.1.7

this will be released starting from next Monday. Please consider this when updating your toggle.


ddf.index.name is set to None after assign

If meta's index name is not explicitly set dask sets the index name to None. Wouldn't it be preferable to use the available index name of ddf?
In [1]: import pandas as pd
   ...: import dask.dataframe as dd
   ...: import numpy as np
   ...:

In [2]: df = pd.DataFrame({
   ...:     'a': np.arange(20)**2,
   ...:     'ts': pd.date_range('01-01-2000', periods=20).map(str)
   ...: }, index=pd.Index(np.arange(20), name='id')
   ...:     )
   ...:

In [3]: ddf = dd.from_pandas(df, npartitions=4)

In [4]: ddf.index.name
Out[4]: 'id'

In [5]: ddf2 = ddf.assign(ts_parsed=ddf.ts.map_partitions(pd.to_datetime, meta='datetime64[ns]'))

In [6]: print(ddf2.index.name)
Out[6]:  None

.....

In [8]: meta = pd.Series([], dtype='datetime64[ns]')
   ...: meta.index.name = 'id'

In [9]: ddf2 = ddf.assign(ts_parsed=ddf.ts.map_partitions(pd.to_datetime, meta=meta))

In [10]: print(ddf2.index.name)
id

Wouldn't it be preferable to use the available index name of ddf?

Yes, that'd be good to do I think. We could maybe make dask.dataframe.util.make_meta accept an index_name argument (default is None). Then anywhere we call it we would pass self.index.name, where self is the original...
@kayibal do you have any interest in working on this?

Then anywhere we call it we would pass self.index.name, where self is the original...

Hmmmm, I'm not sure that's the best idea. We generally assume if the user passes in meta that it's 100% correct. This includes index type and name. We can't automatically set the index name to the current index name, because sometimes user defined functions change the index/index name.

I should say we’d only pass through the current index name when the user defined meta doesn’t include the index (a tuple of series name, dtype or a dict of columns to dtypes)

Would you also copy the index type in that case? Something like "If a non-pandas object is passed in, the output index is assumed to have the same type and name as the original frame". If so, just passing in index=self.index to make_meta should already work.

@TomAugspurger Sure, I would gladly work on this once a consensus on the desired behaviour is reached.

I want to poke at this issue. It causes dd.to_datetime and friends to behave oddly as well, since they use (dask) supplied meta. I'd happily take a crack at a PR, which would pass along index info when a non-pandas object is passed in, as suggested by @jcrist.

Please do!

This doesn't seem to be an issue anymore:
>>> df
      a                   ts
id
0     0  2000-01-01 00:00:00
1     1  2000-01-02 00:00:00
2     4  2000-01-03 00:00:00
3     9  2000-01-04 00:00:00
4    16  2000-01-05 00:00:00
5    25  2000-01-06 00:00:00
6    36  2000-01-07 00:00:00
7    49  2000-01-08 00:00:00
8    64  2000-01-09 00:00:00
9    81  2000-01-10 00:00:00
10  100  2000-01-11 00:00:00
11  121  2000-01-12 00:00:00
12  144  2000-01-13 00:00:00
13  169  2000-01-14 00:00:00
14  196  2000-01-15 00:00:00
15  225  2000-01-16 00:00:00
16  256  2000-01-17 00:00:00
17  289  2000-01-18 00:00:00
18  324  2000-01-19 00:00:00
19  361  2000-01-20 00:00:00
>>> ddf = dd.from_pandas(df, npartitions=4)
>>> ddf.index.name
'id'
>>> ddf2 = ddf.assign(ts_parsed=ddf.ts.map_partitions(pd.to_datetime, meta='datetime64[ns]'))
>>> print(ddf2.index.name)
id
>>> meta = pd.Series([], dtype='datetime64[ns]')
>>> ddf2 = ddf.assign(ts_parsed=ddf.ts.map_partitions(pd.to_datetime, meta=meta))
>>> print(ddf2.index.name)
id
>>> ddf2 = ddf.assign(ts_parsed=ddf.a.map_partitions(lambda x: x+1))
>>> print(ddf2.index.name)
id
>>> ddf2 = ddf.assign(ts_parsed=ddf.a.map_partitions(lambda x: x+1, meta=int))
>>> print(ddf2.index.name)
id

Can we close it?

Thanks @jorloplaz!


core: initial release

Discussions and requirements regarding initial release [soon]

@maxux add technical requirements please

Please see discussion first: https://github.com/threefoldtech/capacity-certifier/discussions/2


Provide an icon support site

Hi,
I like the theme very much, and I am trying to build my own personalized blog recently. However, I encountered a problem. I added a new social networking site to introduction.html, but the corresponding icon could not be displayed in the webpage preview. I learned in a question that the theme of Avicenna is based on  feathericons, and the new icon I use is based on iconfont. I don't know how to add new icons.

In addition, I sincerely hope that the author will include iconfont in the icon system, because it supports more than 20 million icon styles and is convenient for users to customize and modify.
Thanks!


VLANs not displaying correctly in Network Report

Was working in v3, but in v4 my settings are ignored. The ip4routers.yml file was created with the upgrade script.
It looks something like this:
148:
    - 10.148.41.%
38:
    - 10.38.147.%
40:
    - 10.40.103.%
45:
    - 10.45.103.%
137:
    - 192.168.137.%

The result:

I can't replicate your issue. Is theip4routers.yml located at local/module_configs ?

Yes it is. I have some entries in it that look like this
'SW Kip 20':
10.12.5.%

Please validate your .yml file. You can use something like: https://www.json2yaml.com and see if the structure comes out ok.

It seems to OK. Maybe I will rebuild it and see what happens.


Fix ordering of keys in __dict__ with model_construct call

Change Summary
Ensure that __dict__ keys are populated in order that the fields are listed during a call to model_construct.
Related issue number
Closes #8487
Checklist

[x] The pull request title is a good summary of the changes - it will be used in the changelog
[x] Unit tests for the changes exist
[x] Tests pass on CI
[ ] Documentation reflects the changes where applicable
[x] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Please review


Error-Stack trace: ValueError

Not sure what caused the problem tbh.
https://pastebin.com/GCZ6rh9Y

try https://github.com/Nandaka/PixivUtil2/releases/tag/v20180511-beta3


Admin galaxy docker slides

I made a brief setup tutorial here, if this is still needed how should I go about integrating it?

Oh nice! You can check out the main repository and look at the slides which we have created. This could then be improved if you like.


Use Electricity:Facility instead of Electricity:Building as the output variable

According to the .mtd file, Electricity:Building only contains electricity data for the internal loads and the HVAC systems are excluded, while Electricity:Facility contains all of them.
 For Meter=Electricity:Building [J], ResourceType=Electricity, Group=Building, contents are:
  CORE_BOTTOM_LIGHTS:Lights Electric Energy
  CORE_MID_LIGHTS:Lights Electric Energy
  CORE_TOP_LIGHTS:Lights Electric Energy
  PERIMETER_BOT_ZN_1_LIGHTS:Lights Electric Energy
  PERIMETER_BOT_ZN_2_LIGHTS:Lights Electric Energy
  PERIMETER_BOT_ZN_3_LIGHTS:Lights Electric Energy
  PERIMETER_BOT_ZN_4_LIGHTS:Lights Electric Energy
  PERIMETER_MID_ZN_1_LIGHTS:Lights Electric Energy
  PERIMETER_MID_ZN_2_LIGHTS:Lights Electric Energy
  PERIMETER_MID_ZN_3_LIGHTS:Lights Electric Energy
  PERIMETER_MID_ZN_4_LIGHTS:Lights Electric Energy
  PERIMETER_TOP_ZN_1_LIGHTS:Lights Electric Energy
  PERIMETER_TOP_ZN_2_LIGHTS:Lights Electric Energy
  PERIMETER_TOP_ZN_3_LIGHTS:Lights Electric Energy
  PERIMETER_TOP_ZN_4_LIGHTS:Lights Electric Energy
  CORE_BOTTOM_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  CORE_MID_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  CORE_TOP_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_BOT_ZN_1_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_BOT_ZN_2_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_BOT_ZN_3_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_BOT_ZN_4_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_MID_ZN_1_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_MID_ZN_2_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_MID_ZN_3_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_MID_ZN_4_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_TOP_ZN_1_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_TOP_ZN_2_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_TOP_ZN_3_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_TOP_ZN_4_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  CORE_BOTTOM_ELEVATORS_EQUIP:Electric Equipment Electric Energy

 For Meter=Electricity:Facility [J], ResourceType=Electricity, contents are:
  CORE_BOTTOM_LIGHTS:Lights Electric Energy
  CORE_MID_LIGHTS:Lights Electric Energy
  CORE_TOP_LIGHTS:Lights Electric Energy
  PERIMETER_BOT_ZN_1_LIGHTS:Lights Electric Energy
  PERIMETER_BOT_ZN_2_LIGHTS:Lights Electric Energy
  PERIMETER_BOT_ZN_3_LIGHTS:Lights Electric Energy
  PERIMETER_BOT_ZN_4_LIGHTS:Lights Electric Energy
  PERIMETER_MID_ZN_1_LIGHTS:Lights Electric Energy
  PERIMETER_MID_ZN_2_LIGHTS:Lights Electric Energy
  PERIMETER_MID_ZN_3_LIGHTS:Lights Electric Energy
  PERIMETER_MID_ZN_4_LIGHTS:Lights Electric Energy
  PERIMETER_TOP_ZN_1_LIGHTS:Lights Electric Energy
  PERIMETER_TOP_ZN_2_LIGHTS:Lights Electric Energy
  PERIMETER_TOP_ZN_3_LIGHTS:Lights Electric Energy
  PERIMETER_TOP_ZN_4_LIGHTS:Lights Electric Energy
  CORE_BOTTOM_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  CORE_MID_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  CORE_TOP_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_BOT_ZN_1_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_BOT_ZN_2_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_BOT_ZN_3_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_BOT_ZN_4_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_MID_ZN_1_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_MID_ZN_2_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_MID_ZN_3_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_MID_ZN_4_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_TOP_ZN_1_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_TOP_ZN_2_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_TOP_ZN_3_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  PERIMETER_TOP_ZN_4_PLUGMISC_EQUIP:Electric Equipment Electric Energy
  CORE_BOTTOM_ELEVATORS_EQUIP:Electric Equipment Electric Energy
  CORE_BOTTOM VAV BOX REHEAT COIL:Heating Coil Electric Energy
  CORE_MID VAV BOX REHEAT COIL:Heating Coil Electric Energy
  CORE_TOP VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_BOT_ZN_1 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_BOT_ZN_2 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_BOT_ZN_3 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_BOT_ZN_4 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_MID_ZN_1 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_MID_ZN_2 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_MID_ZN_3 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_MID_ZN_4 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_TOP_ZN_1 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_TOP_ZN_2 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_TOP_ZN_3 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  PERIMETER_TOP_ZN_4 VAV BOX REHEAT COIL:Heating Coil Electric Energy
  VAV_1_HEATC:Heating Coil Electric Energy
  VAV_2_HEATC:Heating Coil Electric Energy
  VAV_3_HEATC:Heating Coil Electric Energy
  VAV_1_FAN:Fan Electric Energy
  VAV_2_FAN:Fan Electric Energy
  VAV_3_FAN:Fan Electric Energy
  EXTERIOR FACADE LIGHTING:Exterior Lights Electric Energy
  VAV_1_COOLC DXCOIL:Cooling Coil Electric Energy
  VAV_2_COOLC DXCOIL:Cooling Coil Electric Energy
  VAV_3_COOLC DXCOIL:Cooling Coil Electric Energy
  SWHSYS1 PUMP:Pump Electric Energy

Close via fb3224f250916fea9f88bbd5148250bd2478ceca


Pytorch with cuda on windows

It seems the torch on the Windows system is installed only with the CPU.

Seems to be a problem of uv with Pytorch. See https://github.com/astral-sh/uv/pull/6523 for details.

The PyTorch's configuration in uv has been updated since version 5.3. Check https://github.com/astral-sh/uv/releases/tag/0.5.3 for details.


Refactoring fails with message "Refactoring failed: null"

Step :
In an empty directory initialize a project with the current language
method :
@Step({"In an empty directory initialize a project with the current language"})
public void initializeProject() throws Exception {
}

Gauge-java is not handling the case where array with 1 step text ({"In an empty directory initialize a project with the current language"})  is passed to @Step annotation.

Refactoring a step with alias is not supported but if there is only one value in alias then refactoring should be successful.
@sguptatw Please verify.

This is still replicable
Gauge-IntelliJ Version: 0.3.7.nightly-2017-08-11
Gauge version
Gauge version: 0.9.2.nightly-2017-08-15

Plugins
-------
csharp (0.10.1)
html-report (4.0.2.nightly-2017-08-07)
java (0.6.5.nightly-2017-08-14)
ruby (0.4.1)
spectacle (0.1.2)
xml-report (0.2.0)

@sguptatw This works fine with the latest stable versions.
with the nightly version mentioned above this gives an other error
Error:Cannot perform refactoring: Unable to connect to runner.Runner with pid 50753 quit unexpectedly(exit status 1).

which is being tracked by https://github.com/getgauge/gauge-java/issues/62
Where as it works fine from command line. So issue should be from intelliJ side.
Gauge-IntelliJ Version: 0.3.7.nightly-2017-08-11
Gauge version
Gauge version: 0.9.2.nightly-2017-08-15
Plugins
html-report (4.0.2)
java (0.6.5.nightly-2017-08-14)
spectacle (0.1.2)

@sguptatw Please try with latest Gauge-IntelliJ nightly  :  0.3.7.nightly-2017-08-18


[Spartan] -> [Angular UI Libraries]

Spartan
Cutting-edge tools powering Angular full-stack development.
Link: https://www.spartan.ng/
Checklist:

[X] I have performed a self-review of submitted resource and its follows the guidelines of the project.

@StefanSelfTaught the author said this in here

spartan/ui is our effort to port the incredible shadcn/ui project over to the Angular ecosystem.
The idea is to create un-styled primitives similar to Radix with the help of the Angular CDK and other proven community solutions And then add the beautiful shadcn styles with primitives (and components where necessary).

So yes, it looks like shadcn/ui 😄


Request to add link to New Relic site for how to log into NR

This is from New Relic docs team. We were hoping you might add a link at the bottom of this doc (or somewhere else you think appropriate) on how to log in to New Relic once they've created the New Relic resource in Azure. This is unfortunately a bit complex. We have the instructions for this here: https://docs.newrelic.com/docs/infrastructure/microsoft-azure-integrations/get-started/azure-native/#view-your-data-in-new-relic

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 3aa5047a-c217-dcff-dd38-4c28c36de90b
Version Independent ID: 9aefe4d4-8a0a-ffaa-0cb7-84fae09031ee
Content: Create an instance of Azure Native New Relic Service Preview - Azure Native ISV Services
Content Source: articles/partner-solutions/new-relic/new-relic-create.md
Service: partner-services
GitHub Login: @flang-msft
Microsoft Alias: franlanglois

@zuluecho9
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

@vikassinghvi2007 - Please have a look at this issue.

#assign: @vikassinghvi2007

Thanks for providing feedback that helps improve our documentation. We have incorporated your feedback. You should see the updated in the next couple days. We are closing this issue, but if you feel that it's still a concern, please reopen the issue.
#please-close


Welcome to laravel-scout

Greetings! For a long time watching your project, now there is an official project at the Scout laravel. It is very similar to yours. Even there is a feeling that an idea borrowed from you :)
I would like to invite you to our disskussii for the development of Scout and possible further merger. Your project is much more mature and well developed.
What can be said about Scout. We are looking forward to your participation and experience!
https://github.com/laravel/scout/pull/7

@intech thanks for the letting me know about this.


Column ordering feature in the Data view is a bit buggy

[ ] The arrow indicating which column is ordering the table only appears on the cartodb_id column
[ ] The arrow always points upwards, even when ordering downwards
[ ]  It briefly appears in a different column when you order the table by it, but it immediately disappears and goes back to the cartodb_id one
[ ] The "ordering arrow" doesn't show as disabled in any other column but the cartodb_id one

Stale issue. Closing 👋


Hook up text collection extension to get data from actual projects/resources, instead of getting mock data from the USFM provider

Depends on https://github.com/paranext/paranext-core/issues/237

Will be worked in #477


homepage-dashboard: 0.8.9 -> 0.8.10

Description of changes
https://github.com/gethomepage/homepage/releases/tag/v0.8.10
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I don't understand why we have plenty of
error: a 'x86_64-linux' with features {} is required to build '/nix/store/wkxhkd04kmacylhvp81hwh2fdysmr5sp-append-initrd-secrets.drv', but I am a 'x86_64-darwin' with features {benchmark, big-parallel, nixos-test}

for the tests on Darwin...


Translate title into Portuguese and fix some grammar agreements

Translate "state" and "props" into portuguese
Fix grammar: subject-verb agreement

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 🎉


Making another release

Would you mind labelling another release on the master branch ? Go's dep picks a release candidate by default

I just created a new rc. Thanks for pointing this.


Fix hiding completion on backspace when nothing before cursor.

Dear spyder devs,
Using the fix brought by #12710, I realized it was not working as expected when not at the beginning of a line (or when end of previous line is a word).
Here is a proposition to fix those issues with #12637.
Main idea is to also check for previous character, since "previous word" from qt behaves strangely.
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct:
@ElieGouzien

Hello @ElieGouzien! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file spyder/plugins/editor/widgets/tests/test_completions_hide.py:

Line 71:1: W293 blank line contains whitespace


Return incorrect ordinals numbers to fr_CA

Is it possible to include fr_CA to numbers in the following format: 12e ??

Numbers of what? Because if you mean the day number, then in French (including fr_CA) day number should only have ordinal for the 1 => 1er. All other days does not have ordinal.
The reason is simple : you don't say "Mardi second Mars", you say: "Mardi deux Mars", no ordinal form.
So it should not be implemented in the regular translation. It would be grammatically wrong.
If you're still really sure you want to override this for you app, you can use:
\Carbon\Translator::get('fr_CA')->setTranslations([
    'ordinal' => function ($number) {
        return $number.($number === 1 ? 'er' : 'e');
    },
]);


tiva_c docs should ignore only actual pin instantiations

Fix #373

Coverage remained the same at 85.657% when pulling 0bdefeb361c2aa47885bbe393fac7b4135c414f3 on mcoffin:missing-tiva-docs#373 into e68f861d0471272698e3fdd78b743b8a4d352b18 on hackndev:master.

Coverage remained the same at 85.657% when pulling 0bdefeb361c2aa47885bbe393fac7b4135c414f3 on mcoffin:missing-tiva-docs#373 into e68f861d0471272698e3fdd78b743b8a4d352b18 on hackndev:master.

Ironically, this is PR 404 so make of that what you will...
A quick skim over the commits and this looks much better than my kludgy solution in #404. Are there plans to add docs to some/all of the parts touched in this PR? Most of the parts are pretty self explanatory so actual docs might not be necessary. What about examples and "this thing exists" sections in the docs?

Are there plans to add docs to some/all of the parts touched in this PR?

The better idea is to migrate code to new ioregs and define docs there. Although there's no support for repeated registers yet.


changes

Thanks for opening a pull request. These look like changes that are best left on your personal fork.

My bad


Twenty Sixteen - Core theme - embedding stories related issue list

Bug 1

With 2016 theme enabled, if Show Title option is enabled then the title's are not visible, as the 2016 theme background color is dark, because of which the title's are not shown.

https://user-images.githubusercontent.com/41000648/108035799-63965c80-705d-11eb-8f8b-af368cf932ea.mp4

Titles are now visible.


Aa/data gas prices in block context3

This change is

crates/blockifier/src/fee/fee_utils.rs line 67 at r2 (raw file):
Previously, ArniStarkware (Arnon Hod) wrote…
Document this function.
Have the return value as a tuple.

About the return type. You can wait with that - until I finish the review of the other tests.

crates/blockifier/src/fee/fee_utils.rs line 26 at r2 (raw file):
Previously, aner-starkware wrote…
Is this still relevant?

Yes.
The TODO is about replacing the unwarp_or with an expect (By making sure the value always appears).


Paraquire - paranoidal require

I'm at hard work on paraquire - security-oriented require alternative and I invite you to join.
This PR adds security jails to most libraries used in gulp; unfortunately, I haven't managed to give correct permissions to vinyl-fs, so it remains usually required.
Should I prepare same PR to 4.0 branch?

Cool project, not going to use it in gulp though. No tangible gains as far as I'm concerned, but I could see this being useful in other projects.

Thanks for quick reply!
Could you advice another projects which I should go to?


Update dependencies

Looks like Log4j has slipped out another release, and JUnit needs an update as well.

Done.


feat: intergrate verification code countdown as a component

Deployed at: https://door.chromium.link

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


feat: Support viewfs file system in velox

Support Viewfs file system in velox.

@JkSelf can we add some read/write tests? If not, can we add some unit tests for the "viewfs" scheme?

@majetideepak Thanks for your review. I have fixed the failed unit tests and added the viewfs scheme test. Can you help to review again? Thanks.

Hi @JkSelf , Can you confirm/investigate that the fuzzer failure isnt due to your changes ?

Hi @JkSelf , Can you confirm/investigate that the fuzzer failure isnt due to your changes ?

@kgpai The failure is not due to this pr. I have rebased and the tests passed.

@kgpai Can you help to merge this PR? Thanks.


Clojure sources not available from java-library projects

Expected Behavior
I have a multi-project build where one project, sub-b, depends on another, sub-a.  If I configure sub-a to load the java-library plug-in, I expect the Clojure sources from sub-a to be available from sub-b.
Current Behavior
It appears that when sub-a is a java-library, the class path that sub-b uses includes:

multi-clojurephant/sub-a/build/classes/java/main
multi-clojurephant/sub-a/build/clojure/main

Presumably, since there is no AOT compilation by default, nothing gets put into the clojure build directory.  As a result, the sub-a Clojure sources are not found.
In contrast, if the id 'java-lbrary' is removed from sub-a, sub-b uses a compiled JAR that includes the sources.
Context
While there are workarounds, our attempt to use Clojurephant is being impacted by this and #128 .
If you can give me some pointers on where to look, I could attempt to fix it and submit a PR.
Steps to reproduce
I have created a minimal example at: https://github.com/sattvik/multi-clojurephant
Environment

clojurephant version: 0.5.0
Gradle version: 6.2.1
Java version: 11.0.6
OS version: Linux 4.19.97 amd64

I think I finally have a fix for this, by registering the source dir as a classes dir if you're not doing AOT. This will be in 0.6.0.


event_revoker ignores errors while manual unregistration does not

As can be seen here, the hresult return is ignored:
https://github.com/microsoft/cppwinrt/blob/7e730e7652a42754bd0384feb7c84d5484daff2e/strings/base_events.h#L57-L63
However, in the code generated for manual unregistration, the return value is asserted to be S_OK:
https://github.com/microsoft/cppwinrt/blob/4366357db991bda7bb615dedabdb3637cc93e9e5/cppwinrt/code_writers.h#L1121-L1128
This means that the behavior is different: I was migrating code to use manual unregistration because it was already holding a strong reference so storing a single event_token takes much less storage. While event_revoker worked fine, manual unregistration triggers the assert if the RPC server has died while trying to unregister the callback (because then the method to unregister the callback returns RPC_S_SERVER_UNAVAILABLE).

Yep, the event revoker came much later and by then I realized there was little point in propagating errors resulting from unregistering an event. Ideally we could make the manual unregistration behave the same way. I can't imagine anyone depending on this, but you never know.

People have probably inadvertently started depending on event_revoker ignoring errors (as I did, until I tried manual unregistration), and currently manual unregistration errors are a fatal failure in debug mode and ignored in release mode.
So I don't think anybody depends on asserts firing (because they terminate, and sudden termination is something nobody really depends on), and the "correct" behavior already exists in release mode. Ignoring errors in manual unregistration will bring consistency and should not result in any breakages.

Agreed.


Fix crash when dragging scene files to 2D/3D screen

The crash usually occurs when there is no scene root node.
Fix #89867.

Thanks!


Shadows: Review all components and ensure shadows are applied consistently

What is the purpose of the enhancement?
Some older components are not using shadows consistently with others.
Why do we need it?
For consistency across all comps

@DBD324 please check this across the site.


Creating a Mock calls original constructor

When I create a mock:
mockChatService = TypeMoq.Mock.ofType(ChatService);
Original constructor of ChatService is called, so any code in constructor for example:
constructor (private dataService:DataService) {   this.dataService.addListener('sampleEvent', sampleHandler); }
causes null pointer exception on this.dataService.

Please have a look at #16


⚠ AGEG website (prod) has degraded performance

In 60bb426, AGEG website (prod) (https://www.ageg.ca/) experienced degraded performance:

HTTP code: 200
Response time: 10528 ms

Resolved: AGEG website (prod) performance has improved in aa0be09.


does tiedot has max storage limit?

It works well when I check it yesterday, it has stores 51GB data.
today it grows up to 61GB, it return nothing by http api, also by golang script.
when I use Scrub to fix ,  panic as below
panic: runtime error: makeslice: len out of range
goroutine 1 [running]:
github.com/HouzuoGuo/tiedot/data.(*Collection).Read(0xc00005e400, 0x17c0abd, 0x0, 0x0, 0x0)
/root/go/src/github.com/HouzuoGuo/tiedot/data/collection.go:47 +0x11f
github.com/HouzuoGuo/tiedot/data.(*Partition).ForEachDoc(0xc000060600, 0x0, 0x14a, 0xc00009de00, 0x1)
/root/go/src/github.com/HouzuoGuo/tiedot/data/partition.go:133 +0xf1
github.com/HouzuoGuo/tiedot/db.(*Col).forEachDoc(0xc0000843c0, 0xc00009de00, 0x510d00)
/root/go/src/github.com/HouzuoGuo/tiedot/db/col.go:116 +0x137
github.com/HouzuoGuo/tiedot/db.(*DB).Scrub(0xc0000602d0, 0x510dff, 0xd, 0x0, 0x0)
/root/go/src/github.com/HouzuoGuo/tiedot/db/db.go:212 +0x581
main.main()
/root/go/src/examples/main/dbtest.go:34 +0x14e

You're right, I overlooked the maximum size limit and really should have put it in a wiki page somewhere - sorry about that. I wish I had a workaround for this, but cannot think of any right now.


Is there a built-in way to raise an exception if no expectation is called?

I searched through the documentation and didn't find anything.
Is there a configuration setting (or other way) to have RSpec raise an exception if no expectations are called in a test? This would help detect tests that accidentally do nothing.

It's on the road map -- see #759.  http://blog.sorah.jp/2012/12/17/rspec-warn-for-no-expectations shows one way to accomplish this kind of thing for now since we don't yet directly support it.  Maybe it'll be in 3.4 :).

Thanks for the info. The solution in that post is old and relies on private methods that are no longer available, so I'll just wait until its supported directly.


InvalidOperationException with empty stack on Literal[True] annotation

        [TestMethod, Priority(0)]
        public async Task LiteralParameter() {
            const string code = @"
from typing import Literal

def f(handle: int, overlapped: Literal[True]):
    pass
";
            var analysis = await GetAnalysisAsync(code);
            analysis.Should().HaveFunction("f")
                    .Which.Should().HaveSingleOverload()
                    .Which.Should().HaveParameters("handle", "overlapped");
        }

Crashes.
This is a simplified version of the changes added to _winapi's stub in the latest typeshed:
def ConnectNamedPipe(handle: int, overlapped: Literal[True]) -> Overlapped: ...

https://www.python.org/dev/peps/pep-0586/
Oh boy.