When performing grant_type=refresh_token, the "Authorization: Bearer..." header is applied

I'm not sure it makes sense to be authorizing with a probably-expired access token in the header, at the same time that in the body you are passing the client id+secret and requesting a new access token

Thank you for creating this issue, however, this project is deprecatedand we will only be addressing critical security issues. You can read moreabout this deprecation here.
If you need support or help using this library, we recommend that you ask yourquestion on StackOverflow.
If you still think this issue is relevant and should be addressed, pleasecomment and let us know!


Enable more analyzers in Istiod

13 of config analysers don't work using gcr.io/istio-testing latest.  It was 10 in 1.6.4.
I installed with values.global.istiod.enableAnalysis=true.  The istiod logs show
info	analysis	Skipping analyzer "annotations.K8sAnalyzer" because collection k8s/core/v1/namespaces is disabled.
info	analysis	Skipping analyzer "auth.AuthorizationPoliciesAnalyzer" because collection k8s/core/v1/namespaces is disabled.
info	analysis	Skipping analyzer "deployment.MultiServiceAnalyzer" because collection k8s/core/v1/services is disabled.
info	analysis	Skipping analyzer "deprecation.DeprecationAnalyzer" because collection k8s/apiextensions.k8s.io/v1/customresourcedefinitions is disabled.
info	analysis	Skipping analyzer "gateway.IngressGatewayPortAnalyzer" because collection k8s/core/v1/pods is disabled.
info	analysis	Skipping analyzer "gateway.SecretAnalyzer" because collection k8s/core/v1/pods is disabled.
info	analysis	Skipping analyzer "injection.Analyzer" because collection k8s/core/v1/namespaces is disabled.
info	analysis	Skipping analyzer "injection.ImageAnalyzer" because collection k8s/core/v1/namespaces is disabled.
info	analysis	Skipping analyzer "meshnetworks.MeshNetworksAnalyzer" because collection istio/mesh/v1alpha1/MeshNetworks is not in the snapshot(s).
info	analysis	Skipping analyzer "service.PortNameAnalyzer" because collection k8s/core/v1/services is disabled.
info	analysis	Skipping analyzer "sidecar.SelectorAnalyzer" because collection k8s/core/v1/pods is disabled.
info	analysis	Skipping analyzer "virtualservice.DestinationHostAnalyzer" because collection k8s/core/v1/services is disabled.
info	analysis	Skipping analyzer "schema.ValidationAnalyzer.MeshNetworks" because collection istio/mesh/v1alpha1/MeshNetworks is not in the snapshot(s).

cc @therealmitchconnors

Most of these look correct to me.  enableAnalysis writes its output to the status field, so any analyzers which report errors referring to kubernetes objects have nowhere to write to until the troubleshooting API is complete.  There are a few that seem like they might write status to Istio objects, but with K8s objects as inputs, and I don't think those should be disabled.
cc @jasonwzm

This looks suspicious that the collections are deemed disabled. I don't see those in local istioctl logs though.

istioctl and Istiod have different sets of collections they enable.  istioctl enables all of the ones needed for analysis (or it should if it doesn't.)
If Istiod lacks a collection needed for an analyzer that analyzer won't run and the only output is in the logs.  This only effects users who install with --set values.global.istiod.enableAnalysis=true.  Probably Istiod should watch additional collections if it is launched with the analysis flag turned on.

In addition to enabling the full set of analyzers, analysis should indicate that it ran and did not find a problem with the CRD.  Currently if no analyzer reported a problem there is no Status and no validationMessages:.  Probably there should be a success message or at least an empty list when a CRD is deemed correct by analysis.

I see... We can add the collections in the default snapshot to make it work. But eventually we will move away from the snapshot model.

Not stale.
I'd like to target 1.10 for this.  We can handle it with docs, adding a note to every error code page if that analyzer that produces it only works with istioctl.  Better would be to enable these analyzers, unless there are performance penalties.


Should not be able to create Execution Listeners for Link Events

Link Events do not support Execution Listeners, but you can currently set them in the modeler for Link Throw and Link Catch.

The process engine does not actually execute linkt throw events, so execution listeners for it are ignored (same for IO mappings, etc). It does execute link catch events, so execution listeners for those do work.

Explanation: instead of executing both link throw and catch event, the engine internally connects the sequence flow that targets the throw event directly to the catch event and does not actually wait for any event to occur when execution reaches the catch event. That is somewhat a hack that better fits the internal execution model than actually throwing and then catching an event. Since this is no problem in practice, we are very likely not going to change that behavior any time soon.

👍 makes sense. :)

So would you remove listener tab from Link Throw?


postgresql::server: Remove deprecated createdb_path parameter

It looks like $postgresql::params::createdb_path doesn't even exist? That's quite odd. A) my grep failed or b) the rspec-puppet tests don't use strict_variables=true.
Summary
Provide a detailed description of all the changes present in this pull request.
Additional Context
Add any additional context about the problem here.

[ ] Root cause and the steps to reproduce. (If applicable)
[ ] Thought process behind the implementation.

Related Issues (if any)
Mention any related issues or pull requests.
Checklist

[ ] 🟢 Spec tests.
[ ] 🟢 Acceptance tests.
[ ] Manually verified. (For example puppet apply)

It looks like $postgresql::params::createdb_path doesn't even exist? That's quite odd. A) my grep failed or b) the rspec-puppet tests don't use strict_variables=true.

postgresql::params inherits postgresql::globals :wink:


How to run a model training command in redhat linux slurm file?

Hello , I am trying to run a model training command  for object detection in cluster server. For this reason, I need to run a final command in a particular directory . As I am working on a cluster server, I am creating a slurm file. After the basic instructions, I  wrote the directory where the training command will be executed and now I am unable to connect the training command with the slurm file.

@Homayra22
We see that the issue template has not been filled, could you please do so as it helps us analyse the issue [tf version, steps followed before you ran into this error or stand alone code to reproduce the issue faced]
Please paste error logs its easy to search the issue.

Thanks, my problem is solved. I just used the full forms of all the slurm commands and delete " -l" from the first line. Also, I run the model training code without " srun python 3" command.

@Homayra22
Please move this issue to closed status as its resolved.


Fail pipeline on error by default (fixes #71)

Previously, a pipeline would fail if fail was set to true. In the beginning I wasn't sure if this should be the default, so this is an opt-in. Feedback from users showed that not failing the pipeline on broken links is somewhat unexpected (compare #71). Therefore I'd like to change this and make failing the default.
Since this a potentially breaking change, I consider releasing this as part of v2.0.0.
@dkarlovi fyi

From https://github.com/lycheeverse/lychee-action/issues/71#issuecomment-1022325442

the thought process was that lychee was used as a step within a bigger "linting" pipeline and we didn't want to fail the entire pipeline because of a broken link.

The workflow maintainer should use continue-on-error: true for lychee-action in this case. They can still check the status of lychee-action specifically with steps.lychee.outcome.
Neither exit_status output, nor fail input for lychee-action seem necessary for this action. The purpose they serve is already supported with official workflow syntax that applies for all steps generically.

Would like to see some strong arguments in favor of failing the pipeline

Steps can run only when a failure occurs, such as creating an issue report.
That does not require the pipeline/job to fail however. continue-on-error: true will allow lychee-action to always be "successful" (steps.lychee.conclusion), but steps that are interested can still know if the step actually failed (steps.lychee.outcome).

If you'd like to know more, I have gone into more detail (with references to official GH action docs) in a related PR discussion.

I think it would be better to drop both outputs.exit_status + inputs.fail for 2.0, and raise awareness via documentation of their equivalents:

steps.lychee.continue-on-error: true:

Don't fail a job early when the step fails (sets: steps.lychee.conclusion = 'success').
Step retains failure status (steps.lychee.outcome = 'failure').

steps.other-step.if: ${{ failure() && steps.lychee.outcome == 'failure' }}:

steps.other-step is only run when steps.lychee step fails.

I think it would be better to drop both outputs.exit_status + inputs.fail for 2.0, and raise awareness via documentation of their equivalents.

I see your point, but I'm not fully convinced. While the methods you've described are correct, they may not be straightforward for everyone. Not all users might take the time to read through the documentation to find that specific note. Having a clear argument in lychee-action makes it easier to find and use.
Also, we already have a fail parameter, which makes it easy to adjust. Users can just set fail: false if the update causes any problems. We'll make sure to point this out in the release notes.
I think it's important to go ahead with this update, since it has been pending for a while. Let's make this small improvement now. We can always come back to this topic in version 3, making any adjustments easier then.


Extension activation failed unable to get local issuer certificate

VS Code Version:Version: 1.79.0-insider (system setup)
Commit: f6be5461f8bc69013a605f5baea834651c6589fb
Date: 2023-05-20T01:18:53.811Z
Electron: 22.5.2
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19042

OS Version: Windows_NT x64 10.0.19042
Logs: (Don't find any logs generated for this extension)

Steps to Reproduce:

Using ZScaler Internet Security
Install Copilot extension (nightly)
Restart VS Code
Receive error message:

[ERROR] [default] [2023-05-25T13:37:15.617Z] GitHub Copilot could not connect to server. Extension activation failed: "unable to get local issuer certificate"

Should be fixed by now

Same issue.  What was fixed?


make mark/sweep prepare async with main thread

Fixed Issue(s)
fixes #917

@mbaxter I think you were the one who put the ExecutorService behind a supplier. Do you remember your rationale for that? I inlined it in this change so that we could run the start code on the executor itself.

@mbaxter I think you were the one who put the ExecutorService behind a supplier. Do you remember your rationale for that?

Yeah - I think the point of Supplier was to prevent the Pruner from spinning up resources before start is called.  Otherwise, if you setup a single-threaded executor in the constructor, but never actually start the Pruner, the executor will never get shutdown because the stop method won't run.


about 2-view results on Sintel test

Hi, I notice that your method used warm-start for evaluation on Sintel website. We want to compare our method with others on 2-view setting, so can you provide the 2-view results of MatchFlow on Sintel test? Thanks!

Sorry, we did not have the 2-view results of MatchFlow on Sintel test set due to upload limit. But you can compare the 2-views results with ours on C+T.

您好，您的邮件我已经收到了，谢谢


Automatic Update of README.md

This is an auto-generated PR which updates the README.md from the README.yaml
using the cloudposse/build-harness.

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


Chop off the 'v' from the tag name

Codecov Report

Merging #209 into master will decrease coverage by 0.16%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #209      +/-   ##
============================================
- Coverage     80.59%   80.43%   -0.17%
+ Complexity      478      476       -2
============================================
  Files            79       79
  Lines          1855     1855
  Branches        218      218
============================================
- Hits           1495     1492       -3
- Misses          272      273       +1
- Partials         88       90       +2

Impacted Files
Coverage Δ
Complexity Δ

...jaeger/reporters/protocols/ThriftUdpTransport.java
77.96% <0%> (-5.09%)
14% <0%> (-2%)

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 2550512...554b024. Read the comment docs.


long_description_content_type missing. defaulting to text/x-rst.

It isn't missing; checked some existing Issues, haven't found a fix. Details below; anything unique or did I miss a solution?

Win OS, Anaconda Powershell Prompt, conda virtual env. README.md, setup.py
(viz) PS C:\see-rnn> python setup.py sdist bdist_wheel

Build logs
running sdist
running egg_info
writing see_rnn.egg-info\PKG-INFO
writing dependency_links to see_rnn.egg-info\dependency_links.txt
writing requirements to see_rnn.egg-info\requires.txt
writing top-level names to see_rnn.egg-info\top_level.txt
reading manifest file 'see_rnn.egg-info\SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'see_rnn.egg-info\SOURCES.txt'
running check
creating see-rnn-1.1
creating see-rnn-1.1\see_rnn
creating see-rnn-1.1\see_rnn.egg-info
copying files to see-rnn-1.1...
copying LICENSE -> see-rnn-1.1
copying MANIFEST.in -> see-rnn-1.1
copying README.md -> see-rnn-1.1
copying requirements.txt -> see-rnn-1.1
copying setup.py -> see-rnn-1.1
copying see_rnn\__init__.py -> see-rnn-1.1\see_rnn
copying see_rnn\inspect_gen.py -> see-rnn-1.1\see_rnn
copying see_rnn\inspect_rnn.py -> see-rnn-1.1\see_rnn
copying see_rnn\utils.py -> see-rnn-1.1\see_rnn
copying see_rnn\visuals_gen.py -> see-rnn-1.1\see_rnn
copying see_rnn\visuals_rnn.py -> see-rnn-1.1\see_rnn
copying see_rnn.egg-info\PKG-INFO -> see-rnn-1.1\see_rnn.egg-info
copying see_rnn.egg-info\SOURCES.txt -> see-rnn-1.1\see_rnn.egg-info
copying see_rnn.egg-info\dependency_links.txt -> see-rnn-1.1\see_rnn.egg-info
copying see_rnn.egg-info\requires.txt -> see-rnn-1.1\see_rnn.egg-info
copying see_rnn.egg-info\top_level.txt -> see-rnn-1.1\see_rnn.egg-info
copying see_rnn.egg-info\zip-safe -> see-rnn-1.1\see_rnn.egg-info
Writing see-rnn-1.1\setup.cfg
creating dist
Creating tar archive
removing 'see-rnn-1.1' (and everything under it)
running bdist_wheel
running build
running build_py
installing to build\bdist.win-amd64\wheel
running install
running install_lib
creating build\bdist.win-amd64\wheel
creating build\bdist.win-amd64\wheel\see_rnn
copying build\lib\see_rnn\inspect_gen.py -> build\bdist.win-amd64\wheel\.\see_rnn
copying build\lib\see_rnn\inspect_rnn.py -> build\bdist.win-amd64\wheel\.\see_rnn
copying build\lib\see_rnn\utils.py -> build\bdist.win-amd64\wheel\.\see_rnn
copying build\lib\see_rnn\visuals_gen.py -> build\bdist.win-amd64\wheel\.\see_rnn
copying build\lib\see_rnn\visuals_rnn.py -> build\bdist.win-amd64\wheel\.\see_rnn
copying build\lib\see_rnn\__init__.py -> build\bdist.win-amd64\wheel\.\see_rnn
running install_egg_info
Copying see_rnn.egg-info to build\bdist.win-amd64\wheel\.\see_rnn-1.1-py3.7.egg-info
running install_scripts
adding license file "LICENSE" (matched pattern "LICEN[CS]E*")
creating build\bdist.win-amd64\wheel\see_rnn-1.1.dist-info\WHEEL
creating 'dist\see_rnn-1.1-py3-none-any.whl' and adding 'build\bdist.win-amd64\wheel' to it
adding 'see_rnn/__init__.py'
adding 'see_rnn/inspect_gen.py'
adding 'see_rnn/inspect_rnn.py'
adding 'see_rnn/utils.py'
adding 'see_rnn/visuals_gen.py'
adding 'see_rnn/visuals_rnn.py'
adding 'see_rnn-1.1.dist-info/LICENSE'
adding 'see_rnn-1.1.dist-info/METADATA'
adding 'see_rnn-1.1.dist-info/WHEEL'
adding 'see_rnn-1.1.dist-info/top_level.txt'
adding 'see_rnn-1.1.dist-info/zip-safe'
adding 'see_rnn-1.1.dist-info/RECORD'
removing build\bdist.win-amd64\wheel

(viz) PS C:\see-rnn> twine check dist/*
Checking dist\see_rnn-1.1-py3-none-any.whl: PASSED, with warnings
  warning: `long_description_content_type` missing.  defaulting to `text/x-rst`.
Checking dist\see-rnn-1.1.tar.gz: FAILED
  `long_description` has syntax errors in markup and would not be rendered on PyPI.
    line 99: Warning: Inline literal start-string without end-string.
  warning: `long_description_content_type` missing.  defaulting to `text/x-rst`.

setup(...
    long_description=read_file('README.md'),
    long_description_content_type='text/markdown', ...)

wheel                     0.34.2                     py_1    conda-forge
twine                     3.1.1                    py37_0    conda-forge
setuptools                46.1.3           py37hc8dfbb8_0    conda-forge

I was able to make source and built distributions of the current master branch of your package that passed twine check. It seems like the issue is likely that the versions of wheel/twine/setuptools available to your build command are not the same as what you're reporting here.
Can you give us some details about how exactly you're building the distributions? Are you running python setup.py sdist bdist_wheel? If so, what's the output of python -m pip freeze? If you run python -m pip install -U setuptools twine wheel, can you make distributions that pass twine check?

@di I build with the first code blob in the question, having first cd'd into a local copy of see-rnn. python -m pip freeze --all shows (I presume only these are of interest):
wheel==0.34.2
twine==3.1.1
setuptools==46.1.3.post20200325

setuptools seems to be the only one to differ, installed via consta install -c conda-forge. Running python -m pip install -U setuptools twine wheel and then 'freeze' again, above output doesn't change. I then again ran python setup.py sdist bdist_wheel and then twine check dist/* - same results. How would I check if the build command uses different versions of these libs?

Additional info: tried to debug twine to see why it's not detecting long_description_content_type; breakpointing here (which is line 76 on my twine install), which proceeds to here (line 1429 locally), the output is as follows:
>> fp
<zipfile.ZipExtFile name='see_rnn-1.1.dist-info/METADATA' mode='r' compress_type=deflate>
>> print(fp.read().decode('utf-8'))
Metadata-Version: 2.1
Name: see-rnn
Version: 1.1
Summary: RNN weights, gradients, & activations visualization in Keras & TensorFlow
Home-page: https://github.com/OverLordGoldDragon/see-rnn
Author: OverLordGoldDragon
Author-email<EMAIL_ADDRESS>License: MIT
Requires-Dist: numpy
Requires-Dist: matplotlib
Requires-Dist: tensorflow

# See RNN

So it and many others are also missing, though unsure how to dig further. Debug main script is
import os
from twine import cli

os.chdir(r"C:\see-rnn")
cli.dispatch("check dist/*".split())

Relevant flow logic is as: twine/package.py (L61 local) -->pkginfo /distribution.py :: def extractMetadata(self): data = self.read() --> first "here" above -> second "here".

Also breakpointing setup in setup.py, and here (same line locally) attrs output is as expected:

`[print(k,v) for k,v in attrs.items()]`
name see-rnn
version 1.1
packages ['see_rnn']
url https://github.com/OverLordGoldDragon/see-rnn
license MIT
author OverLordGoldDragon
author_email<EMAIL_ADDRESS>description RNN weights, gradients, & activations visualization in Keras & TensorFlow
long_description # See RNN

RNN weights, gradients, & activations visualization in Keras & TensorFlow (LSTM, GRU, SimpleRNN, CuDNN, & all others)

Features

Weights, gradients, activations visualization
Kernel visuals: kernel, recurrent kernel, and bias shown explicitly
Gate visuals: gates in gated architectures (LSTM, GRU) shown explicitly
Channel visuals: cell units (feature extractors) shown explicitly
General visuals: methods also applicable to CNNs & others

Why use?
Introspection is a powerful tool for debugging, regularizing, and understanding neural networks; this repo's methods enable:

Monitoring weights & activations progression - how each changes epoch-to-epoch, iteration-to-iteration
Evaluating learning effectiveness - how well gradient backpropagates layer-to-layer, timestep-to-timestep
Assessing layer health - what percentage of neurons are "dead" or "exploding"

It enables answering questions such as:

Is my RNN learning long-term dependencies? >> Monitor gradients: if a non-zero gradient flows through every timestep, then every timestep contributes to learning - i.e., resultant gradients stem from accounting for every input timestep, so the entire sequence influences weight updates. Hence, an RNN no longer ignores portions of long sequences, and is forced to learn from them
Is my RNN learning independent representations? >> Monitor activations: if each channel's outputs are distinct and decorrelated, then the RNN extracts richly diverse features.
Why do I have validation loss spikes? >> Monitor all: val. spikes may stem from sharp changes in layer weights due to large gradients, which will visibly alter activation patterns; seeing the details can help inform a correction

For further info on potential uses, see this SO.
To-do
Will possibly implement:

[ ] Weight norm inspection (all layers); see here
[ ] Interpretability visuals (e.g. saliency maps, adversarial attacks)
[ ] Tools for better probing backprop of return_sequences=False

Examples
# for all examples
grads = get_layer_gradients(model, x, y, layer_idx=1)  # return_sequences=True
grads = get_layer_gradients(model, x, y, layer_idx=2)  # return_sequences=False
outs  = get_layer_outputs(model, x,      layer_idx=1)  # return_sequences=True
# all examples use timesteps=100
# NOTE: `title_mode` kwarg below was omitted for simplicity; for Gradient visuals, would set to 'grads'

EX 1: bi-LSTM, 32 units - activations, activation='relu'
show_features_1D(outs[:1], equate_axes=False)
show-features_1D(outs[:1], equate_axes=True, show_y_zero=True)

Each subplot is an independent RNN channel's output (return_sequences=True)
In this example, each channel/filter appears to extract complex independent features of varying bias, frequency, and probabilistic distribution
Note that equate_axes=False better pronounces features' shape, whereas =True allows for an even comparison - but may greatly 'shrink' waveforms to appear flatlined (not shown here)

EX 2: one sample, uni-LSTM, 6 units - gradients, return_sequences=True, trained for 20 iterations
show_features_1D(grads[:1], n_rows=2)

Note: gradients are to be read right-to-left, as they're computed (from last timestep to first)
Rightmost (latest) timesteps consistently have a higher gradient
Vanishing gradient: ~75% of leftmost timesteps have a zero gradient, indicating poor time dependency learning

EX 3: all (16) samples, uni-LSTM, 6 units -- return_sequences=True, trained for 20 iterations
show_features_1D(grads, n_rows=2)
show_features_2D(grads, n_rows=4, norm=(-.01, .01))

Each sample shown in a different color (but same color per sample across channels)
Some samples perform better than one shown above, but not by much
The heatmap plots channels (y-axis) vs. timesteps (x-axis); blue=-0.01, red=0.01, white=0 (gradient values)

EX 4: all (16) samples, uni-LSTM, 6 units -- return_sequences=True, trained for 200 iterations
show_features_1D(grads, n_rows=2)
show_features_2D(grads, n_rows=4, norm=(-.01, .01))

Both plots show the LSTM performing clearly better after 180 additional iterations
Gradient still vanishes for about half the timesteps
All LSTM units better capture time dependencies of one particular sample (blue curve, first plot) - which we can tell from the heatmap to be the first sample. We can plot that sample vs. other samples to try to understand the difference

EX 5: 2D vs. 1D, uni-LSTM: 256 units, return_sequences=True, trained for 200 iterations
show_features_1D(grads[0, :, :])
show_features_2D(grads[:, :, 0], norm=(-.0001, .0001))

2D is better suited for comparing many channels across few samples
1D is better suited for comparing many samples across a few channels

EX 6: bi-GRU, 256 units (512 total) -- return_sequences=True, trained for 400 iterations
show_features_2D(grads[0], norm=(-.0001, .0001), reflect_half=True)

Backward layer's gradients are flipped for consistency w.r.t. time axis
Plot reveals a lesser-known advantage of Bi-RNNs - information utility: the collective gradient covers about twice the data. However, this isn't free lunch: each layer is an independent feature extractor, so learning isn't really complemented
Lower norm for more units is expected, as approx. the same loss-derived gradient is being distributed across more parameters (hence the squared numeric average is less)

EX 7: 0D, all (16) samples, uni-LSTM, 6 units -- return_sequences=False, trained for 200 iterations
show_features_0D(grads)

return_sequences=False utilizes only the last timestep's gradient (which is still derived from all timesteps, unless using truncated BPTT), requiring a new approach
Plot color-codes each RNN unit consistently across samples for comparison (can use one color instead)
Evaluating gradient flow is less direct and more theoretically involved. One simple approach is to compare distributions at beginning vs. later in training: if the difference isn't significant, the RNN does poorly in learning long-term dependencies

EX 8: LSTM vs. GRU vs. SimpleRNN, unidir, 256 units -- return_sequences=True, trained for 250 iterations
show_features_2D(grads, n_rows=8, norm=(-.0001, .0001), show_xy_ticks=[0,0], title_mode=False)

Note: the comparison isn't very meaningful; each network thrives w/ different hyperparameters, whereas same ones were used for all. LSTM, for one, bears the most parameters per unit, drowning out SimpleRNN
In this setup, LSTM definitively stomps GRU and SimpleRNN

EX 9: uni-LSTM, 256 units, weights -- batch_shape = (16, 100, 20) (input)
rnn_histogram(model, 'lstm', equate_axes=False, show_bias=False)
rnn_histogram(model, 'lstm', equate_axes=True,  show_bias=False)
rnn_heatmap(model, 'lstm')

Top plot is a histogram subplot grid, showing weight distributions per kernel, and within each kernel, per gate
Second plot sets equate_axes=True for an even comparison across kernels and gates, improving quality of comparison, but potentially degrading visual appeal
Last plot is a heatmap of the same weights, with gate separations marked by vertical lines, and bias weights also included
Unlike histograms, the heatmap preserves channel/context information: input-to-hidden and hidden-to-hidden transforming matrices can be clearly distinguished
Note the large concentration of maximal values at the Forget gate; as trivia, in Keras (and usually), bias gates are all initialized to zeros, except the Forget bias, which is initialized to ones

EX 10: bi-CuDNNLSTM, 256 units, weights -- batch_shape = (16, 100, 16) (input)
rnn_histogram(model, 'bidir', equate_axes=2)
rnn_heatmap(model, 'bidir', norm=(-.8, .8))

Bidirectional is supported by both; biases included in this example for histograms
Note again the bias heatmaps; they no longer appear to reside in the same locality as in EX 1. Indeed, CuDNNLSTM (and CuDNNGRU) biases are defined and initialized differently - something that can't be inferred from histograms

EX 11: uni-CuDNNGRU, 64 units, weights gradients -- batch_shape = (16, 100, 16) (input)
rnn_heatmap(model, 'gru', mode='grads', input_data=x, labels=y, cmap=None, absolute_value=True)

We may wish to visualize gradient intensity, which can be done via absolute_value=True and a greyscale colormap
Gate separations are apparent even without explicit separating lines in this example:

New is the most active kernel gate (input-to-hidden), suggesting more error correction on permitting information flow
Reset is the least active recurrent gate (hidden-to-hidden), suggesting least error correction on memory-keeping

EX 12: NaN detection: LSTM, 512 units, weights -- batch_shape = (16, 100, 16) (input)

Both the heatmap and the histogram come with built-in NaN detection - kernel-, gate-, and direction-wise
Heatmap will print NaNs to console, whereas histogram will mark them directly on the plot
Both will set NaN values to zero before plotting; in example below, all related non-NaN weights were already zero

EX 13: Sparse Conv1D autoencoder weights -- w = layer.get_weights()[0]; w.shape == (16, 64, 128)
show_features_2D(w, n_rows=16, norm=(-.1, .1), tight=True, borderwidth=1, title_mode=title)
# title = "((Layer Channels vs. Kernels) vs. Weights) vs. Input Channels -- norm = (-0.1, 0.1)"

One of stacked Conv1D sparse autoencoder layers; network trained with Dropout(0.5, noise_shape=(batch_size, 1, channels)) (Spatial Dropout), encouraging sparse features which may benefit classification
Weights are seen to be 'sparse'; some are uniformly low, others uniformly large, others have bands of large weights among lows

Usage
QUICKSTART: run rnn_sandbox.py, which includes all major examples and allows easy exploration of various plot configs.
Note: if using tensorflow.keras imports, set import os; os.environ["TF_KERAS"]='1'. Minimal example below.
visuals_gen.py functions can also be used to visualize Conv1D activations, gradients, or any other meaningfully-compatible data formats. Likewise, inspect_gen.py also works for non-RNN layers.
import numpy as np
from keras.layers import Input, LSTM
from keras.models import Model
from keras.optimizers import Adam
from see_rnn import get_layer_gradients, show_features_1D, show_features_2D
from see_rnn import show_features_0D

def make_model(rnn_layer, batch_shape, units):
    ipt = Input(batch_shape=batch_shape)
    x   = rnn_layer(units, activation='tanh', return_sequences=True)(ipt)
    out = rnn_layer(units, activation='tanh', return_sequences=False)(x)
    model = Model(ipt, out)
    model.compile(Adam(4e-3), 'mse')
    return model

def make_data(batch_shape):
    return np.random.randn(*batch_shape), \
           np.random.uniform(-1, 1, (batch_shape[0], units))

def train_model(model, iterations, batch_shape):
    x, y = make_data(batch_shape)
    for i in range(iterations):
        model.train_on_batch(x, y)
        print(end='.')  # progbar
        if i % 40 == 0:
            x, y = make_data(batch_shape)

units = 6
batch_shape = (16, 100, 2*units)

model = make_model(LSTM, batch_shape, units)
train_model(model, 300, batch_shape)

x, y  = make_data(batch_shape)
grads_all  = get_layer_gradients(model, x, y, layer_idx=1)  # return_sequences=True
grads_last = get_layer_gradients(model, x, y, layer_idx=2)  # return_sequences=False

show_features_1D(grads_all, n_rows=2, show_xy_ticks=[1,1])
show_features_2D(grads_all, n_rows=8, show_xy_ticks=[1,1], norm=(-.01, .01))
show_features_0D(grads_last)

long_description_content_type text/markdown
keywords rnn tensorflow keras visualization deep-learning lstm gru
install_requires ['numpy', 'matplotlib', 'tensorflow']
include_package_data True
zip_safe True
tests_require ['pytest>=4.0', 'pytest-cov']
classifiers ['Programming Language :: Python :: 3.6', 'License :: MIT License', 'Operating System :: OS Independent', 'Intended Audience :: Developers', 'Intended Audience :: Education', 'Intended Audience :: Information Technology', 'Intended Audience :: Science/Research', 'Topic :: Utilities', 'Topic :: Scientific/Engineering', 'Topic :: Scientific/Engineering :: Artificial Intelligence', 'Topic :: Scientific/Engineering :: Information Analysis', 'Topic :: Software Development', 'Topic :: Software Development :: Libraries :: Python Modules']

With this and previous comment, it seems something goes awry at the build stage, not twine check

@OverLordGoldDragon Can you share the distributions you built that are failing the check by attaching them here?

Here's the issue:
$ file README.md
README.md: ASCII text, with very long lines, with CRLF line terminators

Those Windows-style line terminators are leaking into the metadata and causing it to be misformatted.
Can you try doing the following in your setup.py instead:
def read_file(*parts):
-    with codecs.open(os.path.join(current_path, *parts), 'r', 'utf8') as reader:
+    with open(os.path.join(current_path, *parts), encoding='utf-8') as reader:
        return reader.read()

@di So much trouble over something so simple (but subtle) - thank you. P.S., how did you color lines in your code blob?

@OverLordGoldDragon Github's fenced code blocks allow you to specify the syntax highlighter, which includes languages like python and other things like diff. Here's the "source" for that comment:
Here's the issue:

```
$ file README.md
README.md: ASCII text, with very long lines, with CRLF line terminators
```

Those Windows-style line terminators are leaking into the metadata and causing it to be misformatted.

```diff
def read_file(*parts):
-    with codecs.open(os.path.join(current_path, *parts), 'r', 'utf8') as reader:
+    with open(os.path.join(current_path, *parts), encoding='utf-8') as reader:
        return reader.read()
```

TIL that the syntax highlight portion called the "info string" is allowed to be separated by spaces:
``` console
$ file README.md
README.md: ASCII text, with very long lines, with CRLF line terminators
```

github has a very long list of available syntax highlighters.

Here's the issue:
$ file README.md
README.md: ASCII text, with very long lines, with CRLF line terminators

Those Windows-style line terminators are leaking into the metadata and causing it to be misformatted.
Can you try doing the following in your setup.py instead:
def read_file(*parts):
-    with codecs.open(os.path.join(current_path, *parts), 'r', 'utf8') as reader:
+    with open(os.path.join(current_path, *parts), encoding='utf-8') as reader:
        return reader.read()

Hi, there. I have the same exact problem with my package. The long_description_content_type  cannot be detected although it's clearly stated in the setup.py file. Would you mind taking look at my dist package?

@OverLordGoldDragon Can you share the distributions you built that are failing the check by attaching them here?

Hi, there. I have the same exact problem with my package. The long_description_content_type  cannot be detected although it's clearly stated in the setup.py file. Would you mind taking look at my dist package?

@ahmadfebrianto Sure, where can I see it?

@ahmadfebrianto Sure, where can I see it?

Here it is : moodle-kit

@ahmadfebrianto That distribution seems old, here's what I see in that setup.py:
from distutils.core import setup

setup(
    name='moodle-kit',
    packages=['moodle_kit'],
    version='0.1.3',
    license='GNU',
    description='A simple Python package with some functionalities to interact with moodle-based LMS.',
    author='Ahmad Febrianto',
<EMAIL_ADDRESS>    url='https://github.com/ahmadfebrianto/moodle-kit',
    download_url='https://github.com/ahmadfebrianto/moodle-kit/archive/v0.1.3.tar.gz',
    keywords=['moodle'],
    install_requires=[
        'requests',
    ],
    classifiers=[
        'Development Status :: 5 - Production/Stable',
        'Intended Audience :: Developers',
        'Topic :: Software Development :: Build Tools',
        'Programming Language :: Python :: 3.6',
    ],
)

I don't see a long_description or a long_description_content_type.
Looking at https://github.com/ahmadfebrianto/moodle-kit/blob/887ed5267ba7580cd204ec04f3d104e839ec2d07/setup.py#L1, I see that you're using from distutils.core import setup. I would recommend using from setuptools import setup instead, as distutils is unable to support the newer metadata that description_content_type requires.
In the future I'd also recommend using https://github.com/pypa/sampleproject as a template for best practices for structuring a Python package!

@ahmadfebrianto That distribution seems old, here's what I see in that setup.py:
from distutils.core import setup

setup(
    name='moodle-kit',
    packages=['moodle_kit'],
    version='0.1.3',
    license='GNU',
    description='A simple Python package with some functionalities to interact with moodle-based LMS.',
    author='Ahmad Febrianto',
<EMAIL_ADDRESS>    url='https://github.com/ahmadfebrianto/moodle-kit',
    download_url='https://github.com/ahmadfebrianto/moodle-kit/archive/v0.1.3.tar.gz',
    keywords=['moodle'],
    install_requires=[
        'requests',
    ],
    classifiers=[
        'Development Status :: 5 - Production/Stable',
        'Intended Audience :: Developers',
        'Topic :: Software Development :: Build Tools',
        'Programming Language :: Python :: 3.6',
    ],
)

I don't see a long_description or a long_description_content_type.
Looking at https://github.com/ahmadfebrianto/moodle-kit/blob/887ed5267ba7580cd204ec04f3d104e839ec2d07/setup.py#L1, I see that you're using from distutils.core import setup. I would recommend using from setuptools import setup instead, as distutils is unable to support the newer metadata that description_content_type requires.
In the future I'd also recommend using https://github.com/pypa/sampleproject as a template for best practices for structuring a Python package!

Problem solved. It turned out that distutils.core was the cause. After I used setup function from setuptools, the problem went away. Thank you

Use Pandoc and PyPandoc to convert your Markdown(md) files into RestructuredText(rst) before uploading them into PyPi. To accomplish this, add the following to your setup.py file:
pip install pypandoc
try:
   import pypandoc
   long_description = pypandoc.convert_file('README.md', 'rst')
except(IOError, ImportError):
   long_description = open('README.md').read()

setup(
name='blah',
version=find_version('blah.py'),
description='Short description',
long_description=long_description,
)


added walking configuration files for ergoCubGazeboV1

This PR allows for simulating the walking with the new ergoCub robot.
Related issue https://github.com/ami-iit/component_ergocub/issues/183

Hi @mebbaid, thank you! For the time being, I would avoid adding hand_retargeting and joint_retargeting config files since they are not tested.
If you agree I can remove them and merge the PR.
Thank you for the effort

Hi @mebbaid, thank you! For the time being, I would avoid adding hand_retargeting and joint_retargeting config files since they are not tested.
If you agree I can remove them and merge the PR.
Thank you for the effort

@GiulioRomualdi , for me it is fine, thanks you can go ahead


Play Custom Videos

Ik this is a bit out of scope but is there any way i can use this to switch the currently playing video to the video id of my choice?

okay i'll check it out and tell

hey thanks for go-chromecast, but how do i get the chromecast-uuid of the device?


Check hash and signature of cached providers

Description

Replaced terraform providers lock -platform=xxx_xxxx with terraform init.
Added hash and signature authentication.

Fixes #3047.

TODOs
Read the Gruntwork contribution guidelines.

[x] Update the docs.
[ ] Run the relevant tests successfully, including pre-commit checks.
[ ] Ensure any 3rd party code adheres with our license policy or delete this line if its not applicable.
[ ] Include release notes. If this PR is backward incompatible, include a migration guide.

Release Notes (draft)

Added[X] / Removed / Updated.
Check hash and signature of cached providers
Migration Guide

Do we have e2e tests for this?
That is, tests that (a) download valid providers and validate their checksums & signatures and (b) download intentionally invalid providers and ensure we show an error when the checksums or signatures don't match?

We have unit tests that cover 100% of this functionality. For e2e/integration tests we need to implement a test private registry server to simulate the invalid providers. It's quite time-consuming, but if necessary, I'll do it. Or maybe you can recommend a better approach?
Thank for the review!

I don't want to spend a ton of time on this, but I do want to build confidence the hashes and signatures are really checked. We can prob merge this PR as-is. That said, is there some compromise solution that you could add in a follow up PR in a few hours? Could you re-use your own code to run a mock registry on localhost? So you execute run-all, this runs TG, which in turn runs real TF processes that try to download providers, which triggers the TG provider cache, and instead of trying to download those providers from registry.terraform.io, it tries to download them from localhost:12345, which is a server where we can return either valid mock providers or mock providers with invalid signatures.

Very interesting idea! I'll think about it, I'm sure I'll come up with something. Thank you!


Adding stale config to handle stale issues following react-native as …

Overview
As I had discussed with @jgcmarins  at one time, it would be interesting to start using an IC, or something like that to deal with some parts of the project.
An interesting alternative was the pro-bot since it has a simple configuration and is used in several projects in the community, and is used by react-native as it can be seen here: https://github.com/facebook/react-native/blob/master/.github/stale.yml
Before opening this pr, I included some labels based on react-native like: stale, discussion, etc. I choose to set the pro-bot to watch issues, and leave PR opened.
Also, I need the help of someone on the core of react-native-community to approve the pro-bot app request.
Btw, i hope this help the project maintainers to focus on important features. :smiley:

@MateusAndrade - @kelset  wanted me to convey this to you with regards to the stale bot, carried over from Discord, the chat app react-native-community uses:
btw @MikeHardy I was speaking with some GitHub ppl the other day and they said that the
config for the stalebot can also leave in the global repo, and given that now it's installed at org
level, would you mind asking him to do a PR to it -> https://github.com/react-native-
community/.github so that by default we have some config that every repo can use as baseline?
:smiley:

He also mentioned:
ah ok, thanks for letting me know Mike! Do you have direct connection with him? Can you ask
him to send me a DM over on twitter so that I can invite him to the Discord?

Cheers!

👋 @MateusAndrade - thanks for tackling this!
As mentioned by Mike, I've heard that these configurations could be shared by having a PR similar to this in this repo -> https://github.com/react-native-community/.github
Would you mind creating one? So that we can discuss some baseline settings that can be shared by all repos in the org now that we have the bot everywhere :)
(also, I've added you on Linkedin so that I can send you the invite to the Discord XD )

@MateusAndrade - thanks for tackling this!
As mentioned by Mike, I've heard that these configurations could be shared by having a PR similar to this in this repo -> https://github.com/react-native-community/.github
Would you mind creating one? So that we can discuss some baseline settings that can be shared by all repos in the org now that we have the bot everywhere :)
(also, I've added you on Linkedin so that I can send you the invite to the Discord XD )

Thanks man! THis means a lot for me! :smile: :smile: :smile:
I can send a PR applying the stale this week. Also, there are some points that i think would be good to discuss on Discord. I will DM you on Twitter about the Discord link. =D


Implement transform feedback

Some ideas:

Add a TransformFeedbackSession struct which contains one or several &mut VertexBuffer.

Add TransformFeedbackSession::end(self) -> TransformFeedbackResult.

Add VertexBuffer::to_transform_feedback_session() which returns a TransformFeedbackSession.

Add a draw_primitives member to DrawParameters of type bool (will probably be implemented in a separate PR).

Add a primitives_output member to DrawParameters of type Option<&TransformFeedbackSession>.

Add TransformFeedbackProgramMismatch to DrawError that is triggered if you use the same session with multiple different programs.

Add TransformFeedbackFormatMismatch to DrawError if the vertex buffer doesn't have the right format.

Add draw_from_feedback to the Surface trait with takes a &TransformFeedbackResult instead of vertices and indices sources.

Add a method to Program to retreive the vertices format.

Warning: transform feedback objects aren't shared between contexts.


[Feature][Zeta] Client print event which received from jobmaster

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
Currently we support sending job running event to the EventHandler of Jobmaster. https://github.com/apache/seatunnel/blob/1bba72385b6797dc5edd96fa5951376d0594e633/seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/event/JobEventReportOperation.java#L50
We can resend job event to client side. In this way, the client can know the status and progress of the task, instead of having only delayed reading and writing information from job submission to job completion.
The client will be
EventType: ReaderOpen ...
EventType: WriterOpen ...
EventType: ReaderClose ...

Usage Scenario
No response
Related issues
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Can be assigned to me and I will complete it , thanks


Added MANIFEST.in

The current source dist at PyPI is broken:
python setup.py install --single-version-externally-managed --record record.txt
Traceback (most recent call last):
  File "setup.py", line 6, in <module>
    with open('AUTHORS.md') as f:
IOError: [Errno 2] No such file or directory: 'AUTHORS.md'

I just added a MANIFEST.in and hopefully that will fix it.  (Since that is mostly the AUTHORS.md fault I felt responsible :wink:)

Ha! Thanks, all a part of my plan. Should be good to go now.


add power-modulo operator to UIUC K

This is needed to execute the power-modulo operation in the modexp precompiled contract in the EVM semantics.

when we need it we can just represent it with a macro in the prelude that does power and modulo directly. but until we verify contracts that call precompiled contracts it won't be an issue.


[21.05] sway: 1.6 -> 1.6.1, wlroots: 0.13.0 -> 0.14.0

Motivation for this change
Backport PR for #128036, #127897 and #123519 (not so sure about the last one, I decided to update it as well to hopefully fix #127413 locally).
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Not sure if this is really a good idea. Maybe we should wait a bit to see if anyone on nixos-unstable experiences any regressions with wlroots 0.14? I also thought you wanted to test this for ~10 days first (https://github.com/NixOS/nixpkgs/issues/127413#issuecomment-869134761) - or was that just for that issue and not the backport? Additionally I though we intended to backport the wlroots update as wlroots_0_14 (https://github.com/NixOS/nixpkgs/pull/128036#issuecomment-868341743) or are you against that idea?
The libdrm update is also a bit scary (lots of rebuilds) but at least I've never heard of any libdrm regressions since I started maintaining it a few releases ago or so.
Anyway, just some things to consider, this isn't a hard objection / veto.
PS: Ideally we should also state the reason: "4. When the reason to backport is not obvious from the original commit message, use git cherry-pick -xe  and add a reason."

I also thought you wanted to test this for ~10 days first (#127413 (comment)) - or was that just for that issue and not the backport? Additionally I though we intended to backport the wlroots update as wlroots_0_14 (#128036 (comment)) or are you against that idea?

Absolutely! Just thought I'd open it now to give other people on 21.05 the same opportunity. To make that clear, I decided to mark it as draft. (Note: I expected it to be a bit more work to backport this which is another reason why this branch exists :))

The libdrm update is also a bit scary (lots of rebuilds) but at least I've never heard of any libdrm regressions since I started maintaining it a few releases ago or so.

My thinking was kinda simple (and perhaps dumb) here: the crash I've seen happened in a communication between sway and libdrm, so updating it to the latest version was something I wanted to try out and it works fine for me.
But as I said in the original post, I'm not so sure if that's a good idea, so we can leave it out, of course.

I removed the libdrm-update since it hasn't solved my problem (I'm currently trying out various WLR_* settings). sway with a newer wlroots worked fine regardless.

The (more, but currently less frequent) crashes I see were already an issue on sway 1.6, apart from that I don't see any issues with sway 1.6.1/wlroots 0.14.0 on 21.05. Because of that I'm going to mark it as ready for review now.

Redundant comment.

Yeah, I really don't want to change commits during a backport though unless it's strictly needed.

https://octodon.social/@emersion/106544587943751964

Alright, I think I fixed all known wlroots 0.14.0 regressions. Some were pretty tricky. 0.14.1 coming soon!

Just as an FYI (not sure if it's worth it to wait for wlroots 0.14.1 before merging this or not).

@Ma27 if you're interested we could/should also backport #129667 (should be fine to go directly into staging-next-21.05 so that it lands together with this PR once #129778 is merged).


Incorrect link

Power BI “embedded” user dashboard experience - this link goes to an unrelated page.

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

ID: a33278f2-b63d-c61a-920e-7fe85c31dd71
Version Independent ID: f2f2f47f-6c2c-e49a-daeb-6608e2f47c3a
Content: Dynamics 365 US Government - Feature availability - Power Platform
Content Source: power-platform/admin/government-feature-availability.md
Service: power-platform
Sub-service: admin
GitHub Login: @jimholtz
Microsoft Alias: jimholtz

@anbhar
Thanks for the feedback. Taking this to internal email.


the application calls an interface that has been groomed for another thread. (0x8001010E (RPC_E_WRONG_THREAD))

I'm a developer who has just started using Winui3 and I ran into a tricky problem, I looked at the Microsoft documentation, but to solve my problem: the application calls an interface that has been groomed for another thread. (0x8001010E (RPC_E_WRONG_THREAD))
### Tasks

That pretty classically sounds like you're trying to interact with a UI element (a Button, a TextBox, anything really) on a background thread. XAML won't let you do that - any modification of any UI objects needs to be done on the UI thread.
The sample code you're using might be helpful for understanding the issue.
(this should probably also just get moved to a discussion)


[Main] Moved Actions.

Moved the identified extensions that should be actions out, and into rancher/rancher.

Met with Israel and here are the rules to further help distinguish between actions v. Extensions. Please use this for reference when reviewing:
The following qualify a function to be an extension:

Must be either an api call not natively captured by the client OR specific CRUD / wait on resource

i.e. download ssh keys
tokens package
should not only directly convert -> this would make it an action

Disqualifiers for extensions (If any one or more are true, function is an action):

if there's a custom config needed, in any part
if it is a validation of any sort (Waits are okay)
if function is a direct conversion of a resource

more on this, if the function is purely just calling a native call + catching the error, this should not be an extension. A conversion would be more complex; see an example like token package

how re-usable is the code? Shepherd code should be highly re-usable

most comments are in the rancher/rancher PR since they are complementary of eachother. But I have some questions:

I think harden would be an action. It is dependent on the custom config for NodeRoles and ties very closely with that package. wdyt?
I think the kubeconfig package is too specific and don't see it being used much outside of very specific rancher areas; this could be an action, I think.

The harden functions that were clusters.go did get move. The harden package is a lot more generic and I think can stay. Is that what you meant?
I disagree about the kubeconfig package. Look at it closely these are kubernetes specific stuff. kubectl, I can see your point, I think this package should be refactored to use the command line kubectl possibly making it a client instead.

most comments are in the rancher/rancher PR since they are complementary of eachother. But I have some questions:

I think harden would be an action. It is dependent on the custom config for NodeRoles and ties very closely with that package. wdyt?
I think the kubeconfig package is too specific and don't see it being used much outside of very specific rancher areas; this could be an action, I think.

The harden functions that were clusters.go did get moved. The harden package is a lot more generic and I think can stay. Is that what you meant?
I disagree about the kubeconfig package. Look at it closely these are kubernetes specific stuff. kubectl, I can see your point, I think this package should be refactored to use the command line kubectl possibly making it a client instead. But in these are generic funcs to run kubectl on rancher downstream clusters.

I think the hardening functions are good candidates to be an extension but not in their current state. The parameters are customized to provisioning create functions and are strongly tied. Though what it does in the function is more like an extension, in my opinion, they're still actions
For kubeconfig, I agree they are extensions, they are generic Kubernetes utilities that could be used across repos.

most comments are in the rancher/rancher PR since they are complementary of eachother. But I have some questions:

I think harden would be an action. It is dependent on the custom config for NodeRoles and ties very closely with that package. wdyt?
I think the kubeconfig package is too specific and don't see it being used much outside of very specific rancher areas; this could be an action, I think.

The harden functions that were clusters.go did get moved. The harden package is a lot more generic and I think can stay. Is that what you meant?
I disagree about the kubeconfig package. Look at it closely these are kubernetes specific stuff. kubectl, I can see your point, I think this package should be refactored to use the command line kubectl possibly making it a client instead. But in these are generic funcs to run kubectl on rancher downstream clusters.

I think the hardening functions are good candidates to be extensions but not in their current state. The parameters are customized to provisioning create functions and are strongly tied. Though what it does in the function is more like an extension, in my opinion, they're still actions
For kubeconfig, I agree they are extensions, they are generic Kubernetes utilities that could be used across repos.

Ah i see both of your points. I'll move it. Thanks!

backports:

https://github.com/rancher/shepherd/pull/262
https://github.com/rancher/shepherd/pull/263
https://github.com/rancher/shepherd/pull/264


API errors should have error codes

This makes it easier to identify errors.

This has not been needed so far. Closing as wontfix.


Max teams increase

I believe the max entities for access teams (MaxEntitiesEnabledForAutoCreatedAccessTeams) was increased from 5 to 100 per this work item:
https://dynamicscrm.visualstudio.com/OneCRM/_workitems/edit/1058331
Due to performance considerations, maybe we are still suggesting to stay under 5 but we should update the documentation either way.
Thanks!

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

ID: 148f041b-a63f-470c-ec11-08a2ebd3bde1
Version Independent ID: 546ce331-8abc-4187-9bfa-6f4d4e03e62c
Content: Manage teams - Power Platform
Content Source: power-platform/admin/manage-teams.md
Service: power-platform
GitHub Login: @jimholtz
Microsoft Alias: jimholtz

Thanks for the info. The content has been updated.


Add setEncoding

So that an user can provide it's own encoding.
Check in the spec if it's possible ??

Nope

The event stream is a simple stream of text data, which must be encoded using UTF-8. Each message is separated by a pair of newline characters. A colon as the first character of a line is, in essence, a comment, and is ignored.


Keychain cleanups

Change names to be more grepable.
Keep environment out.
Quiet some logs.

@TheBitShepherd Do you remember this one?


Optimized cell storage, May be more efficient

https://github.com/QtExcel/QXlsx/blob/0333829478e2f2674ee89512fa6508235bdb3e35/QXlsx/header/xlsxworksheet_p.h#L178
Hi,
I noticed that the current implementation uses QHash<int, QHash<int, QSharedPointer<Cell>>.
How about replacing it with QMap<std::pair<int, int>, std::shared_ptr<Cell>>?

well, sadly if you read the comment abouve that line it's because of Qt5 we can't do this. Also QMap is definetly too slow for our use case.


Fix/windows compat

Checklist:

[ ] Documentation N/A
[ ] Tests N/A
[x] Ready to be merged

Deploy preview for govuk-react processing.
Building with commit c506941dfd47f3131ae4be944b2351c47186fc3b
https://app.netlify.com/sites/govuk-react/deploys/5c86720e448cbb0007c76cec

Codecov Report

Merging #594 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #594      +/-   ##
==========================================
- Coverage   99.65%   99.62%   -0.03%
==========================================
  Files          97       91       -6
  Lines         576      532      -44
  Branches       66       56      -10
==========================================
- Hits          574      530      -44
  Misses          2        2

Impacted Files
Coverage Δ

components/button/src/index.js
100% <0%> (ø)
:arrow_up:

components/page/src/index.js
100% <0%> (ø)
:arrow_up:

components/breadcrumb/src/index.js
100% <0%> (ø)
:arrow_up:

components/breadcrumb/src/atoms/link/index.js
100% <0%> (ø)
:arrow_up:

components/heading/src/index.js
100% <0%> (ø)
:arrow_up:

components/page/src/atoms/width-container.js
100% <0%> (ø)
:arrow_up:

components/fieldset/src/atoms/legend/index.js

components/breadcrumbs/src/index.js

components/fieldset/src/index.js

components/breadcrumbs/src/atoms/link/index.js

... and 2 more

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 c34ceef...c506941. Read the comment docs.

Codecov Report

Merging #594 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #594      +/-   ##
==========================================
- Coverage   99.65%   99.62%   -0.03%
==========================================
  Files          97       91       -6
  Lines         576      532      -44
  Branches       66       56      -10
==========================================
- Hits          574      530      -44
  Misses          2        2

Impacted Files
Coverage Δ

components/button/src/index.js
100% <0%> (ø)
:arrow_up:

components/page/src/index.js
100% <0%> (ø)
:arrow_up:

components/breadcrumb/src/index.js
100% <0%> (ø)
:arrow_up:

components/breadcrumb/src/atoms/link/index.js
100% <0%> (ø)
:arrow_up:

components/heading/src/index.js
100% <0%> (ø)
:arrow_up:

components/page/src/atoms/width-container.js
100% <0%> (ø)
:arrow_up:

components/fieldset/src/atoms/legend/index.js

components/breadcrumbs/src/index.js

components/fieldset/src/index.js

components/breadcrumbs/src/atoms/link/index.js

... and 2 more

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 c34ceef...c506941. Read the comment docs.


No response for H610Pro

I've used tablet_debug as current tablet on Ubuntu 18.04.2 LTS.
 Tablet itself responds to pen by green light. Kindly find output below
Output:
Finding USB device. . . Done!
Reading configuration. . . Done!
Preparing driver. . . Done!
--------------------------------------------------------------------------------
 c8 |        Params block #2: ??|?????
    |                          Max X: 50800
    |                          Max Y: 31750
    |                   Max pressure: 8191
    |                     Resolution: 5080
    |
 c9 |       Firmware version: HUION_T175_170520
 ca |  Internal manufacturer: HUION Animation Technology Co.,ltd
--------------------------------------------------------------------------------
Setting up driver. . . Done!
	Tablet model name         DEBUG TABLET
	Buttons                   disabled (0)
	Scrollbar                 disabled (0)
	Notifications:            ENABLED
		for buttons       ENABLED
		for scrollbar     disabled
	Screen                    disabled

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
			< DEBUG MODE ENABLED >
Enabled by default. You can disable it by setting debug_mode = false
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SYSTEM: Linux 4.15.0-47-generic (x86_64 x86_64)
#50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019

DEVICE: /dev/input/event10 (py-evdev-uinput)
bus: 0003, vendor 0001, product 0001, version 0003

      ENDPOINT 0x81: Interrupt IN ==========================
       bLength          :    0x7 (7 bytes)
       bDescriptorType  :    0x5 Endpoint
       bEndpointAddress :   0x81 IN
       bmAttributes     :    0x3 Interrupt
       wMaxPacketSize   :   0x10 (16 bytes)
       bInterval        :    0x2

TABLET CAPABILITIES:
[('SYN_REPORT', 0), ('SYN_CONFIG', 1), ('SYN_DROPPED', 3)]
[(['BTN_DIGI', 'BTN_TOOL_PEN'], 320), ('BTN_TOUCH', 330), ('BTN_STYLUS', 331), ('BTN_STYLUS2', 332)]
[(('ABS_X', 0), AbsInfo(value=0, min=0, max=0, fuzz=0, flat=0, resolution=0)), (('ABS_Y', 1), AbsInfo(value=0, min=0, max=0, fuzz=0, flat=0, resolution=0)), (('ABS_PRESSURE', 24), AbsInfo(value=0, min=0, max=0, fuzz=0, flat=0, resolution=0)), (('ABS_TILT_X', 26), AbsInfo(value=0, min=0, max=255, fuzz=0, flat=0, resolution=0)), (('ABS_TILT_Y', 27), AbsInfo(value=0, min=0, max=255, fuzz=0, flat=0, resolution=0))]
VPEN:
name "Tablet Monitor Pen 110558", bus "BUS_USB", vendor "0001", product "0001", version "0003", phys "py-evdev-uinput"
event types: EV_SYN EV_KEY EV_ABS

Huion Kamvas driver should now be running. . .

(Input from the tablet will ONLY be used to print it out)

Please slowly and briefly touch the LEFT UP corner of your tablet:

Hi @MichaelKapustey I've formatted the code in your comment for legibility.
Ok. Let's check first a simple test.
I've created a very simple script that should work in any system: test-evdev.py
If you run it, it should print the letter 'a' to the console, move the mouse cursor to the top left corner (100x100px) and open the right button menu.
You can execute it like this if you prefer:
wget https://gist.githubusercontent.com/joseluis/ace22ea89d22970d17519cd10508d1bb/raw/c154c9eda7901c2599314083c07ba6d5dbe43a73/test-evdev.py -O test-evdev.py
chmod +x test-evdev.py
sudo ./test-evdev.py

Let me know if it works and we work from there.
Also, the digimend kernel drivers repo, could also be an option for the tablet H610pro


upgrade vendor/golang.org/x/net to fix CVE-2021-33194

x/net obtained from:
https://github.com/golang/net/commit/37e1c6afe02340126705deced573a85ab75209d7

Refer to this link for build results (access rights to CI server needed):
https://edge-jenkins.isgtesting.com/job/test_team-build-edge_kubelet/115/
The build failed!!!


Chakra v2 & React 18

Hello,
This package doesn't work with Chakra v2 or React 18... Is there a temparary fix that I can use while we wait for an update?

What seems to be the problem, @AshMW2724? I tried running it with all the latest version in the CodeSandbox and it looks like it's working.

This is the issue im running into... I have been trying to upgrade a project the React 18 (and Chakra UI v2)

Ah, got it! Thanks for reporting, @AshMW2724! This is the line that causes the issue: https://github.com/nikolovlazar/chakra-ui-prose/blob/main/packages/chakra-ui-prose/package.json#L35
If you'd like to contribute, you can open a PR that updates the version from ^1.8.6 to >=1.8.6. That would include v2 as well, and it should make it work for all versions above 1.8.6.

Will do!

@AshMW2724 published! Can you try updating the package to 1.1.0 in your project and see if the issue persists?


rectangle

possible to support drawing rectangle ?

I've added a section "How it works!" in readme.md file.
You can do anything you want, putting a javascript function inside the page built by the component and then call it by ExecuteJavascript method. Please read the explanation inside Readme.

I mean can it support Poligon ? any sample javascript available?

No, I don't know what can you do, and I'm not a javascript expert... You can integrate in the component any Javascript function you can write inside the WEB page that can interactive with del Google Map Object, Look at the Google Maps API to extend this component, as I made for the existing functions of my component. Search for javascript examples in the web.


operator opentelemetry-operator (0.62.1)

Signed-off-by: Benedikt Bongartz<EMAIL_ADDRESS>Thanks for submitting your Operator. Please check the below list before you create your Pull Request.
New Submissions

[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?

[ ] Have you tested your Operator in all supported installation modes?
[ ] Have you considered whether you want to use semantic versioning order?
[ ] Is your submission signed?
[ ] Is operator icon set?

Updates to existing Operators

[ ] Did you create a ci.yaml file according to the update instructions?
[ ] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[ ] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[ ] Is your submission signed?

Your submission should not

[ ] Modify more than one operator
[ ] Modify an Operator you don't own
[ ] Rename an operator - please remove and add with a different name instead
[ ] Modify any files outside the above mentioned folders
[ ] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description of the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/merge possible

/merge possible

@frzifus
Value of 'metadata.annotations.containerImage' not used in any container, please check.
The operator is using some image which must have exactly the same value as 'metadata.annotations.containerImage'.
Please check both values and make them the same.

/merge possible

@frzifus any update?

mh.. let me have a look.

i wonder if all images come without a tag.
0.56.0/manifests/opentelemetry-operator.clusterserviceversion.yaml:    containerImage: ghcr.io/open-telemetry/opentelemetry-operator/opentelemetry-operator
0.58.0/manifests/opentelemetry-operator.clusterserviceversion.yaml:    containerImage: ghcr.io/open-telemetry/opentelemetry-operator/opentelemetry-operator
0.59.0/manifests/opentelemetry-operator.clusterserviceversion.yaml:    containerImage: ghcr.io/open-telemetry/opentelemetry-operator/opentelemetry-operator
0.61.0/manifests/opentelemetry-operator.clusterserviceversion.yaml:    containerImage: ghcr.io/open-telemetry/opentelemetry-operator/opentelemetry-operator
0.62.1/manifests/opentelemetry-operator.clusterserviceversion.yaml:    containerImage: ghcr.io/open-telemetry/opentelemetry-operator/opentelemetry-operator:v0.62.1

/retest

/merge possible

@J0zi could you please help me to interpret the ci output?

/test all

/retest-required

/merge possible


Flashes white on start and on reopening after minimizing

Whole screen flashes white for a fraction of a second before showing the dark theme. Is there a way to make the app start in dark before the UI loads? Otherwise, it defeats the purpose of having a dark theme, as eyes are already blind.
Also, can the menu bar be black as well? Just like how the native menu bar looks like in dark mode.

Sorry for the late reply.

Whole screen flashes white for a fraction of a second before showing the dark theme. Is there a way to make the app start in dark before the UI loads? Otherwise, it defeats the purpose of having a dark theme, as eyes are already blind.

Can you provide a screencast? This is when I open the qbittorrent by systemtray or even starting it before it's minimized, It never flashes white and the app is always dark themed.
The theme on my system:
https://user-images.githubusercontent.com/63877463/160238034-7124ab46-4e16-4c1b-b2b5-355fe6b5a228.mp4

Also, can the menu bar be black as well? Just like how the native menu bar looks like in dark mode.

The menus are also themed dark, Here are some screenshots:

I think this might be Windows qBittorrent version issue since I observer the same problem with app window. It blinks white for ~1 frame.
https://user-images.githubusercontent.com/4563325/160456747-169b044a-36d5-48b5-8355-6e42d6eb609c.mp4

https://user-images.githubusercontent.com/4563325/160457489-0914d52d-e39e-468a-b912-ce9594840f26.mp4
This is likely specific to Windows version qBittorrent and doesn't seem like a theme issue, but rather application issue.

qbittorrent_TZpWzOlQaB.mp4
This is likely specific to Windows version of qBittorrent and doesn't seem like a theme issue, but rather application itself.

Thank you @lainverse for clearing the issue, Maybe this might be fixed with the dark theme on windows?
As you mentioned it's not a theme issue, but OP might have something else on mind and this issue will be open for a quite some time until they close it or respond.
Thank you for your interest in this theme.
Best regards, Mahdi

Maybe this might be fixed with the dark theme on windows?

Unfortunately not. I've looked for dark theme for qB exactly because I'm using dark theme.

Alas.

I also have this issue

This problem on windows is exactly as I stated. This problem exists because the app is non-native. It opens a white canvas and before the rendering engine is active.


Move away from vulnerable zlib dependency

According to https://github.com/oracle/graal/issues/4439#issuecomment-1086617119, zlib 1.2.11 suffers from https://nvd.nist.gov/vuln/detail/CVE-2018-25032. zlib 1.2.12, however, seems to have CRC errors (see https://github.com/madler/zlib/commit/ec3df00224d4b396e2ac6586ab5d25f673caa4c2).
Maybe we need to wait for the next zlib release? What do you suggest, @thiagokokada, @vcunat, and @gradinac?

Consider fixing the bad CRC usage?  The commit suggests that it's just a workaround for bugs in users of zlib.

@borkdude: I know you're not using GHA, but would @vcunat's suggestion work for you if you did?

@fniephaus It's not clear to me what you are asking: do what?

@borkdude would zlib 1.2.12 work for you? Are you upgrading your Circle CI config with it? It seems you'd need to fix your test?

@fniephaus I already tried 1.2.12 which caused the CRC problems, reported in this issue: https://github.com/oracle/graal/issues/4439


fix(types): PageData MetaData exactOptionalPropertyTypes compat

thanks for the amazing project
fixes #843

Thanks for contributing!


Added read variables functionality to SisViewEngine

Added read variables functionality to SisViewEngine and added Trim('\r','\n') of lines in GetCSharpCode() method

It's already done.


Railsconf punchlist

Leaving some notes in here from railsconf:

fasterer looks fun!
someone made a good point about too many build commands, instead of just rails test. might be worth rolling other linting type stuff like brakeman and bundle audit into rails test, so that everything runs in the context of that
we should set up sentry

should make sure that success/warning text has some other textual indication, since red/green colorblindness is a thing

Derailed benchmarks gem

cedar stack EOL, time to bump heroku instances

look at the actionview components talk

Salus gem

spun sentry into its own issue but the rest probably aren't worth it. declaring victory


Missing .prettierrc

There is quite some inconstancy of coding format styles within the codebase.
It would be nice to have .prettierrc file.
Sometimes there are semicolons, sometimes not.
According to your style, it should look something like this:
{
  "trailingComma": "es5",
  "singleQuote": true,
  "semi": false
}

No max-tab-width makes the code quite difficult to read.

Personally I would just go with deno fmt or any other opinionated formatter instead of specifying yet another format config.

Well, right now it's a mess, there are lint errors but they don't get fixed on save. If prettier is enabled it can really improve code readability and speed up the process. Adding another format config is really common, look at other projects.

I also think that there should be a formatter in this project as it simplifies working together on the same code.
I know its common to reinvent the wheel in other projects and I don't like that :P
And I think the JavaScript / TypeScript world is a huge mess because of a lot of different configs. Just reuse an existing style and work with it. Personally I use deno and xo, there is standard, prettier also has a default style, …. Just go with one existing style and use it.
As I am personally moving towards deno I would just use deno fmt. Denos LSP implementation also supports formatting so all Editors supporting LSP can autoformat on save out of the box - no extensions needed.
Note 1: VSCode invented LSP but still requires extensions for them, unlike modern editors that fully work with LSP.
Note 2: Tools like prettier that are not using an LSP / are not integrated well with a lot of editors are a bit more annoying to use.

Regarding the semicolons inconsistencies, it largely comes from my inexperience with TypeScript: I'm generally a semicolon minimalist, but thought those where required.
@EdJoPaTo what are the editors that fully work with LSP?

Regarding semicolons: in most cases JavaScript/TypeScript assumes the semicolons by itself but there are ugly cases where this goes wrong. So I do like code without semicolons (and many of my repos are still without) but now I prefer to just use them to have less of these "it went wrong" problems.
Editors supporting LSP: https://microsoft.github.io/language-server-protocol/implementors/tools/
Personally I use Helix (or Neovim) and especially Helix "just works" with nearly no config.

Since Visual Studio Code is the most used developers, I would welcome it if any developer could clone the rep and everything is already properly formatted (ideally with prettier) in VSC.

As long as there is some kind of npm run fmt.
Speaking of it: npm run lint-fix already exists and eslint is also able to fix and format a lot of code so maybe just add more relevant rules there (which is basically what xo does).
 Like here:
https://github.com/maxlath/wikibase-sdk/blob/b41ed343160d82dfb538a50b89a522afceba3ef3/tests/get_revisions.ts#L17-L20

I gave a try to prettier, but it has non-configurable opinions I don't like, so I would prefer not to use it :(
ESLint autofix should already get us pretty far. I added a rule to be consistent on semicolons (976080f), but that unfortunately seems to ignore type definitions semis.

Interesting find: The README.md states code style standard and there is an eslint config for standard with typescript so it might be interesting to migrate from standard to standard-with-typescript.
Guess all the PRs should be handled before doing this as its breaking for sure.
It also requires some stricter tsconfig settings so maybe string: true should be approached first


Rocket silo missing speed and productivity support

Can't calculate the requirements for Rocket part because speed and productivity can't be set for rocket silo.

That's weird, I added this a couple weeks ago (here is an example: http://www.doomeer.com/factorio/index.html#1132bbbbbbbbbbbb100rgrgrrrrgrrrgrgrrrrrrrrrrrrrrrrrrrrrrrrgrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr1rr). Am I missing something? Or are you by chance using another website? The tool is hosted at other places, maybe their maintainers did not pull the changes yet.

I used this one https://dwahler.github.io/factorio/index.html
Your have the update. Closing this ticket.


Fix/convert filters' expandable prototype

Changes

Fix/convert filters' expandable prototype to use global value setting.

Testing

Visit /browse-filterable/ and note the page loads without error and the filter works.

Review

@KimberlyMunoz
@sebworks
@kave

:+1:


Fixing hard IP related schema limitations

I wonder if ZeroSoc's floorplanning/build scripts might need updating to work with the new 'stackup' schema entries, but if it does I'm sure the changes would be minor.

Yup, good point -- I'll take care of this.


Add audit event for create-service-key

story number: [#87481308]
Signed-off-by: Edward Zhang<EMAIL_ADDRESS>

cc: @maximilien , @shalako
We noticed that for other controllers in CC, there are no test cases for the dependencies related method, as they are public method for controllers, we also created some new test cases to cover the test of these methods, we are thinking it's better to supplement the test cases for other controllers, please check if the test cases we added are proper and if needed, we can help on adding test cases for other controllers.

Cool, since the general policy is to have tests for public methods, good to add them.
Unless others feel otherwise, might make sense to create a chore to do the same for other controllers.
/cc @dsabeti, @jeffh, and @rmasand

Looks good :+1:. We probably won't backfill tests related to dependencies, because they're implicitly tested when the CC is able to start up. But the tests you've written are fine as-is and can be left in with the rest of the commit.


Added deeplabv3 model from gen1 compiled for openvino 2021.2

Replaced the one from Pinto's model zoo, since our version from gen1 is more accurate supposedly. Compiled for 2021.2

This does seem to be more accurate:
PINTO model zoo: https://youtu.be/zjcUChyyNgI
Our gen1 model zoo (this PR): https://youtu.be/zjcUChyyNgI

Here's another with our gen1 model zoo (this PR): https://photos.app.goo.gl/hkq5Ckhbf3WdPbfN8
Hard to say.  But overall this PR's model does feel a bit more accurate.


Merge request for #316

Migrate all styles to scss

I think I got it all now, thanks for quick feedback again 😄

Sure thing, I can tackle that too!

Thank you very much for your PR! Merging!

You're now in our contributors list! https://github.com/bitcartcc/bitcart#contributors-
If you want you can check other issues
About setting up prettier for sass, I will describe it in a separate issue in detail soon
.circleci/config.yml just calls yarn lint, which is located in package.json
eslint config is in .eslintrc.js

@MaximeKoitsalu Actually I checked, and sass formatting should be set up not by linting from eslint, but by pre-commit. It will run prettier on all files, also our linting and our consistency checks, see #320


Carbon Intensity (Independent Publisher) (Student)

Microsoft Learn Student Ambassadors Hackathon Submission Connector Hackfest
Hasan Ünlü

When submitting a connector, please make sure that you follow the requirements below, otherwise your PR might be rejected. We want to make you have a well-built connector, a smooth certification experience, and your users are happy :)

[x] I attest that the connector works and I verified by deploying and testing all the operations.
[x] I attest that I have added detailed descriptions for all operations and parameters in the swagger file.
[x] I attest that I have added response schemas to my actions, unless the response schema is dynamic.
[x] I validated the swagger file, apiDefinition.swagger.json, by running paconn validate command.
[x] If this is a certified connector, I confirm that apiProperties.json has a valid brand color and doesn't use an invalid brand color, #007ee5 or #ffffff. If this is an independent publisher connector, I confirm that I am not submitting a connector icon.

If you are an Independent Publisher, you must also attest to the following to ensure a smooth publishing process:

[x] I have named this PR after the pattern of "Connector Name (Independent Publisher)" ex: HubSpot Marketing (Independent Publisher)
[x] Within this PR markdown file, I have pasted screenshots that show: 3 unique operations (actions/triggers) working within a Flow. This can be in one flow or part of multiple flows. For each one of those flows, I have pasted in screenshots of the Flow succeeding.
[x] Within this PR markdown file, I have pasted in a screenshot from the Test operations section within the Custom Connector UI.
[ ] If the connector uses OAuth, I have provided detailed steps on how to create an app in the readme.md.

@hasanunl Congratulations! The deployment of your connector and documentation page is now complete, We have a short survey on the connector certification process that we would like for you to complete. Your feedback is appreciated and will help us improve the program. Thanks


Create a custom user agent for Monika

While monitoring some sites that use Cloudflare/LiteSpeed, there may be false incidents regarding Cloudflare anti-DDOS protection, which could return 403.
References:
https://betterstack.com/docs/uptime/frequently-asked-questions/#what-user-agent-does-uptime-use
https://betterstack.com/community/questions/whitelisting-better-stack-ip-cloudflare/

What should it be? Something like:
Monika Synthetic Monitoring Bot Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36

What should it be? Something like:
Monika Synthetic Monitoring Bot Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36

Precisely something what I had in mind.


Seq size is undefined after flattening

What happened
Seq size returns undefined after flattening.
How to reproduce
require("immutable").Seq([[1],2,3]).size // === 3
require("immutable").Seq([[1],2,3]).flatten().size // === undefined
require("immutable").Seq([[1],2,3]).flatten().toList().size // === 3

This is not a bug, though I could swear the documentation for size used to be better.
Sequences are evaluated lazily, and the size property is not guaranteed to exist. As general advice I would recommend against using Seq.size for precisely that reason. I thought there used to be better documentation for the size property, but perhaps not.
The real problem is that in order to know the size of the sequence Immutable would need to evaluate it. The point of sequences is that they are evaluated lazily. In your example this means that it's actually the call to toList which is going to cause the flatten operation to occur. Until the flatten step is done, there's no way to know what the size of the sequence will be after flattening.
Immutable could cause access of the size property to trigger computation of the sequence, however this is probably rarely desirable behavior because sequences aren't implicitly cached. Let's say immutable did trigger evaluation of the sequence on size access and you did the following:
const flatSeq = require("immutable").Seq([[1],2,3]).flatten()
flat.size // 3
const flat = flatSeq.toList();

The above code would actually have to do the flattening twice -- once to get the size, and then again when the data is actually used. This is almost certainly not what you want.
SO / tl;dr:
You have three choices:
require("immutable").Seq([[1],2,3]).flatten().toList().size

Hi @conartist6, thank you for the detailed response. This makes total sense now.
However, I would request a different change now that I know this: It would be nice if Seq.size threw an error. It could either something like Objective-C's "Subclasser responsibility" or, ideally, something that explains this exact situation: Error("Seq is a lazy class, and can thus not be guaranteed to know the size at any give point. For this reason, you should concretize this instance (through i.e. toList()) if you need the size").
I feel that there may be some push back to do this as clearly Seq can sometimes have a size (as in your cacheResult() example). I am not familiar with the internals of immutable, and so I totally understand if I am off base here, but at least from a user perspective, I find it surprising that Seq.size can .... mutate. I would actually prefer it to always throw, and thus force me to take one of the two latter steps you described (either calling .toList() or using iter-tools), because as is, it makes my code potentially highly dependent on implementation details.
For example, say some function (lets call it seqReturner) returns a Seq. If it happens to call cacheResult internally, either explicitly, or indirectly (by, perhaps, calling .find() on that Seq at some point, which I have checked and results in the "side effect" of the receiving Seq knowing its size), then the returned Seq will have a .size.  I may then call .size on it and get a result back and everything is fine. If at some later point the implementor of seqReturner finds a way to eliminate that .find() call, they have in theory not broken any contract with their type signature. And yet, my calling function will now break (hopefully quite loudly, but perhaps entirely silently as the .size's now undefined result may be interpreted as !>= 0 in a later check for example). As such, I would have much preferred .size to have thrown explicitly from the beginning, forcing me to do the right thing all along. Another way to say this is that Seq really does double duty as two distinct types: Seq and SeqSizeUnknown.
Anyways, hope that all made sense, and above all, thanks for the solution!

Yeah it definitely makes sense and I totally agree with you. I think it would be a great 4.0 change, since there must be people out who are actually checking for undefined and we can't break their code by throwing an error.

By the way, I found the documentation I was thinking of, and the easiest method to use. It is Collection.count.


Fix typo on nginx configuration

https://github.com/seqeralabs/cx-field-tools-installer/blob/master/assets/src/customcerts/custom_default.conf#L34-L35
        proxy_set_header        X-Forwarded_For $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded_Proto $scheme;

When debugging the Entra OIDC issue, I found this typo and wondered why the forwarding doesn't work. I believe the values should be:
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto $scheme;

Rad. Asked for you to include a bit of test documentation in the PR (please), then I'll merge.


"npm run build" should be run on "prepare" event to allow direct github installs

Currently package.json seems to run npm run build as part of the publish hook. Instead, that part should be run in the prepare hook, to support cases where this repository is installed as a dependency directly from GitHub and not via a published packages.
See: https://docs.npmjs.com/cli/v9/using-npm/scripts#prepare-and-prepublish

👋  howdy @dario-piotrowicz -- this issue is right on the money; this is what I did in my fork, so that I could point the dependency at github:
https://github.com/mrluc/next-on-pages/commit/0ecb47d4aa73d409c9e6c8010b32e0e22dd00976

Thanks for the issue @nakedible 🙂
And thanks for pinging me @mrluc 😄
it does seem sensible to me, I've created a PR with the script, let me know if that works for you 🙂👍

I will test later, but quick comment:
npm publish runs:

prepublishOnly
prepack
prepare
postpack
publish
postpublish

npm install runs:

preinstall
install
postinstall
prepublish
preprepare
prepare
postprepare

Hence there is no sense in having npm run build both in prepare and publish. Prepare should be enough to get it run also when running npm publish. That's the point of the hook...

@nakedible yeah that makes sense, thanks for checking the docs -- my commit referenced above unblocked us 😄 but ofc we're not running npm publish


feat: support attach task by restored terminal

Types

[x] 🎉 New Features

Background or solution
Changelog

LGTM


Update README to Include Links to Wiki and Outline Contribution Guidelines

Summary of Changes
This pull request includes the following updates to the repository:

README Update:

Added a section in the README file that introduces the wiki for the Federal EU Constitution project.
Included a direct link to the wiki, allowing contributors and interested parties to easily access guidelines and foundational concepts related to the project.

Creation of Wiki:

Created a wiki to provide a structured platform for detailing important concepts, contribution guidelines, and additional resources.
The wiki includes:

Foundational Concepts: An outline of key governance ideas such as negative/positive rights, human vs. citizen rights, and more.
Contribution Guidelines: Detailed instructions on how to contribute to the constitution, encouraging wide participation from the community.

Purpose
The purpose of these changes is to enhance transparency and engagement in the project by providing clear guidance and accessible resources to all contributors. The wiki serves as a place for meta-subjects related to the project, while the main repository is focused on the actual body of text for the constitution.

@Mathew-Iron I've fixed the merge conflict, could you review and merge? Thanks!


Update to 1.17

I have updated the mod to 1.17, and added myself as a contributor. :D

Wait apparently the existing mod jar works with 1.17.
So I guess never mind...


[Docker 321] Tomcat SSL connector no longer configured since upgrade to latest version

Make sure SSL connector is added again on latest versions of Tomcat.

is there a way we can test the results of xmlstartlet or the impact ?
don't merge origin/master into your feature branch - use git rebase origin/master (we can squash that when merging, so it's ok now)

1. is there a way we can test the results of xmlstartlet or the impact ?

Yes, we can test if port 8443 is responding or not. That's what xmlstarlet is configuring in the end.

2. ok, my bad!

@tgeens found a quick way to verify if the xmlstarlet changes are applied by exposing the default SSL port in the Alfresco docker-compose. By doing so it automatically gets checked by the gradle docker-compose plugin, it verifies that every exposed port on a container is open.

Nice
Wondering wether that does not break the "integrationTestChangedPorts" test

"integrationTestChangedPorts" is using a different compose file

(It's a bit too implicit, but I need to figure out how to deal with that in docker-tomcat first)


TLS Options Ignored in Profiles

Describe the bug
When I set the TLS options ImapTLS and StartTLS in a profile, they have no effect. Only the options set in the default profile affect the outcome.
To Reproduce
Steps to reproduce the behavior:

Set options  ImapTLS and StartTLS in the default profile so that they match your setup.
Set options  ImapTLS and StartTLS in the profile so that they do not match your setup.
Start the daemon, everything works.
Switch the above and everything stops working.

Expected behavior
The example suggests that the profile options overwrite the default profile options. This works for everything except the two TLS options for me.
Release version
Latest, i.e.  v1.11.7.
Architecture
Linux 64bit.

Thank you @patrickmelix, will take a look into this.


Add typing_extensions dependency explicitly

Things work right now because onnx also depends on it but we should make it explicit. See also: https://github.com/conda-forge/spox-feedstock/pull/3#issue-1646329317

I'd be fine dropping the dependency entirely, as it seems to only be used in an internal which isn't even in _future.
Only use (?):
https://github.com/Quantco/spox/blob/0ca5281cfd3e5dc4fabc7b815cac2dff877128d0/src/spox/_function.py#L1-L24
https://github.com/Quantco/spox/blob/0ca5281cfd3e5dc4fabc7b815cac2dff877128d0/src/spox/_function.py#L150-L166


S3logs

@kltm

added s3 bucket support see vars.yaml and readmes.
see Dockerfile.proxy
see docker-compose.yaml
all templates are now in the templates directory.
the proxy confif files are staged into stage_dir/proxy-configs to keep stage_dir a bit cleaner

Merging to clear; testing pending.