[SPARK-23990][ML] Instruments logging improvements - ML regression package

What changes were proposed in this pull request?
Instruments logging improvements - ML regression package
To be discussed:
I add an OptionalLogging trait, used in WeightedLeastSquares and IterativelyReweightedLeastSquares, so that logInfo/logDebug/logWarning can prior to use instrument to log. if no instrument set, then use default logging.
I add an OptionalInstrument class which used in WeightLeastSquares and IterativelyReweightedLeastSquares.
How was this patch tested?
N/A

@MrBago @jkbradley Thanks!

Test build #89390 has started for PR 21078 at commit 78c4cd9.

Test build #89391 has started for PR 21078 at commit 2239856.

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/2340/
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/2341/
Test PASSed.

Merged build finished. Test PASSed.

Test build #89390 has finished for PR 21078 at commit 78c4cd9.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test build #89391 has finished for PR 21078 at commit 2239856.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

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

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/89391/
Test FAILed.

Test build #89423 has started for PR 21078 at commit 7d286c4.

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/2365/
Test PASSed.

Test build #89423 has finished for PR 21078 at commit 7d286c4.

This patch fails to build.
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/89423/
Test FAILed.

Test build #89427 has started for PR 21078 at commit 2d7a8ca.

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/2369/
Test PASSed.

Test build #89427 has finished for PR 21078 at commit 2d7a8ca.

This patch fails Spark unit tests.
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/89427/
Test FAILed.

Test build #89440 has started for PR 21078 at commit 5f60387.

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/2381/
Test PASSed.

Test build #89440 has finished for PR 21078 at commit 5f60387.

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/89440/
Test PASSed.

Thanks for thinking through the optional logging issue!  I responded in the JIRA to preserve the design discussion there: https://issues.apache.org/jira/browse/SPARK-23990

Test build #89544 has started for PR 21078 at commit bbc86b8.

@jkbradley Updated.
I would like to split RandomForest and GradientBoostedTrees modification into another PR because it will change many methods in them.

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/2465/
Test PASSed.

Test build #89544 has finished for PR 21078 at commit bbc86b8.

This patch fails to build.
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/89544/
Test FAILed.

Test build #89547 has started for PR 21078 at commit cf649ce.

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/2468/
Test PASSed.

Merged build finished. Test PASSed.

Test build #89547 has finished for PR 21078 at commit cf649ce.

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/89547/
Test PASSed.

Test build #89622 has started for PR 21078 at commit 1ab9ce0.

Test build #89622 has finished for PR 21078 at commit 1ab9ce0.

This patch fails Scala style tests.
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/89622/
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/2521/
Test PASSed.

Test build #89623 has started for PR 21078 at commit ece1a3a.

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/testing-k8s-prb-make-spark-distribution/2522/
Test FAILed.

Test build #89623 has finished for PR 21078 at commit ece1a3a.

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

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

Merged build finished. Test PASSed.

Test build #89752 has started for PR 21078 at commit 5ee7e23.

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/2605/
Test PASSed.

Test build #89752 has finished for PR 21078 at commit 5ee7e23.

This patch fails to build.
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/89752/
Test FAILed.

Test build #89754 has started for PR 21078 at commit 492dc46.

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/2606/
Test PASSed.

Test build #89754 has finished for PR 21078 at commit 492dc46.

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/89754/
Test PASSed.

LGTM
Merging with master
Thanks @WeichenXu123 !


Issue about k3s check-config

Environmental Info:
K3s Version: v1.18.6+k3s1 (6f56fa1d)
Node(s) CPU architecture, OS, and Version:  Using Fedora CoreOS
Linux stl02 5.6.19-300.fc32.x86_64 #1 SMP Wed Jun 17 16:10:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Describe the bug:
After a fresh install of FCOS, I tried to run k3s check-config and got this:
[core@stl02 ~]$ sudo k3s check-config /lib/modules/5.6.19-300.fc32.x86_64/config

Verifying binaries in /var/lib/rancher/k3s/data/6ab65ee0083924a980f6161177c37163fa68681b710316bb3dc59f118ff27636/bin:
- sha256sum: good
- links: good

System:
- /usr/sbin iptables v1.8.4 (legacy): ok
- swap: disabled
- routes: ok

Limits:
- /proc/sys/kernel/keys/root_maxkeys: 1000000

modprobe: module configs not found in modules.dep
info: reading kernel config from /lib/modules/5.6.19-300.fc32.x86_64/config ...

Generally Necessary:
- cgroup hierarchy: properly mounted [/sys/fs/cgroup]
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: enabled
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MEMCG: enabled
- CONFIG_KEYS: enabled
- CONFIG_VETH: enabled (as module)
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: enabled (as module)
- CONFIG_NF_NAT_IPV4: missing (fail)
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_IPVS: enabled (as module)
- CONFIG_IP_NF_NAT: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_NF_NAT_NEEDED: missing (fail)
- CONFIG_POSIX_MQUEUE: enabled

Optional Features:
- CONFIG_USER_NS: enabled
- CONFIG_SECCOMP: enabled
- CONFIG_CGROUP_PIDS: enabled
- CONFIG_BLK_CGROUP: enabled
- CONFIG_BLK_DEV_THROTTLING: enabled
- CONFIG_CGROUP_PERF: enabled
- CONFIG_CGROUP_HUGETLB: enabled
- CONFIG_NET_CLS_CGROUP: enabled
- CONFIG_CGROUP_NET_PRIO: enabled
- CONFIG_CFS_BANDWIDTH: enabled
- CONFIG_FAIR_GROUP_SCHED: enabled
- CONFIG_RT_GROUP_SCHED: missing
- CONFIG_IP_NF_TARGET_REDIRECT: enabled (as module)
- CONFIG_IP_SET: enabled (as module)
- CONFIG_IP_VS: enabled (as module)
- CONFIG_IP_VS_NFCT: enabled
- CONFIG_IP_VS_PROTO_TCP: enabled
- CONFIG_IP_VS_PROTO_UDP: enabled
- CONFIG_IP_VS_RR: enabled (as module)
- CONFIG_EXT4_FS: enabled
- CONFIG_EXT4_FS_POSIX_ACL: enabled
- CONFIG_EXT4_FS_SECURITY: enabled
- Network Drivers:
  - "overlay":
    - CONFIG_VXLAN: enabled (as module)
      Optional (for encrypted networks):
      - CONFIG_CRYPTO: enabled
      - CONFIG_CRYPTO_AEAD: enabled
      - CONFIG_CRYPTO_GCM: enabled
      - CONFIG_CRYPTO_SEQIV: enabled
      - CONFIG_CRYPTO_GHASH: enabled
      - CONFIG_XFRM: enabled
      - CONFIG_XFRM_USER: enabled
      - CONFIG_XFRM_ALGO: enabled
      - CONFIG_INET_ESP: enabled (as module)
      - CONFIG_INET_XFRM_MODE_TRANSPORT: missing
- Storage Drivers:
  - "overlay":
    - CONFIG_OVERLAY_FS: enabled (as module)

STATUS: 2 (fail)

As you can see two CONFIG failed and two missed. I asked fedora community for help and got this answer:

According to https://cateee.net/lkddb/web-lkddb/NF_NAT_NEEDED.html, https://cateee.net/lkddb/web-lkddb/NF_NAT_IPV4.html & https://cateee.net/lkddb/web-lkddb/INET_XFRM_MODE_TRANSPORT.html, those options have been removed in recent kernels (probably renamed, merged into another one or made built-in). In general, Fedora CoreOS uses the same kernel as Fedora so if it works on Fedora it should work on Fedora CoreOS.

Please check this issue and determine if you need to make changes to k3s check-config

See https://github.com/rancher/k3s/issues/1291

Yes, the modules have been renamed in newer kernels. Not many folks use check-config since it's not even mentioned in the documentation anywhere. It should probably be fixed at some point though.

https://github.com/rancher/k3s/issues/1291 I'm closing as a duplicate of this issue. Any questions please let me know. Let's track in that issue.


Stretched or distorted image on some Android devices.

Using agora RN 3.7.0
Some users see distorted android image on this device: Android - Samsung J7 prime
Don't know whether we need to add any config. Distorted image is seen on iOS, when talking with Android.

you can try the render mode (the property of the RtcSurfaceView or RtcTextureView component)
Distorted image (you can try setVideoEncorderConfigurarion)

I don't have any updates from client on this issue, looks like the latest library version fixed it? Closing it now.


Need to updated instructions before release of OZ

Need these updates. More to come once we get the OZ screenshots.
Uploading Instructions Update.pdf…

On it...


Namespace overhaul

Mimics recent fix in OSL:

Explicitly and automatically build the vMAJOR_MINOR versioning into
the namespace.

Simplify double nested namespace to just one level.

Change OIIO_NAMESPACE_USING with using namespace OIIO (the macro
was obfuscating without being short or helpful).

LGTM


absolute path question for windows7

ServletContext resource [/D:/etc/cas/log4j2.xml] cannot be resolved to URL because it does not exist

CAS Log4j Configuration

logging.config=D:\etc\cas\log4j2.xml
server.context-parameters.isLog4jAutoInitializationDisabled=true

Please discuss and review this issue with spring boot.


E2E tests for subjects

Perform e2e tests with the nest's default tools (jest) and report the results

Sucessfully tested


Update external packages

Change-type: patch
Signed-off-by: Josh Bowling<EMAIL_ADDRESS>

@balena-ci I self certify!


Project 4 - java

Create a branch with name "java-project4" and submit all files of this project

Created repository to this project using springboot and heroku


Develop

Codecov Report

Merging #2 (c762bd9) into master (af10ac7) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master        #2   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           15        15
  Lines          299       305    +6
=========================================
+ Hits           299       305    +6

Impacted Files
Coverage Δ

lib/src/watcher/verbose_stream.dart
100.00% <ø> (ø)

lib/src/batch_runner/batch_runner.dart
100.00% <100.00%> (ø)

lib/src/batch_runner/batch_runner_state.dart
100.00% <100.00%> (ø)

lib/src/batch_runner/use_case_factory.dart
100.00% <100.00%> (ø)

lib/src/paginator/page_result_item_list.dart
100.00% <100.00%> (ø)

lib/src/paginator/paginator.dart
100.00% <100.00%> (ø)

lib/src/paginator/paginator_state.dart
100.00% <100.00%> (ø)

lib/src/watcher/watcher.dart
100.00% <100.00%> (ø)

lib/src/watcher/watcher_state.dart
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


[SPARK-15194] [ML] Add Python ML API for MultivariateGaussian

What changes were proposed in this pull request?
Added MultivariateGaussian in pyspark ML to match scala's ML API
How was this patch tested?
Tested locally and also added testcases from scala's testsuite

Can one of the admins verify this patch?

@praveendareddy21 Just made a first pass. Also please run PEP8 on your code

@praveendareddy21 For generating documentation for this API correctly, you could include this in spark/python/docs/pyspark.ml.rst
pyspark.ml.stat module
----------------------------

.. automodule:: pyspark.ml.stat
    :members:
    :undoc-members:
    :inherited-members:

Also, just like @MechCoder said, you could run spark/dev/lint-python to make sure you pass all PEP8 checking.

ping @praveendareddy21 Is this still active? If not, I could help with this.

@vectorijk I will be pushing the changes in few days.

@MechCoder @drcrallen @jjthomas @vectorijk
Kindly, review my new changes.

Can you please reopen the pull request across the spark master branch?

Reopened the pull request on master branch.
https://github.com/apache/spark/pull/14375

Can you close this one then?


Spreadsheet - SupportAllDrives and Find File By ID

Could we add supportAllDrives functionality to find_files in drive_object.py?
Similarly, could we allow for searching by file_id, instead of name, if needed?
This worked for me:
def find_files(self, type: FileTypes, name: Optional[str] = None, file_id: Optional[str] = None, supportsAllDrives = False):
    q = f'mimeType="{type}"'
    if name:
        q += f' and name = "{name}"'
        base = self.service.files().list(q=q, supportsAllDrives=supportsAllDrives, includeItemsFromAllDrives=supportsAllDrives).execute()
        files = base.get("files")
        page_token = base.get("nextPageToken")
        while page_token is not None:
            base = self.service.files().list(q=q, page_token=page_token, supportsAllDrives=supportsAllDrives, includeItemsFromAllDrives=supportsAllDrives).execute()
            files += base.get("files")
            page_token = base.get("nextPageToken")
        return files
    if id:
        files = self.service.files().get(fileId=file_id, supportsAllDrives=supportsAllDrives).execute()
        return files

Hey Alec, this is a great suggestion! On top of that, your timing fits well with some changes I have had in progress for sometime (PR here).
In that PR, you'll see some updates to the find_files method, including the support for support_all_drives like you mentioned. This PR still needs a bit of work, especially around documentation, as well as a thorough code review. You can preview what this new functionality will look like in this example file I put together for the use case.
Please feel free to leave any additional feedback about how the functionality looks, and I'll be sure to reach out about some user testing once these changes are deployed!


Asymmetric provider_settings show changes

I introduced provider_settings (see https://buildkite.com/docs/rest-api/pipelines) to allow changes on the pipeline, however this is only the format used for a POST/PUT - when using a GET, those settings are mangled into a map provider, e.g.:
  "provider": {
    "id": "github",
    "webhook_url": "https://webhook.buildkite.com/deliver/xxx",
    "settings": {
      "publish_commit_status": true,
      "build_pull_requests": true,
      "build_pull_request_forks": false,
      "build_tags": false,
      "publish_commit_status_per_step": false,
      "repository": "acme-inc/my-pipeline",
      "trigger_mode": "code"
    }
  },

together with some immutable state (e.g. repository). Unfortunately that means that the map definition is off, which means that changes are shown on a plan:
~ buildkite_pipeline.test
    default_branch:                                             "master" => ""
    provider_settings.%:                                        "3" => "0"
    provider_settings.pull_request_branch_filter_configuration: "" => ""
    provider_settings.repository:                               "joscha/test" => ""
    provider_settings.trigger_mode:                             "code" => ""

I think the right way is to make the settings less generic (currently, they are all bool, but that's not even true for "trigger_mode" for example) and make those parts of the map all optional.
@apparentlymart do you have any recommendation/experience on how to deal with such an asymmetry between local state, push format and read format.

Usually in Terraform providers it's preferred to mimic the structure of the underlying system, but in the past there have definitely been weird cases like this in other providers where there's no standard model used for all operations. This leaves us with a few choices:

Try to invent a common subset or abstraction over the two such that they can be treated the same when writing and reading, and then add extra code to the resource implementation to transform the different API formats to the schema format. This is the most common approach, and generally easiest to document/use since most of the time Terraform user's aren't intimately familiar with the underlying APIs anyway, and so small differences aren't a big deal.
Use separate attributes for reading and writing, with the ones for reading marked as Computed. This is more confusing to use so I would suggest it only if the read and write schema are so divergent that mapping them onto a single schema is not possible. It can also present issues for tracking drift since there would presumably be some parts of the data that are not updated by Read.

I'm honestly not very familiar with this part of the Buildkite API since Say Media doesn't use Github for internal repository hosting, so I'm not sure which of the above is right here but I would definitely lean towards the first option.
It looks like a further complexity here is that the set of settings here can vary based on which provider is in use. Terraform's schema system is not good at dealing with this sort of dynamic structure, so there have been some compromises taken in the past:

Make the dynamic data structure be represented in Terraform as a string containing some JSON. The resource implementation then unmarshalls it and uses it, so the types are not visible to the Terraform schema layer. This is an awkward UX but it's been the most common solution.
Use a nested block structure with a name that implies a type, like this:

resource "buildkite_pipeline" "example" {
  # ...

  github_settings {
    # github-specific settings here
  }
}

In this case we can write out the schema for each possible set of provider settings and then enforce within the provider that only one settings block is allowed regardless of types. Terraform itself probably wouldn't  be able to verify that the right settings block is chosen for the given repository URL, but that could be addressed in documentation.

As a workaround this can be added to the terraform definition:
  lifecycle {
    # TODO remove this once https://github.com/saymedia/terraform-buildkite/issues/14 has been fixed
    ignore_changes = ["provider_settings"]
  }


Replace 'operation' query param by  'operationName'  in /api/traces API

Currently api/traces returns an structure with several fields as operationName
for example:
{
               "traceID":"c54574036f1d750cb58f84a4275e9f8e",
               "spanID":"70a59e0d6f079f65",
               "operationName":"/trace/ping",
               .
               .
               .
}

OperationName represents the same concept as operation trace API query param. For exmaple, /api/traces?service=vertx-web-client&operation=ping
This PR tries to unify both domains in a single domain. My proposal is to use operationName as a first choice, doesn't matter if we are talking about query params or return pojos. operation query param is still supported in order to be backward compatible.

The REST API is intentionally designed to use short words in the URL, like service instead of serviceName. This change would make it more verbose and internally inconsistent, so we can't accept this PR. In the future I would recommend opening a ticket to discuss the change you propose, before spending time working on the code.


Document path array signature for app.METHOD

From https://github.com/expressjs/express/issues/2978:
app.METHOD(path_array, callback [, callback ...]) signature is not documented.
Per @dougwilson:

... the path argument to app.METHOD can not only be a string path, but also an array of string paths, a regular expression, an array of regular expressions, or an array of mixed types.

So, we need to add that.
We probably should add a similar note to to the routing guide (and ideally a short example of using a path array as well) and perhaps also reference topics for app.get, app.post, and app.put for completeness and consistency.
BTW, is this also true for app.all?  It would make sense, but I'd like to confirm before adding anything there?

BTW, is this also true for  app.all ?

Yep, it also has the same ability. In fact, app.use also has this ability if it's not already in the documentation (did not actually look for .use).

Thanks for confirming that, @dougwilson.
We do document path arrays for app.use, specifically it says:

... path can be a string representing a path, a path pattern, a regular expression to match paths, or an array of combinations thereof.

Perhaps that could be worded better, but at least it notes that you can use an array.

Cool. Yea, I would say at lest a quick fix would be to just copy that wording to the app.METHOD and app.all sections :)

@crandmck it is not just the path parameter details we are missing in app.METHOD and app.all, we are missing the details of the callback parameter, too. Ideally it would be good to have the details of both the tables for app.METHOD and app.all also, or have some kind of "smart reference".

Good point, @hacksparrow !
Can you provide that information?  Are the cb params just req, res, and next or is there more to it?
And, not sure what you mean by:

... it would be good to have the details of both the tables for app.METHOD and app.all also, or have some kind of "smart reference".

Can you pls clarify?

On http://expressjs.com/en/4x/api.html#app.use you will see two tables listing the possible types and combos for the path and callback parameters, the same table applies to app.METHOD and app.all as well.


Update OpenLane config.tcl

Added configurations for using a different standard cell library (that is compatible with the base library) when doing resizer optimizations.

Pulled and merged.


Fix performance in the rare case of hashCode evaluating to zero

Problem for java.lang.String explained in https://youtu.be/SZFe3m1DV1A?t=1147 [in Russian].

@krasko hi! Thanks for your contribution, however, I think the fact that this.hashCode() is not equal to super.hashCode() could be quite misleading. Maybe a better approach would be specifying a special value in the AutoHash annotation? E.g @AutoHash(special=0xDEDABEEF) if someone expects a lot of collisions for 0.

I understand your point, it makes sense.
I don't think that specifying any other value could be beneficial. All hash
values ideally would appear with equal probabilities.
Feel free to reject the pull request.
.
On Dec 30, 2016 3:57 AM, "Dmitrii Gerasimov"<EMAIL_ADDRESS>wrote:
@krasko https://github.com/krasko hi! Thanks for your contribution,
however, I think the fact that this.hashCode() is not equal to
super.hashCode() could be quite misleading. Maybe a better approach would
be specifying a special value in the AutoHash annotation? E.g
@AutoHash(special=0xDEDABEEF) if someone expects a lot of collisions for 0.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/karlicoss/autohash/pull/15#issuecomment-269763700, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABatyvaYIIlncr89IKrxYBC1w1L6af54ks5rNPGlgaJpZM4LX9Kg
.


windows goland support?

Can we import go-yara on windows 10 goland in the future?  Are there standard recipes for dealing with other libraries that have C-based dependencies?

@Kwansy98 ping?

I am newbee on golang and i am not sure about that. maybe i should use vscode + go cli rather than goland and compile on cygwin or something, idk...


Keycloak metrics

Describe the topic
What are the right metrics of Keycloak to watch and how to visualize them in a dashboard?
Anything else?
No response

We at ownCloud are using https://github.com/aerogear/keycloak-metrics-spi for additional metrics.
When it comes to metrics that are special to Keycloak, we're mostly interested in logins / token refreshes / logouts and their distribution across OIDC clients. One metric that we didn't find so far is the total number of active sessions, but we plan to add this to the metrics-spi mentioned above.
I currently have no dashboards that I can share.

We are using aerogear/keycloak-metrics-spi  as well. We are monitoring the request count of specific urls, the infinispan caches and the metrics from the Keycloak events. The first two cases are provided by Keycloak now. I have provided a pr keycloak/keycloak#33046 as alternative for the keycloak-metrics-spi MetricsEventListener.
Please feel free to comment and improve


Replace causes error in popup menu entry tracking

Describe the Bug
In some cases, using the replace menu to replace an element causes an error for tracking popupMenu.trigger.
Steps to Reproduce

Add a plain shape
Search for "user task" in replace menu and click option
Check console for error

Expected Behavior
Shouldn't cause errors
Environment

Host (Browser/Node version), if applicable: [e.g. MS Edge 18, Chrome 69, Node 10 LTS]
OS: [e.g. Windows 7]
Library version: [e.g. 2.0.0]

Turns out, this is in all popup menu triggers triggered via keyboard. There is an issue retrieving the entry id because it's determined in different ways in diagram-js for click vs keyboard, so we need to consider both


the beanstalkd() bury method

I want to delete a job that's been attempted more than 3 times, I read on a laracast forum that beanstalkd specifically provides this functionality via bury() method, however I don't see any docs on this for pheanstalk.
I'm working within the Laravel framework (5.0), any documentation shared would be most helpful.

Here's the Bury command class and the $pheanstalk->bury($job, $priority) facade method which uses it.
Pretty much everything is available via the top-level Pheanstalk class which you can read at https://github.com/pda/pheanstalk/blob/master/src/Pheanstalk.php
Note there's also a delete command which you'd use if you never wanted to access that job again. Buried jobs can be inspected and kicked back to life.
The official beanstalkd protocol documentation is at https://raw.githubusercontent.com/kr/beanstalkd/master/doc/protocol.txt too.


[$1000] The text "Account ending in" is not translated despite having a translation in en.js and es.js

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Add a bank account with plaid on staging
Change the language to Spanish
Open the payments page

Expected Result
The text "account ending in" should be in Spanish
Actual Result
The text "account ending in" is in English
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number: 1.2.75-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Expensify/Expensify Issue URL:
Issue reported by: @esh-g
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1676980043749489
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~019ab80a4989edacaf
Upwork Job ID:<PHONE_NUMBER>501514752
Last Price Increase: 2023-02-22

Triggered auto assignment to @NicMendonca (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

Current assignee @NicMendonca is eligible for the External assigner, not assigning anyone new.

Triggered auto assignment to Contributor-plus team member for initial proposal review - @rushatgabhane (External)

Triggered auto assignment to @flodnv (External), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

Proposal
Please re-state the problem that we are trying to solve in this issue.
Incorrect translation is being shown for payment method list.
What is the root cause of that problem?
We're showing the payment method description as it is received from the backend. The backend however, is sending that in english. Thus, setting local language has no effect on what is displayed. This is a sample response that is received after adding a bank account:
[info] [Report] Handled onyxApiUpdate event sent by Pusher - [{"onyxMethod":"merge","key":"bankAccountList","value":{"1579091":{"title":"Plaid Checking","description":"Account ending in 0000","methodID":1579091,"key":"bankAccount-1579091","accountType":"bankAccount","accountData":{"accountNumber":"111122XXXXXX0000","additionalData":{"acceptTerms":true,"bankName":"","country":"US","currency":"USD","fieldsType":"local","plaidAccessToken":"","plaidAccountID":"MxMQgonJv6TEwzxA5jP3F6rLpBAgWpC7PQx4m","previousState":2},"addressName":"Plaid Checking","allowDebit":false,"bankAccountID":1579091,"created":"2022-06-03 20:26:43","defaultCredit":true,"expensifyCardDomain":"memorydump.games","isExpensifyCardSettlementAccount":true,"isSavings":false,"processor":"bancorp","riskChecked":false,"routingNumber":"011401533","sharees":["jeremy@memorydump.games","admin+2000@tulacostarica.com","marco@expensifail.com","allroundexperts+1@gmail.com"],"state":"OPEN","type":"PERSONAL"}}}}]

What changes do you think we should make in order to solve the problem?

We can solve it either at the backend (by reading the users language set and sending translated version to the frontend).
If that is something we need to avoid, then we can run a replace function in the description column of the response to replace the account ending in key automatically.
What alternative solutions did you explore? (Optional)
None

📣 @allroundexperts! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

📣 @Milos213! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~01ee96f841f75f9dd1

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

📣 @Prince-Mendiratta! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

Updated Proposal
Please re-state the problem that we are trying to solve in this issue.
Incorrect translation is being shown for payment method list.
What is the root cause of that problem?
We're showing the payment method description as it is received from the backend. The backend however, is sending that in english. Thus, setting local language has no effect on what is displayed. This is a sample response that is received after adding a bank account:
[info] [Report] Handled onyxApiUpdate event sent by Pusher - [{"onyxMethod":"merge","key":"bankAccountList","value":{"1579091":{"title":"Plaid Checking","description":"Account ending in 0000","methodID":1579091,"key":"bankAccount-1579091","accountType":"bankAccount","accountData":{"accountNumber":"111122XXXXXX0000","additionalData":{"acceptTerms":true,"bankName":"","country":"US","currency":"USD","fieldsType":"local","plaidAccessToken":"","plaidAccountID":"MxMQgonJv6TEwzxA5jP3F6rLpBAgWpC7PQx4m","previousState":2},"addressName":"Plaid Checking","allowDebit":false,"bankAccountID":1579091,"created":"2022-06-03 20:26:43","defaultCredit":true,"expensifyCardDomain":"memorydump.games","isExpensifyCardSettlementAccount":true,"isSavings":false,"processor":"bancorp","riskChecked":false,"routingNumber":"011401533","sharees":["jeremy@memorydump.games","admin+2000@tulacostarica.com","marco@expensifail.com","allroundexperts+1@gmail.com"],"state":"OPEN","type":"PERSONAL"}}}}]

What changes do you think we should make in order to solve the problem?

We can solve it either at the backend (by reading the users language set and sending translated version to the frontend).
If that is something we need to avoid, then we can run a replace function in the description column of the response to replace the account ending in key automatically.
We can also just not use the description that comes with the backend. We can override it on the frontend. To make this useable everywhere, we can pass a new prop to to the function here called translate. This will look like:
function formatPaymentMethods(bankAccountList, cardList, payPalMeData = null, translate = null) {

In the same function, we'll also need to add the following here.
...translate && {
                description: translate(`Account ending in ${bankAccount.accountData.accountNumber.slice(-4)}`),
            },

We can then pass on the translate argument to formatPaymentMethods everywhere its being used so that this works across the board.
We can do the same for credit card and paypal account description as well.
What alternative solutions did you explore? (Optional)
None

📣 @ggalletty! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

@Prince-Mendiratta @allroundexperts thanks for your proposals! @Milos213 was first one so going with that

Thanks for the feedback @rushatgabhane!

@ggalletty i love your solution as well because it's handling both LTR and RTL. But I don't think this is the right time to do it. We should probably do it after the entire app's audit is done for supporting RTL.
I would have approved your solution but @Milos213 was the first one, thanks so much for your proposal!

Thank you @rushatgabhane for feedback! Hopefully I will be able to contribute when the time comes 🙌

Hmmm, good catch! @Milos213 your proposal makes sense. However, after checking, I think in this API call, the backend does not return a field containing only the last four / the account number, or does it...? If it does not, we should add a field 'lastFourDigits' and use that instead. Let me know what you think 🙇

Can't we use this one which was already used in delete modal?

Yes! Does this work for payments cards though?

I think so. The field name is cardNumber. I was not able to test debit card but this code was already used in delete modal:
https://github.com/Expensify/App/blob/9d04b46456253955c96981db9ef38245953baf18/src/pages/settings/Payments/PaymentsPage/BasePaymentsPage.js#L216

Hmmm looking again at the API I think it will work, but please make sure to test this in your PR. I created a followup issue for myself to remove these untranslated fields from the API in a little while (after making sure they're unused): https://github.com/Expensify/Expensify/issues/264765
Go ahead and proceed with the PR @Milos213 ! 🙇

📣 @Milos213 You have been assigned to this job by @flodnv!
Please apply to this job in Upwork and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑💻
Keep in mind: Code of Conduct | Contributing 📖

Reviewing label has been removed, please complete the "BugZero Checklist".

The solution for this issue has been :rocket: deployed to production :rocket: in version 1.2.79-0 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

https://github.com/Expensify/App/pull/15555

If no regressions arise, payment will be issued on 2023-03-14. :confetti_ball:
After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

[ ] External issue reporter
[ ] Contributor that fixed the issue
[ ] Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

Merged PR within 3 business days of assignment - 50% bonus
Merged PR more than 9 business days after assignment - 50% penalty

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

[ ] [@rushatgabhane / @flodnv] The PR that introduced the bug has been identified. Link to the PR:
[ ] [@rushatgabhane / @flodnv] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
[ ] [@rushatgabhane / @flodnv] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
[ ] [@NicMendonca] Determine if we should create a regression test for the bug.
[ ] [@rushatgabhane] If we decide to create a regression test for the bug, please propose the regression test steps to the appropriate location to ensure the same bug will not reach production again.
[ ] [@NicMendonca] Review the proposed regression test steps and location.
[ ] [@NicMendonca] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

Looks like something related to react-navigation may have been mentioned in this issue discussion.
As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our DeprecatedCustomActions.js files should not be accepted.
Feel free to drop a note in #expensify-open-source with any questions.

@esh-g @rushatgabhane @Milos213 Can you please apply for the job so that we can issue payment? https://www.upwork.com/jobs/~019ab80a4989edacaf
Thanks!

Applied under the name Tanya Gupta

everyone has been paid! thank you!


enum indexer property not inferred properly

try flow
This prevents writing certain libdefs, e.g this: try flow
This has never worked. It's especially important when moving exact by default types since A & B would not work in that kind of cases anymore. Now the example is possible to make working with limitation that exact properties are not supported, and using A & B approach.
Would be very interesting to try to fix this by my self, but Flow codebase is a bit frightening. Any pointers what lines should I look at and would this be big task to fix?

This seems like a special case of indexers being totally broken on exact
objects. Changing key: "b" to key: string in your example raises the
same error.
The simplest repro is
({a: 1}: {|[string]: number|});  // fails! :-(

@jbrown215: When objects become exact-by-default, this will be a
crippling pain point. Indexer properties will become basically unusable.
Do we have plans to fix this?

@wchargin: I've brought this up internally. We have no current plans for this, but I'll look into it more before we make the change to exact by default.

Great; thanks.

Oh, didn't remember the comment from @wchargin made a new report about (apparently) exactly the same issue: https://github.com/facebook/flow/issues/7240

Looks like these lines are the culprit: https://github.com/facebook/flow/blob/master/src/typing/flow_js.ml#L6748-L6763
When taking that off, most of the stuff works fine and this specific problem is fixed, although some tests starts to fail.

@jbrown215 made a PR to fix this: https://github.com/facebook/flow/pull/7271
Looks like it does not fix the second case in this: try flow but that's most likely some other issue as it's more complicated example too.

@villesau: I'm curious to know what purpose an "exact object with an indexer" serves. At first glance, an indexer in an exact object looks like it makes the object equivalent to an inexact object with the same properties/indexer.
Perhaps we should disallow indexers with exact objects altogether?

@jbrown215
First of all, consistency. Secondly, I think that {[key: string]: number} as inexact type does not actually make much sense. What ever key you have should be number, but the object also might have some other properties? There is clear conflict in the logic: the type needs to be something, but it also might be something else that you don't know of. But AFAIK the inexact indexer object does not work that way. So in essence the indexer object actually already is exact.
See this example:
// @flow
type A = {|a: number|};
type B = {|...A, [key: 'b']: string |};

const test: B = {a: 321, b: 'abc'};

where exact types are spread. I want to keep them as exact. The key b might come from other types, this example is just simplified.
And lastly, like said, it would be at least prework to get this example working. When moving away from inexact types, we need to spread exact types with indexer properties, {a: nuber} & {b: string} would not work with exact types. that example is a simplified version of what would in future become Rosie libdef: https://github.com/rosiejs/rosie but not allowing exact indexers makes such libdef impossible with exact objects.

I think we view exact objects a little differently. Take this example:
type O = {| a: string, [string]: string |}

declare var x: O;
(x.a: string); // Seems reasonable
(x.b: string); // ?? Seems less reasonable

IMO, the exact object should fully capture the properties in the object. An indexer by nature is "imprecise" and feels weird when combined with a precise representation of an object.

First of all, consistency. You should be able to type everything as exact, otherwise it's not intuitive.

I think this friction is necessary to let people know that what they think is exact doesn't actually behave like an exact object should (as far I as view exact objects, which is a place where we disagree).

Secondly, I think that {[key: string]: number} as inexact type does not actually make much sense. What ever key you have should be number, but the object also might have some other properties?

I get why this seems weird from that perspective, but consider it from the other perspective. Why should you be allowed to specify an imprecise specification for an exact object?

When moving away from inexact types, we need to spread exact types with indexer properties

I think the solution there might be to keep the objects inexact and fix spreads. I'm not even sure what the correct behavior for an exact object with an indexer being spread should be. Couldn't it overwrite all of the object's props if the object with the indexer was spread after other props were specified?

Thanks for the profound arguments!
Note that indexer might have well defined string literal as indexer: ({str: 'str' }: {|['str']: string|}); this should behave 1:1 like ({str: 'str' }: {|str: string|}); but the former one fails currently. The PR I submitted has test cases validating that this case works as expected, at least in the simple and most important use cases.
This is necessary when building libdefs. That's the main issue here, and those are essentially the ones we need to spread too.

I think we view exact objects a little differently. Take this example:

type O = {| a: string, [string]: string |}

declare var x: O;
(x.a: string); // Seems reasonable
(x.b: string); // ?? Seems less reasonable

To me the main issue in this example is that indexer properties should always be optional types: https://github.com/facebook/flow/issues/6980

I get why this seems weird from that perspective, but consider it from the other perspective. Why should you be allowed to specify an imprecise specification for an exact object?

I think it as precise: It precisely defines that the key can be anything, but values of any key is well defined. look at this inexact example:
({str: 'str', num: 123 }: {str: string}); try flow
as you see it has property num which is number, completely fine. Now if we consider inexact indexer objects and previous example, this should be fine too:
({str: 'str', num: 123 }: {[key: string]: string}); try flow
but it's not. So I'd argue that inexact indexer objects are broken here and they actually behave pretty much exactly how exact indexer objects should behave. That said, the strength of inexact indexer object should be very close to plain Object type, maybe even exactly the same.

I think the solution there might be to keep the objects inexact and fix spreads. I'm not even sure what the correct behavior for an exact object with an indexer being spread should be. Couldn't it overwrite all of the object's props if the object with the indexer was spread after other props were specified?

If the key is string literal, it should work like normal exact object. Otherwise I'd expect something like:
type O1 = {|a: number|};
type O2 = {|[key: string]: string, ...O1|}; //becomes {|[key: string]: string, a: number|}

type O3 = {|[key: 'a']: string|};
type O4 = {|[key: string]: string, ...O3|}; // becomes {|[key: string]: string, a: number|}

type O5 = {|[key: string]: string|};
type O6 = {|a: string, ...O5|}; // becomes {|a: string, [key: string]: string|}

where precisely defined keys would overrule indexers. I didn't validate that this would be the best behaviour, but this is what I'd expect at first glance and what would be the least surprising to me.
Anyhow, there are three different cases here: Indexer object with arbitrary key (string type), indexer with string union ('key1' | 'key2') (which I didn't want to touch, that's a topic of it's own) and indexer object with well defined key (some string literal).

I think both of our interpretations are reasonable, but we disagree in our starting points. I'll talk to Sam, who has plans for our object types, to see what a good mental model for exact vs. inexact is going forward

Here is very related issue: https://github.com/facebook/flow/issues/3162

As of Flow 0.111.0, Flow is specifically asking us to make indexed
properties exact:
Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ src/plugins/git/gitUtils.js:41:11

Cannot determine a type for object literal [1]. object type [2] is inexact, so
it may contain TZ with a type that conflicts with TZ's definition in object
literal [1]. Can you make object type [2] exact?

 [2] 17│   return function git(args: string[], env?: {[string]: string}): string {
       :
 [1] 25│     const fullEnv = {
     26│       // Standardize output.
     27│       LANG: "C",
     28│       LC_ALL: "C",
     29│       PAGER: "cat",
     30│       TZ: "UTC",
     31│       // Short-circuit editing.
     32│       EDITOR: "true", // (this is `true` the command-line program)
     33│       GIT_MERGE_AUTOEDIT: "no",
     34│       // Ignore global Git settings, for test isolation.
     35│       GIT_CONFIG_NOSYSTEM: "1",
     36│       GIT_ATTR_NOSYSTEM: "1",
     37│       // Bring over the SSH configuration so that loading private repos is possible
     38│       // This post has some useful information on SSH_AUTH_SOCK:
     39│       // http://blog.joncairns.com/2013/12/understanding-ssh-agent-and-ssh-add/
     40│       SSH_AUTH_SOCK: process.env.SSH_AUTH_SOCK,
     41│       ...(env || {}),
     42│     };
     43│     const options = {env: fullEnv};
     44│     return execFileSync(

I don’t understand the team’s position on this—if exact objects with
indexers don’t make sense, why is Flow asking us to introduce them to
resolve newly added type errors?

This is a bug in the error message. It recommends making the object type exact because it is inexact, not because it has an indexer. We should only recommend making the object exact if there is no indexer. Will fix!

Just to document the TS functionality related to above conversation about indexers: http://www.typescriptlang.org/play/?ssl=12&ssc=3&pln=9&pc=1#code/C4TwDgpgBAglC8UDeAoK6oG0DkBDbAugFxQB2ArgLYBGEATigL4DcKKoksAjAsmhjhjYoAHwAF2aoRIUa9KAHoFZAPbAoAdxV0A1gEtSAcyat24aDABMvVBix5pZKrToAafuhxTiTuW5MeUGacAEI2gZg6ECAkAM7AdAaGPrIuAcHQITyItgJRMVDY8YlGjqnySqrqWrpJ6RyZ1jkR+STYQqIS3jLOFcqkapra+kYBdhlQIQDM4XaR0XEJSSm9-nOtvi4rfu4sbABuuHRQuFwkcDknJFyWM3uHx7iW5zZQ1Ne3UPdHJ1Mvl7gPlNXG8gV9TA8TpYzrAmsgrlAbndWJCns9Ya93ojPt9HrdznCkAikSCsUjwWwUJDqDCwgCwbi3ui6fCyTiUT9qH9Jq9AdjgaD+RTqQAWEgsol8kmCooJYSM6gAVnFvKBIPR5L2VM50PFM3pQoVlmZ+tZDI5x2o+MmpslasFmotTLFNtV-NJbWK8qdVuVroN0o17KAA

I think a string union indexer is the case to focus on, because it comes up in enums, and {[UnionType]: Foo}/{|[UnionType]: Foo|} could be interpreted very differently.
type Unit = 'ft' | 'm'
const attributes: {[Unit]: {toMeters: number, displayText: string}} = {
  ft: {inMeters: 0.3048, displayText: 'Feet'},
  m: {inMeters: 1, displayText: 'Meters'},
}

And @villesau the corresponding TS type is actually Record, not indexer properties.
type UnitAttributes = Record<'ft' | 'm', {toMeters: number, displayText: string}>

Now you can do it with mapped type: https://flow.org/try/#1N4Igxg9gdgZglgcxALlAJwKYEMwBcD6aArlLnALYYrgA2WAzvXGCADQgYAeOBARgJ74AJhhhYiNXClzEM7DFCLl602e0hQhcMtCw18ufgAcqyGUTkhyWIyaEHjp85cMn8CIljRCVZ2QF91CBFqAHpQgAIAARgaCAB3AB0oZJEwOkwI9IZ6CIAxHgg0fgAeABVWCIBBMDAlCSxcIoiAXgjgAB8O-wA+duSIiKwhISrcGRKAaWQIgBJJjH56cp7KgDUZsoBtSYBdHoAKAcGIgGtFmcnWY8GANz0LGbXjgEoZgrwi0or2gDp-mp1cgNJpoSr-X7ALb4SYROBQCJ7J7+CK9ADcxwQGFwACUMPQJLgDm9qrV6nRQcl-Mlkhp6LgImJPsVWhEoBh4vlCsUSp0sDNFOReBgwRFeDN6Wh4QhuocXhiUlA6QymaD+AAmVmqr6-YajcZoA4Acl4RsqRvo5FwAAsoAgAIRG+W06D0xnc-gAZi1Ht1IzGMmNWDNEU96oAjM7FQdtcV1b8sbj8YTiTNOuKIpLpZV+WylMK0N15RFwhESJByJRSIzmiK0EUVOxbiKmNBqLcAAy-CPxjsgfxAA


building with prisma causes this error on preview: Uncaught TypeError: The specifier “.prisma/client/index-browser” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.

Environment
Operating System: Linux

Node Version:     v20.9.0
Nuxt Version:     3.8.1
CLI Version:      3.9.1
Nitro Version:    2.7.2
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      imports, modules, snackbar, css, build, io, discord, auth, vite
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction
integrate prisma into your app like the following:
/service/prisma
import { PrismaClient } from "@prisma/client";

const prismaClientSingleton = () => {
  return new PrismaClient();
};

type PrismaClientSingleton = ReturnType<typeof prismaClientSingleton>;

const globalForPrisma = globalThis as unknown as {
  prisma: PrismaClientSingleton | undefined;
};

export const prisma = globalForPrisma.prisma ?? prismaClientSingleton();

if (process.env.NODE_ENV !== "production") globalForPrisma.prisma = prisma;

Now import into an module you plan on using it in like so:
import { prisma } from "~/services/prisma

//do stuff with prisma

Describe the bug
After build and the during preview, the client doesn't seem to hydrate properly because it's interrupted by the following error:
Uncaught TypeError: The specifier “.prisma/client/index-browser” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.

I'm using enums from prisma so could this be the problem?
Additional context
No response
Logs
No response

Would you be able to provide a reproduction? 🙏
More info

It's kinda hard to provide a reproduction due to the size and scope of the project. I will add that during npx nuxi build I also get this:
.prisma/client/index-browser" is imported by ".prisma/client/index-browser?commonjs-external", but could not be resolved – treating it as an external dependency.

It is a vite build issue, add vite config to your defineNuxtConfig will fix it, like this:
defineNuxtConfig({
vite: {
ssr: {
external: ["@prisma/client"]
},
resolve: {
alias: {
".prisma/client/index-browser": "./node_modules/.prisma/client/index-browser.js"
}
}
}
})


Integrate adding IA with nestedIAs

When adding subIA's to interest area, after typing into input field, it should send a request, and show the results in a dropdown. Current view is this, after this issue is solved, we will have a search functionality with dropdown. Also, it will be multiple select.

I've opened this PR. I'll close this issue after it's merged.


First shot

The following rulesets are included:

Several custom sniffs mainly focuse on naming conventions,
PHPCompatibilityWP (PHP 5.6 and WP 5.4),
WordPress,
Suin (for PSR-4).

Some folders and files are excluded by default.
By default, PHPCompatibility will test agaisnt PHP 5.6 and WP 5.4.

@Chouby Should we also include automattic/phpcs-neutron-standard?


Make Subscription ID field mandatory in Azure discovery

This is a follow-up PR for https://github.com/ManageIQ/manageiq/pull/10531
Subscription ID field which was optional before is now mandatory.

@bronaghs This is a very simple change since I'm just following the precedent here (Client ID, Client Key and Azure Tenant ID).
(but as we discussed earlier, this is how we want it handled)
Let me know if I should look into angularizing this form.
Thanks.
/cc @djberg96

@AparnaKarve - looks good. Is there a check in place to make sure a guid is entered? I am curious if this check is in place for Client ID and tenant id also?

Is there a check in place to make sure a guid is entered?

No, the guid validation does not exist. It will accept any non-empty string for Client ID/Tenant ID and now Subscription ID.

@AparnaKarve - do we check for a guid in the Azure Add Cloud Provider screen? If not, maybe we can add checks for both Azure Add and Discover screens in a separate PR.

@bronaghs We do not check for a guid value in Azure Add Cloud Provider screen.
I can add that validation in a separate PR.

Sounds good

LGTM 👍

@AparnaKarve would you please investigate the test failures on Travis.

@chessbyte I see 2 failures:

One related to MiqReport Seeding which even exists for other open PRs
(looks like https://github.com/ManageIQ/manageiq/pull/11119 would fix that one)
The other one in spec/models/manageiq/providers/vmware/infra_manager/refresher_spec.rb seems like a random failure (could not reproduce it locally)

FWIW, I'll open/close this PR and see if addresses the second one, after https://github.com/ManageIQ/manageiq/pull/11119 is merged.

Darga BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1374815 (This is for this PR and https://github.com/ManageIQ/manageiq/pull/10531)
@miq-bot remove_label bugzilla needed

Darga Backport details:
$ git log
commit f09d1b49dad0b4a7875c70e73605f3791b64cf39
Author: Dan Clarizio<EMAIL_ADDRESS>Date:   Thu Sep 8 14:36:42 2016 -0700

    Merge pull request #11116 from AparnaKarve/subscription_id_mandatory

    Make Subscription ID field mandatory in Azure discovery
    (cherry picked from commit 91243b96b7f85aa584377b85f2ca9f8aafd11934)

    https://bugzilla.redhat.com/show_bug.cgi?id=1374815


Define schema.yaml

For Oracle Resource Manager, if we use conditional booleans, dropdown values (region key for example), and then sections for the config, it will be closer to self documenting.  We can provide a title, description, and regex expression for validity for each terraform variable that is required.  The oci-cloudnative repo has this kind of validation in its terraform for ORM.

Thanks a lot Andrew. We'll include schema.yaml in the next release of Landing Zone.

Added in commit: https://github.com/oracle-quickstart/oci-cis-landingzone-quickstart/commit/ccc028ab8cdec4b17475d1643fadc9b0fb8fa77c#diff-0309db2a89c48166b1a5559bd173631fef40b9684dc18c7cc617372b9aee86b1


disable close button on header

How can I disable/hide close button auto generated by iziModal-header, modal need to hold on before the request end

In the options is not possible yet.  But for now you can use css to hide it.
.iziModal .iziModal-button-close{     display: none !important; }

ya, I use this way now, but I think this should be an enhancement in your plan.
Anyway, this is an awesome modal & toast plugins I have ever seen, thanks for develop it


Can I know that is the default gupl-babel including polyfill by default

The docs said

To include the polyfill you need to require it at the top of the entry point to your application.

require("babel/polyfill");

gulp-babel is doing
require("babel-core")

So I think polyfill is not included but again the doc said that polyfill is

Available from the browser-polyfill.js file within a babel-core npm release

Can you help me to clear this up?

It's not included by default, no.

@yang-wei how'd you add it?

I was hoping to exclude it.
If you want to add it, I think
require('babel/register')

will do the tricks. http://babeljs.io/docs/usage/require/#usage
@mmahalwy

@yang-wei but I need it to run in frontend js world.

@mmahalwy
Then include browser-polyfill.js
http://babeljs.io/docs/usage/polyfill/#usage-in-browser


[White Paper 2019 Media push]  design 1- General

@rstjames,
Without rush, lets create 2 effective yet fun designs for paper media push to hold true for the rest of 2019.
2nd ticket coming up with requirements. :)
Design minimum requirements for general message push:

contain the MP coffee cup
Lars' pic
description for design and tweet next week.

@rstjames,
Media Description:
#MicroProfile is the #OpenSource Enterprise #Java project for a #MicroservicesArchitecture that enables users and developers alike to innovate across its multiple APIs. @mobileLarson's 45 pages white paper explains why NOW is the best time to check out @MicroProfileIO!
#OSS @java

@aeiras Need to shorten the message to fit a link to the WP.

Link to landing page: http://bit.ly/2YMZcWr

1 character left :) maybe a yellow heart, lol thanks Ryan!
#MicroProfile is the #OpenSource Enterprise #Java for a #MicroservicesArchitecture that enables users and developers to innovate across multiple APIs. @mobileLarson's white paper explains why NOW is the best time to check out @MicroProfileIO!
http://bit.ly/2YMZcWr
#OSS @java

@rstjames, I see this tweet went out today:
Is it scheduled to go weekly on wed for the rest of 2019? If so, lets close this ticket and thank YOU!


Support for large svg files and option to install without poetry.

Thank you very much for this software! I needed to port some Maths notes I had in OneNote to my new rM2 and this worked like a charm!
However, I had to introduce some fixes to make it work, which are included in this pull request:

Support in lxml ElementTree for larger svg files (adding huge_tree=True to the XMLParser).
Support for installation without Poetry (this is just me being lazy and not wanting to learn how to use Poetry, but it can't hurt).
Compatibility issue with subprocess (capture_output is a relatively new option, I replaced it with stdout=Pipe, stderr=PIPE).
To make pdf_converter.py run I had to install an inkscape extension. I have added one line in the README in dependencies.

Would you mind giving it a look and possibly merge these? Thanks!

I'm glad you have found the module useful.
Thank you for your suggestions. I will integrate your large SVG support along with your readme change for installing the inkscape extension.

Compatibility issue with subprocess (capture_output is a relatively new option, I replaced it with stdout=Pipe, stderr=PIPE).

What version of python are you using?
Regarding the install script and setup.py. Poetry replaces all those so I'd prefer to keep it "clean". Out of interest did you have issues using the bundled requirements.txt file (ie create vnev, activate then pip install -r requirements.txt)?

Thank you for your suggestions. I will integrate your large SVG support along with your readme change for installing the inkscape extension.

Great, thanks!

What version of python are you using?

3.6.9, capture_output was introduced in 3.7, but it is equivalent to using PIPE, see here. Wouldn't it be better to use PIPE for backward compatibility?

Regarding the install script and setup.py. Poetry replaces all those so I'd prefer to keep it "clean". Out of interest did you have issues using the bundled requirements.txt file (ie create vnev, activate then pip install -r requirements.txt)?

I see, I understand. The issue with running pip install -r requirements.txt is that pypotrace requires numpy to be already installed to build (see here), so running pip install in one go fails unless a pip install numpy is run beforehand. I think Poetry automatically fixes this issue.

Can I also add: I never used Poetry and while it seems like it is easy to use I was initially put off by the fact that I would have had to learn another software to install yours. I think having an install script ready (or explaining in the readme how to install and use Poetry to install the software) could make it more likely for others to use the module.

3.6.9, capture_output was introduced in 3.7, but it is equivalent to using PIPE, see here. Wouldn't it be better to use PIPE for backward compatibility?

I hear you. Although the plan was for 3.7 and higher & 3.6 hasn't got much time left imho.
https://github.com/bsdz/remarkable-layers/blob/f96a73a4c6da2ce93ec42f21e7964a77a910af63/pyproject.toml#L7-L8

I see, I understand. The issue with running pip install -r requirements.txt is that pypotrace requires numpy to be already installed to build (see here), so running pip install in one go fails unless a pip install numpy is run beforehand. I think Poetry automatically fixes this issue.

Ah yes I forgot about pip's unreliable install ordering. I'll update readme with a way around that. Thanks.

Great! Thanks a lot!

I've added the large file support and added a simple pip install. This required creating an alternative pypotrace fork as the original didn't really impose the numpy dependency. Thanks for your help here.

Thanks a lot Blair!


support flatpak for wider distro support

not every linux user are debian based users, and also not everyone use a mutable distro (there are immutable ones such as steamos)
flatpak supports wider range of distros AND works well with immutable ones
https://flatpak.org/

Some features of capter doesn't work well with dynamically linked packages on different distro. This is why I have to remove .tar.gz from releases, because it is compiled on ubuntu and have issues on archlinux.
It is not issue with capter, but with the crates it uses. Maybe if a better crate is created in future, it will be possible.


bi-directional useInfiniteQuery

Say you have a UI with an infinite scrolling table and you want to deep link to a particular row in that table that is not on the first "page". The server could return the "page" that starts with that row as well as both forward and reverse cursors.
It'd be great if there was a version of useInfiniteQuery that allowed for something like fetchMoreReverse. I'm guessing it wouldn't be too hard for us to implement based on the existing useInfiniteQuery hook, but I was curious if it was anything you'd want in react-query and/or if there's a way to do this out of the box.

I think this is a great idea. I will look into the possibility of something like a appendMode or something that would allow you to configure the "direction" which you are adding on to.

This will be a feature in the next major version. 👍

That's great, thanks!

I worked through a similar issue this weekend, and came up with the following approach.  There are a few dependencies:

usePersistedStorage for persisting a "refresh" cursor in local storage
InfiniteLoader (from react-virtualized)
Autosizer (from react-virtualized)
Table (from react-virtualized)
useTable (from react-table)

This assumes the API responses are coming from ElasticSearch.
The refreshCursor is leveraged to keep a users place when the page refreshes.
Disclaimer - I'm a bit of a newbie here, so open to feedback :D (thanks tannerslinsley for the great libraries)
A hook:
interface IStreamQuery {
  key:string
  size: number
  sort:any
  reverseSort:any
  filter: any
  refreshKey:string
  queryFn:any
}

export const useStreamQuery = ({ key, size, sort, filter, reverseSort, refreshKey, queryFn }: IStreamQuery) => {
  const [ refreshCursor, setRefreshCursor ] = usePersistedState(refreshKey, [])
  const [ scrollIndex, setScrollIndex ] = useState<undefined | number>(undefined)
  const [ startCursor, setStartCursor ] = useState()
  const [ initialRefreshCursor, setInitialRefreshCursor ] = useState(refreshCursor)

  const searchParams = useMemo(() => ({ size, sort, searchAfter: initialRefreshCursor, ...filter }), [size, sort, filter, initialRefreshCursor])
  const searchParamsReverse = useMemo(() => ({ size, sort: reverseSort, ...filter }), [size, reverseSort, filter])
  const recordsQuery = useInfiniteQuery([key, searchParams], queryFn, {
    enabled: searchParams.city_id,
    getFetchMore: (lastGroup, allGroups) => {
      const hits = _.get(lastGroup, 'hits.hits', [])
      const nextCursor = _.get(_.last(hits), 'sort')
      return nextCursor;
    }
  })
  const recordsQueryReverse = useInfiniteQuery([key, searchParamsReverse], queryFn, {
    enabled: false,
    getFetchMore: (lastGroup, allGroups) => ({})
  })
  const reverseHits = useMemo(() => {
    return _.flatten((recordsQueryReverse.data || []).map((page:any) => _.get(page, 'hits.hits'))).reverse()
  }, [recordsQueryReverse.data])
  const forwardHits = useMemo(() => {
    return _.flatten((recordsQuery.data || []).map((page:any) => _.get(page, 'hits.hits')))
  }, [recordsQuery.data])
  const totalHits = _.get(recordsQuery.data, '[0].hits.total')
  const lastSearchTimeMs = _.get(recordsQuery.data, '[0].took')
  const fetchUpstream = async (cursor:any) => {
    return await recordsQueryReverse.fetchMore(cursor)
  }
  const fetchDownstream = async () => {
    // @ts-ignore
    if(recordsQuery.isLoading || recordsQuery.isLoadingMore) { return () => {} }
    return await recordsQuery.fetchMore()
  }

  return {
    isLoading: recordsQuery.isLoading || recordsQueryReverse.isLoading,
    hitsWindow: [reverseHits, forwardHits],
    scrollTop: async () => {
      await recordsQuery.clear()
      await recordsQueryReverse.clear()
      setScrollIndex(0)
      setStartCursor(undefined)
      setRefreshCursor([])
      setInitialRefreshCursor([])
    },
    totalHits,
    lastSearchTimeMs,
    fetchUpstream,
    fetchDownstream,
    refreshCursor,
    setRefreshCursor,
    startCursor,
    setStartCursor,
    scrollIndex,
    setScrollIndex,
  }
}

A component:
export const StreamTable = ({ rows, columns, initialState, containerProps, tableProps, ...streamQuery}: any) => {
  const [ afterInitialRender, setAfterInitialRender ] = useState(false)
  const reverseHits = useMemo(() => streamQuery.hitsWindow[0], [streamQuery.hitsWindow])
  const infiniteLoaderProps = {
    rowCount: streamQuery.totalHits?.value,
    loadMoreRows: (data:any) => {
      streamQuery.fetchDownstream();
    },
    isRowLoaded: ({index}: {index:number}) => {
      return !!rows[index];
    }
  }
  const finalTableProps = {
    ...tableProps,
    scrollToAlignment: 'start',
    scrollToIndex: streamQuery.scrollIndex,
    onRowsRendered: ({startIndex}:IReactTableOnRowsRendered) => {
      if(startIndex > 0) {
        streamQuery.setRefreshCursor(_.get(_.flatten(streamQuery.hitsWindow)[startIndex - 1], 'sort'))
      } else if(afterInitialRender) {
        streamQuery.setRefreshCursor([])
      }
      setAfterInitialRender(true)
    },
    onScroll: async ({ scrollHeight, scrollTop }:{scrollHeight: number, scrollTop: number }) => {
      const shouldLoadPrevious = scrollTop === 0 && scrollHeight != 0 && !_.isEmpty(streamQuery.startCursor);
      if(shouldLoadPrevious) {
        const latest = await streamQuery.fetchUpstream(streamQuery.startCursor)
        streamQuery.setScrollIndex(_.get(_.last(latest), 'hits.hits').length)
      } else {
        streamQuery.setScrollIndex(undefined)
      }
    }
  }

  useEffect(() => {
    streamQuery.setStartCursor(_.get(_.first(_.flatten(streamQuery.hitsWindow)), 'sort'))
  }, [streamQuery.hitsWindow, streamQuery.setStartCursor])

  useEffect(() => {
    (async function initialReverseFetch() {
      if(afterInitialRender) {
        const latest = await streamQuery.fetchUpstream(streamQuery.startCursor)
        streamQuery.setScrollIndex(_.get(_.last(latest), 'hits.hits', []).length)
      }
    })();
  }, [afterInitialRender])

  return (
    <InfiniteLoader
      infiniteLoaderProps={infiniteLoaderProps}><AutoSizer><Table tableProps>...</Table></AutoSizer></InfiniteLoader>
  )
}

Usage:
  const streamQuery = useStreamQuery({
    key: 'crmRequests',
    refreshKey: 'crm.refreshCursor',
    size: 100,
    sort: sort,
    reverseSort: sortReverse,
    filter: searchParams,
    queryFn: fetchSearchCrmRequests(networkHeaders)
  })

          <StreamTable
            {...streamQuery}
            columns={columns} rows={rows}
            initialState={initialState}
            containerProps={containerProps}
            tableProps={tableProps}
          />

Say you have a UI with an infinite scrolling table and you want to deep link to a particular row in that table that is not on the first "page". The server could return the "page" that starts with that row as well as both forward and reverse cursors.
It'd be great if there was a version of useInfiniteQuery that allowed for something like fetchMoreReverse. I'm guessing it wouldn't be too hard for us to implement based on the existing useInfiniteQuery hook, but I was curious if it was anything you'd want in react-query and/or if there's a way to do this out of the box.

@aaronjensen  This is a really interesting scenario that I'm trying to implement, but it seems rather confusing especially now that fetchNextPage({ pageParam }) is no longer supported. I was wondering if you can share some tips on how to do it with useInfiniteScroll 🙏🏼

@esivan-cloudinary sorry, we don't use this library anymore.

infinite queries support bi-directional fetching since v3

@aaronjensen
And what would be the ideal library to use at this time when implementing this?


Could not update ENVs on server

** Execute figaro_yml:check_figaro_file_exists
cap aborted!
NoMethodError: undefined method `exists?' for File:Class (NoMethodError)
next if File.exists?(figaro_yml_local_path)
            ^^^^^^^^

Did you mean?  exist?
/Users/marcusfranzen/.rbenv/versions/3.2.1/lib/ruby/gems/3.2.0/gems/capistrano-figaro-yml-1.0.5/lib/capistrano/tasks/figaro_yml.rake:14:in `block (2 levels) in <top (required)>'

This problem is now solved with v1.0.0, as capistrano-ops now includes the functionalities of capistrano-figaro-yml gem
so you can update to the v1.0.0 and remove the capistrano-figaro-yml gem


Removed unused file which blocked null safety

For some reason, a previous commit renamed the controller file without deleting the old one. This triggered the null-safety check to fail even though the package was already ready for sound null safety.

@fedeoo Can you please release a new package version after this? Google suggests using v1.0.0 or v0.6.0 to indicate the change, I'd go with v1.0.0. The package is relatively stable already with no upcoming breaking changes. I think the only realistic changes will be additional backwards compatible customization options.


Move circe-spray to its own project

This is the other part of #514. Most importantly we can now get rid of sbt-doge now, which means we don't have to worry about fixing the fact that sbt update wasn't working when 2.12.1 was the default Scala version.

Current coverage is 82.16% (diff: 100%)

Merging #519 into master will increase coverage by 0.15%

@@             master       #519   diff @@
==========================================
  Files            69         70     +1
  Lines          1968       1974     +6
  Methods        1828       1833     +5
  Messages          0          0
  Branches        140        141     +1
==========================================
+ Hits           1614       1622     +8
+ Misses          354        352     -2
  Partials          0          0

Powered by Codecov. Last update 831526f...010c61f


creating eksctl command: repository does not exist

I created a cluster yesterday using this code block:
resource "eksctl_cluster" "this_new" {
  eksctl_version = "0.35.0"
  name = local.cluster_name
  region = data.aws_region.current.name
  spec = file("${path.module}/files/ng1.yaml")
  version = "1.18"
}

Now I'd like to delete this cluster, and I removed this code block. But on remote apply, I am getting this error:
Error: creating eksctl-delete command: creating eksctl command: repository does not exist
Terraform Cloud was having some CDN issues earlier today, which perhaps affected its ability to download eksctl via shoal? (this is only a speculation). So I've switched to applying locally. However,  this results in a different error:
[ℹ]  eksctl version 0.35.0
[ℹ]  using region us-east-2
[ℹ]  deleting EKS cluster "perfect-crawdad"
[ℹ]  deleted 0 Fargate profile(s)
[ℹ]  cleaning up AWS load balancers created by Kubernetes objects of Kind Service or Ingress
Error: cannot list Kubernetes Services: Unauthorized

The latter error is likely due to me not having authentication to the cluster. I am also unable to delete the cluster by just running eksctl delete cluster locally, which seems likely related to https://github.com/weaveworks/eksctl/issues/1070.
But the main concern is not being able to apply remotely due to an external dependency. What can I do to mitigate this?
I am using Terraform 0.14.4 with Terraform Cloud.

I can no longer reproduce this, it was likely related to the aforementioned CDN outage.
Still, it's a concern that eksctl needs to be installed on each remote apply?

I can no longer reproduce this, it was likely related to the aforementioned CDN outage.
Still, it's a concern that eksctl needs to be installed on each remote apply?

@ebr Thanks for the update 🙏

Still, it's a concern that eksctl needs to be installed on each remote apply?

In Terraform Cloud, I believe so - Outside of it we can use e.g. regular CI cache to save/restore the .shoal directory created by the provider for storing eksctl binaries. There's no cache for local files on Terraform Cloud, right?

@ebr Thanks for the update 🙏

Still, it's a concern that eksctl needs to be installed on each remote apply?

In Terraform Cloud, I believe so - Outside of it we can use e.g. regular CI cache to save/restore the .shoal directory created by the provider for storing eksctl binaries. There's no cache for local files on Terraform Cloud, right?


Authentication inside GraphQL / Juniper

In Node.js GraphQL servers you simply give as context functions that handle the cookies/session to do the authentication, but in this template the authentication is being handled outside of GraphQL, how can I handle it all inside GraphQL? when I try to simply give the actix session stuff it just says it can't be shared between threads.

The GraphQL specification doesn’t tell you how to do authentication or authorization. It can be a bit confusing to developers who are new to GraphQL.  I don’t claim to have all the answers, so if you have a different idea or a different opinion, feel free to share that in the comments so we can all learn together!

Let the web server (e.g. express or nginx) take care of authentication or a micro service like auth server.
Handle authentication in GraphQL itself.

I am fan of SRP (single responsibility principle), GraphQL for the query, the endpoint for consuming the data and the authentication server for what you know ... Like major compagnies with Oauth ...
In my point I don't think it's a good choice to handle it into the graphql endpoints as it is a single endpoint...what you can do if you want to make the full endpoint private?

In the Node.js ecosystem there is good tooling around authorization inside the GraphQL schema itself, to give some examples:

graphql-shield
TypeGraphQL authorization

I don't have the experience in Rust to give some examples in how I could do it here, but it's specially convenient for the client side to use the same tooling used for the GraphQL schema (Apollo / Relay / urql /gqless, etc...) while doing the authentication process, simply using mutations, instead of hacking around extra logic just for the current_user / login / sign_up / logout.

And it raises another question, how can I expose some parts of the GraphQL Schema of this template to be open without authorization?


TODO: move project metadata from setup.py to pyproject.toml

Related answer: https://stackoverflow.com/a/75753567
In short: move most of the setup() parameters to the pyproject.toml according to the documentation, leave only cython related metadata in setup.py.

Implemented in #29


Support for right to left languages

Hello,
I am trying to write a blog post in Hebrew using fastpages (opening this issue here because to my understanding it uses nbdev to do the conversion to HTML). The Hebrew is displayed correctly in jupyter using
   "metadata": {
    "direction": "rtl"
   },

However, in the rendered HTML file the Hebrew is aligned to the left. Also some combination of Hebrew+English is displayed incorrecly.
Is there a way to add support for right to left languages such as Hebrew or Arabic?
Thanks

Can you try wrapping https://github.com/fastai/nbdev/blob/master/docs/_layouts/page.html#L52 like this
<div dir="rtl">
{{content}}
</div>

found on stack overflow.  If you test it out and it works for you, perhaps we can discuss the best way to include the option in nbdev (likely with a _config parameter).
cc:/ @jph00

Thank you @hamelsmu !
Yes, this does the trick and now all the text is aligned to the right. Unfortunately this also applies to the code cells :disappointed: which I would like to remain aligned to the left.
Adiel

@jph00 should we put this on the v2 roadmap?

@hamelsmu yes!

Should be fixed in v2


fix(cd): Use GH_TOKEN instead of FABRIC8CD_GH_TOKEN for CICO

@jarifibrahim Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2556 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2556 and visit http://localhost:5000 to access it.


[FarmBeats] Use x-ms-parameterized-host

Use the x-ms-parameterized-host pattern, which our code generators
understand and generate better code for.

Per a in person discussion with @iscai-msft, submitting this on her behalf.  Having this in the swagger is also helpful for the C# and Java SDKs.

Hey I think we want to merge to this branch:
https://github.com/Azure/azure-rest-api-specs/tree/dev-agfood-Microsoft.AgFoodPlatform-2021-03-31-preview

Hey I changed the target branch to the one that we wanna merge, looks like you'll need to rebase your commit onto the new target branch.


Don't start the push updater if the Apple TV is 'off'

Ensures that Apple TVs that are 'off' (using the fake on/off support in https://github.com/home-assistant/home-assistant/pull/5962) aren't woken up at startup when the poller starts.
/cc @postlund https://github.com/home-assistant/home-assistant/pull/6323

Hi @jnewland,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

Yes :+1: This should be included in the next minor release i.e. 0.40.1.

Cherry-picked for 0.40.1


feat(staking): add skeleton to grid card

Checklist

[x] JIRA - https://input-output.atlassian.net/browse/LW-9271<link>
[x] Proper tests implemented
[x] Screenshots added.

Proposed solution
Staking Pools Grid Skeleton added
Testing
Use storybook
Screenshots

coverage: 52.444%. remained the same
when pulling 5de7a5554d852383aefbd018e7e463cfdd51efd6 on feature/LW-9271-staking-grid-skeleton
into 7e570b919a8ac328f983c179bebbdb1f046886e8 on main.


Xibo Cloud Germany/Frankfurt - Reduced Performance

Planned: We will be carrying out some routine maintenance on our Germany region at this time. No downtime is expected, but there may be a reduction in performance for the duration.


Suggestion: Configurable Level Names

I could have sworn this was already in the mod, but I can't seem to find it in the configs.
It would be nice to be able to change the text on tools that displays their current level "Clumsy, Legendary, etc."
For example, if I wanted to add a tier called "Crude" before the others, or rename "Comfortable" to "Groovy."

They're configurable through resource packs.


Fix polyfilling with sideEffectFree option and add regression test

Side effect free require pruning was added to webpack so the existing CommonJS workaround stopped working.
This PR adds a regression test to prevent future breakages

!merge


[#155894002] Allow to create Redis clusters with cluster mode enabled

What
We want to introduce unclustered plans as some client libraries used by the
tenants are not compatible with clustered setups.
We will allow to set the "cluster-enabled" parameter and the automatic_failover_enabled parameter for the Redis plans.
Redis Multi-AZ with Automatic Failover is supported on T2 node types only if
you are running Redis version 3.2.4 or later with cluster mode enabled. [1]
Multi-AZ with Automatic Failover is required on all Redis (cluster mode
enabled) clusters, whether or not they have read replicas. Clusters without
read replicas do not provide high availability or fault tolerence. [1]
For Redis (cluster mode disabled) clusters, backup and restore are not
supported on cache.t1.micro or cache.t2.* nodes. All other cache node types are
supported. [2]
[1] https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/AutoFailover.html
[2] https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/backups.html#backups-constraints
How to review
Review as part of https://github.com/alphagov/paas-cf/pull/1282
Who can review it
Not me.

@dcarley

I can add a test case for the LastOperationState status message to check for the backup window (I see this was not tested specifically previously)
I'm not sure we should create an unclustered Redis cluster during the integration tests as it takes forever (we are already at 30 minutes, this would be doubled). It's only a parameter difference which is handled by the unit tests
I definitely wouldn't test for the CROSSLOT issue as that would test the AWS Redis service itself and not the broker.

@dcarley see last commit for the extra test cases for LastOperation

@dcarley see last commit for the extra test cases for LastOperation

Thanks!

I'm not sure we should create an unclustered Redis cluster during the integration tests as it takes forever (we are already at 30 minutes, this would be doubled). It's only a parameter difference at creation which is handled by the unit tests

We could parallelise it, but I don't feel that strongly.

I definitely wouldn't test for the CROSSLOT issue as that would test the AWS Redis service itself and not the broker.

We already do, by connecting to it with a Redis library, but I think this might be harder to reproduce and again I don't feel strongly about it.
Will merge after the tests have passed 👍


Allow Partitioned tables to be created without a primary key

There are some scenarios where partitioned tables are created without ids(for example, accessory tables
This patch allows tables to be created without a primary key(using rails migration id: false)

Is there anything I am missing to get this PR approved and merged?

CI failing on Rails 5.2

Looks like the issue is a regression unrelated to this PR, similar issue hit with other PR


[libpq]  libpq has a pthread-win32.cpp that conflicts with pthread library on windows

Describe the bug
libpq optionally comes with its own static-implementations of pthread* apis
src\interfaces\libpq\pthread-win32.c (src\interfaces\libpq\Makefile)
that conflicts with libraries that are using pthread port.
This is a problem when linking libpq along with anything else that uses the pthread vcpkg port for pthread functions, using the static windows ports (windows-static )
A clear and concise description of what the bug is.
Environment

OS: Windows
Compiler: All

To Reproduce
Reproducing the issue will require setting up a project that links libpq:x64-windows-static (or gdal, osg, osgearth) along with any other port that uses pthreads:x64-windows-static ports.
I believe the fix is to not rely on pthread-win32.c but use pthread port in libpq for pthread* apis.
A good way to test the fix would be to eliminate the pthread-win32.c from libpq port and have the osgearth port compile.
The osgearth port has tool-exe that will fail to link if there are undefined references.
Expected behavior
libpq should use pthread vcpkg port for linking
Failure logs
-(please attached failure logs)
Additional context
Add any other context about the problem here.

Since the upstream doesn't provide a method to use the external pthreads, I think we can only avoid to install both libpq[pthread] and pthreads?

I think the trick is to mangle the pthread symbols on windows. The pthread-win32 looks more like a mockup than a real pthread implementation.

I'm pretty sure, omitting pthread-win32 from libpq and linking with the pthread port should work.
I can't think of a valid reason why upstream won't accept such a change

@ankurverma85  Can you please report this to the upstream first?


Draft: Updated Webhook types

Added missing fields in DeploymentEvent.
Since GitLab doesn't send time data in RFC3339 format, currently, it is being unmarshalled as a string, I have added customTime as https://github.com/go-playground/webhooks/blob/master/gitlab/payload.go#L12 is doing.
For now only updated DeploymentEvent, planning to update other events as well soon.

@svanharmelen What are your thoughts on changing the fields with time data, from string to customTime type?

Hmm... We already have ISOTime as a custom time value, I'm not sure if I want to add more custom time objects.
Yet I do like your idea to try and parse multiple different formats, but that will only help parsing from the string to time.Time, not the other way around (for queries that take a time).
It's indeed a shame the GitLab API doesn't use a consistent time format, yet until now we seemed to be able to get away with just ISOTime and time.Time.
Guess I want to think about it a little and have a closer look when back behind a desk again (I'm away for a few days).

OK, I just noticed I commented on a specific commit instead of the whole PR and that the PR is still labelled as Draft 😊 So you should probably take my comments with a grain of salt...
I'll check again when the Draft label is removed and please also note that you can actually create a draft PR instead of just adding the text Draft as a label...

I thought ya'll had an alternative to time.Time that you were using, but I only saw time.Time in these structures. The name customTime is actually coming from other code that we're currently using. Is this something that we could consider adding to the ISOTime? Or could we perhaps add some additional functionality to ISOTime or customTime to track what format was read, for re-marshaling later. (Though we'd have to have some sort of functionality to map it to 3339, as that's what our existing code is intended to do...)

@svanharmelen waiting for your response on this.

@smit-modi,
For your reference,
https://gitlab.com/gitlab-org/gitlab/-/issues/394785
https://gitlab.com/gitlab-org/gitlab/-/issues/19567
So we will need more than one formats to be handled, as I don't see any of the above ticket being resolved sooner or at all. They kept the same format as webhooks in graphql response for some reason when using time.RFC3339 is closest to being perfect format when used in UTC.

@smit-modi  we've migrated the repository over to GitLab.com.
Please see https://github.com/xanzy/go-gitlab/issues/2060#issuecomment-2532116371 for more context.