Evaluate trust namespace value as template

When installing trust-manager as a subchart (i.e. dependency) it would be useful to automatically set the trust namespace value to the release namespace, or another dynamic value. At the moment this is unfortunately not possibile since the app.trust.namespace value is evaluated as-is and so it needs to be always explicitly specified if you don't want the default one.
This can be easily solved if the value were evaluated as a template, e.g.
 metadata:
   name: {{ include "trust-manager.name" . }}
-  namespace: {{ .Values.app.trust.namespace }}
+  namespace: {{ tpl .Values.app.trust.namespace . }}

Then it would be possibile to set the trust namespace dynamically, e.g.
# Subchart configuration when trust-manager is a dependency
trust-manager:
  app:
    trust:
      namespace: {{ .Release.Namespace }}

Is this something that might be worth a PR? I'd be happy to contribute!

Alternatively, we might add a special value/ additional option to make it match the release namespace. I think that there are probably only a limited set of values that we would like to create templates for, so maybe templating is overkill and might introduce unexpected problems/ security issues.


[fix] @ValidateNested() used to throw Error when the property being v…

@ValidateNested() used to throw Error when the property being validated is not an object. This causes all the other validation errors to be ignored, and returning exception with no details regarding this validation error. This fix removes the error throw, and can be used together with custom "IsObject" validator to add indicative ValidationError

I don't think this will be merged without adding some return value. I see your point, and I agree we should raise a validation error, instead of throwing an exception, however, we should not simply just remove the exception.
I see after removing this line the tests still pass, so we have no coverage here, this should be fixed also.


[OSSM-6739] Add test case for CNI resources prune

Integrated CNI prune/preserve checks in smoke upgrade/delete tests
TEST_CASE=TestSmoke
Upgrade
=== RUN   TestSmoke/upgrade_v2.3_to_v2.4
    ...
    smoke_test.go:88: STEP 14: Check that previous version CNI resources were pruned and needed resources were preserved
    smoke_test.go:259:    SUCCESS: Resource ClusterRole/istio-cni was pruned
    smoke_test.go:250:    SUCCESS: Resource ClusterRole/ossm-cni was preserved
    smoke_test.go:259:    SUCCESS: Resource ClusterRoleBinding/istio-cni was pruned
    smoke_test.go:250:    SUCCESS: Resource ClusterRoleBinding/ossm-cni was preserved
    smoke_test.go:259:    SUCCESS: Resource ConfigMap/istio-cni-config-v2-3 was pruned
    smoke_test.go:250:    SUCCESS: Resource ConfigMap/ossm-cni-config-v2-4 was preserved
    smoke_test.go:259:    SUCCESS: Resource DaemonSet/istio-cni-node-v2-3 was pruned
    smoke_test.go:250:    SUCCESS: Resource DaemonSet/istio-cni-node-v2-4 was preserved
    smoke_test.go:259:    SUCCESS: Resource ServiceAccount/istio-cni was pruned
    smoke_test.go:250:    SUCCESS: Resource ServiceAccount/ossm-cni was preserved
    ...

=== RUN   TestSmoke/upgrade_v2.4_to_v2.5
    ...
    smoke_test.go:88: STEP 14: Check that previous version CNI resources were pruned and needed resources were preserved
    smoke_test.go:250:    SUCCESS: Resource ClusterRole/ossm-cni was preserved
    smoke_test.go:250:    SUCCESS: Resource ClusterRoleBinding/ossm-cni was preserved
    smoke_test.go:259:    SUCCESS: Resource ConfigMap/ossm-cni-config-v2-4 was pruned
    smoke_test.go:250:    SUCCESS: Resource ConfigMap/ossm-cni-config-v2-5 was preserved
    smoke_test.go:259:    SUCCESS: Resource DaemonSet/istio-cni-node-v2-4 was pruned
    smoke_test.go:250:    SUCCESS: Resource DaemonSet/istio-cni-node-v2-5 was preserved
    smoke_test.go:250:    SUCCESS: Resource ServiceAccount/ossm-cni was preserved
    ...

=== RUN   TestSmoke/upgrade_v2.5_to_v2.6
    ...
    smoke_test.go:88: STEP 14: Check that previous version CNI resources were pruned and needed resources were preserved
    smoke_test.go:250:    SUCCESS: Resource ClusterRole/ossm-cni was preserved
    smoke_test.go:250:    SUCCESS: Resource ClusterRoleBinding/ossm-cni was preserved
    smoke_test.go:259:    SUCCESS: Resource ConfigMap/ossm-cni-config-v2-5 was pruned
    smoke_test.go:250:    SUCCESS: Resource ConfigMap/ossm-cni-config-v2-6 was preserved
    smoke_test.go:259:    SUCCESS: Resource DaemonSet/istio-cni-node-v2-5 was pruned
    smoke_test.go:250:    SUCCESS: Resource DaemonSet/istio-cni-node-v2-6 was preserved
    smoke_test.go:250:    SUCCESS: Resource ServiceAccount/ossm-cni was preserved
    ...

Delete:
=== RUN   TestSmoke/delete_smcp_v2.4
    ...
    smoke_test.go:126: STEP 3: Check that CNI resources were pruned
    smoke_test.go:275:    SUCCESS: Resource ClusterRole/ossm-cni was pruned
    smoke_test.go:275:    SUCCESS: Resource ClusterRoleBinding/ossm-cni was pruned
    smoke_test.go:275:    SUCCESS: Resource ConfigMap/ossm-cni-config-v2-4 was pruned
    smoke_test.go:275:    SUCCESS: Resource DaemonSet/istio-cni-node-v2-4 was pruned
    smoke_test.go:275:    SUCCESS: Resource ServiceAccount/ossm-cni was pruned
    ...

=== RUN   TestSmoke/delete_smcp_v2.5
    ...
    smoke_test.go:126: STEP 3: Check that CNI resources were pruned
    smoke_test.go:275:    SUCCESS: Resource ClusterRole/ossm-cni was pruned
    smoke_test.go:275:    SUCCESS: Resource ClusterRoleBinding/ossm-cni was pruned
    smoke_test.go:275:    SUCCESS: Resource ConfigMap/ossm-cni-config-v2-5 was pruned
    smoke_test.go:275:    SUCCESS: Resource DaemonSet/istio-cni-node-v2-5 was pruned
    smoke_test.go:275:    SUCCESS: Resource ServiceAccount/ossm-cni was pruned
    ...

=== RUN   TestSmoke/delete_smcp_v2.6
    ...
    smoke_test.go:126: STEP 3: Check that CNI resources were pruned
    smoke_test.go:275:    SUCCESS: Resource ClusterRole/ossm-cni was pruned
    smoke_test.go:275:    SUCCESS: Resource ClusterRoleBinding/ossm-cni was pruned
    smoke_test.go:275:    SUCCESS: Resource ConfigMap/ossm-cni-config-v2-6 was pruned
    smoke_test.go:275:    SUCCESS: Resource DaemonSet/istio-cni-node-v2-6 was pruned
    smoke_test.go:275:    SUCCESS: Resource ServiceAccount/ossm-cni was pruned
    ...

Related:

https://issues.redhat.com/browse/OSSM-6739
https://issues.redhat.com/browse/OSSM-2101
https://github.com/maistra/istio-operator/pull/1816

/retest-required

/retest-required


it dosen't work, just "thinking..."

It worked properly last night, it suddenly does not work now.

by the way, I don't have the command "ChatGPT: Reset token".（）

Information:
ChatGPT: v3.5.6
Vs Code: Latest
windows 10 20H2 19042.1586

Fixed using official API in v2 release.


Spans for extracted placenames incorrectly start at 0

All spans returned by Mordecai begin at 0, which is incorrect. E.g.
geo.geoparse("""The state of North Rhine-Westphalia ranks first in population among
German states for both Roman Catholics and Protestants.""")

{...
'spans': [{'end': 22, 'start': 0}],
...}

Yeah i'm getting both start and end spans that are completely wrong.
[{'word': 'Jollibee',
'spans': [{'start': 0, 'end': 8}],
'country_predicted': 'PHL',
'country_conf': 0.93927664},
{'word': 'Jollibee',
'spans': [{'start': 0, 'end': 8}],
'country_predicted': 'PHL',
'country_conf': 0.93927664},
{'word': 'Metro Manila',
'spans': [{'start': 0, 'end': 12}],
'country_predicted': 'PHL',
'country_conf': 0.9998105,
'geo': {'admin1': 'Metro Manila',
'lat': '14.57775',
'lon': '121.04599',
'country_code3': 'PHL',
'geonameid': '7521311',
'place_name': 'National Capital Region',
'feature_class': 'A',
'feature_code': 'ADM1'}}]

This is a result of disabling the dependency parser for speed. spaCy uses the dependency parse to find sentence splits, so without the dependency parse, we can't get good sentence boundaries and that messes up the offsets. (There's a basic rule-based sentence splitter, but it doesn't work well for me). Here are the two options:

Add the dependency parser, which gives sentence splits but takes about twice as long as the NER only on 5,000 long documents:

0m34.324s  (ner only)
1m9.149s   (ner, dep)
1m25.417s  (ner, dep, tagger)

Use documents, rather than sentences, as the main unit of text. This might be better anyway, since all of Mordecai's training data is sentence-level. The major downside is that if people pass large documents in, all the text will be duplicated in every result and the offsets will be large.

Since I'm really trying to improve the speed right now, I'm more inclined to go with option 2.


Virus Detected

It won't even download with an exception. See if it can be fixed.

Unfortunately a known issue for us poor souls trying to publish compiled binaries for Windows users to distribute in zip files on GH releases. One of many examples here: https://github.com/liquidctl/liquidctl/issues/370
I am also a Windows user and long ago I had to spend a significant amount of time wrestling with Windows Defender to be able to do something as simple as download a zipped release from GitHub.
I can try reaching out to MS about this false positive, but I'm not going to hold my breath. For now your options are to either spend some time tweaking your Windows Defender settings or compiling from source.
Over the weekend I'll work on publishing this to scoop to provide an alternative avenue for installation of prebuilt binaries.
Apologies that I don't have better news for you. 😞

PR opened to scoop's extras bucket: https://github.com/ScoopInstaller/Extras/pull/8713

https://www.virustotal.com/gui/file/fb00e0c43336787eeb12151e35bbddf6f0190eded4431bfdcf7776fbda806fdf for additional peace of mind, no viruses detected. 😅

unsubscan can now be installed on Windows via scoop after adding the extras bucket. Steps have been documented on the readme.

Would it be possible to add it to winget as well? That's built into window now.


info :: global_mem_cache_type differs from sycl/1.2.1 spec.

Bug summary
The definition of the enum class cl::sycl::info::global_mem_cache_type has write_only, which is not in the sycl/1.2.1 spec, and is missing read_write, which is in the spec.
To Reproduce
Look at the source code and the spec? :-)
#include <CL/sycl.hpp>
int main()
{
  cl::sycl::device device;
  auto foo = device.get_info<cl::sycl::info::device::global_mem_cache_type>() == cl::sycl::info::global_mem_cache_type::read_write ;
  return 0;
}

Expected behavior
hipSYCL and sycl/1.2.1 match.
No compile time warning error: 'read_write' is not a member of 'hipsycl::sycl::info::global_mem_cache_type'
Optional additional diagnostic information
I find write_only in 3 header files, all related to global_mem_cache
./include/hipSYCL/runtime/hardware.hpp:45:  global_mem_cache_write_only,
./include/hipSYCL/sycl/device.hpp:456:          rt::device_support_aspect::global_mem_cache_write_only))
./include/hipSYCL/sycl/device.hpp:457:    return info::global_mem_cache_type::write_only;
./include/hipSYCL/sycl/info/device.hpp:165:enum class global_mem_cache_type : int { none, read_only, write_only };

Additional context
Looking at SYCL specification:  Version 1.2.1  Document Revision: 7  Revision Date: April 27, 2020
Still in my first week of learning / playing with SYCL, so please be kind if I'm clueless. :-)

Thank you, you are absolutely right :) This was changed sometime in the spec and it seems we forgot to change it in hipSYCL.
PS: Better look at the SYCL 2020 specification as hipSYCL has already started moving to SYCL 2020 ;)

Thank you, you are absolutely right :) This was changed sometime in the spec and it seems we forgot to change it in hipSYCL.
PS: Better look at the SYCL 2020 specification as hipSYCL has already started moving to SYCL 2020 ;)


Fix install command from binary in README

We have to unpack downloaded file.

@h3poteto Oh, Thanks 🙏


Add try-with-resources statement to ensure input stream is closed

looks good to me;
note that there are other places in this class (e.g. the copy method) which would benefit from the same change


Format parsing errors are reported against

[ERROR] Failed to execute goal com.theoryinpractise:googleformatter-maven-plugin:1.0.4:format
(com.theoryinpractise:halbuilder-styleguide-tile:1.0.4-SNAPSHOT::reformat-sources) on project
halbuilder-core: <stdin>:474:49: error: Syntax error on token ">>", > expected -> [Help 1]

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------< com.group31.editor:pixel-editor >-------------------
[INFO] Building pixel-editor v0.1-CANARY
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- googleformatter-maven-plugin:1.7.3:format (reformat-sources) @ pixel-editor ---
[INFO] Found 37 uncompiled/modified files in C:\Users\Terri\source\repos\scc210-2223-grp-31\src\main\java to reformat.
[INFO] Found 1 uncompiled/modified files in C:\Users\Terri\source\repos\scc210-2223-grp-31\src\test\java to reformat.
[INFO] ------------------------------------------------------------------------
[INFO] Finished at: 2022-12-10T10:21:45Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.theoryinpractise:googleformatter-maven-plugin:1.7.3:format (reformat-sources) on project pixel-editor: 38:18: error: : expected -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

Similar error, didn't mean to necro the post there was only a few issues open and this seemed similar :)


Problems with password protected databases

Just realised (when trying MySQL 8) that the Debian packages do not like that the MySQL root user is password protected...

Thinking that all scripts (but the ah_db_user function) should use the arrowhead user and the password we generate.
The ah_db_user function should ask (once!) for the root password for creating the arrowhead user.

The ah_db_user function should ask (once!) for the root password for creating the arrowhead user.

I think that's a fine solution. I'll keep open this issue, until it is implemented.

This requirement shall be included in the install documentation

Should be solved in develop branch now - Zoltan, could you please confirm that it works for you also?

I tested the latest code on Ubuntu server and it worked.
1 small thing to note is that setting a root password after the mysql installation is the easiest via the provided sudo mysql_secure_installation script, which at the very least demands database passwords to be 8 character or longer. This concerns the password for the arrowhead user too, so if during install the cloud operator gives a short password, the install will fail with

Your password does not satisfy the current policy requirements

and the packages need to be purged, and try again.


Recipe with camera

Describe your recipe idea
As I see there is a challenge for me to keep up with all the api changes from expo, it would be nice to get a recommendation about what packages to use for photo/video recording.

Hello @freewill777
Thank you for your contribution 🚀

expo-camera work out of the box and I personally successfully used it on many apps.
react-native-vision-camera is another library if you need more advanced features.

I will close it for now because it doesn't require a specific recipe.


Updated Detect Exchange Web Shell

Updated Detect Exchange Web Shell based on data

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Detect Exchange Web Shell, ProxyLogon :white_check_mark:

diskUsage: 741376
runDuration: 35.901s
scanCount: 51293


user = User.authenticate stopped working

Hi @rhymes,
Been running a Parse Server Heroku app smoothly for quite a while with no recent changes.  IN the last week when authenticating with:
user = User.authenticate(username, password)
it just stopped returning the User object.
Wondering if you might have any suggestions on things I might of have forgot to check. Heroku and postgres seem to be running normally and there were no changes to the code.

@OpConTech it's hard to know without any error messages or something.
Are you sure nothing has changed? Maybe you updated the Parse server code and it doesn't work anymore?
Did you try to debug?

Yes did a full debug. The mobile side using iOS Parse SDK working fine. Strictly on the Rails side. Got stuck because have not changed anything on the Parse Server or Rails App in months. So I reached out to see if I might of have overlooked something.
Thanks for trying to help.
On Dec 6, 2017, at 12:07 AM, rhymes <notifications<EMAIL_ADDRESS>wrote:
@OpConTechhttps://github.com/opcontech it's hard to know without any error messages or something.
Are you sure nothing has changed? Maybe you updated the Parse server code and it doesn't work anymore?
Did you try to debug?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/adelevie/parse-ruby-client/issues/225#issuecomment-349565066, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACA5xwRkcac6yIcmc5DBrXMJLLGO4Q6hks5s9ktcgaJpZM4Q3cS4.

BTW is it still as per the documetation:
user = Parse::User.authenticate("cooldude6", "p_n7!-e8", client)
or did Parse::User.auth... become just User.auth... ?

@OpConTech Bummer this isn't working as intended. As you can see, we haven't changed anything on this end for quite a while, so it's hard to imagine something here changed. I haven't worked with parse recently, so I'm not sure if something changed on the server itself (if they changed the response to /login, then we wouldn't be able to return the user object anymore, for example). I'd look there.
Sorry we can't be more help!

Hi Guys,
I dug deeper and found that it was dropping out because of SSL network failure. It turns out the ExpeditedSSL guys renewed our cert on our Heroku instance for the Parse Server. ExpeditedSSL reported back that the root cause was that they incorrectly installed an intermediate cert.
Thank you for your replies and helping me troubleshoot.


Data not updated correctly after selections

Issue:
The data in is not correctly updated after making selections with multiple instances of components on the same page.
Components
Issue occurs in following components

QdtKpi
QdtPicasso

Steps to reproduce

Create two QdtKpi objects on a single page.
Add a selection box
Filter the data with a selection box.

See also the Qdt-components demo page:
https://qdt-apps.qlik.com/qdt-components/react/#/kpi

Fixed on 2.2.14.
https://qdt-apps.qlik.com/qdt-components/react/#/kpi
thank you


Change model to support async interceptors

Currently, Interceptors can only be written in a blocking way.
For a call x.foo(y), we can prevent the call to foo, change parameter y, etc, but if we need to perform a longer/blocking action before doing so, we have to block. An example is checking for authorizations in a remote server.
The current model is an automaton that interacts with blocking semantics. To allow non-blocking interceptors, we must change to a callback based model where we can proceed whenever we want. This proceed() call can optionally take updated arguments.

Done in primeval-reflect


Export the JSON in PubAnnotation endpoint

Create a JSONExport module (#3), and inject it in the plan.

Closed as duplicate of #6


how can we change it to work on WAN

Hello,
Yes, it can. Can be deployed on any server, just need to setup the correct port on environment variables.
I added a easy way to deploy on heroku.
Can you try?
The process are described on Readme:
https://github.com/tiagorlampert/CHAOS#3-deploy-on-heroku


docs: workflows for openapi and autodoc publication

What this PR changes/adds
Add/fix worfklows for autodoc and openapi publication.
Why it does that
Autodoc and openapi publication
Further notes
List other areas of code that have changed but are not necessarily linked to the main feature. This could be method
signature changes, package declarations, bugs that were encountered and were fixed inline, etc.
Linked Issue(s)
Closes # <-- insert Issue number if one exists
Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.

it would be great to add the jobs also in the release workflow like it's done in the connector repo

done


[FLOC-2193] Move merging PR

Please clarify the steps to make the path leading to JIRA issue acceptance or rejection clearer.

OK to merge. Thanks.


what condition that can make compression fail?

I need to handle a case where image compression fail
On what condition that can make image compression fail so I can reproduce the step?
thanks

A simple case to make it fail is to call the function with a non-image file such as a PDF file.


Duplicate default hashes

This PR makes default hashes unique to their repo, not unique globally.

./tsrc-dev test JeffreyLWood demo run_tests
All tests pass


WIP: Converting other kinds of data into OData

@ezagroba , looking at the length of the document, will it make sense to turn it into a section of the Register Data Assets document?

@MariaShaposhnikova If it stays at this length, then yes I agree. There's still some discussion about whether there will be long code snippets and instructions included.

@MariaShaposhnikova what's the outlook on verifying and publishing this?


OpenSSL 1.0.1 compatibility

It seems that in #4395 a precedent for OpenSSL backward compatibility to 1.0.1 was set.  It certainly worked for the previous version I was using, 1.14.1.  In trying to move forward to 1.19.1 I ran into a build failure:
.../src/core/tsi/ssl_transport_security.cc:659:52: error: 'X509_V_FLAG_TRUSTED_FIRST' was not declared in this scope

This is from 5a0699c705177d4a3c6a35c95a92d0be3ec378a6, which is presumably a desirable change.  In order to work around the issue, I simply reverted the commit.  That doesn't seem very safe to me, since I didn't investigate the implications or assumptions of the surrounding code.
The flag (X509_V_FLAG_TRUSTED_FIRST) seems to have been added in OpenSSL 1.0.2a, and is in the 1.0.2 documentation, as early as I can find.

It might be time to drop OpenSSL 1.0.1 . Requesting opinion from jiangtaoli2016

OpenSSL 1.0.2 has been released since Jan 2015. I think it is time to stop supporting OpenSSL 1.0.1 or older versions in gRPC. @nicolasnoble What do you think?

Dropping OpenSSL 1.0.1 support due to its age sounds reasonable. We might be able to do some cleanup in our repo if that's approved.
https://github.com/grpc/grpc/blob/master/tools/openssl/use_openssl.sh
Btw, it would be good to come up with a list with OpenSSL versions in stable distros we support (e.g. debian / ubuntu / centos / fedora / alpine / arch / opensuse ). If all of them have OpenSSL 1.0.2+, we should be good.
I also remember that v1.0.2 is the first version that supports ALPN, so by dropping 1.0.1 support, we might be able to get rid of some complexity in C-core?

I think that we might be fine when

#21293 is solved
and this https://github.com/grpc/grpc/blob/master/tools/openssl/use_openssl.sh script is updated to use 1.1.1

@Croydon  I don't think the "use_openssl.sh" script is used for anything. AFAIK it's a remaining piece of tests we no longer run.
Also, we no longer recommend building with Makefile (which is what use_openssl.sh) does.

Okay, understood. Are there any tests running with OpenSSL currently?
Thanks for pushing this forward

Okay, understood. Are there any tests running with OpenSSL currently?
Thanks for pushing this forward

Some portion of our CMake distribtests actually uses pre-installed openssl instead of boringssl
(this is actually a requirement if you set -DgRPC_SSL_PROVIDER=package for cmake build, because boringssl doesn't provide a standalone installation).
See e.g. here:
https://github.com/grpc/grpc/blob/2b200d2313e739fa1841edf3ea86ab8532862505/test/distrib/cpp/run_distrib_test_cmake.sh#L24
https://github.com/grpc/grpc/blob/2b200d2313e739fa1841edf3ea86ab8532862505/test/distrib/cpp/run_distrib_test_cmake.bat#L30

This issue is being closed because it has been marked with the label kind/question. This form is for bug reports and feature requests ONLY!
Please post questions on https://groups.google.com/g/grpc-io so that the wider community can help answer.


Issue with tellraw and customName

Hello,
I get error to parse tellraw commands:
/tellraw @a [{"selector":"@s"}," throws item"]

Error:
Updated error.
Line #1: Failed to parse 'tellraw @a [{"selector":"@s"}," throws item"]':
Parser 'minecraft:component' failed to parse '[{"selector":"@s"}," throws item"]': Expected a valid JSON.

And customName does not convert:
/summon item ~ ~ ~ {PickupDelay:70,CustomName:"Terracotta",CustomNameVisible:1,Item:{id:"minecraft:magenta_glazed_terracotta",Count:1b,tag:{display:{Lore:["lore line 1","lore line 2"]}}}}

I get this from spu:
/summon item ~ ~ ~ {PickupDelay:70,CustomName:"Terracotta",CustomNameVisible:1,Item:{id:"minecraft:magenta_glazed_terracotta",tag:{display:{Lore:["lore line 1","lore line 2"]}},Count:1b}}

It will execute but there is warning in console. The correct one seems to be:
/summon item ~ ~ ~ {CustomNameVisible:1b,PickupDelay:70,CustomName:"{\"text\":\"Terracotta\"}",Item:{id:"minecraft:magenta_glazed_terracotta",Count:1b,tag:{display:{Lore:["lore line 1","lore line 2"]}}}}

(From https://mcstacker.net/1.13converter.php)
Thanks.

Thank you for the quick fix.
I have sent you an email, please check that out.
Thanks again.

BTW The tellraw 1.13 result should be
/tellraw @a {"selector":"@a","color":"white","extra":[{"text":"throws","color":"white"}]}

It seems the extra section is only used for more than one segment in tellraw, like this:
/tellraw @a {"text":"test","color":"white","extra":[{"selector":"@s","color":"aqua"}]}

Arrays can still be used in text components.


5.1 Feedback:  [Design QA] Robot Settings Page#10151 & Robot Settings > Advanced > Usage settings styling is off #10106

Overview
Round 1 design QA for Robot Settings page
Current Behavior
View the annotated Figma frame

Calibration

[x] (1) Update the font styling here to the updated label font size  (11 font size, 12px line height)
[x] (2) Update font colour to our 'dark-black'
[x] (3) Update this link to our 'link/primary/blue/internal' styling. There's a heavier font weight and a hover state
[x] (4) Update the tertiary button styling. Need correct hover/pressed/potentially disabled state (cant activate disabled using devtools)
[ ] (5) Are we nixing the rest of the content on this page? If so, let's nix that last line beneath content. Also, let me know so I can update designs.

Networking

[ ] (1) Update all text to our 'dark-black' on this page
[x] (2) Should be semi-bold
[ ] (3) Update to our 'input/field-with-label' component. The label should be our label styling, currently our p styling
[x] (4) Missing 24px margin
[ ] (5) Double the size of the icon, should be 12x12
[ ] (6) Missing hover state on the primary link styling
[ ] (7) 1rem spacing between link and "looking for
[ ] (8) Need to update these icons

Advanced

[ ] (1) Bit too much spacing here, should be 1rem from the edge of the container
[ ] (2) Update all text to our 'dark-black' on this page
[ ] (3) Should be 1 rem beneath each section header (about, usage settings, trouble shooting, legacy settings). Also, making a last-minute decision to update the headers from h3's to h2's and semibold to help add some distinction.
[ ] (4) Update tertiary button style
[ ] (5) Needs our link styling (semibold, hover states)
[ ] (6) Missing the 'update now' button? This displays when the toast saying there's an update available.
[ ] (7) Upping the margin to 40px between each section (sorry, this is new!)
[ ] (8) Update these to our toggle component
[ ] (9) Update size of font, size of icon and add the states in
[ ] (10) Looks like a margin-bottom of 1rem snuck in there

Expected Behavior
No response
Steps To Reproduce
No response
Operating system
No response
Robot setup or anything else?
No response

https://user-images.githubusercontent.com/474225/168160607-9fd4c41c-f880-4a47-bd0b-a7ef239b071c.mov

@mmencarelli

@mmencarelli

Yup, I can see the confusion. If you step out two levels you'll see that the component includes some padding around the vector. So vector is 8x8, but there should be some padding around it that cause it to be 12x12. Video here

@mmencarelli thank you for the video.
After checking components, noticed that ExternalLink's line-height was 16px instead of 20px.
The following is line-height 20px. What do you think of these?
0.5 rem 8px

0.6 rem 9.6px

0.75 rem 12px

Default fontColor #4a4a4a

@mmencarelli thank you for the video.
After checking components, noticed that ExternalLink's line-height was 16px instead of 20px and added align-items: center to centralize text and icon vertically.
The following is line-height 20px. What do you think of these?
0.5 rem 8px
0.6 rem 9.6px
0.75 rem 12px

Love the options! 0.5 rem 8px is the one :)

@mmencarelli Thank you for your feedback!

[ ] icon size 0.5 rem for ExternalLink


Tests would crash when using react-loader - need to remove react/react-dom deps from react-loader

Hi
I'm getting an error when I run tests in my application when react-loader is included in one of my components.
The main cause is that it loads react and react-dom additonally so with it my project loads reactjs 2 times and this causes an error.
When I remove react/react-dom dependencies from node_modules in react-loader directory then it works flawlessly.

PR #41 should fix it.

Awesome thanks for the info! :) I hope that it gets merged soon and released

Looks like it was just merged and released as 2.3.0

Thanks for pointing this out, @pypetey, I have merged in #41 and published 2.3.0 to npm. Let me know if you are still having issues.


.Google command responding in German

In public Nadeko and in a server where the language is set to english.
On my selfhost, results come back in English.
Maybe some glitch, but idk

I've created a pr for a solution that works with keyword test, but it removes one part that I don't know if you want to keep.

Probably due to where the server IP originates from.
The API request is going to come from the server.

But it randomly changes, which is a problem

Might be because it could use the websocket gateway that Discord assigns as the country for redirect for efficiency.

and now its Ukrainian :^)

Tested this out on NadekoBot v2.10.1. Still present.

@Kwoth I could swear there was a PR about this and I commented on it, what happened to it?

@Kwoth found what my comment was. It needs ?cr=countryUS. I tested it on 2 tabs, showed different results.
Source: https://productforums.google.com/forum/#!category-topic/websearch/qBv0VZLSG50

Is this fixed for everyone? I've tested it out, but still got some german results.

@Macley-Kun I have Ukranian results.

I do know a way how to solve this.
https://github.com/appu1232/Discord-Selfbot/wiki/Google-API-Setup-for-Image-Search-Command
Sadly it does require users to add an extra line where the search engine ID is in. But i'm pretty confident that it will fix the issue.
I'm not a programmer so it's really up to Kwoth if he agrees to add code just to fix this issue with the above methode.


[FEATURE] BundleBuilder: support modules using ES6 with usePredefineCalls

When using the bundle option usePredefineCalls modules using ES6
features such as arrow functions, classes, ... are not supported
and the bundler will break as the mozilla-ast of uglify-es is not
ES6 ready.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@codeworrior any objections on the pull request - the performance decrease IMO can be ignored for the moment until we have a better solution. Using it on a trivial library shows code generation times of about 0-3 ms for standard library resources!

I did some measurements (ui5 build --all)

Project
before PR
with PR

openui5-sample-app
0:52
0:52

openui5/testsuite
3:58
4:05

Neglectable, I would say.


Policy change: pushing to protected branches is now blocked

Starting this week, we[^1] are enabling branch protection on Nixpkgs to require pull requests for all commits to the master and release-* branches. This will prevent the almost 200 Nixpkgs committers from pushing directly to those branches, which already almost never happens anyways.
[^1]: @zimbatm will enable it, with support by @infinisil
Unless this causes major problems, we intend to keep this enabled permanently. Please use this issue to report any problems you encounter because of this.
What branches are affected?
The master and release-* branches that are consumed by Hydra.
What if I need to push?
Please contact the release managers as they will be added to the exception list.
In general, we expect that the PR workflow will be enough for the vast majority of cases.
Background
This change was originally proposed almost 3 years ago with closed RFC 79 when direct pushes were way more frequent at about 5%.
Very recently a new attempt was started with RFC 156, for which @infinisil computed that nowadays only 0.05% of commits are pushed directly.
The RFC was struggling to get enough shepherds, when @zimbatm rightly pointed out that such simple decisions shouldn't be blocked, following up with the proposal to just enable it and try it out.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/policy-change-pushing-to-protected-branches-is-now-blocked/31719/1

I also created @NixOS/nixpkgs-release-managers to track who has push access. Please don´t abuse this to ping them :)

Note that releases should also work without direct pushes, which is being discussed in https://github.com/NixOS/release-wiki/pull/70, so this exception should be removed in the future

@Ma27 pointed out that it looks like PR's can't be merged anymore when a committer requested changes (though it seems like those reviews can be dismissed?), additionally auto-merge seems to be available now:

It doesn't seem inherently bad, but I did not expect that to happen.

@FRidh I'm pretty sure that setting is not enabled. Indeed as an example, https://github.com/NixOS/nixpkgs/pull/249150 was merged 1 hour ago (when the setting was already in effect), and it was merged without any reviews.
The good thing is that dismissing reviews does allow merging then, and even better: To dismiss reviews you have to give a reason, I tested this here: https://github.com/infinisil/github-test/pull/2#pullrequestreview-1577305009

Fyi, we do have the option to turn off allowing auto-merges, see here.

I think we should disable the auto-merge feature because it works only based on the reviews and completely ignores the OfBorg status. And until we have more solid CI we cannot also require CI checks to pass before merging.

I turned off auto-merges.

The RFC was struggling to get enough shepherds, when @zimbatm rightly pointed out that such simple decisions shouldn't be blocked, following up with the proposal to just enable it and try it out.

Meh. I don't oppose this policy, but I don't like how this decision sidesteps the RFC process.
Does this imply proposals can be tacitly approved if they don't get enough attention? It doesn't seem right.

The good thing is that dismissing reviews does allow merging again, even if it's your own PR. And even better: To dismiss reviews you have to give a reason, I tested this here: infinisil/github-test#2 (review)

@infinisil for the record, I'm fine with that and I withdraw my skepticism :)
The problem I had with the previous behavior was that there was no way to override it (and from my experience almost every rule tends to have an exception ;-) ). I haven't checked it so far, but if it's possible to dismiss now while having to provide a reason for that seems good to me, thanks :+1:

https://discourse.nixos.org/t/policy-change-pushing-to-protected-branches-is-now-blocked/31719/1

OK with this one being pinned globally, my other issue is also resolved, this provides reasonable visibility for each committer.
IIRC we haven't had notable config changes in the repo for a while and I'm not sure if there are follow-ups planned to this, but for the future I'd like to suggest to always communicate it via a globally pinned discourse topic (and perhaps even cc all of the committers in $github_issue).

Meh. I don't oppose this policy, but I don't like how this decision sidesteps the RFC process.
Does this imply proposals can be tacitly approved if they don't get enough attention? It doesn't seem right.

@rnhmjoj I know it looks a bit like we pulled a Flake again, but:

The change does not have any long-lasting API or user implications, it can be reverted at any point without problems
The change has a very low negative impact, only ~0.05% of commits were direct pushes
Meanwhile, the change has a significant positive impact, especially for security

Considering this, I don't think it's necessary to have an RFC for this, because it should be an uncontroversial change, and indeed, we haven't seen any good reason in the RFC to not do this.
But also a big argument is that going through an RFC for something so minor distracts people from more important problems to fix. Not having to maintain this RFC for months frees up time for me to e.g. focus on implementing accepted NixOS/rfcs#140, which is considerably more impactful.

Closing as this was up long enough


General Helm app stability changes.

This change has some general stability changes to the parsing of helm
variable files. Although not perfect yet, this change prevents nil variables
from existing in the scraped variable files, and attempts to prevent
incorrect configs from being associated with the wrong chart and
chart version.

Coverage decreased (-0.2%) to 55.122% when pulling cf4dc80e9900fb4c4f815b3063576c141559b30e on gopherstein:master into 8c46591da33b806c51a99b3b98bdfa80dbca53b2 on supergiant:master.


Add Spanish and Spanish Latam Translation V1

The traditions are already there, only the ".meta" files are missing.

I don't know Spanish myself but I have some questions :3

In es_419.lang and es_ES.lang on line 27 camera is spelled Camara and on the next line it's spelled Cámara
Is this a typo or intentional?

On line 21 in both files the translation ends with Please check me out.
Was this intentional?

Nothing was intentional, they were mistakes on my part that I didn't notice when I did the translation the first time, I have corrected them and also added a few things to make certain functions more understandable.
On line 21 I didn't see that I already had the "\n" and I left the word out, sorry.

Line 26 and 63 in both files tab.model.reset_layout has a trailing dot. Remove it
Other than that everything else looks good 👍

Done! 👍

There is one file typo en_ES.lang instead of es_ES.lang
I get errors when I try the languages in the app

The tool tip text might be a bit to small in the help text window. Could you remove the left click part or simplify it?

Ignore the failing checks


3 -> 4

➡ Forward port
Port ign-sensors3 to ign-sensors4
Branch comparison: https://github.com/ignitionrobotics/ign-sensors/compare/ign-sensors4...ign-sensors3
Note to maintainers: Remember to Merge with commit (not squash-merge or rebase)

This failed consistently on all GitHub actions:
  [ RUN      ] GpuLidarSensor/GpuLidarSensorTest.TestThreeBoxes/ogre2
  [Msg] Loading plugin [ignition-rendering-ogre2]
  [Msg] Publishing laser scans on [/ignition/sensors/test/lidar1]
  [Msg] Publishing laser scans on [/ignition/sensors/test/lidar2]
  /github/workspace/test/integration/gpu_lidar_sensor_plugin.cc:540: Failure
  The difference between sensor1->Range(0) and expectedRangeAtMidPointBox2 is 0.00010395050048828125, which exceeds 1e-4, where
  sensor1->Range(0) evaluates to 4.5001039505004883,
  expectedRangeAtMidPointBox2 evaluates to 4.5, and
  1e-4 evaluates to 0.0001.
  [  FAILED  ] GpuLidarSensor/GpuLidarSensorTest.TestThreeBoxes/ogre2, where GetParam() = "ogre2" (309 ms)

Is this on your radar, @iche033 ? Should we make those checks not required for ign-sensors4?

hmm the test was failing in different checks on macOs as mentioned in https://github.com/ignitionrobotics/ign-sensors/issues/66. I don't remember if it was happening on github actions though. How about we make them not required for now and add info on the new failed checks to issue #66?

It looks like Actions has been consistently green for ign-sensors4 until now: https://github.com/ignitionrobotics/ign-sensors/actions/workflows/ci.yml?query=branch%3Aign-sensors4
I don't think this PR is introducing the issue though. Maybe an upstream change? I retriggered the ign-sensors4 branch to see if it changes: https://github.com/ignitionrobotics/ign-sensors/actions/runs/950365124

after taking a closer look at the test failure, it's caused by loss of precision. The expected vs actual depth value now slightly exceeds the specified tolerance (1e-4). The only upstream PR that looks related is https://github.com/ignitionrobotics/ign-rendering/pull/296 that configures the depth texture resolution based on the number of samples instead of a hardcoded 1024 value (to save memory). I did not expect this to affect precision though since depth buffers precision is mainly affected by near and far clip planes which had not changed. I reverted https://github.com/ignitionrobotics/ign-rendering/pull/296 locally and verified that depth precision didn't change so the test is passing locally as well.
I think we can do one of the followings:

revert  https://github.com/ignitionrobotics/ign-rendering/pull/296 and rerun ign-sensors test on github actions (I'm not sure how to do that with a custom upstream branch)
relax tolerance for that particular check from 1e-4 to 2e-4 to make the test pass.

I reverted ignitionrobotics/ign-rendering#296 locally and verified that depth precision didn't change so the test is passing locally as well.

Spoke too soon! The value did change by a very small amount locally, by a diff of 6-e5, . So I think ignitionrobotics/ign-rendering#296 is the reason for the test failure. So the tradeoff here is depth sensor accuracy vs gpu memory. The precision loss is very small so I'm leaning towards  just relaxing the tolerance for that particular check in the gpu integration test

I'm leaning towards just relaxing the tolerance for that particular check in the gpu integration test

SGTM :+1:

CI green after c087c9a


JWT authorizer created but is not attacheable, terraform gives error

Description
Trying to use this code (concern is about the authorizer):
module "api_gateway" {
  source  = "terraform-aws-modules/apigateway-v2/aws"
  version = "~> 2.2.2"

  name          = local.api_gateway_name
  description   = " App - ${var.environment_name}"
  protocol_type = "HTTP"

  cors_configuration = {
    allow_headers = [
      "content-type",
      "x-amz-date",
      "authorization",
      "x-api-key",
      "x-amz-security-token",
      "x-amz-user-agent"
    ]
    allow_methods = [
      "*"
    ]
    allow_origins = [
      "*"
    ]
  }

  # Custom domain
  create_api_domain_name      = true
  domain_name                 = local.apigw_full_dns_name
  domain_name_certificate_arn = module.acm.acm_certificate_arn

  # Access logs
  default_stage_access_log_destination_arn = aws_cloudwatch_log_group.api-layer-log-group.arn
  default_stage_access_log_format          = "$context.identity.sourceIp - - [$context.requestTime] \"$context.httpMethod $context.routeKey $context.protocol\" $context.status $context.responseLength $context.requestId $context.integrationErrorMessage"

  # Routes and integrations.
  integrations = {

    "POST /apimethod" = {
      integration_type        = "AWS_PROXY"
      integration_http_method = "POST"
      payload_format_version  = "2.0"
      lambda_arn              = module.lambda_billing_use_credits.lambda_function_qualified_arn
      credentials_arn         = aws_iam_role.api_gateway_credentials_call_lambda.arn
      authorizer_key          = "user_pool"
    }

  }
  tags        = var.tags
  authorizers = {
    # see https://aws.amazon.com/ru/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/.
    "user_pool" = {
      authorizer_type  = "JWT"
      identity_sources = ["$request.header.Authorization"]
      name             = "${local.env}-apigw-userpool-jwt-authorizer-int"
      audience         = [aws_cognito_user_pool_client.cognito.id]
      issuer           = "https://${aws_cognito_user_pool.users.endpoint}"
    }
  }
}

Authorizer is created, but I get the error
 Error: updating API Gateway v2 route (xgwpui1): BadRequestException: Unable to update route. Authorizer type is invalid or null.

The same authorizer is easily attached via Console, after which Terraform sees no changes to be made.

[x] ✋ I have searched the open/closed issues and my issue is not listed.

⚠ Note
Before you submit an issue, please perform the following first:

Remove the local .terraform directory (! ONLY if state is stored remotely, which hopefully you are following that best practice!): rm -rf .terraform/
Re-initialize the project root to pull down modules: terraform init
Re-attempt your terraform plan or apply and check if the issue still persists

Versions

Module version [Required]:

Terraform version:

Terraform v1.5.2
on windows_386

provider registry.terraform.io/hashicorp/aws v5.11.0
provider registry.terraform.io/hashicorp/external v2.3.1
provider registry.terraform.io/hashicorp/local v2.4.0
provider registry.terraform.io/hashicorp/null v3.2.1
provider registry.terraform.io/hashicorp/random v3.5.1

Provider version(s):

Terraform v1.5.2
on windows_386

provider registry.terraform.io/hashicorp/aws v5.11.0
provider registry.terraform.io/hashicorp/external v2.3.1
provider registry.terraform.io/hashicorp/local v2.4.0
provider registry.terraform.io/hashicorp/null v3.2.1
provider registry.terraform.io/hashicorp/random v3.5.1

Reproduction Code [Required]

Steps to reproduce the behavior:

Create an API Gateway with a Lambda integration.
Add a JWT authorizer info
Modify route for the integration to use the authorizer

Latest versions of provider and module were used.

Expected behavior
JWT authorizer is attached as shown in your documentation example.
I remind that in your readme you have
    "GET /some-route-with-authorizer" = {
      integration_type = "HTTP_PROXY"
      integration_uri  = "some url"
      authorizer_key   = "azure"
    }

    "$default" = {
      lambda_arn = "arn:aws:lambda:eu-west-1:052235179155:function:my-default-function"
    }
  }

  authorizers = {
    "azure" = {
      authorizer_type  = "JWT"
      identity_sources = "$request.header.Authorization"
      name             = "azure-auth"
      audience         = ["d6a38afd-45d6-4874-d1aa-3c5c558aqcc2"]
      issuer           = "https://sts.windows.net/aaee026e-8f37-410e-8869-72d9154873e4/"
    }
  }

Actual behavior
JWT authorizer is created OK  but is not attached as expected
Terminal Output Screenshot(s)

Additional context

UPD solved by using this advice https://github.com/hashicorp/terraform-provider-aws/issues/17497
added
 integrations = {

  ...
    "POST /apimethod" = {
     ...
     authorization_type = "JWT" // added
     authorizer_key          = "user_pool"
     }


invalid go version

Hi, running in debian linux kernel 6+ (MXlinux) raise this message:
"/home/elements/peerswap-web/go.mod:3: invalid go version '1.21.5': must match format 1.23"

"/home/elements/peerswap-web/go.mod:3: invalid go version '1.21.5': must match format 1.23"

Hello. Are you running the latest version of Go? 1.21.5 should not produce this error. If you cannot upgrade, try this:
Run 'go version' and put the value you get into go.mod file on line 3.

Ok, that's works!  thanks!


WIP: Rework controller link tests

Most of the change is due to golden files being added.
Apart from that I've removed all the ugliness of test setup and have grouped tests into sub-tests under their proper parent test (e.g. TestCreate, TestList, TestShow, TestUpdate, TestDelete)

@kwk snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1769-1

@kwk snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1769-2

@kwk snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1769-3

Codecov Report

Merging #1769 into master will increase coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1769      +/-   ##
==========================================
+ Coverage   57.33%   57.39%   +0.05%
==========================================
  Files         129      129
  Lines       15255    15255
==========================================
+ Hits         8746     8755       +9
+ Misses       5801     5795       -6
+ Partials      708      705       -3

Impacted Files
Coverage Δ

controller/work_item_relationships_links.go
62.16% <0%> (ø)
:arrow_up:

controller/work_item_link.go
81.31% <0%> (+2.47%)
:arrow_up:

Continue to review full report at Codecov.

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

@kwk snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1769-4

@kwk snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1769-5

[test]

[test]

[test]

[test]

[test]

[test]

[test]

[test]

[test]

[test]

Hey @kwk it is failing here
--- FAIL: TestList (0.04s)
    --- FAIL: TestList/OK (0.01s)
        --- FAIL: TestList/OK/for_/api/workitems/:id/relationships/links (0.01s)
        	golden_files_test.go:48: mismatch of actual output and golden-file /tmp/go/src/github.com/fabric8-services/fabric8-wit/controller/test-files/work_item_link/list/ok.golden.json:

No need to remind me @pranavgore09 . It failed mutliple times in different places which is why I run it from time to time to find them.

[test]

@kwk snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1769-6

@kwk snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1769-7

[test]

@kwk snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1769-8

[test]

[test]

[test]

[test]

[test]

[test]

[test]

@kwk snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1769-9

[test]

[test]

[test]

[test]


Add tool reporting outdated l10n documents by lastmod difference

This PR adds tool (report-outdated-by-mod.py) reporting outdated l10n documents by Lastmod difference.

Ref: #42441
"outdated content" warning on localization pages introduced in https://github.com/kubernetes/website/pull/41768. This automation adds a warning message to localization pages when the English version of the page has been updated more recently than the localized page. This is determined by comparing the Lastmod of a page in English and a given Localization.

This script compares markdown files across different language directories
to identify and report localized documents that may be outdated,
based on modification date differences.
It focuses primarily on:

Reporting outdated documents based on modification date differences.
Estimating false alerts.
Calculating the similarity between the English version and localized versions of documents.
(similarity analysis includes line counts, special character patterns, and English word usage patterns.)

The output in table style will be useful to maintaining localized documents and also checking overall status of all languages.
How to use
$ python ./scripts/report-outdated-by-mod.py --help
Usage: report-outdated-by-mod.py [-h] [--path PATH] [target_lang ...]

    Users can specify target languages for comparison against the English base.
    If no languages are specified, all directories will be compared.

    The path to the content directory can be specified using the --path parameter;
    if not provided, './content' or '../content' is used as the default.

positional arguments:
  target_lang  Target language directories (e.g., ko ja fr). If empty, all directories will be compared.

options:
  -h, --help   show this help message and exit
  --path PATH  Base content directory. Default is './content'

Screenshots

./scripts/report-outdated-by-mod.py ko

./scripts/report-outdated-by-mod.py

/area localization

Hi @divya-mohan0209 @reylejano @natalisucks
I think this PR is ready for approval. I believe this script is useful for localization teams as is, and the tool can be further enhanced if needed.

Since we have a much simpler script for this, i.e. scripts/lsync.sh, why bother adding a new tool which does almost the same thing?

If the new tool provides a benefit to a localization team, I think it's welcome, because we support localization teams to pick a workflow that works for them.
It's also OK to combine the lsync.sh and report-outdated-by-mod.py tools; that would need buy in from all the localization teams that rely on either tool.

Hi @tengqm @sftim
I understand that lsync.sh is a simple tool that is already being used effectively by specific localization teams to track differences between documents. However, I believe the script tool introduced in this PR has a somewhat different purpose, as described in the PR content.

Reporting outdated documents based on modification date differences.
Estimating false alerts. The output in table format will be useful for maintaining localized documents and checking the overall status of all languages.
Calculating the similarity between the English version and localized versions of documents. (The similarity analysis includes line counts, special character patterns, and English word usage patterns.)

Although it is possible to merge it with an existing script like lsync.sh, I think merging might not bring significant benefits to contributors who are already using the simple lsync.sh effectively for their purposes. In fact, it could introduce unnecessary inconvenience. Instead, I suggest treating the script introduced in this PR as a Proof of Concept and encouraging people to try it out and improve if necessary.

I like the idea of this, but I'm not in any localization team.
Also see https://github.com/kubernetes/website/pull/48163
/remove-lifecycle rotten

@seokho-son I've not LGTMed or approved this because:

I don't do localization work enough to check whether this script is useful
(AIUI) I shouldn't have access to approve this change

I recommend asking localization teams to try it out and comment.

@seokho-son I've not LGTMed or approved this because:
* I don't do localization work enough to check whether this script is useful

* (AIUI) I shouldn't have access to approve this change

I recommend asking localization teams to try it out and comment.

I'd like to second this—the review bot has asked me to review this PR. While I like the idea of this tool, I'm not on any localization team so my opinion of the tool isn't so useful.
/uncc @nate-double-u


Default Directories

In CMake, if you don't set the FAST_TEST_DATA_DIR, by default the data is downloaded to the source directory under data/.
By default, the configuration file doesn't have a data directory set because the FAST_TEST_DATA_DIR variable is empty:
# from CMakeList.txt, line 170
# If test data dir has been set by user, write it to config file
if(NOT FAST_TEST_DATA_DIR STREQUAL "")
    # Remove any existing "
    string(REPLACE "\"" "" FAST_TEST_DATA_DIR ${FAST_TEST_DATA_DIR})
    message("-- FAST test data directory set to: \"${FAST_TEST_DATA_DIR}\"")
    set(CONFIG_TEST_DATA_PATH "TestDataPath = ${FAST_TEST_DATA_DIR}/")
endif()

When reading the configuration file during the tests, the data path defaults to a directory named data in the build directory.
The same is true of the KernelSourcePath (see lines 71-80 of Config.cpp).
void loadConfiguration() {
    if (mConfigurationLoaded)
    	    return;

    // Set default paths
    mTestDataPath = getPath() + "../data/";
    mKernelSourcePath = getPath() + "../source/FAST/";
    mKernelBinaryPath = getPath() + "kernel_binaries/";
    mDocumentationPath = getPath() + "../doc/";
    mPipelinePath = getPath() + "../pipelines/";
    //....
}

The simple fix is to set the KernelSourcePath to a default value and to set the FAST_TEST_DATA_DIR variable to the default value if the user doesn't set it explicitly.

getPath() returns the path to the build directory, so getPath() + "../data/". Should become root/build/../data/, which gets resolved to root/data/. I have never had issues with this, so not sure how to reproduce what you are seeing?

@smistad My is build is not in the same directory as my source. I typically do out of source builds which keeps things much cleaner on my machine. So my source is in C:/Repositories/FAST and my build it in C:/Repositories/Fast-build. This way build and source are completely separate.
So on my machine, getPath() + "../data/" gets resolved to .../Fast-build/data not .../Fast/data.
In general (at least on windows) it's best to do out of source builds with cmake since that's kind of the point of the tool (to seperate source and build).
Is this structure different than what you're using? I should also note I'm using windows, so this could be a windows specific thing?

I see, personally I prefer to have the build dir in the root directory. But I know many prefer your method, and fast should definitely support it

@smistad Yeah it's probably more common on windows than anything else. This is mostly because we at times have to support multiple compilers so we do multiple builds of the same source.

Closing this since #80 was merged.


'az aks create' error if name contains character underscore(_)

az feedback auto-generates most of the information requested below, as of CLI version 2.0.62

Describe the bug

$> az aks create --resource-group wooccdocker -n "aks_woocccluster" --node-count 1
--name cannot exceed 63 characters and can only contain letters, numbers, or dashes (-).
Expected behavior

According to the document, underscore can be used for names.

Entity
Scope
Length
Valid Characters

managedClusters
resource group
1-63
Alphanumerics, underscores, and hyphens.Start and end with alphanumeric.

openShiftManagedClusters
resource group
1-30
Alphanumerics.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules#microsoftcontainerservice
Environment summary
$ az --version
azure-cli                         2.22.0
core                              2.22.0
telemetry                          1.0.6
Extensions:
subscription                       0.1.4
blueprint                          0.1.1
account                            0.2.1

We got the same problem, can you investigate on it ?

AKS service team should look into this

In my case, it happens when using the aks-preview extension which might be the effective root cause :
cli.azure.cli.core.commands: The behavior of this command has been altered by the following extension: aks-preview
cli.azure.cli.core.util: azure.cli.core.util.handle_exception is called with an exception:
cli.azure.cli.core.util: Traceback (most recent call last):
  File "/opt/az/lib/python3.6/site-packages/knack/cli.py", line 231, in invoke
    cmd_result = self.invocation.execute(args)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 645, in execute
    self._validation(expanded_arg)
  File "/opt/az/lib/python3.6/site-packages/knack/invocation.py", line 113, in _validation
    self._validate_arg_level(parsed_ns)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 853, in _validate_arg_level
    validator(**self._build_kwargs(validator, ns))
  File "/home/vagrant/.azure/cliextensions/aks-preview/azext_aks_preview/_validators.py", line 91, in validate_linux_host_name
    raise CLIError('--name cannot exceed 63 characters and can only contain '
knack.util.CLIError: --name cannot exceed 63 characters and can only contain letters, numbers, or dashes (-).

cli.azure.cli.core.azclierror: --name cannot exceed 63 characters and can only contain letters, numbers, or dashes (-).
az_command_data_logger: --name cannot exceed 63 characters and can only contain letters, numbers, or dashes (-).

Where the function validate_linux_host_name is called to validate the AKS cluster name and does not allow the underscore _ character.

https://github.com/Azure/azure-cli-extensions/blob/main/src/aks-preview/azext_aks_preview/_validators.py#L79
Maybe the issue should be moved to the https://github.com/Azure/azure-cli-extensions project ?


The web page is coming empty

Hi There,
I installed the web interface on dedicated win2019 server in the same network with the O365 backup server and i am using admin account to connect.
The web page is coming empty and it is not discovering  / reading the environment.
I have configured REST API 4443 on the O365 Backup server and when I try with tenant's account it is coming just with the  email/one drive/SP - but again empty ...
Am I missing something ?

Which VBO version are you running?

Hi Niels,
It is VBO <IP_ADDRESS>0.
It is installed in with CCB10 <IP_ADDRESS>4 on the same servers

I saw a pending update for VBO to <IP_ADDRESS>.
After the update, the VBO SS Portal is working!
Thanks for creating the Portal - this is great stuff and very helpful!

Thanks for sharing. I will have to do a test with <IP_ADDRESS> to see if there is a difference.


Initial library iteration

Prepared GH issue for a provider. Please review it before I create an issue for each provider. https://github.com/utopia-php/logger/issues/4

Does this library need to support PHP7.4? Can we run with PHP8 or 8.1?

Does this library need to support PHP7.4? Can we run with PHP8 or 8.1?

@eldadfux Your decision probably. I would guess code can work without problem on both. With v8, there might be features to make code cleaner.

@Meldiron We can stick to 8.0 and 8.1.

@kodumbeats @eldadfux Upgraded requirements to PHP 8.0 in commit https://github.com/utopia-php/logger/commit/db66b8c0c8f8595107cfb093c30b35c170b14887. Please let me know if that is all or I missed something.

@kodumbeats @eldadfux Upgraded requirements to PHP 8.0 in commit db66b8c. Please let me know if that is all or I missed something.

You should be good 👍


add Viewport support

Hi, I found myself needing the Viewport->WorkPos and ->WorkSize values, so I prototyped what the API might look like. This PR also has an unrelated demo (wrinkles) in it, sorry about the clutter.
I was wondering if I could request viewport functions as demonstrated here in zgui.cpp + zgui.zig?
I've marked the PR draft because I don't expect it to be merged, but feel free to cherry-pick if you like.
Thanks

Hi, and thanks for the patch!
It is now committed in: https://github.com/michal-z/zig-gamedev/commit/132d6763ff6ba4951ba9a171b373b1b3752b9172

@meshula Btw, can I ask what are you working on?

I'm working with a partner on a new mathematical representation of time, to replace the core calculations in OpenTimelineIO. We've discovered a way to eliminate the need to round off or snap time to framerates, and to match simulations of varying framerates, and to get the same results for time calculations across applications. The demo is meant to visualize how it works for when we roll it out, because in a way it's "quaternions for time", and I'd like to have people think it's intuitive rather than a mystery bag of math.
We're going to break opentime (https://github.com/AcademySoftwareFoundation/OpenTimelineIO/tree/main/src/opentime) out into its own library, written in C, so you can follow there over the next few months if you're interested, or in the "wrinkles (in time)" demo. I absolutely expect it to be super useful for games, and we're doing it in C so we can use it from all the languages we use :)
PS, I've built the demo inside of a fork of zig-gamedev because I'm struggling to build zig-gamedev when it is a git  submodule and my focus is getting my demo working, not solving the submodule problem ;). My working theory is that the comptime thisDir() function doesn't return the current build.zig's directory, but the root build.zig's directory. That's why did a spin of exploring the simulations repo to work out how it's being accomplished there.

Fantastic work on zgui by the way. I have any number of my own partial wrappings for Dear Imgui and microui, depending on what I needed on any one project. zgui by far has the nicest wrapping pattern I've tried.

@meshula This sounds very interesting! I will be following your work for sure!
Personally I don't like submodules but below project got it working with zig-gamedev:
https://github.com/ckrowland/simulations
For now, the recommended way of using zig-gamedev is to just copy needed libraries or use the whole package as you did.

I haven't tried copying before. I assume that would mean copying the z* libs in zig-out/libs to somewhere in my project, and then use LibExeObjStep.addPackage and addPackagePath to point to each of the libraries, which I could then @import in the normal way.

Yes, here is an instruction for zgpu:
Copy zgpu, zpool and zglfw folders to a libs subdirectory of the root of your project.
Then in your build.zig add:
const zgpu = @import("libs/zgpu/build.zig");
const zpool = @import("libs/zpool/build.zig");
const zglfw = @import("libs/zglfw/build.zig");

pub fn build(b: *std.build.Builder) void {
    ...
    const zgpu_pkg = zgpu.getPkg(&.{ zpool.pkg, zglfw.pkg });

    exe.addPackage(zgpu_pkg);
    exe.addPackage(zglfw.pkg);

    zgpu.link(exe);
    zglfw.link(exe);
}

Perfect, thank you very much!!

I see you have similar instructions in the individual lib readme files. I put together a new repo following that pattern, and it worked like a charm. https://github.com/meshula/wrinkles


AoC month changes

Description

This allows AoC commands to be ran in January, along with limiting AoC join to only be ran in Nov, Dec and Jan.
This also removes the aoc subscribe command, since Python has a replacement for it now.
Did you:

[ ] Join the Python Discord Community?
[ ] Read all the comments in this template?
[ ] Ensure there is an issue open, or link relevant discord discussions?
[ ] Read and agree to the contributing guidelines?

https://github.com/python-discord/sir-lancebot/pull/996/commits/e7e023867a6135b2e6962c9e110aa1bc0f0fe4bb

Dupe of #972

https://github.com/python-discord/sir-lancebot/pull/996/commits/e7e023867a6135b2e6962c9e110aa1bc0f0fe4bb

Dupe of #972

.aoc stats needs a restrictive decorator as well.
Might want to consider it for .aoc refresh as well, even though its staff only, it would cause a sentry issue.

Feel free to open an issue. Don't want to delay this PR though.

.aoc stats needs a restrictive decorator as well.
Might want to consider it for .aoc refresh as well, even though its staff only, it would cause a sentry issue.

Feel free to open an issue. Don't want to delay this PR though.

Feel free to open an issue. Don't want to delay this PR though.

Everything else works, this will just cause a sentry error in February as the code isn't made for that. (Tried it with month override to February.)
If I don't open an issue sentry will

Feel free to open an issue. Don't want to delay this PR though.

Everything else works, this will just cause a sentry error in February as the code isn't made for that. (Tried it with month override to February.)
If I don't open an issue sentry will

Feel free to open an issue. Don't want to delay this PR though.

Everything else works, this will just cause a sentry error in February as the code isn't made for that. (Tried it with month override to February.)
If I don't open an issue sentry will

"the code isn't made for that". Yes it is, you just need to set the AOC_YEAR env var, otherwise it will try to get next year's leaderboard.
Please don't make assumptions about the code and then say there are a "few bugs".

Feel free to open an issue. Don't want to delay this PR though.

Everything else works, this will just cause a sentry error in February as the code isn't made for that. (Tried it with month override to February.)
If I don't open an issue sentry will

"the code isn't made for that". Yes it is, you just need to set the AOC_YEAR env var, otherwise it will try to get next year's leaderboard.
Please don't make assumptions about the code and then say there are a "few bugs".

Yes it is, you just need to set the AOC_YEAR env var, otherwise it will try to get next year's leaderboard.

No where is it documented that this variable has to be set in production. The contributing guide says debug, which I presumed would not need to be used in prod.

link to guide
I now understand that it is currently being used in prod, but this was not made clear in the issue body, nor comments, until after my review.

Yes it is, you just need to set the AOC_YEAR env var, otherwise it will try to get next year's leaderboard.

No where is it documented that this variable has to be set in production. The contributing guide says debug, which I presumed would not need to be used in prod.

link to guide
I now understand that it is currently being used in prod, but this was not made clear in the issue body, nor comments, until after my review.

Yes it is, you just need to set the AOC_YEAR env var, otherwise it will try to get next year's leaderboard.

No where is it documented that this variable has to be set in production. The contributing guide says debug, which I presumed would not need to be used in prod.
link to guide
I now understand that it is currently being used in prod, but this was not made clear in the issue body, nor comments, until after my review.

I can understand where you are coming from, really. The contribution guidelines can be made clearer in that respect, but there's only so much you can do with limited room in that table.
My point however was you are calling out this PR saying it has a few bugs. However, that area of the code hasn't even been changed in this PR, neither are they actual bugs.
While I don't mind it so much someone else, who is maybe new to contributing to our projects, would be put off by comments like this, so I wanted to raise it here so that it doesn't happen to someone else.

Yes it is, you just need to set the AOC_YEAR env var, otherwise it will try to get next year's leaderboard.

No where is it documented that this variable has to be set in production. The contributing guide says debug, which I presumed would not need to be used in prod.
link to guide
I now understand that it is currently being used in prod, but this was not made clear in the issue body, nor comments, until after my review.

I can understand where you are coming from, really. The contribution guidelines can be made clearer in that respect, but there's only so much you can do with limited room in that table.
My point however was you are calling out this PR saying it has a few bugs. However, that area of the code hasn't even been changed in this PR, neither are they actual bugs.
While I don't mind it so much someone else, who is maybe new to contributing to our projects, would be put off by comments like this, so I wanted to raise it here so that it doesn't happen to someone else.

While I don't mind it so much someone else, who is maybe new to contributing to our projects, would be put off by comments like this, so I wanted to raise it here so that it doesn't happen to someone else.

yeah ofc

While I don't mind it so much someone else, who is maybe new to contributing to our projects, would be put off by comments like this, so I wanted to raise it here so that it doesn't happen to someone else.

yeah ofc


I paste the string of code from patreon-dl and get this error

VM169:54 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'split')
at eval (eval at  (posts:1), :54:78)
sorry if this is a common fix and i failed to understand it I'm new to this.

That looks like a bug. What account did you run this on?

That looks like a bug. What account did you run this on?

Asyrie

Asyrie

Same error here.

Same error here. Its in the for loop that adds the file to downloads, you'll want to check for falsy in parsedInital.included[i].attributes.file_name before splitting it and calling addFileDownload.

@Zaneaby Good call. I'll get a new release on when I get the opportunity to do so.

A new release has been published, it should fix this issue.


Very basic type-checking seems broken.

Flow version: v0.107
Not sure if I'm crazy, but some very basic type checking seems to be just broken? Given
type Record = {
   foo: number,
   bar: string
}

const x: Record = {};

Expected behavior
Error indicating x is not of type Record
Actual behavior
No errors!

Link to Try-Flow or Github repo:
https://flow.org/try/#0C4TwDgpgBAShDGB7ATgEygXigbwFBQIDNFEAuKAOwFcBbAIwmQBp8C6BDZcgZ2GQEsKAc1wBfXLiQVeUAB7k4SNJhyiA3LiA

If you make the object exact, it does correctly errors.
The same if you add a property to the empty object.
I think this is related to: https://github.com/facebook/flow/issues/2977
And the weird differences you get with empty objects.

{} is special in flow, it's an unsealed object. The easiest way to avoid this is to do something like { ...null } which will result in a regular empty object.

https://github.com/facebook/flow/issues/7424

Wow, that really clashes with your expectations after hearing Flow is supposed to value "soundness".
Always appreciate the hard work of devs to provide the community things for free, but feels like this whole project would be better off managing your expectations on it a differently.
Going to close this since #7424 seems to track this.
:+1: on removing unsealed objects fwiw.


video_player can't load and play video from the network from http requests, only https are working

i'm trying to create new video player app that load vast xml and and extract the data from it.
one item in the data  is video file, it can be http or https and i can't know in advance,
i can't just replace http to https because then i can be wrong domain name.
is there a why to stream the video file with http?
Thaks.

As stated in the readme you need to add NSAppTransportSecurity -> NSAllowsArbitraryLoads to your Info.plist in order to load things over http on the iOS platform...

@roischr if the feedback above helped, could you close this issue?

As no reply came till now I close this issue


Fixing Redirect on Successful License Submission

Intended to Solve #449

Looks like @rtgdk comment has been resolved - I'll go ahead and merge to include in the next update


[GitHub Desktop] Stashing changes feature

Why:
Closes #1202
This PR creates a new article, "Stashing changes," to document a new feature and moves content about stashing changes from "Managing branches" to the new article.
What's being changed:
I used two reusables/two steps for the new procedure on stashing changes rather than one so that click-changed-files-header.md can be reused if the Discard All Changes feature is documented later.

Article in staging
Source
Changes

"Stashing changes"
Source
Create new article

index.md
Source
Update index

"Managing branches"
Source
Move content about restoring stashed changes to new article

Check off the following:

[x] I have reviewed my changes in staging. (look for the deploy-to-heroku link in your pull request, then click View deployment)
[x] For content changes, I have reviewed the localization checklist
[x] For content changes, I have reviewed the Content style guide for GitHub Docs.

@main
I'm new and sry about node


MINIFI-521 - Update template version for MINIFI toolkit

Thank you for submitting a contribution to Apache NiFi - MiNiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[ ] Does your PR title start with MINIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[ ] Has your PR been rebased against the latest commit within the target branch (typically master)?

[ ] Is your initial contribution a single, squashed commit?

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi-minifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under minifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under minifi-assembly?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

hey @nghiaxlee, this will certainly solve the issue laid out.  Going to combine this with #185 to accommodate additional changes.


Add CreateTransportOptions to PeerConnectionServer constructor

This opens up the override options needed to to disabling e.g. REMB (disableREMB) as a CreateTransportOptions is misssing when creating the PeerConnectionServer
Handles issue from #240

could you sign the CLA? https://cla-assistant.io/medooze/media-server-node

thank you very much!


Omit vendor install docs from scheduling task

This change might mean that the changes proposed in https://github.com/kubernetes/website/pull/36982 are no longer needed.
Relevant to https://github.com/kubernetes/website/issues/36983
Fixes #36983

/assign

@rolfedh can you clarify whether you're suggesting further improvements to the page that might be made at some point, or whether the feedback so far represents changes that I as author must make as part of omitting vendor details?
When we make changes that relate to a specific issue, I'm wary of also recommending general unrelated improvements. My advice is to keep PRs small and focused.

@rolfedh can you clarify whether you're suggesting further improvements to the page that might be made at some point, or whether the feedback so far represents changes that I as author must make as part of omitting vendor details?

Hi Tim. Thanks for requesting clarification. These suggestions are based on our review process, which states "In general, review pull requests for content and style in English", and some of the guidelines in our style guide. You're free to apply the suggestions you think improve the quality of the content you're updating or adding, and ignore the rest.

Imo, all current comments and suggestions are non-blocking (including mine)
Current comments and suggestions can be proposed in a follow-up PR if reviewers like to do so
/lgtm

Re-applying my lgtm
/lgtm

since there's a second lgtm from this comment
/approve


File system disposal after data connection end

I have a custom implementation of the in-memory file system, when a connection end it is automatically disposed?

It should be disposed automatically when the connection was closed.


"Manual" for iota-pm ...

Hi akashgoswami
can you (or someone else) clarify what the different transactions numbers (all, random, new, invalid and sent) mean? Or point me to where I can get some information about them?
Thx a lot!
kind regards
opel22

Hi Opel22,
IOTA PM calls following API for this information
https://iota.readme.io/reference#getneighborsactivity

@opel22 Take a look here where I add a tiny bit more information to the counters.


breakfix: Git username prompt breaks building docker image with this plugin

Hello, this error is thrown while building the Dockerfile below:
2022/09/14 16:22:13 [INFO] exec (timeout=0s): /usr/local/go/bin/go get -d -v github.com/greenpau/caddygit/module/git<EMAIL_ADDRESS>go: module github.com/greenpau/caddygit/module/git: git ls-remote -q origin in /go/pkg/mod/cache/vcs/49b5969af648321b8e1b610bca7e23162a006c17f126d617be4906822618e6bc: exit status 128:
	fatal: could not read Username for 'https://github.com': terminal prompts disabled
Confirm the import path was entered correctly.
If this is a private repository, see https://golang.org/doc/faq#git_https for additional information.
2022/09/14 16:22:16 [FATAL] exit status 1

Dockerfile
FROM caddy:builder AS builder

RUN xcaddy build \
    --with github.com/greenpau/caddygit/

FROM caddy:latest

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

Configuration
Paste full Caddyfile below:
{
    email REDACTED

    git {
        repo REDACTED.com {
            base_dir /srv/REDACTED
            url https://github.com/REDACTED/REDACTED.git
            webhook Github X-Hub-Signature-256 {$WEBHOOK_SECRET}
            branch main
        }
    }
}

REDACTED.com, www.REDACTED.com {
    root * /srv/REDACTED

    route /update {
        git update repo REDACTED.com
    }

    route {
        file_server {
            hide .git*
        }
    }
}

REDACTED.REDACTED.com {
  encode gzip

  reverse_proxy /notifications/hub REDACTED:REDACTED

  reverse_proxy REDACTED:REDACTED {
       header_up X-Real-IP {remote_host}
  }
}

Version Information
N/A, build issue
Expected behavior
Plugin should build

Yes

It seems that the issue happens because authentication fails when downloading this plug-in from github, which does not make any sense since this repo is public.

The fix was typing the repo url correctly (github.com/greenpau/caddygit -> github.com/greenpau/caddy-git). Thank you for the quick response.


Adding Spiral Framework recipe

[ -] Bug fix #…?
[+] New feature?
[ -] BC breaks?
[ -] Tests added?
[ -] Docs added?

I tried to add an E2E test, but the testing infrastructure uses PHP 7.3. Minimum required PHP version for Spiral Framework 8.1.

@antonmedv Hi. Could you review this PR? Thx!


Catch project.deploy() not updating

Having an invalid looker_project_name may not give errors, but it means the deploy webhook might fail silently. Ideally we catch the response from the webhook and notify that nothing was updated
proj = lookml.Project(
  repo= "organization/customer-repo",
  access_token="abc123",
  #Optional args for the deploy URL (for deploying directly to prodcution mode)
  looker_host="https://customer.looker.com/",
  looker_project_name="wrong_project_name"
)

for f in files:
  proj.put(f)

proj.deploy()

Will review this shortly

Will review this shortly


4/7 - Coworking Session - 5:00-7:00 - STO 442

Come join us for a coworking session. These are great sessions to work on your project and reinforce the lessons we have already learned.

Changing this to 4/7 so we can do R Shiny on 3/24

One idea is to do a code review session following Mozilla's guide.
Thoughts?

I think code review would be a fantastic idea. We've started doing it internally in our lab, and it's been great. Having some outside opinion would be even better.
:+1:

One idea I heard in a Study Group call was having 10-15 minute code reviews that the group would look at. Thoughts? Ideas?

:+1: That sounds great! Is it something we'd do at every study group meeting, or something that we'd schedule independently?
Alternatively, we could set up a system of rotating code/repository review, where somebody volunteers their script/repository each week and the rest of us comment on it. That way, we don't have to worry about scheduling conflicts. We could do this just through vanilla GitHub, but maybe there's some nice open-source code review software that we could leverage? From 2 minutes of Googling, I found Gerrit, which could be promising, though I haven't tested it.

@ceholden  @wkearn  - thoughts? Suggestions? It could also be interesting to try to connect with a few CS folks.

:+1: for me on code review. We've taken baby steps toward implementing this in our lab group, but we're basically flying blind on what to do and what strategies to employ. I'd love to see what others are doing or just chat about code review, especially if we could get some CS people to come hangout.
I haven't used any software dedicated to code review (like Gerrit that Alexey mentioned), but I have some understanding of how to do a code review using Github by following a handful of open source projects that basically do code review during a PR. These projects are small enough or have small enough needs for Github's built-in tools to accommodate, but I suspect it would break down at scale where a dedicated software would really shine.

Code review via Pull Requests is exactly how we do it in our lab, and it
works pretty well, but as you mentioned, those are typically pretty small
changes. Also, I think the kind of code review we'd do here wouldn't
necessarily lend itself to that format, unless we create new repositories
and submit toy pull requests to them, which feels kind of awkward.
:+1: for getting CS people involved.
On Wed, Mar 16, 2016 at 10:28 AM Chris Holden<EMAIL_ADDRESS>wrote:

[image: :+1:] for me on code review. We've taken baby steps toward
implementing this in our lab group, but we're basically flying blind on
what to do and what strategies to employ. I'd love to see what others are
doing or just chat about code review, especially if we could get some CS
people to come hangout.
I haven't used any software dedicated to code review (like Gerrit that
Alexey mentioned), but I have some understanding of how to do a code review
using Github by following a handful of open source projects that basically
do code review during a PR. These projects are small enough or have small
enough needs for Github's built-in tools to accommodate, but I suspect it
would break down at scale where a dedicated software would really shine.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/bulib/studyGroup/issues/31#issuecomment-197354525

If there is interest tonight perhaps we can talk a little about the summer / #34 as well as do a quick feedback session.

A quick note from today's session, for those interested in Open Refine, the library has a copy of Using Open Refine

@tomhohenstein Great tip! I look forward to playing with it.
When poking around for possible R packages for interacting with Open Refine, I came across the IBM Data Scientist Workbench, a web interface that combines Open Refine, Rstudio, Jupyter, and some other stuff for facilitating data workflows. Haven't played with it yet, but looks promising!

Very cool - I signed up for it. I'll let you know how it goes.
Also - last night we had 4 attendees

@keithfma - if we could build a workbench using the cluster, we'd be heros (or nerds) or both. the IBM workbench is pretty pretty cool.


Re-apply "SIL: Remove special meaning for @semantics("stdlib_binary…

…only")"
With -sil-serialize-all gone, this no longer means anything; just
don't declare the function as @_inlineable instead.
Fixes rdar://problem/34564380.

@swift-ci Please smoke test

This broke stuff before. A smoke test is not sufficient.
@swift-ci Please clean test

(he says, wearing his build czar hat)

And I've confirmed locally that the revert fixes things.

Can you send me a failing build log? PR testing doesn't build StdlibUnittest with -sil-serialize-all, only some presets do that. It was put in place originally to improve optimizer test coverage by a bit, but it blows up build time. I don't think we're losing much by removing that.

https://ci.swift.org/job/oss-swift_tools-RA_stdlib-RD_test-simulator/177/

If the stdlib and perf teams are okay with the loss of coverage then we're fine, but please hold off on removing stdlib_binary_only until -sil-serialize-all is actually gone (Roman's patch).

@swift-ci Please smoke test

This has been merged into https://github.com/apple/swift/pull/12256, closing


Service Discovery: Reduce number of packages that are dependent on our SD implementations (e.g K8s, Azure) to just main.

Proposal
Prometheus has official support for numerous discovery mechanisms by default.
Currently, those are in the form of separate packages: https://github.com/prometheus/prometheus/tree/0730d6eb74a2a6e268260a800f5de90958d0253a/discovery
Each of those implementations is pretty specific and depends on large (very often larger than Prometheus itself) dependant Go modules (e.g Azure, Google, AWS).
That causes a few issues:

Big Prometheus binary size (not a big problem, but causes some issues for rate users who run Prom within IoT, e.g. in their fridge)
It is blocking the reusability of many packages. Currently, many packages depend on config -> depends on discovery stuff. This means that many packages are affected by huge dependency baggage. This blocks external projects e.g Thanos or Cortex to reuse such packages does not want to have extra dependencies that cause de hell (e.g mismatching versions).

All of the above also results in a blocker to extend official ones with custom SD plugins (e.g for docker).
Unfortunately on top of this there is overall go module problems described many times.
The overall first step, we should think about now, is how we can reduce the number of packages that depend on SD implementation to just one (main).
Prometheus Discovery package dependency Inspection
goda graph -short github.com/prometheus/prometheus/cmd/prometheus | dot -Tsvg -o graph.svg
NOTE: It's too big to render readable PNG Only SVG is usable. But just look on this!

Most of it is Kubernetes, so after we ignore k8s to see anything and focusing on discovery:
goda graph -short github.com/prometheus/prometheus/cmd/prometheus - github.com/prometheus/prometheus/discovery/kubernetes | dot -Tsvg -o smgraph.svg

As we see there are 3 links we might want to change as part of this work:

[ ] main -> discovery -> discovery/config -> SD implementations
[ ] main -> discovery/config -> SD implementations
[ ] main -> config ->  discovery/config -> SD implementations

Idea is to have just main. The problem is how to make the indirection required for config. Well, there is one solution that we chosen in Thanos, see:
https://github.com/thanos-io/thanos/blob/55cb8ca38b3539381dc6a781e637df15c694e50a/pkg/objstore/client/factory.go#L38
With such factory and config alignment we can have instead of this:
// ScrapeConfig configures a scraping unit for Prometheus.
type ScrapeConfig struct {
         // ( ...)

	ServiceDiscoveryConfig sd_config.ServiceDiscoveryConfig `yaml:",inline"`
}

We can have:
// ScrapeConfig configures a scraping unit for Prometheus.
type ScrapeConfig struct {
         // ( ...) b
	ServiceDiscoveryConfig yaml.Unmarshaler `yaml:",inline"`
}

Then we can have unmarshaler which knows which implementation's configuration to use. Such marshaller will be added by main.go only, so config will no longer be dependent on all SD.
Help wanted! :hugs:

I removed low hanging fruit as I think that it should be done by someone experienced; I think marking it as low hanging fruit might lead to pull requests that will take ages to be merged. WDYT?

Yeah, this one is going to be non-trivial. It's not the sort of things someone new to the project could plausibly figure out in an afternoon.

I'm interested in taking a crack at this, but by definition it's going to require breaking package APIs... Are there any stability guarantees around the config/discovery packages that must be respected, besides the YAML formatting?

I'm interested in taking a crack at this, but by definition it's going to require breaking package APIs... Are there any stability guarantees around the config/discovery packages that must be respected, besides the YAML formatting?

Hello, I am already working on this one.

Hello, I am already working on this one.

I see. Here's what I had already implemented: https://gist.github.com/abursavich/dfd8541dad8e33e1eeb12af987e1a58d

Sure.

Are there any stability guarantees around the config/discovery packages that must be respected, besides the YAML formatting?

There are none, however we should try to avoid requiring any changes to https://github.com/prometheus/prometheus/tree/master/documentation/examples/custom-sd
If we do end up having to break that, there's some more things I'd like to cleanup there while we're at it.

I don't see anything in custom-sd that would need to change.

In an attempt to make this as painless as possible, I've gone down a pretty deep rabbit hole with YAML parsing... creating several issues and PRs upsteam (https://github.com/go-yaml/yaml/issues/639, https://github.com/go-yaml/yaml/issues/640, https://github.com/go-yaml/yaml/issues/641, https://github.com/go-yaml/yaml/issues/642, https://github.com/go-yaml/yaml/issues/643).
Implementing this change requires using a custom yaml.Unmarshaler for the type that will hold the service discovery configs (currently ServiceDiscoveryConfig), since that type can't have dependencies on the implementations and the expected fields will be dynamic at runtime. These configs are then inlined into ScrapeConfig and AlertmanagerConfig, which is where we run into a problem with using "strict" yaml unmarshaling.
Both yaml.v2 and yaml.v3 rely solely on the fields in the go structs to implement known-field matching. Currently, there's no way to account for fields that are only used in a custom yaml.Unmarshaler and do not otherwise exist in the structs. These "extra" fields that the custom yaml.Unmarshaller is actually expecting will always result in an "unexpected field" error.
Here's a small-ish example: https://play.golang.com/p/Ma_TavWqKwI
Without making deep (unwelcome?) changes to the yaml package, it seems like the options are:

Remove strictness in unmarshaling yaml configs. Configs with typos or unknown/unsupported fields would be silently accepted.
Remove inlining of service discovery configs in ScrapeConfig and AlertmanagerConfig. This would be a breaking change and existing YAML configs would need to be modified when upgrading.
Hoist the dynamic unmarshaling out of a shared type (e.g. ServiceDiscoveryConfig) and implement it in both ScrapeConfig and AlertmanagerConfig's custom UnmarshalYAML methods. This will make the implementation more complicated and messy, but should have the least impact.

Thoughts before proceeding further?

More path:

The approach used in https://github.com/Ompluscator/dynamic-struct

Or even unmarshalling a map[string]interface{}, removing the keys from SD's and re-marshalling the rest of the struct.

I hadn't seen dynamic-struct package before, but I was using reflect the same way to create a new type with fields for the registered discovery mechanisms at runtime.  The problem is that I can't (3) abstract the special yaml.Unmarshaler into a single static type, (2) inline that type into other types (ScrapeConfig and AlertmanagerConfig), and (1) support strict decoding mode. I have to give up on one of 1, 2, or 3.

and 2. are not acceptable to me:

leads users with issues like typos etc which means that Prometheus does not behave like they would expect (e.g. because they use scrape config).

This is breaking change too; unless we hardcode all the existing implementations (?) but that does not sound right.

I'd say that we should go for 3. I am not afraid of it being "a bit more messy" if it's properly tested. Do you already have an idea of what it would look like?
(or ro you think we could also upstram to yaml an option to register fields to ignore with the strict unmarshaling?)

I'm also leaning to 3. I haven't written anything for it yet, but I'll try to come up with something clean. I don't think this will be a problem in practice, but it's worth mentioning that the same problem will reemerge if ScrapeConfig or AlertmanagerConfig are ever inlined into any other config types.

Awesome, should you be blocked or have further questions, do not hesitate to come back to us.
Note that if you think that 2. would be really a lot more clean, maybe we could keep a compatibility layer for the existing service discoveries and add the new ones to the new way of configuring SD's.

Cool.
I think 2 would be a very bad user experience, but it would be the easiest way of side-stepping the issues with the yaml package now and in the future. If it would require adding a compatibility layer, then I don't think there's any reason to do it. I mostly bring it up for completeness and in case there's another breaking change in the works and it makes sense to bundle them together.

Actually, we could just keep the field names as it for now. Without having two ways to configure them.
And just users would not be able to register any service discoveries, just the ones we have now.
In the mean time we can see with upstream yaml what would be the best solution.

Also, it 3 is just having a field: CustomSDs map[string]interface{} "yaml,inline" and raise an error upon Unmarshal when the sd is not known, that is probably not too hard to implement?

Fixed by #7701.