Reverse relationship query not working in particular situations

Describe the Bug
Difference in behavior when a field is resolved via strawberry_django.auth.current_user() vs. strawberry_django.node() related to async.
System Information

Async
Docker image base: python:3.11-slim-bookworm
Strawberry version: 0.196.2
Strawberry GraphQL Django version: 0.14.1
Strawberry Django Auth version: 0.375.0

Additional Context
Representative Example:
class FollowRelationship(Model):
  from_user = models.ForeignKey(
    to="User",
    null=False,
    blank=False,
    related_name="following",
    on_delete=models.CASCADE,
  )
  to_user = models.ForeignKey(
    to="User",
    null=False,
    blank=False,
    related_name="followers",
    on_delete=models.CASCADE,
  )
  ...

class User(AbstractUser):
  ...

@strawberry_django.type(FollowRelationship)
class FollowRelationshipType(strawberry.relay.Node):
  from_user: "UserType"
  to_user: "UserType"
  ...

@strawberry_django.type(User)
class UserType(strawberry.relay.Node):
  followers: strawberry_django.relay.ListConnectionWithTotalCount[FollowRelationshipType] = strawberry_django.connection()
  ...

@strawberry.type
class Query:
  user: UserType = strawberry_django.node()
  current_user: Optional[UserType] = strawberry_django.auth.current_user()

When I issue a query:
query {
  currentUser {
    followers {
      ...
    }
  }
  user(id: "<current-user-id>") {
    followers {
      ...
    }
  }
}

The currentUser query fails due to:
Traceback (most recent call last):
  File "/.venv/lib/python3.11/site-packages/graphql/execution/execute.py", line 528, in await_result
    return_type, field_nodes, info, path, await result
                                        ^^^^^^^^^^^^
  File "/.venv/lib/python3.11/site-packages/strawberry_django/fields/field.py", line 361, in async_resolver
    resolved = await resolved
                ^^^^^^^^^^^^^^
  File "/.venv/lib/python3.11/site-packages/strawberry_django/relay.py", line 103, in wrapper
    resolved = await conn
               ^^^^^^^^^^
  File "/.venv/lib/python3.11/site-packages/strawberry/relay/types.py", line 874, in resolver
    assert isinstance(iterator, (AsyncIterator, AsyncIterable))

whereas the user query works. I can query most other fields on currentUser the same as through user  except reverse relationships. I was able to assert that the current_user resolver I provided was returning a User class object of the currently authenticated user (not anonymous user). Please let me know if there's any additional information I can provide or if you have any other recommendations.

What version of django are you using?
Based on the error, it seems that either the nodes iterable that the connection tried to resolve was not a queryset (since it should be an instance of AsyncIterable), or you are using an older version of django which didn't have async iteration over the queryset.

@bellini666 Hi, thanks for your attention again. I really appreciate it. You have helped me before in the Discord channel as well. I am currently on django 4.2.3. It looks like the newest stable version is 4.2.4, but the release notes for that patch don't mention anything about async iteratators.
>>> django.VERSION
(4, 2, 3, 'final', 0)

However, something does seem to be up WRT QuerySet (django.db.models) not implementing AsyncIterable. When I was migrating, I was following the docs and for connections that I define the resolver, I was trying to set the return type to QuerySet[SomeDjangoType] but get this error:
error: Wrong annotation used on `<field-name>` resolver. It should be return
an `iterable` or `async iterable` object.

I have had to set those return types to Iterable[SomeDjangoType] instead.
Is there a particular django version you would recommend or would you expect this django version to work?

Hi, thanks for your attention again. I really appreciate it. You have helped me before in the Discord channel as well

Happy to be helpful :)
Regarding the typing issue, the you can actually type the resolver return value as Iterable. e.g.
@strawberry.type
class Query:
    @strawberry_django.connection(ListConnectionWithTotalCount[SomeModelType])
    def some_conn(self) -> Iterable[SomeModel]:
        return SomeModel.objects.all()

As long as your django is properly typed (I recomend using this stubs lib), that will not produce any issues with pyright/mypy and will work with the connection implementation.

Played in shell and it seems like QuerySet is a AsyncIterable and AsyncIterator even though when I try to type hint that as the return type of a connection resolver it doesn't like it.

Indeed, that's why I asked your django version. On django QuerySet's versions didn't have an __aiter__ method, meaning they could not be asynchronously iterated. That's also the reason why we have this workaround for django 4.1 or older.
The fact that the assertion is failing there, even though you are using django 4.2+, means the connection is not receiving a queryset to work with there. Could you check what it is? Also, is that traceback from that exact piece of code you shared or do you have any kind of custom resolvers in there?

@bellini666

As long as your django is properly typed (I recomend using this stubs lib), that will not produce any issues with pyright/mypy and will work with the connection implementation.

Thanks, I didn't know about this alternative to django-stubs. I will try it out.

The fact that the assertion is failing there, even though you are using django 4.1+, means the connection is not receiving a queryset to work with there. Could you check what it is? Also, is that traceback from that exact piece of code you shared or do you have any kind of custom resolvers in there?

The type is a list. This list contains two FollowRelationship django models. I have no custom resolvers in there. The example code is what I believed is the entirety of relevant code from within my codebase. I have omitted other models, gql types and gql fields. However, when I tried to create an entirely minimal reproduction, I was unsuccessful despite setting almost everything up the same as my main project. In the reproduction it seemed to consistently work. :sweat:

However, when I tried to create an entirely minimal reproduction project, I was unsuccessful despite setting almost everything up the same as my main project. In the reproduction it seemed to consistently work. sweat

Ohh T_T
Taking a look at this again, I think it has something to do with the queryset being already prefetched and returning a list when sliced. If my assumption is correct, this strawberry PR should fix the issue

@bellini666 That looks like it would fix what I'm running into! Thanks for taking the time to look into this. Feel free to close this issue at your preference. As I become more familiar with async and this library, I'll try to come with solutions instead of problems =).

@bellini666 That looks like it would fix what I'm running into! Thanks for taking the time to look into this. Feel free to close this issue at your preference. As I become more familiar with async and this library, I'll try to come with solutions instead of problems =).

Hahaha, reporting issues is always helpful as well :)
Going to close this since the fix was released on strawberry during the weekend


Authorization

Implement access control scheme described here: https://github.com/seasketch/geoprocessing/wiki/OriginalDesignDoc#access-control-tokens
This system should protect user sketch data and support locking down report outputs to specific authorized projects.

Example of adding authorizer to gateway/lambdas in Typescript with latest CDK

https://github.com/elthrasher/planetstack/blob/main/fns/authorizer.ts
https://github.com/elthrasher/planetstack/blob/main/cdk/authorizer.ts

How it could work:

SeaSketch will provide a JWT to geoprocessing React App via PostMessage bridge (more detail needed).
gp React app will pass JWT to all API requests (REST/Lambda, web socket?)
Add custom JWT authorizer Lambda that API Gateway calls, which extracts token (from Authorizer header?) and authorizes it (just checks

Sources:

AWS API Gateway custom authorizer using Auth0 - https://auth0.com/docs/customize/integrations/aws/aws-api-gateway-custom-authorizers
https://circleci.com/blog/rest-api-lambda-authorizer/

Could potentially use the same token provided in sketch URL.  Add additional claims there.
Could provide an easier way to get token for debugging purposes - context menu item in sketch menu?

Should be able to use a jwt library to verify token with issuer, etc.


'Who to follow' showing up again

seen here: https://twitter.com/DiscussingFilm

This is still working for me, so it's probably the same cause as #559, which was also likely caused by Control Panel failing to run on profile pages after recent Twitter changes - still looking into these

using the new update. still getting who to follow, though i toggle on the ext. and it goes away. no biggie. would like a way to force them not adding users i dont follow, though the algo thinks i would want to see it.
brave, ublock, ghostery, vpn.


Automate deployment

Run Terraform & Ansible to setup the Jenkins master on push to main

Deployment is documented in https://github.com/falldamagestudio/UE-Jenkins-BuildSystem/blob/main/SETUP_AND_TEARDOWN.md now, but I'm not sure about what checks & balances to have when automating deployment on any pushes.

Jenkins is too finicky to reasonably attempt this. There was the Jenkins Operator. Then there was the Helm chart. Now we're moving to Ansible and a VM. A couple of manual steps (with manual validation) for core configuration is probably better.


cdc: load old value from data CF if necessary

What is changed and how it works?
Issue Number: Close #10256
What's Changed:
cdc: load old value from data CF if necessary

Related changes

PR to update pingcap/docs/pingcap/docs-cn:
Need to cherry-pick to the release branch

Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)

Side effects

Performance regression

[x] Consumes more CPU
[ ]Consumes more MEM

Release note
None

/release

This PR can be closed because fetching old-values in transaction layer increases transactin latency. It's inacceptable. However, the issue could still exist for the cases with very heavy insert load, although we didn't neet it for a long while. We can try another way to resolve it: fetching old-values in some workers in cdc module, or introducing a multi-thread CDC endpoint loop.


Build in anomaly detection function in influxdb

Feature Request
Proposal: Build in anomaly detection in influxdb
Use case:
It would be nice to see holt-winter and some build-in time series anomaly detection functions in influx QL.
E.g. https://blog.twitter.com/2015/introducing-practical-and-robust-anomaly-detection-in-a-time-series
http://robjhyndman.com/hyndsight/yahoo-data/
With this support, people should be able to see visualize  anomalies that happened in the history and be able to set the alert rule more accurately.
Kapacitor for sure is able to integrate with UDF to detect anomaly. However it just reports the results with predefined rule and doesn't give user a good experience of visualizing the anomalies levels over a continuous  time span.
having buildin anomaly detection in InfluxDB allows people to visualize the anomaly status via viz tools (e.g, Grafana), and thus have a better idea of tunning the anomaly detection system.
An example of visualizing anomalies like visualizing regular metric is as below

I believe the next release of Kapacitor is going to have a built-in anomaly detection function, so I wouldn't expect this to be added to InfluxDB. Kapacitor also has support for User-Defined Functions (UDF's), so custom anomaly detection functionality can be written if needed.

Kapacitor for sure is able to integrate with UDF to detect anomaly. However it is just report the results with predefined rule and doesn't give user a good experience of visualizing the anomalies levels over a continuous  time span.
having buildin anomaly detection in InfluxDB allows people to visualize the anomaly status via viz tools (e.g, Grafana), and thus have a better idea of tunning the anomaly detection system.
An example of visualizing anomalies like visualizing regular metric is as below

@dengliu InfluxDB shouldn't be responsible for things like this. The pipeline should be that other tools (e.g., Kapacitor) take InfluxDB data  and perform the anomaly detection analysis, and then optionally feed that data back into InfluxDB, which can then be visualised using whatever visualisation tool is in play.


Stop button in audio player

In standard audio player, there supposed to be a stop button. While I want to re-listen a surah from the beginning, there is no way. Therefore I had to refresh the entire page. A stop button would be great to start over.

This should be a feature labeled not a bug

@murad073 @AhmedShab once playing the icon should change to pause/stop

I will work on this :smile:

Sallam @AhmedShab. Are you still working on this ?

Walikum salam @andela-aolaniran, not yet. I was busy over the last few months. Sorry about that. I can get to it later. When do you guys need me to work on this?

@AhmedShab I asked because I was looking through issues and was interested in this. Since you're still working on it, I guess you can go ahead with it when its convenient for you.

@azeezolaniran2016 I actually didn't start yet. You can go ahead and work on it.


Remove EntityViewParameter from Entities Call

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.

Automation for azure-sdk-for-node

Automation for azure-sdk-for-python

We need to remove this parameter from the swagger for now. We will be pushing a new api version with a new call use the parameter and related objects. We have also verified that no calls have made using this parameter.

Automation for azure-sdk-for-go

@marstr Can you please look into this?

The service is running. Also, we have verified no calls have been made with that parameter.

Automation for azure-libraries-for-java

@AutorestCI rebuild azure-libraries-for-java


LieTensor becomes torch.Tensor in DataParrallel

🐛 Describe the bug
I'm trying to use run DataParrallel for mulit-gpu training with pypose's LieTensor. However, I noticed that when I sent a LieTensor pose object to the data parrallel model, the pose becomes a torch.Tensor:
Example:
import torch
import torch.nn
import pypose as pp
class DataParallelModel(nn.Module):
    def __init__(self):
        super().__init__()

    def forward(self, x, T):
        print("type of T is ",type(T))
        assert(isinstance(T, pp.LieTensor))
        return T @ x

def test_parallel():
    a = pp.randn_SO3(4)
    a.requires_grad = True

    net = DataParallelModel()
    if torch.cuda.device_count() > 1:
        print("Let's use", torch.cuda.device_count(), "GPUs!")
        net = nn.DataParallel(net).cuda()
        net(torch.rand(4), a)

test_parallel()

Output:
Let's use 4 GPUs!
type of T is  <class 'torch.Tensor'>
type of T is  <class 'torch.Tensor'>
type of T is  <class 'torch.Tensor'>
type of T is  <class 'torch.Tensor'>
....
Original Traceback (most recent call last):
  File ".../python3.7/site-packages/torch/nn/parallel/parallel_apply.py", line 64, in _wo
rker
    output = module(*input, **kwargs)
  File ".../python3.7/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
    return forward_call(*input, **kwargs)
  File "test_backprop.py", line 65, in forward
    assert(isinstance(T, pp.LieTensor))
AssertionError

Versions
% python collect_env.py
Collecting environment information...
PyTorch version: 1.13.1+cu117
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A

GCC version: (GCC) 7.3.1
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.2.5

Python version: 3.7.16
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration:
GPU 0: Tesla V100-SXM2-16GB
GPU 1: Tesla V100-SXM2-16GB
GPU 2: Tesla V100-SXM2-16GB
GPU 3: Tesla V100-SXM2-16GB

Nvidia driver version: 515.105.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] lietorch==0.4
[pip3] numpy==1.21.6
[pip3] numpydoc==1.5.0
[pip3] torch==1.13.1
[pip3] torch-vision==0.1.6.dev0
[conda] Could not collect

This could be a bug from PyTorch DataParrallel which calls scatter function, which could take tensor subclass as inputs, but cannot return tensor subclasses (LieTensor is a subclass of Tensor), especially considering that other torch tensor functions work well for tensor subclass.
We could submit an issue to Pytorch, but that will take a long time. An instant solution is to explicitly convert to LieTensor again if using DataParrallel, e.g.,
class DataParallelModel(nn.Module):
    def __init__(self):
        super().__init__()

    def forward(self, x, T):
        T = pp.SO3(T)
        return T @ x

BTW, you could use a = pp.randn_SO3(4, requires_grad=True) instead of a = pp.randn_SO3(4) then a.requires_grad = True

Thanks for the response! I added T = pp.SO3(T) as follows
class DataParallelModel(nn.Module):
    def __init__(self):
        super().__init__()

    def forward(self, x, T):
        print("type of T is ",type(T))
        assert(isinstance(T, pp.LieTensor))
        assert(T.is_leaf)
        return T @ x

but would it to the newly declared T being a non-leaf (and thus not optimizable)?
  File ".../python3.7/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
    return forward_call(*input, **kwargs)
  File "model/test/test_backprop.py", line 68, in forward
    assert(T.is_leaf)
AssertionError

Yes, it is expected. You create the tensor from a = randn_SO3(), so only a should be a leaf tensor. If you want something to be optimizable in the module, you need to define it as pp.Parameter(something).

Just to make sure I understood correctly, if I init a LieTensor from an existing leaf tensor, the newly initialized LieTensor is expected to be a non-leaf?
        a = torch.tensor([1,2.0,3,4],requires_grad= True)
        assert(a.is_leaf)              # True
        b = (pp.SO3(a))
        assert(b.is_leaf)              # False

Or, in other words, is there a recommended way to convert a non-leaf newly constructed LieTensor to a leaf?

Hi @zeroAska, you can easily propagate the grad. See the following example. Note that in the first case, is_leaf is False, but in the second case, is_leaf is True.
>>> c = torch.randn(4, requires_grad=True)
>>> p1 = pp.SO3(c)
>>> print(p1.is_leaf)
False

>>> p1.Log().sum().backward()
>>> print(c.grad)
tensor([1.0391, 0.2323, 1.4643, 0.0000])

>>> c = torch.randn(4)
>>> p1 = pp.SO3(c)
>>> print(p1.is_leaf)
True

If you want to convert a non-leaf tensor to a leaf tensor, you can call a.requires_grad_(True), where a can be both Tensor or LieTensor. Basically, usage of a LieTensor is totally the same with a Tensor.

Thanks a lot! I have finally made it work. When I construct a least square optimizer inside DataParallel
forward(), the pose to be optimized should take a newly-constructed LieTensor pose from the copy of the input torch.Tensor pose. It must be initialized from a copy of the input torch.Tensor instead of the original torch.Tensor input so that it is still a leaf.


multi-relationship classification?

Hello, I have a dataset，the same subject and object have multiple relationships，does the framework support multi relationship classification?

Hello, I will say yes and no. The relation decoding is multi-label because for every possible subject-object pair, a list of probabilities is computed for each predicate. So in theory, you can select more than one predicate per subject-object pair. However, in practice during training the learning is done such that the cross-entropy loss will optimize only the top relation. To modify this, you will need to change the loss and the dataloader a bit (remove this part for instance).
The metric that validate multi-label relationships is called No Graph Constraint Recall and is already implemented here. You will have to activate it by modifying this line.

Hello, I will say yes and no. The relation decoding is multi-label because for every possible subject-object pair, a list of probabilities is computed for each predicate. So in theory, you can select more than one predicate per subject-object pair. However, in practice during training the learning is done such that the cross-entropy loss will optimize only the top relation. To modify this, you will need to change the loss and the dataloader a bit (remove this part for instance). The metric that validate multi-label relationships is called No Graph Constraint Recall and is already implemented here. You will have to activate it by modifying this line.

ok，thanks，
I'll give it a try


DLS performance issue while terms in huge array

We were using dls to build user custom privilege system in kibana.
We have met performance issue while using huge terms in filter, such as:
{ "terms" : {             "appId" : [ 	            "00004c9a2a3408fa108637b5e56dde4a284f53bf", 				"0008f1f3231fa94dd870e219e574add6c3c5cee8", 				"00206dd6368c87c08bd4631ef1340ec45aace6bf", 				"00231d66b0aa0a9dbe98ce11ec2f2b27e367a2fb", 				"002aa1e6b1d2873d7f2e692876e8c9be77acd950", 				"003266a319036da6d86baaf4e72f3f779cef113a", 				"0034aede41afb566cb3f7c235be8106e62b2fed8", 				"003df3f126bf7ecba1f86c81cd1490c92d1dc18a", 				"0041345214cc64e149ea527befce4caac60ba8fb", 				...over 1000 appIds... 		] 	} }
Then simple queries like "appId:002aa1e6b1d2873d7f2e692876e8c9be77acd950" becomes pretty slow. it tooks over 6secs, in the mean time, the super admin account only took 300ms.

looks like, the plugin is trying to fetch huge result instead of just append the query then send it to es.
it's there any help i can fix it, or any doc i can find to help me understand how it works ( https://opendistro.github.io/for-elasticsearch-docs/docs/security-access-control/document-level-security/ this doc is too simple )

What is the performance of the DLS term query if it is executed by the admin? The DLS by itself should not impact performance much, it all depends on the complexity of the query used to define DLS.

took 1.5s using admin account.
repeat over 5 times.

try the following query:
{
  "query": {
    "bool": {
      "minimum_should_match": 1,
      "should": [
        {
          "constant_score": {
            "filter": {
              "terms" : { "appId" : [ "00004c9a2a3408fa108637b5e56dde4a284f53bf", "0008f1f3231fa94dd870e219e574add6c3c5cee8", ...] }
            },
            "boost": 1.0
          }
        }
      ],
      "must": [
        {
          "term": {
            "appId": "002aa1e6b1d2873d7f2e692876e8c9be77acd950"
          }
        }
      ]
    }
  }
}

it quite closely matches what DLS will execute.

try the following query:
{
  "query": {
    "bool": {
      "minimum_should_match": 1,
      "should": [
        {
          "constant_score": {
            "filter": {
              "terms" : { "appId" : [ "00004c9a2a3408fa108637b5e56dde4a284f53bf", "0008f1f3231fa94dd870e219e574add6c3c5cee8", ...] }
            },
            "boost": 1.0
          }
        }
      ],
      "must": [
        {
          "term": {
            "appId": "002aa1e6b1d2873d7f2e692876e8c9be77acd950"
          }
        }
      ]
    }
  }
}

it quite closely matches what DLS will execute.

it takes same time as normal user query

Try to optimize your DLS query definition.


fix: add message when secret creation fails from existing sso. Fixes #10420

Fixes #10420
Please do not open a pull request until you have checked ALL of these:

[x] Create the PR as draft .
[x] Run make pre-commit -B to fix codegen and lint problems.
[x] Sign-off your commits (otherwise the DCO check will fail).

[x] "Fixes #" is in both the PR title (for release notes) and this description (to automatically link and close the issue).
[x] Add unit or e2e tests. Say how you tested your changes. If you changed the UI, attach screenshots.
[x] Github checks are green.
[x] Once required tests have passed, mark your PR "Ready for review".

If changes were requested, and you've made them, dismiss the review to get it reviewed again.

In my environment, make pre-commit -B was failing due to a missing newline at the end of the following file.
(If necessary, I would like to create another PR after further investigation)
ref: https://github.com/golangci/golangci-lint/issues/1726
$ git diff util/grpc/interceptor.go
diff --git a/util/grpc/interceptor.go b/util/grpc/interceptor.go
index 0ca0a3c3..552b0723 100644
--- a/util/grpc/interceptor.go
+++ b/util/grpc/interceptor.go
@@ -94,4 +94,4 @@ func getClientIP(ctx context.Context) string {
        address := p.Addr.String()
        ip := strings.Split(address, ":")[0]
        return ip
-}
\ No newline at end of file
+}


Change URI process start.

When attempting to run a windows service, "File not found error" was raised. Proposed change fixes this issue.

Checklist

General Contributing

[ ] Have you read the Code of Conduct and signed the CLA?

Is This a Code Change?

[ ] Non-code related change (markdown/git settings etc)
[ ] SDK Code Change
[ ] Example/Test Code Change

Validation

[ ] Does this code build successfully?
[ ] Do all tests pass?
[ ] Does Stylecop pass?

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

Running windows service using .Net 6.0 in Visual Studio.
Output Type: Console Application (debug)
Log file from the service attached with the Win32Exception. (client ID is masked)
Looks like it tries to open the authentication URL as a file and not as a webpage.
HDBS_LogFile.txt

Thanks! I'll ask the team to review this.


Update ModelClassDiagram

Fixes #116

Don't merge yet as I have yet to update the model diagram; unsure how to do so.


what does this do?

I ran it and it gave some sort of info and it said it was liking videos i dont even know what this is doing.....

yeah please i want to know to, it seems liking and unlinking trending videos, the same with following, the nickname in quickstart is justinbiber? do i need to change this ? it getting trending videos from this feed? thanks for explanation.


Move re_renderer examples to its own crate in order to make workspace level examples less confusing

What
This way we don't show renderer examples like "the examples". Also, due to some dependency issues with the optional re_renderer arrow dependency (details somewhat unclear..), we were previously no longer able to run examples on the web. This works nicely now again:

depicted:

cargo run -p re_renderer_examples --bin multiview (native)
cargo run-wasm -p re_renderer_examples --bin multiview --features "webgl" (webgl, using firefox here)
cargo run-wasm -p re_renderer_examples --bin multiview (webgpu, using chrome here)

Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[x] I have tested the web demo (if applicable):

Full build: app.rerun.io
Partial build: app.rerun.io - Useful for quick testing when changes do not affect examples in any way

[x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

PR Build Summary
Docs preview
Examples preview
Recent benchmark results
Wasm size tracking

As in, it would still be an independent crate, with a cargo name of re_renderer_examples but a repo/filesystem name of re_renderer/examples?

👍 I'll try that! Not sure if cargo gets confused by this

tried and Cargo doesn't like it at all. We figured it's time to directorify crates, not happening in this PR though.


[Compute] sig image version create: Support data disk VHDs

Description

--data-vhd, --data-vhd-luns, --data-vhd-storage-accounts
Adding test now. Please review existing part.
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

@olayemio I got an error. Could you have a look? Thanks!
azure.core.pipeline.policies._universal: Request URL: 'https://management.azure.com/subscriptions/0b1f6471-1bf0-4dda-aec3-cb9272f09590/resourceGroups/cli_test_gallery_image_version_vhdjhhtrrgijlkbuwn4yh3ssnxpgblbsyukyjpn533rd/providers/Microsoft.Compute/galleries/gallery_czbiieilm2au/images/image1/versions/1.0.0?api-version=2020-09-30'
azure.core.pipeline.policies._universal: Request method: 'PUT'
azure.core.pipeline.policies._universal: Request body:
azure.core.pipeline.policies._universal: {"location": "westus", "tags": {}, "properties": {"publishingProfile": {"targetRegions": [{"name": "westus"}], "replicaCount": 1}, "storageProfile": {"osDiskImage": {"source": {"id": "/subscriptions/0b1f6471-1bf0-4dda-aec3-cb9272f09590/resourceGroups/cli_test_gallery_image_version_vhdjhhtrrgijlkbuwn4yh3ssnxpgblbsyukyjpn533rd/providers/Microsoft.Storage/storageAccounts/vhdstoragef7ab8a40af7d1f", "uri": "https://vhdstoragef7ab8a40af7d1f.blob.core.windows.net/vhds/osdisk_f7ab8a40af.vhd"}}, "dataDiskImages": [{"source": {"id": "/subscriptions/0b1f6471-1bf0-4dda-aec3-cb9272f09590/resourceGroups/cli_test_gallery_image_version_vhdjhhtrrgijlkbuwn4yh3ssnxpgblbsyukyjpn533rd/providers/Microsoft.Storage/storageAccounts/clitestk5xdgk6xivqtphsvp", "uri": "https://clitestk5xdgk6xivqtphsvp.blob.core.windows.net/container1/file1.vhd"}, "lun": 0}, {"source": {"id": "/subscriptions/0b1f6471-1bf0-4dda-aec3-cb9272f09590/resourceGroups/cli_test_gallery_image_version_vhdjhhtrrgijlkbuwn4yh3ssnxpgblbsyukyjpn533rd/providers/Microsoft.Storage/storageAccounts/clitestk5xdgk6xivqtphsvp", "uri": "https://clitestk5xdgk6xivqtphsvp.blob.core.windows.net/container1/file2.vhd"}, "lun": 1}]}}}

azure.core.pipeline.policies._universal: Response content:
azure.core.pipeline.policies._universal: {
  "name": "1.0.0",
  "id": "/subscriptions/0b1f6471-1bf0-4dda-aec3-cb9272f09590/resourceGroups/cli_test_gallery_image_version_vhdjhhtrrgijlkbuwn4yh3ssnxpgblbsyukyjpn533rd/providers/Microsoft.Compute/galleries/gallery_czbiieilm2au/images/image1/versions/1.0.0",
  "type": "Microsoft.Compute/galleries/images/versions",
  "location": "westus",
  "tags": {},
  "properties": {
    "publishingProfile": {
      "targetRegions": [
        {
          "name": "West US",
          "regionalReplicaCount": 1,
          "storageAccountType": "Standard_LRS"
        }
      ],
      "replicaCount": 1,
      "excludeFromLatest": false,
      "publishedDate": "2021-04-21T08:11:32.7607026+00:00",
      "storageAccountType": "Standard_LRS"
    },
    "storageProfile": {
      "osDiskImage": {
        "hostCaching": "ReadWrite",
        "source": {
          "uri": "https://vhdstoragef7ab8a40af7d1f.blob.core.windows.net/vhds/osdisk_f7ab8a40af.vhd",
          "id": "/subscriptions/0b1f6471-1bf0-4dda-aec3-cb9272f09590/resourceGroups/cli_test_gallery_image_version_vhdjhhtrrgijlkbuwn4yh3ssnxpgblbsyukyjpn533rd/providers/Microsoft.Storage/storageAccounts/vhdstoragef7ab8a40af7d1f"
        }
      },
      "dataDiskImages": [
        {
          "lun": 0,
          "hostCaching": "ReadOnly",
          "source": {
            "uri": "https://clitestk5xdgk6xivqtphsvp.blob.core.windows.net/container1/file1.vhd",
            "id": "/subscriptions/0b1f6471-1bf0-4dda-aec3-cb9272f09590/resourceGroups/cli_test_gallery_image_version_vhdjhhtrrgijlkbuwn4yh3ssnxpgblbsyukyjpn533rd/providers/Microsoft.Storage/storageAccounts/clitestk5xdgk6xivqtphsvp"
          }
        },
        {
          "lun": 1,
          "hostCaching": "ReadOnly",
          "source": {
            "uri": "https://clitestk5xdgk6xivqtphsvp.blob.core.windows.net/container1/file2.vhd",
            "id": "/subscriptions/0b1f6471-1bf0-4dda-aec3-cb9272f09590/resourceGroups/cli_test_gallery_image_version_vhdjhhtrrgijlkbuwn4yh3ssnxpgblbsyukyjpn533rd/providers/Microsoft.Storage/storageAccounts/clitestk5xdgk6xivqtphsvp"
          }
        }
      ]
    },
    "provisioningState": "Updating"
  }
}

Finally, it failed.
azure.core.pipeline.policies._universal: Response content:
azure.core.pipeline.policies._universal: {
  "startTime": "2021-04-21T08:11:38.9484481+00:00",
  "endTime": "2021-04-21T08:11:54.0271433+00:00",
  "status": "Failed",
  "error": {
    "code": "GalleryImageVersionInternalError",
    "message": "An internal execution error occurred. Please retry later."
  },
  "name": "442fe2fe-9ab2-4cdc-b040-262c6cb9388c"
}


Tk/parameterized tendencies

Structure for the parametrized physics tendencies (draft PR)
Overkill at this stage to implement ALL tendencies (deep convection, large scale condensation, short and long wave radiation, surface fluxes, PBL etc. ). Which of these are sufficient to just get a minimal working example running?

@tomkimpson Hi, after talking to @milankl I was thinking of doing some work on the physical parametrisations for SpeedyWeather.jl. Would you be happy for me to take over here, or would you like to collaborate somehow? Let me know what might work best for you!

@tomkimpson thanks a lot! Okay perfect, will just create a fresh branch then.

@white-alistair A more up to date branch for the tendencies stuff is at https://github.com/milankl/SpeedyWeather.jl/pull/39, just for your information. There you can see src/parameterized_tendencies is empty, apart from the function definition. To match with the rest of the code, it would be good if you could leave the function arguments unchanged e.g.
function parametrization_tendencies!(Prog::PrognosticVariables{NF}, # Prognostic variables
                                      Diag::DiagnosticVariables{NF}, # Diagnostic variables
                                     M
                                     ) where {NF<:AbstractFloat}

...

Closing - superseded by https://github.com/milankl/SpeedyWeather.jl/pull/39


error when running train

hi, when i try to run the code, it happened:
enforce fail at CPUAllocator.cpp:56] posix_memalign(&data, gAlignment, nbytes) == 0. 12 vs 0
could you pls help me? thanks a lot

This is probably an out-of-memory error. See this thread.


Fix Tor issue when cross compile for Linux

The reason it fail is because $PKG_CONFIG --variable=libdir openssl will try to grab system library instead of library in depends directory. I don't know why it also fixed undefined references to evutil_secure_rng_set_urandom_device_file too. Maybe the above pkg-config mess with configure prefix somehow.
Fixes #188

@riordant you can try to see if it work on your machine or not. I already tested with my machine and it worked.

Tested ACK
Tested building x86_64-linux-gnu in the depends directory.
I think this can be merged - though shall we wait for CI to ensure it works for all cross-compilations?

The upcoming CI will not build for other platforms when running on branches and PRs. It will build only when it do CD (which is not supported yet). So just a manual test on this should be enough.


fix grammar in docs: "can the" → "can be"

@das-g Hi! Could you please re-open your PR against ghc-9.2 please? ghc-head is not used anymore and was for GHC patches.

Closing in favor of #1477.


support for webhooks

would it be possible to add icomming webhook support? With gitlab as oauth provider, i do not have the possibility to create a MattermostUser/MattermostPassword

I think isn't possible use webhooks, because Mattermail can post in multiple channels and with webhooks we can post in a only one channel.

Maybe create a filter to redirect only to webhooks

centralized on #60


add to check if runs as bitbucket pipe

Bitbucket requires using a different proxy URL if running as Bitbucket Pipe.

Sry for the late response. Can you update the CHANGELOG?


Obfuscate Android Library

Can I use this library to obfuscate an android library I have already created in order to release it for customers?
I want to obfuscate full classes, methods, and strings, but exclude certain ones.
Is this possible?

Hi @ziadagh, StringCare plugin should obfuscate XML files before mergeResources task at compilation time for every module because the plugin is applied globally.
Then (let's suppose) you publish it in Bintray as JAR file, and the XML files obfuscated, there is a problem here:

StringCare needs the original fingerprint

So it won't be able to read strings (at least those you added for library logic).
You can use StringCare with libraries (for example) obfuscating user data. Imagine you use SQLite as the local database (or any other config) in your app; it can be a safe combination.
And for using encrypted strings at runtime in any module import the library in any library module.
Any other thing in your code must be obfuscated with ProGuard: vars, methods, class names... (it doesn't hide hardcoded strings).


Fix chat infinite loading when opening a chat with report id of 0

Details

If the report id is 0 or "null", we don't send an API request and the loading local state is always true, so the skeleton loader is showing infinitely.
Fixed Issues

$ https://github.com/Expensify/App/issues/32651
PROPOSAL: https://github.com/Expensify/App/issues/32651#issuecomment-1845720239
Tests

Same as QA Steps

[x] Verify that no errors appear in the JS console

Offline tests

Same as QA Steps
QA Steps

Open a chat with an id of 0 (staging.new.expensify.com/r/0)
Verify you see not found page

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/50919443/4ca0fd8f-41b6-4c1a-a010-e9c3c8d34507

Android: mWeb Chrome

https://github.com/Expensify/App/assets/50919443/cf7c7181-14f6-4f1b-8ef9-773ae2d8b89e

iOS: Native

https://github.com/Expensify/App/assets/50919443/0feb00b5-4437-444a-8b76-520fa1a076b4

iOS: mWeb Safari

https://github.com/Expensify/App/assets/50919443/48045a2c-ec8f-4c85-b1f7-1f6402c11a7c

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/50919443/bdd80212-3a12-4971-b204-36ae5dc07d09

MacOS: Desktop

https://github.com/Expensify/App/assets/50919443/1b3a870f-d6bc-4624-8bd6-3d7f3b3d4272

Waiting for feedback here https://github.com/Expensify/App/issues/32651#issuecomment-1865698503

Waiting for a confirmation - https://github.com/Expensify/App/issues/32651#issuecomment-1908063870

@alitoshmatov code updated

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native
n/a

Android: mWeb Chrome
https://github.com/Expensify/App/assets/59907218/6f79481a-6528-4845-8b9b-6d9617c4a80a

iOS: Native
n/a

iOS: mWeb Safari
https://github.com/Expensify/App/assets/59907218/ee65b583-0f35-4f80-966a-6822f36b080a

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/59907218/c4442ad7-4fc7-42f8-b3d3-bf95d8ee9617

MacOS: Desktop
https://github.com/Expensify/App/assets/59907218/81f05825-f962-41c5-bb7f-f640d363a8ff

@bernhardoj please fix the typescript checks, maybe by merging main, and rename the variable while you're at it.

@neil-marcellini merged with main

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to production by https://github.com/thienlnam in version: 1.4.41-12 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Continuous Group questions Y axis label

it's always %!!
https://www.metaculus.com/questions/26043/

closing as complete


May I inquire if you would be able to provide the answers to the exercises for Chapters 16 to 19 in their entirety?TY!

May I inquire if you would be able to provide the answers to the exercises for Chapters 16 to 19 in their entirety?TY!

I would definitely get in to it, when I have time.


Upload-sarif action doesn't seem to respect "uriBaseId" in SARIF files

We're using "Android Lint" to generate a sarif file. The sarif locations use this pattern:
            "originalUriBaseIds": {
                "%SRCROOT%": {
                    "uri": "file:///runner/_work/myrepo/myrepo/some/repo/dir/"
                }
            },
            ...
                             "physicalLocation": {
                                "artifactLocation": {
                                    "uriBaseId": "%SRCROOT%",
                                    "uri": "src/main/kotlin/Foo.kt"
                                },

The artifact location is relative to this uriBaseId. This is a reference to originalUriBaseIds, which the SARIF spec says should be used by consumers to find the absolute path.
However, the upload-sarif action debug logs show lines such as this:
##[debug]Unable to compute fingerprint for non-existent file: /runner/_work/myrepo/myrepo/src/main/kotlin/Foo.kt

which shows that it's not resolving paths using that %SRCROOT% path -- the correct path would be /runner/_work/myrepo/myrepo/some/repo/dir/src/main/kotlin/Foo.kt. We also see that the code scanning page says src/main/kotlin/Foo.kt can't be found in our repo ("Sorry, we couldn't find this file in the repository.").
(Caveat: we're using v2 because we can't use node20 in our private runners yet)

While originalUriBaseIds is indeed present in the SARIF spec, I’m afraid it is not supported by Code Scanning or the CodeQL Action. The Sorry, we couldn't find this file in the repository error is good example of how originalUriBaseId can cause confusion, as when loading code location for display in the GitHub UI the we don’t want to be using the arbitrary filesystem location for the file when the code was being analysed, but rather the path relative to the root of the repository. Use of originalUriBaseIds can also lead to leaking of personal/private information about the system on which the analysis was run.
In this case I’m afraid Android Lint isn’t producing SARIF that is compatible with Code Scanning, so I think you’ll need to open a ticket with them to address the problem. Documentation on supported SARIF properties can be found here.

Thanks for the response!

The Sorry, we couldn't find this file in the repository error is good example of how originalUriBaseId can cause confusion, as when loading code location for display in the GitHub UI the we don’t want to be using the arbitrary filesystem location for the file when the code was being analysed, but rather the path relative to the root of the repository. Use of originalUriBaseIds can also lead to leaking of personal/private information about the system on which the analysis was run.

Well, the upload-sarif action already handles the case where the sarif has an absolute path, and makes it relative to the repo root. (In fact that's how we're working around this bug - we use uriBaseId to replace the uri field with an absolute path, and then upload-sarif works as expected.) It seems really easy then for upload-sarif to just merge uriBaseId and uri before making the paths relative.

Sorry for the further delay in responding!
Perhaps what might help here is to specify the checkout path when calling upload-sarif? You can see that option detailed here...
https://github.com/github/codeql-action/blob/main/upload-sarif/action.yml#L12
That should hopefully allow you override the default (root of the repo checkout) and append an arbitrary/folder/path as needed.

Well there are multiple lint "runs" in the sarif file. Each gradle subproject gets a different lint result, and each one has a different originalUriBaseId path.

In that case, if you're looking for a way to get this working you could try post-processing the SARIF in order to ensure the uri for each artifactLocation has the correct path from the route of the repository. That might give you a way forward if you don't have any luck getting a compatibility fix from Android Lint.
Also, it's worth reiterating that even if Code Scanning did use originalUriBaseIds things would still be broken with SARIF output like this, as you would end up with the arbitrary path from the Actions runner rather than (as needed) the path within the repository, and hence the GitHub UI would remain broken. So compatibility with Code Scanning will definitely require changes on the Android Lint side, I'm afraid.

In that case, if you're looking for a way to get quickly unblocked you could try post-processing the SARIF in order to ensure the uri for each artifactLocation has the correct path from the route of the repository. That might give you a way forward if you don't have any luck getting a compatibility fix from Android Lint.

We're already doing just that, as I mentioned above.

Also, it's worth reiterating that even if Code Scanning did use originalUriBaseIds things would still be broken with SARIF output like this, as you would end up with the arbitrary path from the Actions runner rather than (as needed) the path within the repository, and hence the GitHub UI would remain broken. So compatibility with Code Scanning will definitely require changes on the Android Lint side, I'm afraid.

This is not correct. I explained above that upload-sarif already rewrites the sarif file to replace absolute paths (specific to GHA) with relative ones. So the fact that originalUriBaseIds has an absolute path is not the issue.
It's quite simple - upload sarif only reads the "uri" field, which doesn't match the SARIF spec. Instead it should read originalUriBaseIds[uriBaseId] + uri - literally just concatenate the two paths. Our current workaround preprocesses the SARIF to do exactly that, and it works as expected, even though the resulting path is an absolute path specific to GHA.
Again, no changes are needed for Android Lint - they are the ones following the recommendations from the SARIF spec. It's upload-sarif that is not following the spec.

We're already doing that, as I mentioned above.

Apologies, so you did. Returning sporadically to this issue was not a recipe for the most coherent response... 😬

explained above that upload-sarif already handles absolute paths (specific to GHA)

Ah, I have learned it is not in fact the Action that handles this, but in GitHub itself...

Code scanning interprets results that are reported with relative paths as relative to the root of the repository analyzed. If a result contains an absolute URI, the URI is converted to a relative URI. The relative URI can then be matched against a file committed to the repository.

This explains why the GitHub interface does in fact work, even though upload-sarif does not itself alter the absolute URIs.
As documented Code Scanning only commits to supporting a subset of the SARIF spec, but I'll create a feature request for adding support for originalUriBaseIds when processing SARIF.

This came up for another user: https://github.com/github/codeql-action/issues/2456#issuecomment-2325767041 this time from Trivy.


We need a CoC

Which of these is most suitable?
https://github.com/civicdata/civicdata.github.io/community/code-of-conduct/new?template=citizen-code-of-conduct or
https://github.com/civicdata/civicdata.github.io/community/code-of-conduct/new?template=citizen-code-of-conduct

These seem very similar.  I can't find any major differences.  They both seem fine.

Yeah, I'm confused, aren't these the same?

sorry- it was late. diff link is: https://github.com/civicdata/civicdata.github.io/community/code-of-conduct/new?template=contributor-covenant

I think we're should go with the citizen coc vs the contrib coc


Update Links “tiktok-24”

Automatically generated by Netlify CMS

👷 Deploy Preview for distracted-hoover-7b89cc processing.
🔨 Explore the source changes: 2df3a84f906c9b12544e03420b2c99b9e58a8464
🔍 Inspect the deploy log: https://app.netlify.com/sites/distracted-hoover-7b89cc/deploys/6219ea0590f94b0007b118c1


Add Support for Teiid Driver

This pull request introduces support for the Teiid JDBC Driver in DBeaver. The Teiid  is a data virtualization system that allows users to query and integrate data from multiple sources.
https://teiid.io/

Thanks for your contribution!
We will review your PR and let you know if some changes are needed

Thanks. For the future, when committing changes in your branch, include the ticket number in the commit message like this: dbeaver/dbeaver#issue-number Initial commit for my super-duper feature
And here's our guide for contributors https://github.com/dbeaver/dbeaver/wiki/Contribute-your-code#create-pull-request

Thanks for the contribution. Passing the PR to our QA team now.

@edulauer

Could you please tell how to configure a  Teiid connection using DBeaver? I would appreciate very much if you describe it step by step.
For now the icon and links should be fixed:
2.1 The icon

2.2 The incorrect Website link in the driver settings

2.3  The incorrect link to Driver documentation in the Driver properties


services/*: Implement proposal 12-support-both-directory-and-prefix-based-list

ref: #157

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- services/azblob/storager.go  9

Clones added
============
- services/azblob/storager.go  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- services/azblob/storager.go  9

Clones added
============
- services/azblob/storager.go  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- services/azblob/storager.go  9
- services/cos/storager.go  1

Clones added
============
- services/azblob/storager.go  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- services/azblob/storager.go  9
- services/cos/storager.go  7

Clones added
============
- services/azblob/storager.go  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- services/azblob/storager.go  9
- services/cos/storager.go  7

Clones added
============
- services/azblob/storager.go  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- services/azblob/storager.go  9
- services/cos/storager.go  7
- services/gcs/storager.go  5

Clones added
============
- services/azblob/storager.go  1

Clones removed
==============
+ services/gcs/storager.go  -2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- services/cos/storager.go  7
- services/azblob/storager.go  9
- services/kodo/storager.go  7
- services/gcs/storager.go  5

Clones added
============
- services/cos/storager.go  3
- services/azblob/storager.go  1
- services/kodo/storager.go  2

Clones removed
==============
+ services/gcs/storager.go  -2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- services/azblob/storager.go  9
- services/qingstor/storager.go  2
- services/kodo/storager.go  7
- services/oss/storager.go  4
- services/cos/storager.go  7
- services/gcs/storager.go  5

Clones added
============
- services/azblob/storager.go  1
- services/qingstor/storager.go  1
- services/kodo/storager.go  5
- services/oss/storager.go  6
- services/cos/storager.go  4

Clones removed
==============
+ services/gcs/storager.go  -2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- services/oss/storager.go  4
- services/gcs/storager.go  5
- services/azblob/storager.go  9
- services/s3/storager.go  4
- services/qingstor/storager.go  2
- services/cos/storager.go  7
- services/kodo/storager.go  7

Clones added
============
- services/oss/storager.go  6
- services/azblob/storager.go  1
- services/s3/storager.go  2
- services/qingstor/storager.go  2
- services/cos/storager.go  3
- services/kodo/storager.go  6

Clones removed
==============
+ services/gcs/storager.go  -2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- services/s3/storager.go  4
- services/qingstor/storager.go  2
- services/uss/storager.go  5
- services/oss/storager.go  4
- services/azblob/storager.go  9
- services/cos/storager.go  7
- services/kodo/storager.go  7
- services/gcs/storager.go  5

Clones added
============
- services/s3/storager.go  2
- services/qingstor/storager.go  2
- services/qingstor/storager_test.go  2
- services/oss/storager.go  6
- services/azblob/storager.go  1
- services/cos/storager.go  3
- services/kodo/storager.go  6

Clones removed
==============
+ services/uss/storager.go  -2
+ services/gcs/storager.go  -2

See the complete overview on Codacy


WIP: Create "temurin" variant distinct from "hotspot"

Fixes https://github.com/adoptium/temurin-build/issues/2671
This is a stop-gap to using a better split of VARIANT/VENDOR that will let us test this in principle using the current way we use VARIANT, while allowing the default run of the build scripts to NOT include any Eclipse or Temurin strings which is better for anyone running the scripts themselves. It will also make it simpler to allow users to switch to an alternate openjdk repository that doesn't have out markers in them. Doing this as a stop-gap means we can work on the changes required with minimal risk of destabilising anything else
Will need further testing (possibly a comparison from @andrew-m-leonard to ensure that they are binary identical!) and a corresponding update to the pipelines repo for s/hotspot/temurin/, the smoke tests, and possibly the testing too (Also, what about the pipeline generators?)
WIP/Draft as I'm not going to be around for much of next week but putting this up for review and to see if anyone sees may be more that will be required :-)

@sxa looks ok as a wip, just a couple of things I presume are draft, ie.the with-verion-pre-opt default and ignoring NUM_PROCESSORS. I suspect doing test builds with this will be needed to trial it...

@sxa looks ok as a wip, just a couple of things I presume are draft, ie.the with-verion-pre-opt default and ignoring NUM_PROCESSORS. I suspect doing test builds with this will be needed to trial it...

Yep those were just to force particular configurations on the system I was experimenting on.

run tests

run tests

https://ci.adoptopenjdk.net/view/Failing Builds/job/build-scripts/job/jobs/job/jdk17u/job/jdk17u-linux-x64-hotspot/58/console is a hotspot build and produces this:
16:19:44  =JAVA VERSION OUTPUT=
16:19:44  openjdk version "17.0.1-beta" 2021-10-19
16:19:44  OpenJDK Runtime Environment (build 17.0.1-beta+12-202201061534)
16:19:44  OpenJDK 64-Bit Server VM (build 17.0.1-beta+12-202201061534, mixed mode, sharing)
16:19:44  =/JAVA VERSION OUTPUT=

Metadata for the above is:
metadata.hotspot.58.txt.gz
59 is temurin and has:
16:20:00  =JAVA VERSION OUTPUT=
16:20:00  openjdk version "17.0.1-beta" 2021-10-19
16:20:00  OpenJDK Runtime Environment Temurin-17.0.1+12-202201061534 (build 17.0.1-beta+12-202201061534)
16:20:00  OpenJDK 64-Bit Server VM Temurin-17.0.1+12-202201061534 (build 17.0.1-beta+12-202201061534, mixed mode, sharing)
16:20:00  =/JAVA VERSION OUTPUT=
16:20:00  ===GENERATING RELEASE FILE===

Metadata is
metadata.temurin.59.txt.gz
Output and metadata look reasonable.

Couple of notes:

At the moment the code is producing a filename with _temurin_ in it instead of _hotspot_ - we could special case that and just use the output filename option to override that if we want to keep the same download name, however we currently don't have anything explicitly saying "Temurin" in the output.
The pipelines are currently saying Unrecognised build variant: temurin after the smoke tests which is stopping the pipeline from starting the test runs. I've added in some changes for the ci-jenkins-pipelines repository in https://github.com/adoptium/ci-jenkins-pipelines/pull/226

Currently running tests at https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk17u/job/jdk17u-linux-x64-hotspot/62/ with the new pipeline changes to see if that resolves the last one. Also running JDK8 arm32 hotspot and arm32 temurin from the new code since those are from different repositories and I'm not yet sure what will happen ;-)

Linter failures are covered under https://github.com/adoptium/temurin-build/issues/2831


Add Jenkins and Gerrit apps

Apps use the default 'quick' install. Gerrit allows the user to change the war file. These are specific to Ubuntu.

Hold off please.  I found an error when testing in a different environment

Fixed

Hi Greg,
Pushing to murano-project/murano-app-incubator is deprecated, please submit
your applications as a change-request to stackforge/murano-apps on
review.openstack.org
On Wed, Mar 18, 2015 at 2:25 AM, Greg Pryzby<EMAIL_ADDRESS>wrote:

Fixed
—
Reply to this email directly or view it on GitHub
https://github.com/murano-project/murano-app-incubator/pull/31#issuecomment-82637922
.

--
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com |<EMAIL_ADDRESS>+7<PHONE_NUMBER>, 0261
+7<PHONE_NUMBER>


The binary is not signed for macOS

The dsv binary appears to be unsigned – macOS x86 refuses to run it, unless I override in Security & Privacy. It says the binary is from an unidentified developer.

Hey Max!  I love that you are looking in on things here.  I just checked on my Mac, and the releases here on Github and the downloads page are the same binary, and it is signed.  I do have to approve it the first time after downloading it, which is a pain, but once it's been approved, the next version works well.  I installed a tool called WhatsYourSign that shows the details of signing, and it checked out.  Now, you say x86, but I expect you mean x64, unless you are running on a very old MacOS.

Hi Thomas, thanks for the response! What's strange is that I have to approve every new version of dsv, and I've been running macOS Monterey for a while now. Each new version is a completely different binary, could this be the reason?

Ok, on further inspection, it looks like the 1.30 and 1.31 weren't signed.  But 1.32 is.  Versions 1.28 and 1.29 are signed.  So there was a lapse in something, perhaps our signing cert lapsed.  I will add a test to verify that new builds are signed in the future.  Thanks for alerting me on this!


[5.6] Start adding argon hashing support.

Hello everyone.
With the release of php 7.2 which is due to be released at the end of november Argon 2i password hashing  was added. rfc for reference
So i have added support of both bcrypt and Argon2i password hashing. Simply by adding a new class. And returning a password manager within the serviceProvider.
Note: Argon2i password hashing is only availiable if a speciel confuration flag is passed during php compile time.
Edit: If ypu are on a mac and is using homebrew i added the ability to compile php 7.2 with the correct configuration flag. use the fallowing command brew install php72 --with-argon if you want to test it.

Will be looking into the failing test.. :)

Seems a good starting point. 👍

Interesting :+1:

The bcrypt helper would need to be forcing the Bcrypt implementation.

Would it make sense to also add a hash() helper that uses whatever driver is set as default?

@36864 hash() is already a PHP function. Also, another name for a hash helper has been widely discussed, but we didn't get to anything.

I guess it didn't make much sense if it was going to use bcrypt anyway.
While most people will probably choose one or the other and use the
appropriate helpers, if they change their minds in the future they'll
potentially have to make changes in a lot of places.
Just spitballing, but what if these helper functions were prefixed with
'hash_', so we could have hash_bcrypt(), hash_argon() and maybe
hash_default()?
I'm not sure if that adds readability or unnecessary complexity (besides
being a BC-break).
Maybe I'm overthinking this and/or overestimating how much use this will
have. I think most people will continue using bcrypt for the foreseeable
future and not even know about argon.
However, if in the far future bcrypt is found to be broken and people have
to switch over to argon, using something like hash_default() and just
changing a config variable would be far better than having to go through
every file and switch bcrypt() to argon(). And if there's a BC break,
people may choose to use hash_default instead of hash_bcrypt, either
because they don't know/care which algorithm to use, or because it will be
easier to change in the future.
On Tue, Oct 31, 2017 at 6:21 PM, Miguel Piedrafita<EMAIL_ADDRESS>
wrote:

@36864 https://github.com/36864 hash() is already a PHP function. Also,
another name for a hash helper has been widely discussed, but we didn't get
to anything.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/laravel/framework/pull/21885#issuecomment-340856295,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGzCJHtnExkukNb6i7C2Phdw4-bh96C3ks5sx2UvgaJpZM4QL9eJ
.

--
Cumprimentos,
Miguel Serejo

I’ll leave that up to @taylor to decide.

Some discussions on this topic just for further discussion:

rename bcrypt to hasher and allow null value (PR #21502)
Some new helpers ideas emerged.
Add a str_hash() helper (PR #20169)
Found out the str_ prefix does not match with "password hashing".
Rename bcrypt() helper (PR #20155)
Favored #20152.
bcrypt changed to Hash::make and renamed to str_hash (PR #20152)
First proposal, ideas started emerging.
Use Hash::make() instead of a direct call to bcrypt in ResetsPasswords.php (internals issue #695)
Where discussions started.

The only thing decided is that, if helpers have to change at some point, the bcrypt() helper would still be included and deprecated in the next major release following the deprecation promise. 👍

I don't really want to add any new helpers, I just want to force bcrypt to the Bcrypt implementation.

It should already be forcing the correct implementation if it’s not can you point me in the right direction?
I’ll remove the new helper I added.

Removed the helper.

Do you see that you have failing tests?

The travis environments look like they would need to have argon enabled on the php install - is that something the community can adjust or only @taylorotwell ?

@taylorotwell The failing tests on travis should now have been resolved.

Why did you make another binding for bcrypt? Is that really the way to solve the issue?

Maybe i was thinking of this wrong the wrong way. But sense the manager before just returned whatever was set as the default driver. Forcing bcrypt in the bcrypt helper made it very difficult. Spilting up the bindings makes this a lot easier. But if you know any other way i could do this without another binding some directions will be helpful :)

Why would the helper not do app('hash')->driver('bcrypt')... am I missing something?

I think everything else looks pretty fine if we can work out this binding issue.

Fixed the broken tests you were having.

I added Argon2 hashing support for 5.5 (with a dependency on libsodium) in #21524 and this was closed. PHP 7.2 is approaching stable, but it would be great to see backwards compatibility with >= 7.0.

The command to install PHP 7.2 with argon hashing for MacOS (homebrew) listed in the PR description is missing the number 2 in the with flag.
The command is: brew install php72 --with-argon2

A little light needed here @taylorotwell @morloderex
For an existing application that uses bcrypt, which means the passwords were hashed using bcrypt, won't changing the config to argon (for newer signups) affect the decrypting of the earlier "bcrypted" passwords?

The ArgonHasher::check() method uses PHP's built-in password_verify function, so users with passwords using the bcrypt algorithm will still be able to log in. You would need to check at the time of login whether the hash used the correct algorithm and options, and rehash if required:
// The user credentials have been verified already
if (Hash::needsRehash($hashedPassword)) {
    $user->password = Hash::make($plainTextPassword);
    $user->save();
}

@BenExile, thanks. Will check it out.


How to set the selected star’s border color

Hi, sorry for the late response. What do you mean by "selected star" ?

Same issue

me too

me too


Animations aren't playing back in newer versions of Sollumz

As in the title, animations aren't playing back in newer versions of Sollumz, when I downloaded commit from February everything started working just fine

same it isnt playing anymore :(


Add in ESLint

Add in Airbnb Javascript style guide and lint

We can use this package
https://github.com/dburles/meteor-eslint


added covalent api's, which supports multiple blockchain data

added covalent api's to public apis

[x] My submission is formatted according to the guidelines in the contributing guide
[x] My addition is ordered alphabetically
[x] My submission has a useful description
[x] The description does not end with punctuation
[x] Each table column is padded with one space on either side
[x] I have searched the repository for any relevant issues or pull requests
[x] Any category I am creating has the minimum requirement of 3 items
[x] All changes have been squashed into a single commit

@fawazahmed0 Can you review my PR and please let me know your feedback. Thank you.

«  I have searched the repository for any relevant issues or pull requests » lol


Add generation for compatibility matrix

Signed-off-by: Maria Kotlyarevskaya<EMAIL_ADDRESS>
Description

adds generation for compatibility matrix
adds separate arkade command to invoke a function

Motivation and Context

[x] I have raised an issue to propose this change, which has been given a label of design/approved by a maintainer (required)

fixes #762
How Has This Been Tested?

./arkade get --matrix=true
|       TOOL       | DARWIN/X86 64 | DARWIN/ARM64 | LINUX/X86 64 | LINUX/AARCH64 | LINUX/ARMHF | MING/X86 64 |
|------------------|---------------|--------------|--------------|---------------|-------------|-------------|
| kubens           | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| kubetail         | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| helm             | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| linkerd2         | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| kubectl          | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| porter           | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| tfsec            | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| dive             | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| kubebuilder      | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| mc               | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| kumactl          | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| kustomize        | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| vagrant          | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| waypoint         | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| terraform        | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| doctl            | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| packer           | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| metal            | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| kim              | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| vault            | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| influx           | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| helmfile         | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| civo             | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| goreleaser       | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| k9s              | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| autok3s          | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| k0sctl           | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| inletsctl        | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| minikube         | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| argocd-autopilot | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| argocd           | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| bun              | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| kubescape        | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| istioctl         | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| devspace         | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| flux             | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| arkade           | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| talosctl         | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| kops             | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| nats             | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| rpk              | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| kind             | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| hey              | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| k3d              | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| k3sup            | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| golangci-lint    | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| run-job          | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| k3s              | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| osm              | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| tkn              | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| gomplate         | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| gh               | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| kanctl           | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| polaris          | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| nerdctl          | ✅            | ✅           | ✅           | ✅            | ✅          | ✅          |
| docker-compose   | ✅            | ✅           | ✅           | ✅            | ✅          | ❌          |
| butane           | ✅            | ✅           | ✅           | ✅            | ✅          | ❌          |
| cilium           | ✅            | ✅           | ✅           | ✅            | ✅          | ❌          |
| nova             | ✅            | ✅           | ✅           | ✅            | ✅          | ❌          |
| lazygit          | ✅            | ✅           | ✅           | ✅            | ✅          | ❌          |
| k0s              | ✅            | ✅           | ✅           | ✅            | ✅          | ❌          |
| rekor-cli        | ✅            | ✅           | ✅           | ✅            | ❌          | ❌          |
| eksctl           | ✅            | ✅           | ✅           | ✅            | ❌          | ❌          |
| krew             | ✅            | ✅           | ✅           | ✅            | ❌          | ❌          |
| kail             | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| stern            | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| kubectx          | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| opa              | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| mkcert           | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| inlets-pro       | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| kubeseal         | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| trivy            | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| popeye           | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| just             | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| buildx           | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| pack             | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| kube-bench       | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| promtool         | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| kgctl            | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| dagger           | ✅            | ✅           | ✅           | ✅            | ❌          | ❌          |
| faas-cli         | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| kubestr          | ✅            | ✅           | ✅           | ❌            | ❌          | ❌          |
| hostctl          | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| oh-my-posh       | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| jq               | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| terragrunt       | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| sops             | ✅            | ❌           | ❌           | ❌            | ❌          | ❌          |
| vcluster         | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| operator-sdk     | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| kubecm           | ✅            | ✅           | ✅           | ✅            | ❌          | ❌          |
| terrascan        | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| hadolint         | ✅            | ❌           | ❌           | ❌            | ❌          | ❌          |
| nats-server      | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| k10multicluster  | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| caddy            | ✅            | ❌           | ❌           | ❌            | ❌          | ❌          |
| k10tools         | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| cosign           | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| tilt             | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| hubble           | ✅            | ❌           | ❌           | ❌            | ❌          | ❌          |
| clusterctl       | ✅            | ✅           | ❌           | ❌            | ❌          | ❌          |
| hugo             | ✅            | ❌           | ❌           | ❌            | ❌          | ❌          |
| yq               | ✅            | ❌           | ❌           | ❌            | ❌          | ❌          |
| fzf              | ✅            | ❌           | ❌           | ❌            | ❌          | ❌          |
| cr               | ✅            | ❌           | ❌           | ❌            | ❌          | ❌          |

Are you a GitHub Sponsor yet (Yes/No?)

[ ] Yes
[x] No

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Documentation

[ ] I have updated the list of tools in README.md if (required) with ./arkade get -o markdown
[ ] I have updated the list of apps in README.md if (required) with ./arkade install --help

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I've read the CONTRIBUTION guide
[x] I have signed-off my commits with git commit -s

[ ] I have tested this on arm, or have added code to prevent deployment

I probably missed this. It looks interesting as a kind of internal tool or utility for us to use to go back and revisit tools and see if they've added Arm/Windows etc yet, or maybe to raise issues there.

I probably missed this. It looks interesting as a kind of internal tool or utility for us to use to go back and revisit tools and see if they've added Arm/Windows etc yet, or maybe to raise issues there.

Yes, the initial idea was like this but it turns out that Github very quickly ban you if you are doing a lot of concurrent requests from one IP. So, it's not easy to get the reliable data in the way that I've tried to implement it.


MoorDyn updates and bug fixes

Feature or improvement description
Finished Connections to Points:
The transition to using the word points from using the word connections has been completed. Going forward all development should use the word points.
Standardized outputs:
MoorDynF and MoorDynV2 (C++ code) output flags have been standardized according to the following table:
Bug Fixes:
Resolves a body added mass bug, a rod Aq bug, rod inertia bug, and typos in comments:

The body added mass calculation was adding a volume to the mass, which is dimensionally incorrect, and was missing the water density and the Ca coefficient.
The rod Aq bug was identified by Lu Wang at NREL. The force labeled Froude-Krylov force is actually the long-wave diffraction force. The force labeled dynamic pressure is actually the Froude Krylov force. The 1 that was added to CaEnd was a mistake because it represents the FK contribution which had already been accounted for in the dynamic pressure calculation (now FK force). See Eq. (32) on page 51 of the HydroDyn manual for the detailed equations: https://www.nrel.gov/wind/nwtc/assets/downloads/HydroDyn/HydroDyn_Manual.pdf
The rod inertia bug has been discussed in PR 93 on the C++ repo (https://github.com/FloatingArrayDesign/MoorDyn/pull/93 ). The lumped mass approach incorrectly handles the end nodes moment of inertias and incorrectly applies the parallel axis theorem for the rod. External contributors to the C++ code have introduced a correction term that @mattEhall and I have verified produces the correct moment of inertia for the rod.

Related issue, if one exists
n/a
Impacted areas of the software
MoorDyn
Additional supporting information
The new output flags have been added to the MoorDyn documentation.
Test results, if applicable
n/a

@mattEhall, can you review this?

@RyanDavies19, are there any input file changes required for MD?  It also looks like this may be changing the regression test results for MoorDyn (not surprising given the bugfixes).

@andrew-platt No input file format changes for MD, other than the possible flags in the output options section are slightly different and have more options. This is being updated in the MD C++ documentation that the MD OpenFAST documentation page is linked to.

There are some modifications needed in FAST.Farm as well: https://github.com/OpenFAST/openfast/actions/runs/5812836020/job/15761098777?pr=1727

Fixed that FAST.farm error. It needed to be updated to match the points convention.

Thanks @RyanDavies19!  I'll take a look at the differences in the regression test results and verify they make sense.  Then probably do a PR to your branch with the regression test baseline update.
Since this is a bug fix, I'm going to put it into the rc-3.5.1 branch for our next release.

Hi Andy, I've reviewed and approve this once all tests are passing.
Thanks Ryan for doing all this, and Andy for catching the FAST.Farm adjustment.

@andrew-platt FYI I just added a new fix. MoorDyn was taking body orientation inputs as radians when it should have been degrees. Chatted with Matt and Lu about this.

Hi @RyanDavies19, I just want to check with you whether the expression for the axial drag force on rod ends is as intended on the following two lines:
https://github.com/RyanDavies19/MoorDynF_ryan/blob/357d82717e41af504f044e33bb0d0d0bca2151d9/modules/moordyn/src/MoorDyn_Rod.f90#L830
https://github.com/RyanDavies19/MoorDynF_ryan/blob/357d82717e41af504f044e33bb0d0d0bca2151d9/modules/moordyn/src/MoorDyn_Rod.f90#L860
It looks like the drag force is missing a coefficient of 0.5 in front (or 0.25 if you follow the HydroDyn convention).

@luwang00, you're right, a factor of 0.5 is missing!
(I think this single-ended convention is a good fit for MoorDyn, rather than the HydroDyn convention of using 0.25.)
@RyanDavies19, if this sounds right to you too would you mind making this fix and also checking MD-C?
Also, I noticed a couple ancient commits sitting on my OpenFAST dev branch. This PR is probably a good place to include them. Could you please cherry-pick in https://github.com/mattEhall/openfast/commit/70c011a1f8d13747c8b4c3701c0b63f9e41236d2, and let's chat about a few updates to the warnings and messages.

Hi @RyanDavies19, I just want to check with you whether the expression for the axial drag force on rod ends is as intended on the following two lines:
https://github.com/RyanDavies19/MoorDynF_ryan/blob/357d82717e41af504f044e33bb0d0d0bca2151d9/modules/moordyn/src/MoorDyn_Rod.f90#L830
https://github.com/RyanDavies19/MoorDynF_ryan/blob/357d82717e41af504f044e33bb0d0d0bca2151d9/modules/moordyn/src/MoorDyn_Rod.f90#L860
It looks like the drag force is missing a coefficient of 0.5 in front (or 0.25 if you follow the HydroDyn convention).

@luwang00 I didn't know those were off, good catch. Is the correct fix then to use HydroDyn coefficients as shown below?
Line 830:
! axial drag
            Rod%Dq(:,I) = Rod%Dq(:,I) + **0.25** VOF * 0.25* Pi*Rod%d*Rod%d * p%rhoW*Rod%CdEnd * MagVq * Vq

@mattEhall will do and add to this branch. Happy to chat about changes to error handling, most everything was with regards to how things were printed.

@luwang00 I chatted with Matt, 0.5 is what he said is best.

@RyanDavies19 Thanks for confirming. Looks good to me.

This is ready to merge. The fix to the catenary solver was changing the units of the line wet weight passed into the catenary from kg/m to N/m (Used by MoorPy and MoorDynC v1/v2). Prior to this, MoorDynF was not initializing the line tension correctly as seen in the figure below. Discussed this issue with Lu Wang and Stein Housner and they are in agreement.

With this change, the initial tensions look like the following:

The difference is due to a bug in the v2 C code, as MoorDynF now matches MoorDynC v1.

According to the documentation for MoorDyn v2 (https://moordyn.readthedocs.io/en/latest/inputs.html#points-list), it seems that the attachment could be defined as “Fixed”, “Vessel”, “Connect”.

However, OpenFAST v3.5.1 does not accept "Connect".

It seems that this "Connect" has been removed and "Coupled" should be used instead. Right?

@RBergua It depends what you are looking for. Previous versions of MoorDyn used the word 'connect', which we have now transitioned to 'point'. Connect referred to a free point, and the key words 'free', 'point', or 'p' will give the same behavior in MoorDyn as the old 'connect' keyword would. In changing to points I tried to keep things backwards compatible, but missed this in the fortran code (connect is still and option in the C code).