[RFC] Eclipse plugin

For real this time: an Eclipse plugin.
@Balletie @gfokkema Please provide early feedback on what is there currently!

@gfokkema Also please look at the folded comments.

Might want to consider passing Composite by assisted inject, instead of introducing state in the guice module.

The RxJava implementation (6dc1d75545e5ed82a13dbe8bb799c52db7e5753b) is not really where we want to be, but before I improve that I want to have drawn out the model of how the KeyListeners are going to work (I'm thinking strategy pattern here with a listener for single line and a listener for multiline mode, but perhaps this is overkill -- I haven't really thought about the differences in keybindings yet).
Before I do that, however, I'm going to look into syntax highlighting as I think that's more important for the demo tomorrow.

@Balletie @gfokkema New features such as completions, hovers, syntax highlighting et cetera require more changes than I'm willing to make in this PR. I think it's ready to review: it provides a basic plugin that is already usable.

I have resolved all of @gfokkema's comments. @Balletie your turn :smile:

Rebased on #20.

After 292c02c5402c0490dba3b8d36947c57a78fee6a3, the aggregator pom is completely redundant. Perhaps we should remove it?

The build errors seem to have been resolved. It builds locally in Maven, for me. To actually run the Eclipse plugin from Eclipse, you need to open org.metaborg.spoofax.eclipse.externaldeps, org.metaborg.spoofax.eclipse.meta and org.metaborg.meta.lang.dynsem.interpreter. Next, go to Run -> Run Configurations, click on the Plug-ins tab and make sure to de-select org.metaborg.spoofax.eclipse.externaldeps and org.metaborg.spoofax.eclipse.meta under Target Platform. Make sure all three projects mentioned are selected under Workspace.
The Eclipse projects are to resolve the changes I made in our Spoofax Eclipse fork which in due time will have to make it upstream. The dynsem project should be embedded into our org.metaborg.spoofax.shell.eclipse.externaldeps module, but for some reason this still does not work. Maven has no problem resolving it, so opening this project is purely an Eclipse-workaround.


✨ Add line number to unpinned dependency: GitHub workflow "uses" field

Please check if the PR fulfills these requirements

[x] Tests for the changes have been added (for bug fixes / features)
[x] PR title follows the guidelines defined in  https://github.com/ossf/scorecard/blob/main/CONTRIBUTING.md#pr-process

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature

What is the current behavior? (You can also link to an open issue here)
Line numbers are not displayed in the results when there are unpinned dependencies.
#725

What is the new behavior (if this is a feature change)?
When there is an unpinned uses field in a .github/workflows file , the line number for the uses field will be displayed in the detailed results.
I will create additional PRs to add line numbers for other places in the code that deal with unpinned dependencies.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No

Other information:
I updated gopkg.in/yaml to v3 in checks/pinned_dependencies.go in order to use the newer UnmarshalYAML() in order to set the line number of the field. I did not update other files to go from gopkg.in/yaml/v2 to ``gopkg.in/yaml/v3` because when I tried doing so, some of the test for Token-Permissions failed.

Thanks,Could we add some tests to this?

Sure thing, I'll get some added.

Tests have been added.

FYI, we can start migrating to using new structure. Example in https://github.com/ossf/scorecard/pull/883

@laurentsimon Is this good to merge?

I wanted to wait for @chrismcgehee to migrate the changes he made to the new structured results (https://github.com/ossf/scorecard/pull/883), if possible.
@chrismcgehee what option do you prefer? Merge as-is or do you want to take a second pass?

@chrismcgehee what option do you prefer? Merge as-is or wait for you to update?

I'd like to update this PR to take advantage of the logging structure.


fix(build): Use ttsc for compiling

#701 introduced a change to fix imports like "../../core/src" showing up in .d.ts files. However, if you install the latest version (v3.1.1) of stoplight/prism-cli, you'll see that the relative imports still exist in the built package, as no version has been published after this change.
Additionally, the build step in package.json still reads: tsc --build ./packages/tsconfig.build.json; this PR updates it to use ttsc instead, so that type files are created correctly when building locally. The CircleCI config has also been updated to use this build script instead of the one-off npx command.

Hey @BinaryMuse

However, if you install the latest version (v3.1.1) of stoplight/prism-cli, you'll see that the relative imports still exist in the built package, as no version has been published after this change.

This is correct! We haven't been able to publish (yet) 3.2.0 as we're doing some final e2e tests. However, we have a tagged beta that you can install in case you want to try it out right now.
Thank for the PR, I missed this step!

Hey, yes, I'm trying to build a dynamic mock server that, given a sha, can fetch the OpenAPI for that sha, then serve mock requests 😅  I know it's a bit off the beaten track for this project, but since you all have done so much great work in this area already, it'd be silly for me to reinvent the wheel without trying this out first.
For the moment, it works fine: it's just a very small OpenAPI spec, so fetching, parsing and mocking in a single request cycle is fine. But we'll see how it grows 😆
This was my first go at TypeScript, so I called for help when I encountered the error mentioned above. Thanks for your work on this! I'll keep an eye out for the new release.

Ah nice, understood. So basically what's making you use Prism programmatically is the data source. Neat stuff!


Small format fixes

@davidgasquez many thanks for the pull! Everything here LGTM. There's 1 minor thing which is that CI is failing because the document you modified gets compiled as a binary asset for pachctl and thus needs to be recompiled. If you do make assets from the root of the repo and push the results it should get CI passing.

I see! Thanks for pointing me to make assets. Just ran it and committed the new assets.go file. Let me know if I should do anything else.

@davidgasquez awesome, thanks! That should do it as soon as CI passes I'll hit the merge button.

Nice! One thing I've noticed is that there are two types of documentation files, .rst and .md. It's probably for a specific reason but I was thinking if moving everything to Markdown would improve consistency in the formatting.

@JoeyZwicker would that work with ReadTheDocs? I think ReadTheDocs might require a RST.

I think it should work (PFS documentation is written in Markdown), although perhaps RST has more formatting options.

Ugh, seems like the CI build is still failing! 😅

@davidgasquez yeah, unfortunately our CI can be flaky at times. Anecdotally it seems to coincide with high traffic periods such as the end of the day on Friday. I'll keep trying it, and I bet it'll pass eventually.

The rst format is needed for some features of ReadtheDocs that we use. In general, docs that are mainly read on the documentation website are in rst and things that are meant to be viewed on GH (such as Readme's for examples) are md.
For these files I think we want to keep the formats as is, but it's something we've certainly considered unifying in the future.

Thanks for the info @JoeyZwicker! I just wanted to point this super small thing in case you missed. Makes sense to keep both formats then.

Seems that the check are still failing... 🤔 Anything I can do?

@davidgasquez pretty sure this are spurious failures so not much to be done on your end. I'm going to rerun a few times and see if I can get it to pass.

Praise the CI gods it passed. Merging.

Awesome! I'm deleting the branch then! 😉


[SPARK-6211][Streaming] Add Python Kafka API unit test

Refactor the Kafka unit test and add Python API support. CC @tdas @davies please help to review, thanks a lot.

Test build #28427 has started for   PR 4961 at commit d4f2e5b.

This patch merges cleanly.

Test build #28427 has finished for   PR 4961 at commit d4f2e5b.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
 class EmbeddedZookeeper(val zkConnect: String)

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

Test build #28429 has started for   PR 4961 at commit 4898694.

This patch merges cleanly.

Test build #28429 has finished for   PR 4961 at commit 4898694.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
 class EmbeddedZookeeper(val zkConnect: String)

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

Jenkins, retest this please.

Test build #28431 has started for   PR 4961 at commit 4898694.

This patch merges cleanly.

Test build #28431 has finished for   PR 4961 at commit 4898694.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
 class EmbeddedZookeeper(val zkConnect: String)

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

Test build #28458 has started for   PR 4961 at commit f66a067.

This patch merges cleanly.

Test build #28458 has finished for   PR 4961 at commit f66a067.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
 class EmbeddedZookeeper(val zkConnect: String)

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

Hi @davies @tdas , I added the Python Kafka API unit test, it works very well in my local test, but seems always failed in Jenkins test with error like:
Traceback (most recent call last):
  File "pyspark/streaming/tests.py", line 568, in setUp
    .loadClass("org.apache.spark.streaming.kafka.KafkaTestUtils")
  File "/home/jenkins/workspace/SparkPullRequestBuilder/python/lib/py4j-<IP_ADDRESS>-src.zip/py4j/java_gateway.py", line 538, in __call__
    self.target_id, self.name)
  File "/home/jenkins/workspace/SparkPullRequestBuilder/python/lib/py4j-<IP_ADDRESS>-src.zip/py4j/protocol.py", line 300, in get_return_value
    format(target_id, '.', name), value)
Py4JJavaError: An error occurred while calling o4409.loadClass.
: java.lang.ClassNotFoundException: org.apache.spark.streaming.kafka.KafkaTestUtils

I'm sure I added the kafka assembly jar with --jars, as you can see I dump the log into console:
Additional argument: --jars /home/jenkins/workspace/SparkPullRequestBuilder/external/kafka-assembly/target/scala-2.10/spark-streaming-kafka-assembly_2.10-1.3.0-SNAPSHOT.jar

I'm not sure is there any environment difference or something should be  taken care when testing in Jenkins, would you please give me some hints? Thanks a lot.

Looks like it is a difference between Maven and SBT, run-tests script package the jars using maven do not generate kafka-assembly fat jar. I'm going to find out a solution to fix this.

This seems like a bug that was fixed couple of weeks ago. Are you sure you have merged with master recently. In fact the PR has merge conflicts.

Other than the assembly issue, its looks quite good. Only a few minor comments.

Thanks a lot @tdas for your review, actually I rebased the code in my local environment and tried to test again, seems a recent merged PR #3916 changed the behavior of pyspark, so previously --jars argument that can be worked in unit test are failed to work now, I'm trying to figure out  a way to enable this in unit test.

Test build #28553 has started for   PR 4961 at commit d290955.

This patch merges cleanly.

Test build #28553 has finished for   PR 4961 at commit d290955.

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

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

@davies @JoshRosen Could either of you take a look at the python changes?

Test build #28558 has started for   PR 4961 at commit 26513ba.

This patch merges cleanly.

Test build #28558 has finished for   PR 4961 at commit 26513ba.

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

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

Test build #28683 has started for   PR 4961 at commit e583134.

This patch merges cleanly.

Test build #28684 has started for   PR 4961 at commit 4a3bb3e.

This patch merges cleanly.

Test build #28684 has finished for   PR 4961 at commit 4a3bb3e.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

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

Jenkins, retest this please.

Test build #28689 has started for   PR 4961 at commit 4a3bb3e.

This patch merges cleanly.

Test build #28683 has finished for   PR 4961 at commit e583134.

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

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

Test build #28689 has finished for   PR 4961 at commit 4a3bb3e.

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

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

@tdas @davies would you mind taking a look at this PR, thanks a lot.

Test build #29145 has started for   PR 4961 at commit 6d71de0.

This patch merges cleanly.

Test build #29145 has finished for   PR 4961 at commit 6d71de0.

This patch passes all tests.

This patch merges cleanly.

This patch adds the following public classes (experimental):

   implicit class DslSymbol(sym: Symbol) extends ImplicitAttribute

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

Overall this looks good to me, just a few minor comments. I also asked @JoshRosen  to take a look at the Python changes.

Thanks a lot @tdas and @JoshRosen for your review, I will address all the comments :).

Test build #29838 has started for   PR 4961 at commit 76ace9a.

@tdas  @JoshRosen , mind taking a look at this again, thanks a lot.

Test build #29838 has finished for   PR 4961 at commit 76ace9a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

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

The new changes look good to me.  I'll let @tdas take another look.  It looks like the Thread.sleep(2000) hasn't been resolved, but I guess that's a carryover from the old code so we could add a followup JIRA and address that separately.

Hi @JoshRosen , thanks a lot for your review.
I think I just removed this Thread.sleep(2000), from my local test seems this sleep is not necessary, and currently there's no better solution like eventually to wait for the start of Kafka broker. So here I just simply remove this Thread.sleep(2000). I'm not sure if there's any problem with Jenkins, since it has more overhead compared to my local test. Maybe we could resolve this later when this problem exists.

Jenkins, retest this please.

Hi @tdas , would you please take a look at this again, so I can move on to another PR which is depending on this, thanks a lot and appreciate your time :).

Test build #29912 has started for   PR 4961 at commit 76ace9a.

Test build #29912 has finished for   PR 4961 at commit 76ace9a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

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

overall its looking good. regarding the thread.sleep, let me do a brute force 10 runs to see whether it increases flakiness or not.

Test build #644 has started for   PR 4961 at commit 76ace9a.

Test build #645 has started for   PR 4961 at commit 76ace9a.

Test build #646 has started for   PR 4961 at commit 76ace9a.

Test build #647 has started for   PR 4961 at commit 76ace9a.

Test build #648 has started for   PR 4961 at commit 76ace9a.

Test build #649 has started for   PR 4961 at commit 76ace9a.

Test build #650 has started for   PR 4961 at commit 76ace9a.

Test build #651 has started for   PR 4961 at commit 76ace9a.

Test build #652 has started for   PR 4961 at commit 76ace9a.

Test build #29934 has started for   PR 4961 at commit 1cda32a.

Test build #650 has finished for   PR 4961 at commit 76ace9a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test build #645 has finished for   PR 4961 at commit 76ace9a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test build #644 has finished for   PR 4961 at commit 76ace9a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test build #652 has finished for   PR 4961 at commit 76ace9a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test build #649 has finished for   PR 4961 at commit 76ace9a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test build #648 has finished for   PR 4961 at commit 76ace9a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test build #651 has finished for   PR 4961 at commit 76ace9a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test build #647 has finished for   PR 4961 at commit 76ace9a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test build #646 has finished for   PR 4961 at commit 76ace9a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test build #29934 has finished for   PR 4961 at commit 1cda32a.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

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

Jenkins, retest this please.

Test build #29938 has started for   PR 4961 at commit 1cda32a.

Test build #29938 has finished for   PR 4961 at commit 1cda32a.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

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

Jenkins, retest this please.

Test build #29959 has started for   PR 4961 at commit 1cda32a.

Test build #29959 has finished for   PR 4961 at commit 1cda32a.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

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

Jenkins, retest this please.

Test build #29991 has started for   PR 4961 at commit 1cda32a.

Looks like several unrelated unit test failure makes Jenkins complaint.

The most recent set of failures today were due to a Jenkins upgrade, but the issue should be resolved now.

Test build #29991 has finished for   PR 4961 at commit 1cda32a.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

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

Seems recent merged PR #5261 changed the script and make my test fail, I will fix it.

Test build #29999 has started for   PR 4961 at commit ee4b919.

Test build #29999 has finished for   PR 4961 at commit ee4b919.

This patch passes all tests.

This patch merges cleanly.

This patch adds the following public classes (experimental):

class FlattenedValuesSerializer(BatchedSerializer):

class ExternalList(object):

class ExternalListOfList(ExternalList):

class GroupByKey(object):

class ExternalGroupBy(ExternalMerger):

This patch does not change any dependencies.

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

Jenkins, retest this please.

Test build #30006 has started for   PR 4961 at commit ee4b919.

Jenkins, retest this please.
On Apr 9, 2015 6:52 PM, "Apache Spark QA"<EMAIL_ADDRESS>wrote:

Test build #29991 has finished
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/29991/consoleFull
for PR 4961 at commit 1cda32a
https://github.com/apache/spark/commit/1cda32ac2611e7110d79666ef75da5c6562483f8
.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

—
Reply to this email directly or view it on GitHub
https://github.com/apache/spark/pull/4961#issuecomment-91399082.

LGTM. Will merge if it passes.

Test build #30006 has finished for   PR 4961 at commit ee4b919.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

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

Merging this.

Thanks @jerryshao for doing this!


Modification of index.js included hook to retrieve the parent application

With this fix we now allow the addon to find the parent application from another addons and in versions of ember lower than 2.7 where the findHost helper is not available.
We are copying the old implementation of ember-cli

Versioned as 2.10.0


Acessing onready variables from extended script returns null

Godot version
4.0 Alpha 7
System information
Windows 10 Nvidia GTX 1060 Intel i5 4690k
Issue description
Lets say you have an "Item" class

Base scene is Item
Attached script is Item
class_name is Item
you set an onready variable; lets call it item_property1
item_property1 = 1
You instance scene "Item" in a new scene

You unattach the script, and attach a new script.
Lets call it "ItemBall"
"ItemBall.gd" extends from "Item.gd".
Therefore, in this new scene, lets call it ItemBall.
You should be able to access the properties in "Item.gd"
However, if you try to, it will return null.

This issue has existed in multiple Godot 4 versions, but definitely prevalent in Alpha7.
It will be fixed if you remove onready from variable names in the base class, however, this is problematic.
https://user-images.githubusercontent.com/83078010/167248382-94108c1c-7a9a-4a37-ac84-05be81124173.mp4
Steps to reproduce
Create a base scene (Item.tscn)
Create a script for this scene (Item.gd)
Give it a basic class_name (Item)
Instance this scene in a new scene.
Save this scene as (ItemBall)
Unnattach the script
Attach a new script (ItemBall.gd)
extend this script from Item.gd
Try to access properties in Item.gd, they will return null (Run itemBall.tscn, it will try to print Item.gd property)
Minimal reproduction project
ScriptExtensionBug.zip

At least for me, if the extended class has either _ready() or any onready -variables, the base _ready() will be overriden, which in return means no onready-calls i.e. variables remain unassigned. To counteract it, one must call the _ready()-method of the base class from the extended:
Base class:

Extended Class:

If this is intended, as it probably should be (as it is a basic form of overriding), the caveats of using onready-variables could be documented.

Yes, it's a duplicate.
btw you can use super() instead of super._ready().


How to adjust the length of the rectangle of the green circle?

Hi, @DHaylock
How to adjust the length of the rectangle of the green circle? Thinks a lot!

Change the camera width to be the same size as your video's width.

And height. Then alter the offset and the startposy to be half the camera height

Check the configuration.md

I get it !Thinks!


client/updater design: mirror config redesign

This is a future wishlist item for client API (#1135), based on working on pip integration. I'm not sure what exactly should happen here, just documenting the issues
Warehouse may be an unusal setup but here's how it works (using server names of the pypi instance as examples):

pypi.org serves TUF metadata, no other server serves metadata
pypi.org also serves target files (content is html files like https://pypi.org/simple/django/, file location is undecided but potentially e.g. https://pypi.org/simple/django/index.html)
files.pythonhosted.org also serves target files (in numerous directories like https://files.pythonhosted.org/packages/8f/1f/74aa91b56dea5847b62e11ce6737db82c6446561bddc20ca80fa5df025cc/Django-1.1.3.tar.gz#sha256=0e5034cf8046ba77c62e95a45d776d2c59998b26f181ceaf5cec516115e3f85a)

Issues encountered while implementing a client for this:

There's no way in the client mirror config to say "this server has no metadata: don't request from here" (#1079)
confined_target_dirs seems useless: it is not possible to use e.g. "packages/" or "simple/" as a confining directory in the above target file example because only files directly under those directories would then be accepted

This could be fixed in TUF... but reality is that pip does not really need a mirror config: it always knows which server it wants to use for a particular download. With current API this means I will end up storing two mirror configurations and choosing the correct one every time before a download happens.

This could be fixed in TUF

After further meditation: this particular issue cannot be fixed in TUF client. Even if confined_target_dirs allowed subdirectory matching, pip could not use them to separate index files and distribution files: The directory names "simple" and "packages" are just implementation details of pypi.org, not part of the Warehouse API. Some other instance might use the same directory name on both servers.
This is essentially a result of not namespacing the target names of index files and distribution files in the Warehouse TUF implementation: it is impossible to tell the two targets apart without some heuristics.


fix(recipe-contact-info): remove d-of-hidden

Fix Recipe Contact Info
:hammer_and_wrench: Type Of Change

[x] Fix
[ ] Feature
[ ] Refactoring
[ ] Documentation

:book: Description
Removed d-of-hidden class from default_list_item as I don't see any reason to keep it and it is breaking the behavior if it contains a popover anchor inside it.
:bulb: Context
This is related with https://github.com/dialpad/firespotter/pull/27100, the real issue is that contact-info has a d-of-hidden class that prevents the popover anchor element to have the required space to display properly.
:pencil: Checklist

[x] I have reviewed my changes
[ ] I have added tests
[ ] I have added all relevant documentation
[ ] I have validated components with a screen reader
[x] I have validated components keyboard navigation
[ ] I have considered the performance impact of my change
[ ] I have checked that my change did not significantly increase bundle size
[ ] I am exporting any new components or constants in the index.js in the component directory
[ ] I am exporting any new components or constants in the index.js in the root

I agree with this but I'm a bit worried about it breaking something in product. Can we migrate this to dialpad and check instances of dt-list-item?

Sure, I'll migrate and test before merging

Tested all over the places where DtListItem was being used and everything looks fine. I think we are safe, merging this.

This was originally added to enable truncation of the content https://github.com/dialpad/dialtone-vue/pull/604. It's still possible when using a custom type, but we could consider adding this conditionally as a prop or use a generic contentClass or something to allow passing any classes to this element.


Project related issue: Building canvas-based app: Having CORS issue

Hi, I'm building a canvas-based application using fabricJS. When I load images into the canvas from other websites it has no problem at all like Icons8, etc. But when I load images that I uploaded to Nhost's storage it will have some CORS issue.
I already get the public url of each uploaded images using:
const publicUrl = nhost.storage.getPublicUrl({ fileId: '<File-ID>' })
I already use and search every possible solution from fabricJS community, adding {crossOrigin: "Anonymous"}, etc.
Is there any setting I can set for Access-Control-Allow-Origin inside Nhost or Hasura? Or the bucket itself?
Error:

Would you mind sharing a working public URL here that we can test?
Also, how do you use the image in fabricJS? Mind sharing some example code?

@elitan thanks for the quick response. Planning to create a fiddle but since I can't also show the whole process, here are 2 methods I created whenever I will insert images into the canvas through fabricJS:
const addImgToCanvasUtil = (url) => {
		if (fabric && url) {
			new fabric.util.loadImage(
				url,
				(img) => {
					const loadedImg = new fabric.Image(img);
					loadedImg.scale(loadedImg.width > 2900 ? 0.04 : 0.15);
					loadedImg.set({
						id: nanoid(6),
						snapAngle: 45,
						snapThreshold: 10,
						clipPath: new fabric.Circle({
							radius:
								loadedImg.width > maxImageWidthForRadius
									? maxRadiusValue + maxRadiusValueLarge
									: maxRadiusValue,
							originX: 'center',
							originY: 'center',
							startAngle: 0,
							angle: Math.PI * 2,
						}),
					});
					canvas.add(loadedImg);
					canvas.centerObject(loadedImg);
					canvas.setActiveObject(loadedImg);
					canvas.renderAll();
					// save it
					// const _stringifiedCanvas = JSON.stringify(canvas.toJSON());
					// saveCanvas(_stringifiedCanvas);
					// side-effect
					// disableCanvasWrapZooming();
				},
				{ crossOrigin: 'anonymous' }
			);
		}
	};

and this one:
const addImgToCanvas = (url) => {
		if (fabric && url) {
			new fabric.Image.fromURL(
				url,
				(img) => {
					img.scale(img.width > 2900 ? 0.4 : 0.15);
					img.set({
						id: nanoid(6),
						snapAngle: 45,
						snapThreshold: 10,
						clipPath: new fabric.Circle({
							radius:
								img.width > maxImageWidthForRadius
									? maxRadiusValue + maxRadiusValueLarge
									: maxRadiusValue,
							originX: 'center',
							originY: 'center',
						}),
					});
					canvas.add(img);
					canvas.centerObject(img);
					canvas.setActiveObject(img);
					canvas.renderAll();
					// save it
					// const _stringifiedCanvas = JSON.stringify(canvas.toJSON());
					// saveCanvas(_stringifiedCanvas);
					// side-effect
					// disableCanvasWrapZooming();
				},
				{ crossOrigin: 'anonymous' }
			);
		}
	};

pardon the format, but that's some of the methods I use whenever inserting normal images like jpeg, png, to the canvas.

Thanks for the info.
Maybe Access-Control-Allowed-Origin should be defined in storage.buckets.
Or, more generally, we could have a headers (JSONB) column in storage.buckets where developers can set custom headers for all files for a specific bucket.

Thanks as well. Yah, that would be really awesome!

@elitan @dbarrosop I appreciate all your work for Nhost. Everything is great about it especially with your latest improvements and updates. But, regarding my case, is there any chance this will be implemented this month? I know there are lots of process in order to implement a certain feature, but just hoping it might be just quick 🤞🏻. Coz, my client already wants this project to be deployed/finished. Thank you.

@MelodicCrypter are you setting the Origin header? hasura-storage already sets the relevant CORS headers when needed.
A similar issue: nhost/hasura-storage#74 (comment) For reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#the_http_request_headers

Thanks for it. I'm sorry if I'm not that knowledgeable pertaining to this. Can you elaborate more how to do this? Coz, basically when adding images into the canvas through fabricJS they have their own request method, you can check it here:
https://github.com/fabricjs/fabric.js/blob/0830cdb24cc3c2004f3885a40cc1c91542343240/dist/fabric.js#L3523
So what I did, to test your suggestion, hopefully I'm doing it correctly, is that I patched their library using PNPM patch, and inserted
xhr.setRequestHeader('Origin', 'http://localhost:3000');
on line 3545 inside their request() method and hard-coded localhost just to test. But when I do that it also spit some error 'Refused to set unsafe header "Origin"'.
Thanks for the help. @dbarrosop  @elitan

I am afraid I don't know anything about fabric.js so I can't help you there. You can check the two links I shared before. On the first one you can see how the CORS related headers are being set correctly if the request includes the Origin header and on the second link you can read about CORS itself, in particular, notice the following statement:

Note that in any access control request, the Origin header is always sent.

I see. But, I just don't quite get why the images returned from Icons8 through their API works properly inside the canvas. Like this one:
https://ouch-cdn2.icons8.com/kU5D5N_CuhLTaKG0_RnvD-aPLExtQtExNoktGkHXz2U/rs:fit:1157:912/czM6Ly9pY29uczgu/b3VjaC1wcm9kLmFz/c2V0cy9zdmcvMzAv/YTIzZmMzODUtNDg5/Ni00NGY3LWI5ZTMt/ZmU2M2E3ZThiOWQ3/LnN2Zw.png
that's one of the API's returned image, and when I add that to the canvas, there's no any CORS error.
But when I add from Nhost storage:
https://.storage.us-east-1.nhost.run/v1/files/2c78ac02-6581-47b3-b685-d03756a22c94
it triggers CORS error

Because they are not following the CORS specification. They are returning the control headers even though the request didn't include an Origin header.

I completely understand and agree with you. But flexibility is also vital. I guess, what @elitan suggested above is also ideal, especially for this type of use case.

@MelodicCrypter What is the error message you're getting exactly?
I tried myself to use Fabric.js and was able to add an image from Storage:
<canvas id="canvas" width="300" height="300" style="border: 1px solid"></canvas>

<script
  src="https://cdnjs.cloudflare.com/ajax/libs/fabric.js/5.2.4/fabric.min.js"
  integrity="sha512-HkRNCiaZYxQAkHpLFYI90ObSzL0vaIXL8Xe3bM51vhdYI79RDFMLTAsmVH1xVPREmTlUWexgrQMk+c3RBTsLGw=="
  crossorigin="anonymous"
  referrerpolicy="no-referrer"
></script>
<script>
  var canvas = new fabric.Canvas('canvas')

  const url =
    'https://absvxxnsesanljntvxui.storage.eu-central-1.nhost.run/v1/files/e407259e-848f-48b0-91cb-cceb511f0966'
  new fabric.util.loadImage(url, (img) => {
    const loadedImg = new fabric.Image(img)
    // loadedImg.scale(loadedImg.width > 2900 ? 0.04 : 0.15)
    canvas.add(loadedImg)
    canvas.centerObject(loadedImg)
    canvas.setActiveObject(loadedImg)
    canvas.renderAll()
  })
</script>

@elitan The error I got is the screenshot I sent in the first conversation above. Where did you run this code? Fiddle?
When developing locally:

client is on http://localhost:3000
hasura/nhost server is http://localhost:1337

I also tried deploying it:

client is deployed in DigitalOcean, so it's already https based
then server is your prod default

all resulting to CORS issue. When I was using Express js before I could easily setup CORS, but I don't know what's really going on here in this case. Maybe, based on what dbarrosop said, I guess, Fabric not setting Origin headers. A bit lost right now.
By the way, my client framework is SvelteKit.
I will try to use the version of Fabric you used here, coz mine is using 5.2.1, and yours is 5.2.4

@elitan I notice your using the fabric.util.loadImage method, that will work perfectly when adding images but when you export your canvas to real image like jpeg or png, the canvas would be tainted, meaning it will not allow you to export your canvas because of the CORS issue.
Please try adding image using this method fabric.Image.fromURL coz this will automatically spit out the error. This method is Fabric's main method adding images (url based).
The one you used, will allow you to add first, but you will not be able to export the canvas, which the most important aspect of my project.

Here is a Fiddle: https://jsfiddle.net/Melodic_Crypter/7j04t2ba/8/ still using v5.2.4
I added new url from storage and a url from Icons8 to test each. Please uncomment/comment each block to check each results. Thanks for your patience.

My last option for Nhost storage assets, for now, is maybe proxy. I will try to figure out this one to proxy the image if it comes from your storage. I'm still going to implement it. Still not sure how to do it the proxy flow.

The problem is your image. In your fiddle you have two images url and newURL, both using our storage. The image in url returns the error you mention but the one in newUrl works fine:

So this doesn't seem to be a CORS problem.

I think this time, you're missing the point. I'm only using mobile right so I can't edit the fiddle.
For simplicity sake, we can just use one image from storage. Coz in the current fiddle maybe it's a bit all over the place. I will update it and just use one image.
The main point is that each Fabric method acts differently. But I'm certain that the current error corresponds to CORS issue - pertaining with Fabric.
Coz I can also confirm that all images from your storage does not produce CORS issue when used in image tags in normal applications. Cors only appears when used with Fabric.

I can use both images in your jsfiddle without any errors.
See video:
https://user-images.githubusercontent.com/331818/194754885-825d09b4-2681-4243-bb1f-a34b2a4bcea1.mp4
Can you explain the steps to reproduce this error in the jsfiddle?

@elitan I confirm that it is working (INSIDE THE FIDDLE) for both images coming from Nhost storage and using the fabric.Image.fromURL() method. I really don't know what happened coz last time it was not working. Thanks for trying. I also confirm that it is working for both versions 5.2.1 and 5.2.4 - both worked inside the Fiddle.
Anyway, still, it is not working inside my real project application. Please see screenshot. App is using SvelteKit and hosted in DigitalOcean. I'll just solve this on my own coz I think it doesn't have to do with your storage settings at all. I really don't know why it is not working, but in Fiddle it is working. Maybe it is because of Vite, coz SvelteKit is using Vite. I don't know.  I also bumped my project's Fabric version to 5.2.4.
Thanks again.

Something I'd suggest you to try is running the following:
curl --output /dev/null -v -H "Origin: example.com" https://xcffducurpnshjgqihcv.storage.us-east-1.nhost.run/v1/files/b80478bd-8009-43b8-98fd-15347f78a31e

Replacing example.com with your origin to make sure you see the relevant headers (for instance, with example.com you should see in the output:
< access-control-allow-origin: example.com
< access-control-expose-headers: Content-Length,Content-Type,Cache-Control,Etag,Last-Modified,X-Error

If you are testing on a browser you can also go to developer tools -> Network, find the request to the storage there and see if the request includes the Origin header.

@dbarrosop I appreciate your help. Thanks. These are the results, I tested using Network tab:
Setup:

Chrome, latest version
SvelteKit (Svelte) framework
Hosted in DigitalOcean

Application flow:

when the app loads, all the images from Nhost storage that user owns are loaded
so when loaded, there are no cors issues or anything, all file urls are injected to the DOM each IMG tags
when user clicks an image (hosted from Nhost storage or not) it should be added to the canvas (Fabric)

Test flow:

after images were loaded
I tried clicking an image
screenshots below are the same image file, first successfully loaded to the DOM, but when clicked, that's when issue occurs

1 IMAGE - LOADED INTO THE DOM WITHOUT ANY ISSUES

2 IMAGE - ALREADY LOADED INTO THE DOM, BUT WHEN INJECTED TO THE FABRIC CANVAS, HAS ISSUE

Have you figured this one out? I am happy to help but without a way of reproducing I feel like there isn't much more I can do. However, by the looks of it, if looks like something is interfering with the CORS headers; the origin header is in the request and the response header has access-control-expose-headers but I can't see the access-control-allow-origin, which is extremely strange as the server adds both as you can see if you query yourself the server with curl so something must be removing it.

I have the same issue, how can I fix it?

@oriollpz please, open a new issue and describe your problem and detailed steps to reproduce thanks.
I am closing this issue as this wasn't a problem on hasura-storage to the best of our knowledge.


Brand settings page broken for SSR

It uses window.getComputedStyle in data() but there is no window yet.

Test report:

Brand settings can be saved with all values set - also other combinations tried
Show Rancher community support links checkbox renders html by using aria-checked="true" attribute when set; without the attribute when not set.

Close.


Fix routing when root-path is set  in SPA mode

Fixes #224

@stephan-strate would you have a look?

Got it. Looks good to me 👍


Code the program for Linear Search in C

Add it to Linear_Search.c in SearchAlgorithms folder

@HarendraSingh22 I would like to contribute the code for it.

i added the implementation for linear search and binary search, see pull request #14


test(storybook): add snapshot tests

add snapshot test for all stories

⚠  currently blocked by https://github.com/storybookjs/test-runner/issues/68#issuecomment-1214989696

Seems to be fixed for now. Probably some weird dependency errors.
But there is still one problem: In some of our components we generate random IDs which lead to following errors:
    -       <label for="ino-switch-id__4h67rw409">
    +       <label for="ino-switch-id__8g9ktqkwt">

We need to think about how we want to handle these cases. IDs are necessary for <label> elements.


Kafka streams errors out "Missing source topic" after upgrading from 1.0.0

Hello team,
I have recently upgraded from 1.0.0 to 2.3.x. I have a kafka streams application whose topology is built as :
source topic -> Processor1 -> output topic 1 -> Processor2 -> output topic 2 -> Processor 3 ....etc
Only source topic was always existent before application started and the remaining topics were created as the processing goes on or during spinning up the application, as part of 1.0.0.
But the new version errors out on "Missing source topic  output topic 2   durign assignment. Returning error INCOMPLETE_SOURCE_TOPIC_METADATA."
The auto-create-topics is set to true. So shouldn't the streams take care of creating topics and waiting until they are available? (atleast for the intermediate topics)
Did anything change as part of configuration after 1.x in Kafka streams that should be included?
I currently am setting : StreamsConfig.APPLICATION_ID_CONFIG, StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG, StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG, StreamsConfig.NUM_STREAM_THREADS_CONFIG, StreamsConfig.DEFAULT_TIMESTAMP_EXTRACTOR_CLASS_CONFIG as part of KafkaStreamsConfiguration.
Thanks.

As explained in the docs, input and output topic are considers "user topics" and you need to create those topics upfront: https://docs.confluent.io/current/streams/developer-guide/manage-topics.html
In older versions, auto-create-topic might still trigger but it was always an undesired side effect and this "bug" was fixed in newer versions. Thus, in newer versions if input topics don't exist, you get the error you describe and the app shuts down.
Also note that internal topics like repartition topic and changelog topics will still be created for you. However, Kafka Streams does not rely on auto-create-topic for this, but an explicit create-topic-request is sent to the cluster.


[Java] Publish SBOM artifacts

Describe the enhancement requested
This issue aims to publish SBOM artifacts along with the other Apache projects.

https://cwiki.apache.org/confluence/display/COMDEV/SBOM

Here is an article to give some context.

https://www.activestate.com/blog/why-the-us-government-is-mandating-software-bill-of-materials-sbom/

Software Bill of Materials (SBOM) are additional artifacts containing the aggregate of all direct and transitive dependencies of a project. The US Government (based on NIST recommendations) currently accepts only the three most popular SBOM standards as valid, namely: CycloneDX, Software Identification (SWID) tag, Software Package Data Exchange® (SPDX).

I hav e added the blocker label as the PR is done and only contingent on the failed Ng gandiva tests.


CSharp namespace for resource-manager, move data-plane API specs to resource-manager, remove UsageMetrics API from the spec

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

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

Quality of Swagger

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

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

Fixing issues

#1837 fix cSharp namespace for resource-manager,
#1838 : move data-plane API specs to resource-manager,
#1839: remove UsageMetrics API from the spec

@ravbhatnagar

moving from data-plane to resource-manager
changing namespace
removing specs

@gucalder what is the migration plan and impact for our customers?

@shawns1 do you know why CI is not triggered for the PR?

For CI references https://github.com/Azure/azure-rest-api-specs/pull/1846

@sergey-shandar CI seems to be working fine.  Travis ran the build.

I am moving data-plane to resource-manager because some teams are generating SDKs for languages we do not handle (like Java,) and their work started with resource-manager only. Those teams assume that any call specified in the data-plane folder does not go through ARM, but in our case that is not true: all our calls go through ARM. So we are conveying an incorrect message by separating the calls into folders. Other than history there are not many reasons to keep the two folders separated.
In terms of impact the migration will remove one client. Until today we have two clients that are doing the same: calling our servers via ARM. Now there will be only one client with all the calls.
The calls themselves won't change.

The other two changes, one is a bug, i.e.: incorrect namespace, visible only after the generation of code. It will impact the users of the SDK (.Net only,) but we cannot leave that value incorrect for that. BTW: our SDK .net is still in "preview" state, so this kind of changes are still possible.
The other change, i.e. deprecation of one API, has been announced for months already in PowerShell, and no one is using that API anymore.

@shawns1 thanks. It was not showing any CI in the PR and I couldn't find the job in Travis-CI. So I had to reopen the PR but it didn't help. It looks like magic.

@gucalder

what is the migration plan and impact for our customers?
could you solve merge conflicts?


different color between HTML tags and Component tags

when use VUE or REACT
eg:
the color of  <Component> is the same as the <div> ....
wish the colors of the two labels can be distinguished
thanks, ayu is very beautiful theme , and wish it's to be better.

oh boy i want it so badly
up up up

Do you have examples of themes making this useful and nice?

the themes that i like that have this features are the Github Theme, Dracula and Omni Theme. I also tried to modify ayu based on the variables that those themes provide, but no sucess :(

yo guys, found a way to do this in your user settings
Ctrl + Shift + P > Open Settings (JSON) > paste this code, changing the "foreground" color with one of your preference.
"editor.tokenColorCustomizations": {         "textMateRules": [             {                 "scope": [                  "entity.name.tag.tsx",                   ],                  "settings": {                  "foreground": "#569CD6",                  }             },         ]     }

Great suggestion @quanscheng. I'll adopt @leutzed's suggested solution into the next release

sure, but @dempfi use a color which is in the ayu-colors repo, than you won't need to change the pallete :)

Released in v1


[DO NOT MERGE] add type time to valueTime

/azp run automation - sdk

Can one of the admins verify this patch?

@kristapratico I can't merge this due to failing required checks.


Add akram as a maintainer

Description
Adds Akram Ben Aissi (@akram) as a maintainer of the legacy openshift jenkins plugin.
Current maintainers Ben Parees and @gabemontero  transfered ownership of the project to him.
https://github.com/jenkinsci/openshift-pipeline-plugin
Submitter checklist for changing permissions

@daniel-beck
@gabemontero

Always

[x] Add link to plugin/component Git repository in description above

For a newly hosted plugin only

[x] Add link to resolved HOSTING issue in description above

For a new permissions file only

[x] Make sure the file is created in permissions/ directory
[x] artifactId (pom.xml) is used for name (permissions YAML file).
[x] groupId / artifactId (pom.xml) are correctly represented in path (permissions YAML file)
[x] Check that the file is named plugin-${artifactId}.yml for plugins

When adding new uploaders (this includes newly created permissions files)

[x] Make sure to @mention an existing maintainer to confirm the permissions request, if applicable
[x] Use the Jenkins community (LDAP) account name in the YAML file, not the GitHub account name
[x] Make sure to @mention the users being added so their GitHub account names are known if they require GitHub merge access (see below).
[x] All newly added users have logged in to Artifactory at least once

Reviewer checklist (not for requesters!)

[ ] Check this if newly added person also needs to be given merge permission to the GitHub repo (please @ the people/person with their GitHub username in this issue as well). If needed, it can be done using an IRC Bot command
[ ] Check that the $pluginId Developers team has Admin permissions while granting the access.
[ ] In the case of plugin adoption, ensure that the Jenkins Jira default assignee is either removed or changed to the new maintainer.
[ ] If security contacts are changed (this includes add/remove), ping the security officer (currently @daniel-beck) in this pull request. If an email contact is changed, wait for approval from the security officer.

There are IRC Bot commands for it

/approve


Add basic docs around docsearch

A gulp build would be required here, rebuild is required for use/testing.


convertPathData removes a perfect circle

node 7.7.2
npm 4.1.2
svgo 0.7.2
We have an icon that contains, as far as I can tell, a perfect circle. That circle gets removed after running svgo with default settings. After playing around with custom config I concluded that convertPathData plugin is at fault, as disabling it fixes the issue, but causes 62.2% compression shrink to 32.2%. Trying to configure convertPathData yielded no changes in behaviour.
Example file and our result are attached:
svg-with-circles.zip

I looked further into this and found out that a path for the circle

M7.9975,6.00125 C9.65875,6.00125 11.0013,7.33875 11.0013,8.99875 C11.0013,10.6587 9.65875,12.0025 7.9975,12.0025 C6.3375,12.0025 5,10.6587 5,8.99875 C5,7.33875 6.3375,6.00125 7.9975,6.00125 L7.9975,6.00125 Z

is successfully simplified into

M7.997 6.001a3.002 3.002 0 1 1 0 0z

However, this resulting string renders nothing.

This appears to be a rounding/precision/floating point issue.
Try adding a scaled up version of your circle:
<svg xmlns="http://www.w3.org/2000/svg">
    <path fill="red" d="M7.9975,6.00125 C9.65875,6.00125 11.0013,7.33875 11.0013,8.99875 C11.0013,10.6587 9.65875,12.0025 7.9975,12.0025 C6.3375,12.0025 5,10.6587 5,8.99875 C5,7.33875 6.3375,6.00125 7.9975,6.00125 L7.9975,6.00125 Z"/>
    <path transform="scale(2)" fill="blue" d="M7.9975,6.00125 C9.65875,6.00125 11.0013,7.33875 11.0013,8.99875 C11.0013,10.6587 9.65875,12.0025 7.9975,12.0025 C6.3375,12.0025 5,10.6587 5,8.99875 C5,7.33875 6.3375,6.00125 7.9975,6.00125 L7.9975,6.00125 Z"/>
</svg>

The first will be simplified wrongly and disappear like in your example, the second will be simplified right, (scaling down would also disappear):
<svg xmlns="http://www.w3.org/2000/svg">
    <path fill="red" d="M7.997 6.001a3.002 3.002 0 1 1 0 0z"/><!--gets eliminated with --multipass -->
    <path fill="#00f" d="M15.995 12.002a5.993 5.993 0 0 1 6.008 5.995 6.003 6.003 0 0 1-6.008 6.008A5.994 5.994 0 0 1 10 17.997a5.983 5.983 0 0 1 5.995-5.995z"/>
</svg>

The culprit lies in line:
https://github.com/svg/svgo/blob/3ec0767ba0ca3aff507ace3b3798de69084c4649/plugins/convertPathData.js#L356
This normally checks, how different the summed angle is from 360° or 2*PI.
If it is too different, it is not a circle, if not, it is a circle.
In your example, the arc seems to be a bit too short (the difference too great), so it is not recognized as circle.
The problem is the error constant/epsilon of 1e-3.
Fix:
Increasing it (and maybe other mentions of 1e-3) might work, but might break other stuff: a large error could lead to bigger almost-circles to be wrongly recognized as circles.
My math is rusty and my understanding of the code shallow, but it might be possibly to either set the error constant(s) adaptively depending on the scale/precision we are working in, or to use some the supplied precision arguments/create a new one.
http://www.floating-point-gui.de/errors/comparison/ (really!)
suggests using some kind of relative error.

@na-oma Thank you for being thorough! Scaling precision in checks would be great for the library IMO. Our image was created with Sketch, and, as far as I know, nothing about export settings for this one did stand out. So, other people may run into a similar issue as well.
As for a workaround, I used an older version of SVGO, which is published at https://jakearchibald.github.io/svgomg/. It resulted in a slightly bigger file, but the app didn't have any issues with our circle. And after that the latest version of SVGO stopped ruining the image too (guess, it sees no need to optimize it now).

Same problem with options: convertPathData and convertShapeToPath. They broke svg.
So I run:
svgo --enable={convertPathData,convertShapeToPath} img/spinner.svg

Original svg:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32" width="16" height="16" fill="rgb(49, 123, 249)">
  <path transform="translate(2)" d="M0 12 V20 H4 V12z">
    <animate attributeName="d" values="M0 12 V20 H4 V12z; M0 4 V28 H4 V4z; M0 12 V20 H4 V12z; M0 12 V20 H4 V12z" dur="1.2s" repeatCount="indefinite" begin="0" keytimes="0;.2;.5;1" keySplines="0.2 0.2 0.4 0.8;0.2 0.6 0.4 0.8;0.2 0.8 0.4 0.8" calcMode="spline"  />
  </path>
  <path transform="translate(8)" d="M0 12 V20 H4 V12z">
    <animate attributeName="d" values="M0 12 V20 H4 V12z; M0 4 V28 H4 V4z; M0 12 V20 H4 V12z; M0 12 V20 H4 V12z" dur="1.2s" repeatCount="indefinite" begin="0.2" keytimes="0;.2;.5;1" keySplines="0.2 0.2 0.4 0.8;0.2 0.6 0.4 0.8;0.2 0.8 0.4 0.8" calcMode="spline"  />
  </path>
  <path transform="translate(14)" d="M0 12 V20 H4 V12z">
    <animate attributeName="d" values="M0 12 V20 H4 V12z; M0 4 V28 H4 V4z; M0 12 V20 H4 V12z; M0 12 V20 H4 V12z" dur="1.2s" repeatCount="indefinite" begin="0.4" keytimes="0;.2;.5;1" keySplines="0.2 0.2 0.4 0.8;0.2 0.6 0.4 0.8;0.2 0.8 0.4 0.8" calcMode="spline" />
  </path>
  <path transform="translate(20)" d="M0 12 V20 H4 V12z">
    <animate attributeName="d" values="M0 12 V20 H4 V12z; M0 4 V28 H4 V4z; M0 12 V20 H4 V12z; M0 12 V20 H4 V12z" dur="1.2s" repeatCount="indefinite" begin="0.6" keytimes="0;.2;.5;1" keySplines="0.2 0.2 0.4 0.8;0.2 0.6 0.4 0.8;0.2 0.8 0.4 0.8" calcMode="spline" />
  </path>
  <path transform="translate(26)" d="M0 12 V20 H4 V12z">
    <animate attributeName="d" values="M0 12 V20 H4 V12z; M0 4 V28 H4 V4z; M0 12 V20 H4 V12z; M0 12 V20 H4 V12z" dur="1.2s" repeatCount="indefinite" begin="0.8" keytimes="0;.2;.5;1" keySplines="0.2 0.2 0.4 0.8;0.2 0.6 0.4 0.8;0.2 0.8 0.4 0.8" calcMode="spline" />
  </path>
</svg>

Becames:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32" width="16" height="16" fill="#317BF9">
    <path d="M2 12v8h4v-8z">
        <animate attributeName="d" values="M0 12 V20 H4 V12z; M0 4 V28 H4 V4z; M0 12 V20 H4 V12z; M0 12 V20 H4 V12z" dur="1.2s" repeatCount="indefinite" begin="0" keySplines="0.2 0.2 0.4 0.8;0.2 0.6 0.4 0.8;0.2 0.8 0.4 0.8" calcMode="spline" />
    </path>
    <path d="M8 12v8h4v-8z">
        <animate attributeName="d" values="M0 12 V20 H4 V12z; M0 4 V28 H4 V4z; M0 12 V20 H4 V12z; M0 12 V20 H4 V12z" dur="1.2s" repeatCount="indefinite" begin=".2" keySplines="0.2 0.2 0.4 0.8;0.2 0.6 0.4 0.8;0.2 0.8 0.4 0.8" calcMode="spline" />
    </path>
    <path d="M14 12v8h4v-8z">
        <animate attributeName="d" values="M0 12 V20 H4 V12z; M0 4 V28 H4 V4z; M0 12 V20 H4 V12z; M0 12 V20 H4 V12z" dur="1.2s" repeatCount="indefinite" begin=".4" keySplines="0.2 0.2 0.4 0.8;0.2 0.6 0.4 0.8;0.2 0.8 0.4 0.8" calcMode="spline" />
    </path>
    <path d="M20 12v8h4v-8z">
        <animate attributeName="d" values="M0 12 V20 H4 V12z; M0 4 V28 H4 V4z; M0 12 V20 H4 V12z; M0 12 V20 H4 V12z" dur="1.2s" repeatCount="indefinite" begin=".6" keySplines="0.2 0.2 0.4 0.8;0.2 0.6 0.4 0.8;0.2 0.8 0.4 0.8" calcMode="spline" />
    </path>
    <path d="M26 12v8h4v-8z">
        <animate attributeName="d" values="M0 12 V20 H4 V12z; M0 4 V28 H4 V4z; M0 12 V20 H4 V12z; M0 12 V20 H4 V12z" dur="1.2s" repeatCount="indefinite" begin=".8" keySplines="0.2 0.2 0.4 0.8;0.2 0.6 0.4 0.8;0.2 0.8 0.4 0.8" calcMode="spline" />
    </path>
</svg>

Here is both of them: spinners.zip

Cannot reproduce. Probably fixed. Opened new issues for animation bug https://github.com/svg/svgo/issues/1388


libgphoto2 probably needs updating udev generation

We currently use version 175 and export it to 40-gphoto2.rules
https://github.com/NixOS/nixpkgs/blob/26f5e6dd5f2d703d5c39d661540397ea119aa94f/pkgs/development/libraries/libgphoto2/default.nix#L40
The help page suggests there is version 201 and the file name should be 90-libgphoto2.rules:
https://github.com/gphoto/libgphoto2/blob/4a0d9dcb1fffd226925da095684dfce2184fe430/packaging/generic/print-camera-list.c#L1417 (modes should called versions)
The change will also likely need a hwdb file according to:
https://github.com/gphoto/libgphoto2/blob/4a0d9dcb1fffd226925da095684dfce2184fe430/packaging/generic/print-camera-list.c#L508
This is apparently required to support cameras that use SCSI tunneling support:
https://github.com/gphoto/libgphoto2/blob/4a0d9dcb1fffd226925da095684dfce2184fe430/packaging/generic/print-camera-list.c#L744-L746
cc @jcumming (maintainer) @league (introduced the udev file)

For reference
https://github.com/archlinux/svntogit-packages/blob/acd9af4de4b07d4fcdb08142f7eb596ae75d81d2/trunk/PKGBUILD#L57
Fedora https://src.fedoraproject.org/rpms/libgphoto2/blob/rawhide/f/libgphoto2.spec#_104


ToJsonNode() does not preserve YAML null values

Nuget Package
Yaml2JsonNode
Package Version
1.2.2
Operating System
None
.Net Target (if relevant, please specify the version in the description)
None
A clear and concise description of the bug
YAML null values are not preserved when converting to JsonNode. They are converted as a string literal instead.
Please add test code or steps to reproduce the behavior
Here is a test code exhibiting the issue.
https://dotnetfiddle.net/DDdvhP
What did you expect?
null values from YAML documents are preserved when converting to JsonNode
Is there any other information you'd like to share regarding this bug?
No response
Code of Conduct

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

Thanks for the report.  I'll set up a test to see if I can reproduce this.

It looks like YamlDotNet either isn't handling these right or is just trying to present all of the information from the text.  Regardless, it's not presenting null for any of these; it's giving me a string.  (They have a several open issues regarding nulls, this issue being among them.)
For (my) reference: https://yaml.org/type/null.html
I'll have to add some hack code to work around this.


Use send_help to ensure that our help command is correctly invoked

Currently, we're invoking our help command manually like this:
await ctx.invoke(self.bot.get_command("help"), "bot")

However, unfortunately, this fails when the command callback function is decorated, leading to exceptions like:
AttributeError: 'Help' object has no attribute 'channel'
  File "discord/ext/commands/core.py", line 83, in wrapped
    ret = await coro(*args, **kwargs)
  File "bot/cogs/snekbox.py", line 292, in eval_command
    await ctx.invoke(self.bot.get_command("help"), "eval")
  File "discord/ext/commands/context.py", line 132, in invoke
    ret = await command.callback(*arguments, **kwargs)
  File "bot/decorators.py", line 149, in inner
    if ctx.channel.id == destination_channel:

Error executing command invoked by <>: !e

See Sentry issue: BOT-4T
The solution is to use the way of invoking the help command built built into discord.py: ctx.send_help, as the recent refactoring of the help command made our custom help command compatible with that Context method.

A Quick comment, would it be more efficient to pass in ctx.command rather than the name of the command, where applicable? Passing in a string means an extra lookup and if for some reason the command name were to change this way means an additional change isn't required

A Quick comment, would it be more efficient to pass in ctx.command rather than the name of the command, where applicable? Passing in a string means an extra lookup and if for some reason the command name were to change this way means an additional change isn't required

The docs don't mention support for passing in a Context object. It can either be a Cog, a Command-object, or a string.

Right, but can't you get a Command object with ctx.command?

I accidentally hit edit instead of reply.


Make ctx.i18n non-enumerable

Make ctx.i18n non-enumerable to exclude from serialisation in conversations, as discussed in
https://t.me/grammyjs/107171

Seems like CI failed due to type-error in dcdunkan/tests. @dcdunkan can you take a look?

@deptyped Merge grammyjs:main.


Connection Failed

Hi，我遇到了连接失败的问题。在本地使用本地命令行的 sftp 功能能上传成功，但是在 Github Actions 中使用 sftp-action 就出现了问题。我不太清楚这是发生了什么错误，能否提供一些帮助？
Hi, I came up with a connection failure issue. I was able to upload successfully locally using the sftp through PowerShell, but I failed in using sftp-action in Github Actions. I'm not quite sure what error is happening here, could you provide some help?
Using Powershell... OK

Using sftp-action... Failed

CI Log：https://github.com/Lionad-Morotar/blog/runs/4498360584?check_suite_focus=true
Deploy.yaml：https://github.com/Lionad-Morotar/blog/blob/4ee959898f3a8b253798da8909aae3ec83ad5a5b/.github/workflows/deploy.yml

But thanks for creating an issue!

Thanks for reply，I'll try it~~


imporve documentation development

See #1964

[x] have read the CONTRIBUTING.md file
[x] raised a GitHub issue or discussed it on the projects chat beforehand
[ ] added unit tests
[ ] added integration tests
[x] updated documentation if needed
[ ] updated CHANGELOG.md

@kradalby I guess I could need your nix expertise on this one.
I guess trying to run poetry within the nix develop shell is not working as I expected and maybe a complete nix approach is needed.


Cleanup main README.md

This change is

gen/ISDx/ASy/endhost (in section Environment) will become gen/ASx on marcfrei/scionlab_nextversion.


Autocomplete/expansion broken on hyper 2.1.0-canary.2

[x] I am on the latest Hyper.app version

[x] I have searched the issues of this repo and believe that this is not a duplicate

OS version and name: OSX Mojave

Hyper.app version: 2.1.0-canary.2

Relevant information from devtools (CMD+ALT+I on macOS, CTRL+SHIFT+I elsewhere):
Plugin hyper-snazzy (1.3.0) loaded.
Plugin hyper-statusline (1.7.6) loaded.
Plugin hyper-alt-click (0.1.1) loaded.
Plugin hyperterm-tab-icons (1.1.0) loaded.
Plugin hyperlinks (0.5.0) loaded.
Plugin hyperfullscreen (1.0.1) loaded.

The issue is reproducible in vanilla Hyper.app: Yes- removed all plugins and still present

Issue
Using TAB to complete adds invalid characters to the input. Consider this example where I hit TAB 3 times:
~
❯ cd htdocs/

~
❯ cd htdocs/
zsh: do you wish to see all 104 possibilities (26 lines)?

❯ cdcd htdocs/
Chart.js/                       fritzapi/                       modbus/                         syno-elk/

The 3rd time cd become cdcd. Here is another example how this looks (brbr):

This bug has now made it's way into 2.1.0 (stable).
Any tab completion results in the original input being "pinned" to the input line.
cd then TAB results in:
cdcd
The pinned characters seem to just be a visual artifact and do not affect actual input.
The characters cannot be removed via backspace/delete, you also cannot move the cursor to the characters with the arrow keys.

This bug has now made it's way into 2.1.0 (stable).

It has :( I can support testing if there's change but wouldn't know where to start with fixing.

Completely uninstalling (brew cask uninstall hyper) and reinstalling seems to have fixed it for me.

It's a locale issue, see #183

#183 was closed as fixed in 2016- seems its back if thats the root cause. I do have these locale settings for sake of reference:
LANG=en_DE.UTF-8
LC_CTYPE=en_DE.UTF-8

Just tried with those locale settings and I'm also having issues, but I tried with LANG=de_DE.UTF-8 and my current locale LANG=it_IT.UTF-8 without having any problem.

Btw, still broken on canary 3.0 which has just landed today for me.

Fixed for me by workaround according to https://github.com/zeit/hyper/issues/3091#issuecomment-398304629


Add [skip ci] workaround to avoid obsolete builds

Support [skip ci] out of box with github actions
Workaround: https://github.community/t/github-actions-does-not-respect-skip-ci/17325
Marketplace: https://github.com/marketplace/actions/ci-skip-action

name: my CI github action

on:
  push:
    branches:
      - master

jobs:
  build:
    if: "!contains(github.event.head_commit.message, 'skip ci')"
    runs-on: ubuntu-latest

Seems to work, see https://github.com/tillkuhn/angkor/actions/runs/451323325


Feature docker

I added a Dockerfile and configuration to run the prov-db-connector without local environment.
Useful if you just want to try out the examples.

See  https://github.com/DLR-SC/prov2bigchaindb/blob/master/prov2bigchaindb/core/utils.py#L30 for a similar function. Remove six dependency.


Volume create

Description
When I would like to create additional volume for newly created server, the ansible script runs though without error, but the volume is not present.
Additional volume is not created, the process is finished without any error message.
Expected behavior
volume is created
Ansible version:
ansible 2.10.15
config file = None
configured module search path = ['/usr/share/ansible/plugins/modules/ionos-module-ansible']
ansible python module location = /opt/rh/rh-python38/root/usr/local/lib/python3.8/site-packages/ansible
executable location = /opt/rh/rh-python38/root/usr/local/bin/ansible
python version = 3.8.11 (default, Sep  1 2021, 12:33:46) [GCC 9.3.1 20200408 (Red Hat 9.3.1-2)]
Module version:
5.0.5
OS:
Centos7
Configuration Files
ansible snipet:

name: Create data volume
volume:
username: "myusername"
password: "password"
datacenter: "{{ datacenter }}"
server: "{{ machines[0].id }}"
size: 10
disk_type: HDD
name: "backupdisk"
licence_type: "OTHER"
wait_timeout: "{{ timeout }}"
availability_zone: ZONE_1
state: present
environment: "{{ proxy_env }}"

ignore_errors: yes
tags: always
delegate_to: localhost
Error and Debug Output
ok: [localhost -> localhost] => {
"action": "create",
"changed": false,
"instance_ids": [],
"invocation": {
"module_args": {
"api_url": null,
"auto_increment": true,
"availability_zone": "ZONE_1",
"backupunit_id": null,
"bus": "VIRTIO",
"count": 1,
"cpu_hot_plug": null,
"datacenter": "datcenterID",
"disc_virtio_hot_plug": null,
"disc_virtio_hot_unplug": null,
"disk_type": "HDD",
"image": null,
"image_password": null,
"instance_ids": [],
"licence_type": "OTHER",
"location": null,
"name": "backupdisk",
"nic_hot_plug": null,
"nic_hot_unplug": null,
"password": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"ram_hot_plug": null,
"server": "serverID",
"size": 10,
"ssh_keys": [],
"state": "present",
"user_data": null,
"username": "myusername",
"wait": true,
"wait_timeout": 600
}
},
"volumes": []
}

Hello!
Can you, please, provide the entire playbook? (Or at least the part with the creation of the first module)
I am asking because the Ansible module skips the volume creation if a volume with the same name already exists, so this would be a reason for the described behavior. If the volumes have different names, a more detailed playbook would be helpful for reproducing the problem.
Thank you!

Hi,
the the required snipet is the first volume creation. (  The server does not have named volume before).
I have found the "interesting berhavior: if I name the new volume: datadisk or backupdisk it failes, but it the name has number on end: datadisk0 datadisk1, backupdisk0. etc it runs fine...
Gyorgy

Hello!
Thank you for the provided info. We're currently working on the fix for this bug. I've been trying to reproduce the scenario you presented, but with no success. Can you, please, provide more information about the setup? It would be helpful to have more details about the server (location, other entities, etc.), and I think the easier way to do that would be to provide here the command you use for the creation of the server (with sensitive info covered, of course).
Thank you!

Update: I receive the same output as above only if I try to create a volume that already exists. The empty list ("volumes": []) on response appears due to another issue whose fix will be included in the next release.
Can you, please, check on the API level or on DCD and confirm that, after running the playbook, the volume is not created?

Closing this issue due to inactivity. If the problem persists or you have new info, please open a new issue and link back to this one. Thanks!


Add reflection mask to reflection probes

The cull_mask property on reflection probes had a double function that did not make sense.

It determined which objects were rendered to the probe
It determined which objects would get reflections using this probe

Rarely do you want to have an object reflect onto itself so a likely use case is where you'd want to exclude the object that gets reflections from being rendered to the probe. But due to this combined function that was impossible.
The documentation stated that it should be doing 1 and never mentioned 2 however seeing that for all other objects that have a cull_mask (i.e. lights and decals) cull_mask behaves as defined at 2 I've chosen to split off 1 into a separate property.
This PR introduces a new property called reflection_mask that determines which layers are rendered to the probe.
Using the material tester demo I've added a reflection probe to the mirror ball:

Note that the mirror ball itself has been placed into layer 2
The result is proper reflections onto the mirror ball:

Fixes #50195

The fact that cull_mask was being used for both jobs in master was a bug. The "layer" property was used in 3.x to determine what objects receive light from the reflection probe and the cull mask was just used to determine which objects get rendered into the reflections. IMO we should keep the behaviour the same as it was in 3.x.

The fact that cull_mask was being used for both jobs in master was a bug. The "layer" property was used in 3.x to determine what objects receive light from the reflection probe and the cull mask was just used to determine which objects get rendered into the reflections. IMO we should keep the behaviour the same as it was in 3.x.

Yup, working on a new PR that does just that fix

Okay, monkey wrench into this one @clayjohn, turns out we don't have access to the layer mask where we need to.
Basically the two calls to reflection_probe_get_cull_mask in this code:
https://github.com/godotengine/godot/blob/master/servers/rendering/renderer_rd/renderer_scene_render_rd.cpp#L2334
Need to be changed to obtain the layer mask to get the behavior we had in Godot 3.
But as the layer mask is stored on the associated VisualInstance and as a probe in theory can belong to multiple instances (I doubt it ever does) we don't actually have any methods to obtain this mask as we don't know for which instance we're handling the probe.
@reduz promised to have a closer look at this tomorrow.

@reduz promised to have a closer look at this tomorrow.

Famous quote :P
Might be worth poking at again soon.

Any chance this is going to get looked at again in the near future?

The "layer" property was used in 3.x to determine what objects receive light from the reflection probe

I just tested in 3.x, the layers only determine if the probe should render at all depending on if it's part of the camera's cull mask. Is that not what it's intended to do? Or was it broken since you wrote that?

Any chance this is going to get looked at again in the near future?

I wrote a quick and dirty fix over here if you need the 3.x behavior back urgently, but based on the above I'm not sure that's right either.

What is the status of this?

Also, maybe related, but I was wondering if it could be implemented a way of priority for a probe to override reflections if 2 or more reflections probes are overlapping instead of blending. There are too many cases where you will have a central reflection probe and other scatter inside for small details and you will want to override this details instead of blending with the central.
If this require a new proposal I will write it

@IPlayKindred Please don't bump without contributing significant new information. Use the :+1: reaction button on the first post instead. Just poking the issue without having something constructive isn't, well, constructive.

Superseded by https://github.com/godotengine/godot/pull/86073.


Update answer-auto-attendant-and-call-queue-calls.md

The call queue capability is not in preview, as below
https://techcommunity.microsoft.com/t5/microsoft-teams-blog/auto-attendant-and-call-queues-service-update/ba-p/564521#M3003

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@LolaJacobsen PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Create and Deploy HTML5 and SAP Fiori Launchpad Site Modules

Tutorial URL: https://developers.sap.com/tutorials/abap-environment-deploy-cf-production.html
Please specify the step you are referring to
Hi all,
I refer to step 7: (selection of annotation files)
I see both annotation files and can select them. As they are both links, I tried to click them. But got an error: http 404 not found. Here is one of the two urls:
https://webidecp-d029515trial.dispatcher.hanatrial.ondemand.com/sap/opu/odata/IWFND/CATALOGSERVICE;v=2/Annotations(TechnicalName='Z_I_SFLIGHT_V2_00_VAN',Version='0001')/$value
Why is this url not working?

Hi @D029515 ,
can you please send me a screenshot of your error message. Normally this should work. Does your example in ADT work properly? I can see, that you have chosen another example (Z_I_SFLIGHT_V2_00_VAN).
Please make sure, that your example works properly, otherwise test it with our example Booking and try it out again.
Best regards,
Merve

Hi Merve,
attached you'll find the screenshots.
My example works properly in ADT preview. (Also the MTA app works fine. It's just the links)
Regards,
Claudia
Screenshots Annotation Links.docx

Hi @D029515 ,
you have to checkmark both annotation files and then click Next.

Best regards,
Merve

Hi Merve,
yes, I know. But that not my question. My question is, why the links to the two files do not work.
Regards,
Claudia

@mervey45 Can you update?

Hi @D029515 ,
yes, that is normal, that you can't see the metadata. You're using the trial.
Just basically follow the instruction in the tutorial.
Best regards,
Merve


test: delete test users with null activeAt

I noticed in Clerk that we're recycling a small number of test users at the moment. Maybe 15 or so. Looking at the code for the test user pool, it's because some test users have been created but have no lastActiveAt. They then get sorted at the end of the clerk response after the most recently active users
This PR takes a different approach to cleanup:

Filter staging users by whether the have a test email address
Sort test users by lastActiveAt OR createdAt
Delete one of the oldest 8 users (to reduce conflicts between simultaneous runs)

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


Allow implicit conversion of dimensionless quantities to NumericalType

Okay, it's actually NumericType, without the al, but now I've already created the commit...

You can go back and git commit --amend ;) (or you can change NumericType to NumericalType in the code if you're confident that it's the right thing, English as a second language here, my first language has only one word for these two concepts)
If we go this way (and I think we should), it would be better to also make raw() private. This is because the raw quantity, taken alone, can be misleading. Say that I define _g instead of _Kg:
unit_base<units::gram> _g(1);
unit_base<units::gram> _Kg(1000);
auto _N = (_Kg * _m) / (_s * _s);

Now _N is 1000 * (_g * _m) / (_s * _s), so if I just use newtons.raw() on some Newton quantity, I get a value a thousand times larger than I would expect. However, if we make unitless quantities convertible to their underlying numeric(al?) type, we can say that the canonical way to get a raw number is to divide a quantity by its unit (newtons / _N), and now the problem disappears because we divide the quantity by 1000 in the process.

The problem with amending is that I can't push. I'm doing everything through the web UI at work because I happen to have logged in once. For pushing I'd need my push token, and I'd need it more than once. I'll just create new commits.

About making raw() private: Why keep it at all then? You can just remove it.

I don't mind removing it either.

When writing that last change, I found a bigger problem... But I think I should open a new issue for that, because I have two different ideas for fixing it and I'm not sure which one would be better.

Oops, this doesn't compile yet. I'll have to make another quick change..


[BEAM-11928] Implement stand-alone Combine Globally operation

Modify TryCombine to use standard combine_globally URN instead of routing through CombinePerKey. Extends the current method of handling combines to include a special CombineGlobally scope name.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

 That's what gave rise to the direct runner having to drop in a CoGBK ahead of the global combine, since the CoGBK outputs in that FullValue/ReStream pair. I'm a little surprised the Flink runner doesn't like it given that every other runner does, though. And adding logic to handle the nil ReStream case will likely not fix it, as that means it is outputting individual elements to process element instead of arranging them to be processed together. The next operation would only get the accumulation function output for a single element, not for all of the elements.
Regardless, it makes sense that the expectation of getting a ReStream should be wrapped with some checking and a more helpful error message than just a generic index out of bounds panic. I added a quick check and we can go from there.

I'm still reviewing the code, but I'll comment on the error first. I'm assuming this is the main error:
13:41:31 2021/09/15 20:41:31  (): java.io.IOException: Insufficient number of network buffers: required 17, but only 14 available. The total number of network buffers is currently set to 2048 of 32768 bytes each. You can increase this number by setting the configuration keys 'taskmanager.memory.network.fraction', 'taskmanager.memory.network.min', and 'taskmanager.memory.network.max'.

I started running into this error on a PR of my own, where I'm adding Go to the x-lang test suites. I'm not sure the exact reason started popping up, but it definitely looks like our tests are using too many network resources for some reason, although I find that strange because AFAIK we should have no parallelism while running the Flink tests.
We should probably find someone who might already know what's going on with this error.

It first came up in the initial TestStream implementation, it's something with how Flink is setting up its environment. We asked around when TestStream was first submitted and no one seemed to know, which is why those tests were generally not enabled. Seems to be machine specific, impacting places like Jenkins but passing on other machines without issue.

Gotcha, it makes sense then that it would be the same issue with that TestStream test.
In my PR I ran into this with an XLang test (TestXLang_Multi), so it looks like the environment setup cause problems even without TestStream. Probably something we should try and fix soon.

 Offline you mentioned failures, are they only happening for the disabled trigger and teststream tests?

Yes the failures are with the TestStream/trigger tests. I modified the only active teststream test to handle the altered behavior to make sure that was the only issue with the Flink test suite, so everything is green apart from the discussed issues

Solution for global combines being handled in different approach, closing PR


Check Blocking XML Errors

Check_Blocking throws this error occasionally:
Msg 9420, Level 16, State 1, Procedure Check_Blocking, Line 339
[Batch Start Line 0] XML parsing: line 1, character 369, illegal xml character

This may be related to this XML parsing issue. In which case, adding some explicit aliasing as text should solve it? Maybe?
Something like this:
 SELECT
   x =
   (
       SELECT
           [text()] =
               http://b.Name
       FROM dbo.Badges AS b
       WHERE http://b.Id = 100564
       FOR XML
           PATH(''),
           TYPE
   ).value
     (
         './text()[1]',
         'nvarchar(max)'
     );

I got this too


Suggestion to improve value() accessors with respect to move semantics

Here's a couple suggestions that I think might be worth adding to improve the usage of value() function:

Use "universal reference" && instead of const& for default_value to lift a problem that const ValueType& default_value inhibits move when default_value is temporary/r-value:

Before:
template<class ValueType, typename std::enable_if<
                 std::is_convertible<basic_json_t, ValueType>::value, int>::type = 0>
    ValueType value(const typename object_t::key_type& key, const ValueType& default_value) const
    {
        // at only works for objects
        if (JSON_LIKELY(is_object()))
        {
            // if key is found, return value and given default value otherwise
            const auto it = find(key);
            if (it != end())
            {
                return *it;
            }

            return default_value;
        }

        JSON_THROW(type_error::create(306, "cannot use value() with " + std::string(type_name())));
}

After
template<class ValueType, typename std::enable_if<
                 std::is_convertible<basic_json_t, detail::uncvref_t<ValueType>>::value, int>::type = 0>
    detail::uncvref_t<ValueType> value(const typename object_t::key_type& key, ValueType&& default_value) const &
    {
        // at only works for objects
        if (JSON_LIKELY(is_object()))
        {
            // if key is found, return value and given default value otherwise
            const auto it = find(key);
            if (it != end())
            {
                return *it;
            }
            return std::forward<ValueType>(default_value);
        }

        JSON_THROW(type_error::create(306, "cannot use value() with " + std::string(type_name())));
    }

This will allow this:
json j{{"x", "test"}};
std::string defval = "default value";
auto val = j.value("y", std::move(defval) /* or a temporary constructed in-place */);

// defval is now empty (moved-from) and val contains "default value"

Provide r-value reference overload for value() to allow moving from JSON's values when JSON is temporary/r-value:

template<class ValueType, typename std::enable_if<
                 std::is_convertible<basic_json_t, detail::uncvref_t<ValueType>>::value, int>::type = 0>
    detail::uncvref_t<ValueType> value(const typename object_t::key_type& key, ValueType&& default_value) &&
    {
        // at only works for objects
        if (JSON_LIKELY(is_object()))
        {
            // if key is found, return value and given default value otherwise
            const auto it = find(key);
            if (it != end())
            {
                return std::move(it->template get_ref<ValueType&>());
            }

            return std::forward<ValueType>(default_value);
        }

        JSON_THROW(type_error::create(306, "cannot use value() with " + std::string(type_name())));
    }

This will make possible the following:
json j{{"x", "123"}};
auto val = std::move(j).value("x", std::string{"whatever"});

// j["x"] in now empty (moved-from) and val contains "123"

One more thing: it may also be useful to provide r-value reference overload to the conversion operator ValueType() to allow moving elements when resulting type is not basic_json:
Currently, this doesn't do what one might expect:
json j{{"x", "123"}};
std::string val = std::move(j["x"]);
// oops, j["x"] still has the value "123" - we just copied stuff even though wanted to move
// we have to do this to make it work, cumbersome
std::string val = std::move(j["x"].get_ref<std::string&>());

+1 on the first point. Forwarding reference definitely makes sense there.
I don't agree on the second one. I could see an argument for it to return a "ValueType&&", but returning a "ValueType" with a side-effect of changing the underlying json object feels "surprising" to me (and I don't like surprises in interfaces :)).

I don't agree on the second one. I could see an argument for it to return a "ValueType&&", but returning a "ValueType" with a side-effect of changing the underlying json object feels "surprising" to me (and I don't like surprises in interfaces :)).

You can't return ValueType&& since it won't do what I would expected it to after doing move(json).value(...) because the return type here is deduced at the same time as the type of default_value (that is, if ValueType if l-value ref then you will return l-value ref and copy will occur instead of move). While return by value will actually work as expected. Remember that it is an r-value overload.

I wrote "ValueType&&" as shorthand, sorry for being imprecise. I meant that it really should be returning rvalue in all cases (aka, detail::uncvref_t<ValueType>&& value(..., ValueType&&) &&), but you're right that if ValueType&& == T const& then you have a binding problem.
You could solve this by adding additional overloads to trap those, but then you get very different behavior depending on what type your second argument is, and that is also a "surprising" API to me.
All in all, I like the spirit of your (2) suggestion, but I don't see a way to get all the benefits without adding surprises too. The idea that a function named "value(key,def)&&" has side effects is surprising to me as a code-maintainer. If you rename your function to "pop_value(key,def)&&" that returns value type (exactly as described above), then I am totally on board.

Reopened due to bug found. See #2181.

PR #2251 reverts #2181. Happy to see PRs to fix this issue once #2251 is merged.


[#102562916] Assertions repopulated on edit pages

See https://www.pivotaltracker.com/story/show/102562916
This brings in the changes necessary to repopulate assertion answers with their values - both on validation error and when editing previously completed pages.
Depends on:

[x] https://github.com/alphagov/digitalmarketplace-api/pull/238
[x] https://github.com/alphagov/digitalmarketplace-frontend-toolkit/pull/151
[x]  https://github.com/alphagov/digitalmarketplace-utils/pull/158

Checked out locally and works :+1:

Should attempt to do a whole PaaS submission and complete it on preview, just to make sure.


BinaryEngine: Rename engineEndpoint to externalRunningBinary or similar, and document (internally)

engineEndpoint is a fringe (internal!) feature of BinaryEngine that can be used to use an externally already running Binary Engine as the endpoint to send Prisma Client Queries to. This is highly confusing as it is not documented at all and also is not obvious from the code.
Internal discussion: https://prisma-company.slack.com/archives/CEYCG2MCN/p1592992017273200?thread_ts=1592985426.262900&cid=CEYCG2MCN

I guess I understand the corporate desire for this, but if anything as a user I think it would be nice if in fact it was easier to override the engineEndpoint (or whatever you call it in the future) from a calling client

By default this is not even active any more in Prisma Client, in any way, as we are using a Node-API based library for the engine. This is only an internal debugging feature for testing binary engines. What would be the use case to override that for normal users?

The use case I am thinking of is not necessarily for end users -- where hiding this makes sense per the technical goals of the core devs  -- but rather for library authors who are building on top of Prisma. Other language packages -- like prisma-py -- haven't built the C-bindings like you guys have and keeping the flexibility of connecting multiple clients to a single backend query engine (started as a subprocess or otherwise) I think could be useful.

Do external clients like prisma-py run the (binary) engine in a way that the JS Client could connect to that? The JS Client would not be able to give any guarantees in the other direction probably as it just manages the running (binary) engine in a way that gives no external guarantees (e.g. running at a known address etc).


Cleanup navigation items in the top bottom view controllers

Avoid duplicates

[X] This enhancement request has not already been raised before
[X] Enhancement request is specific for iOS only, for general issues / questions that apply to iOS and Android please raise them in CWA-Wishlist
[X] If you are proposing a new feature, please do so in CWA-Wishlist

Current Implementation

View controllers that are used as top controller in a TopBottomViewController often use their parent's navigation item instead of their own, like parent?.navigationItem.title = ... This forces them to be aware of the context in which they are used (embedded in a top-bottom view controller or direct children of a navigation controller).
Since #3474 is resolved, this is no longer necessary. This code can now cleaned up, which improves encapsulation.
Suggested Enhancement

Replace patterns like parent?.navigationItem.title = ... with the more simple and better navigationItem.title = ... for all controllers embedded as the top view controller of a top-bottom view controller.
Expected Benefits

Improve quality of the code. Cleaner usage of the navigation items. Better encapsulation.
Note: I would volunteer to support you with this, at least for those which I can test (I am using the simulator).

Internal Tracking ID: EXPOSUREAPP-9599

I have submitted a first PR #3548 for the DataDonationViewController as an example.
@dsarkar @heinezen could you please label it? - Thanks!

@dsarkar @heinezen please label also PR #3580 - thanks!

Thanks @ndegendogo for another PR!

@dsarkar @heinezen I have submitted another PR #3630 - please apply the labels. Thanks!

I have submitted still another PR #3644 on this ticket
@dsarkar @heinezen would you please be so kind and apply the labels? Thanks!

All PR are merged and available in the latest dev branch (release/2.13.x).
Closing as implemented.