How to specify multiple testproject

Can i do something like this:

name : coverlet
uses<EMAIL_ADDRESS>with:
testProject: ['myProjectTests/myProjectTests1.csproj', 'myProjectTests/myProjectTests2.csproj']
output: 'lcov.info'
outputFormat: 'lcov'
excludes: '[program],[test]test.'
name: coveralls
uses<EMAIL_ADDRESS>with:

Hello @Tirthas , I think simple listing csproj separated by spaces should do the job.
Coule you try and share please

@Tirthas , please answer ! you've opened and immediatly closed an issue. Have you find a way to solve your need ? share it with the community ! it's the way OSS works

As for now multiple test project are not supported.
Specifying many test project in the testProject attribute does not work. specifying the sln solution file would run all the tests but then will generate as many coverage report as test project.
We need some rework to be able to merge those report in a single one.

@Tirthas ,
version 1.3.4 solves the issue. Using the sln as test project coverlet-action will run all test project included in solution and aggregate coverage.
Warning : coverage threshold will not be tested as coverlet output many coverage table that can not be merged to get a global coverage. i will look if something is possible here.
    - name: Test with dotnet
      uses<EMAIL_ADDRESS>      id: 'coverlet'
      with:
        testProject: solution.sln
        output: 'lcov.info'
        outputFormat: 'lcov'
        excludes: '[program]*'


error installing rubyzip

I try to use this cookbook with aws opsworks but it keeps failing with the following error:
[2016-10-24T13:30:51+00:00] INFO: Processing chef_gem[rubyzip] action install (/var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise-archive/files/halite_gem/poise_archive/archive_providers/zip.rb line 47)

================================================================================
Error executing action `install` on resource 'chef_gem[rubyzip]'
================================================================================

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '127'
---- Begin output of /opt/chef/embedded/bin/gem install rubyzip -q --no-rdoc --no-ri -v "1.2.0" ----
STDOUT:
STDERR: sh: /opt/chef/embedded/bin/gem: No such file or directory
---- End output of /opt/chef/embedded/bin/gem install rubyzip -q --no-rdoc --no-ri -v "1.2.0" ----
Ran /opt/chef/embedded/bin/gem install rubyzip -q --no-rdoc --no-ri -v "1.2.0" returned 127

Cookbook Trace:
---------------
/var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise-archive/files/halite_gem/poise_archive/archive_providers/zip.rb:47:in `install_rubyzip'
/var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise-archive/files/halite_gem/poise_archive/archive_providers/zip.rb:41:in `block in check_rubyzip'
/var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise/files/halite_gem/poise/helpers/subcontext_block.rb:54:in `instance_eval'
/var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise/files/halite_gem/poise/helpers/subcontext_block.rb:54:in `subcontext_block'
/var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise/files/halite_gem/poise/helpers/notifying_block.rb:67:in `notifying_block'
/var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise-archive/files/halite_gem/poise_archive/archive_providers/zip.rb:40:in `rescue in check_rubyzip'
/var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise-archive/files/halite_gem/poise_archive/archive_providers/zip.rb:38:in `check_rubyzip'
/var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise-archive/files/halite_gem/poise_archive/archive_providers/zip.rb:32:in `unpack_archive'
/var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise-archive/files/halite_gem/poise_archive/archive_providers/base.rb:70:in `block in action_unpack'
/var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise-archive/files/halite_gem/poise_archive/archive_providers/base.rb:65:in `action_unpack'

Resource Declaration:
---------------------
# In /var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise-archive/files/halite_gem/poise_archive/archive_providers/zip.rb

47:         chef_gem 'rubyzip'
48:       end

Compiled Resource:
------------------
# Declared in /var/chef/runs/7f0df452-daea-4452-b5ee-53b77e4a8d11/local-mode-cache/cache/cookbooks/poise-archive/files/halite_gem/poise_archive/archive_providers/zip.rb:47:in `install_rubyzip'

chef_gem("rubyzip") do
package_name "rubyzip"
action [:install]
retries 0
retry_delay 2
default_guard_interpreter :default
declared_type :chef_gem
cookbook_name "bbr_bastion"
gem_binary "/opt/chef/embedded/bin/gem"
end

Platform:
---------
x86_64-linux

this is what I add to my book:

poise_archive 'http://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.1.zip' do
destination '/opt'
end

do you maybe know how I could fix this?

Unfortunately chef_gem not working is unrelated to this cookbook, but it probably an issue with how OpsWorks installs Chef. You'll have to take it up with Amazon support or stop using OpsWorks.


Build with Java 17 LTS

Close #654 and #664

Two comments about RandomDestinationConnectionStrategy...
(1)
The class used to expose a public getRandom() method. The only reason these method was made public is to allow mocking by Mockito during test case (some tests are not in the same package so the method could not have been made protected instead).
Issue #664 is about Mockito unable to Mock the java.util.Random class with Java 17. To work around the issue, this PR does not expose the Random anymore but instead defines a nextInt() method directly on the strategy class. Test cases are modified to mock/intercept that method instead of mocking the Random itself.
However, this new method must still be public which is definitely not "good". IMHO a better approach is to make it protected and let testcases extend the class and override the method with the desired behaviour for the test.
(2)
RandomDestinationConnectionStrategyTest is about testing the random strategy - but there is no "random" anymore: each test starts by giving the sequence of "random" number that should be returned by subsequent calls to Random#nextInt()... According to me, we are not testing the "RandomConnectionStrategy" here but rather the DestinationConnectionStrategyWithTtl...

(1) Feel free to make protected and extend as you mentioned.
(2) The test does not need to test that Random/ThreadLocalRandom behave properly, since they have been thoroughly tested by the jdk release process.  The test just needs to verify that the RandomDestinationConnectionStrategyTest calls Random/ThreadLocalRandom properly and returns their values.  So mocking the Random return values, and checking that the RandomDestinationConnectionStrategy returns those values is a valid test.
(3)  I'd have to dig in to see if it is safe to remove.  I don't think there's a harm in using a thread local Random to ensure the strategy is threadsafe.

(1) Feel free to make protected and extend as you mentioned.

I chose to pass a UnaryOperator function as argument to the constructor to generate random numbers. The default implementation makes use of ThreadLocalRandom.current().nextInt(). Test cases can provide their own implementation to control the sequence of generated random numbers.

(3) I'd have to dig in to see if it is safe to remove. I don't think there's a harm in using a thread local Random to ensure the strategy is threadsafe.

I kept the ThreadLocalRandom. The "thread-safety" question can be raised for the other connection strategies as well. I propose to open a separate issue to cover them all if we feel the need to investigate any further.


Enable GHSA to consolidate affected entries

Context
Currently, GitHub's Advisory Database encodes pairs of (introduced, fixed) events in separate affected objects. This is because GitHub needs to preserve these pairs when converting the OSV entry back into their internal database represenation.
An example: https://github.com/github/advisory-database/blob/d6004eb8de91ad341605da869ab1b9f1e4abe433/advisories/github-reviewed/2017/10/GHSA-xgr2-v94m-rc9g/GHSA-xgr2-v94m-rc9g.json#L14
"affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "activesupport"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            { "introduced": "2.3.2" },
            { "fixed": "2.3.16" }
          ]
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "activesupport"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            { "introduced": "3.0.0" },
            { "fixed": "3.0.20" }
          ]
        }
      ]
    }
  ],

One obvious alternative here is to use a single affected entry and have two separate ECOSYSTEM ranges in there:
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            { "introduced": "2.3.2" },
            { "fixed": "2.3.16" }
          ]
        },
        {
          "type": "ECOSYSTEM",
          "events": [
            { "introduced": "3.0.0" },
            { "fixed": "3.0.20" }
          ]
        }
      ]

However, I believe this wasn't done, because GitHub needs to record version metadata using a <= operator, and relies on database_specific to this. One example: https://github.com/github/advisory-database/blob/d6004eb8de91ad341605da869ab1b9f1e4abe433/advisories/github-reviewed/2020/03/GHSA-gww7-p5w4-wrfv/GHSA-gww7-p5w4-wrfv.json
This has a bunch of affected entries that look like:
GHSA-gww7-p5w4-wrfv.json
    {
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.0.0"
            }
          ]
        }
      ],
      "database_specific": {
        "last_known_affected_version_range": "<= 2.0.6"
      }
    },

Problems
There are a number of problems here:

Using the the current evaluation pseudo-code, the semantics of the GHSA-gww7-p5w4-wrfv.json  entry above would mean: everything after 2.0.0 is affected, regardless of any fixes that are encoded afterwards in other affected entries.
This advisory has fixes later specified in <IP_ADDRESS> and <IP_ADDRESS>, but they're not going to be considered under the current evaluation algorithm. Any version after 2.0.0 will be incorrectly considered to be vulnerable.

Having duplicate package entries makes the entry a lot less lean than it should be

Proposed solutions
Add database_specific to affected[].ranges[]
If we instead add database_specific to affected[].ranges[], we could encode GHSA-gww7-p5w4-wrfv as
{
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.0.0"
            },
          ],
          "database_specific": {
            "last_known_affected_version_range": "<= 2.0.6"
          }
        },
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.1.0"
            },
          ],
          "database_specific": {
            "last_known_affected_version_range": "<= 2.1.5"
          }
        },
        ...
      ],

The pseudo-code as is should work as intended with this encoding (with minor changes re sorting), and the resulting JSON has far less duplication.
Support a <= event
Similar to above, rather than encoding this in database_specific, we support a "last_known_affected" event or something similar:
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.0.0",
              "last_known_affected": "2.0.6"
            },
          ],
        },
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.1.0",
              "last_known_affected": "2.0.6"
            },
          ],
        },

In the vast majority of cases, GitHub does actually know the exact fix version (example), but they would still like to record this <= information for use in tools such as Dependabot.
Supporting this would mean we potentially complicate our version specification, and potentially encourage entries that only use last_known_affected when we really want fixed in all cases. On the other hand, CVE 5.0 does support a lessThanOrEqual, and perhaps OSV was missing this.
Fix the evaluation algorithm to consider all affected entries for the same package.
We could alternatively make the pseudo-code handle these problematic cases, but it doesn't seem ideal as it:

Does not address the duplication issue. The intention of having multiple duplicate affected entries for the same package was to encode things like platform configurations where the set of affected versions are not the same.
Complicates the algorithm.

@rsc @chrisbloom7 WDYT? I'm starting to think supporting an event that encodes "<=version" makes sense, especially since it's supported in CVE 5.0.

@oliverchang Thanks for explaining why the current approach could be problematic and for iterating through a number of potential solutions.
For starters, I would love to remove our dependence on custom database_specific hint fields like last_known_affected_version_range as it adds hidden requirements to contributing to our repo that are not immediately clear outside of the curation pipeline and would be easy to get wrong and difficult to explain how to get it right - a classic anti-pattern that we must unfortunately rely on at the moment. So, adding support for a last_known_affected event type (and validating that either it or fixed can be present but not both) sounds really appealing. I share your conern that this could end up being used where fixed would be more appropriate. Maybe naming it last_known_unfixed etc might offer a built-in hint that it is less preferred than fixed? Just a suggestion.
If that potential for misuse makes option 2 less attractive, then your first suggestion for Add database_specific to affected[].ranges[] does resolve one problem we would otherwise have with rehydration (the last_known_affected_version_range hinting key). There is another potential issue with mixing affected[].versions fields with affected[].ranges[] where the versions don't match (we use this to determine when a range should be rehydrated using the = operator), but I have some ideas for working around that problem.

grumble thinking about this further, we use last_known_affected_version_range to retain enough context about an upper bound that we can determine if it originated as a < or as a <=, in the absence of a fixed version. We would still need a way to do that even if last_known_affected event was introduced. (i.e. exclusive bound operators are problematic, but sometimes necessary.)

I see, perhaps we can start with the range-specific database_specific, since that would be required either way?
@rsc, what do you think of all of this?

Maybe we can do both options 1 and 2? They serve different purposes, and having both options available would be useful on our side to clean up our round-trip transformation process.

It is a design goal for OSV for all clients to be able to determine in an algorithmically precise way whether a particular version is affected. Having "database_specific" in the affected object would harm that goal, because now the meaning depends on knowing about each particular database. So I'd very very much like to avoid doing that.
Changing the algorithm has similar problems.
That leaves the potential for adding a <= operator in some form. Since we did that for CVE JSON 5.0 and we ideally want to be able to convert losslessly between CVE and OSV, it does seem reasonable to add <=. Today we have "introduced" and "fixed". If we added <=, I assume the way it would work is that we'd add "last_affected", and an entry can have either "last_affected" or "fixed" but not both. And then the test would be < fixed or else <= last_effected. I think that matches CVE JSON 5.0's lessThan and lessThanOrEqual.
Do I have that right?

It is a design goal for OSV for all clients to be able to determine in an algorithmically precise way whether a particular version is affected. Having "database_specific" in the affected object would harm that goal, because now the meaning depends on knowing about each particular database. So I'd very very much like to avoid doing that.

Right, in this case though, I don't think database_specific would necessarily change the algorithm. <= isn't completely necessary. It's mostly providing necessary metadata for GitHub to convert entries back to their internal DB representation (and may still be necessary even if we add last_affected).

Changing the algorithm has similar problems.
That leaves the potential for adding a <= operator in some form. Since we did that for CVE JSON 5.0 and we ideally want to be able to convert losslessly between CVE and OSV, it does seem reasonable to add <=. Today we have "introduced" and "fixed". If we added <=, I assume the way it would work is that we'd add "last_affected", and an entry can have either "last_affected" or "fixed" but not both. And then the test would be < fixed or else <= last_effected. I think that matches CVE JSON 5.0's lessThan and lessThanOrEqual.

I'm also leaning toward this given the CVE JSON 5.0 support and the closer alignment with GHSA. I can draft up a PR for this if we all agree here.

Do I have that right?

Might I suggest that if we're willing to add last_affected we also add last_known_good, and potentially last_known_bad? With those in place we can easily represent >, >= (i.e. introduced), = (introduced and/or specific versions), <= (this proposal), and < operators, all of which can be used to describe certain problems, eliminating the need for special database specific context hints that are not obvious how to use or consistent across databases. We've discussed the possibility of a last_known_good operator in the past and I could not make a strong argument for it at the time, but realistically sometimes exclusive operators are the best way to describe a vulnerability when a curation team cannot identify an inclusive version for any number of reasons. The same constraints would apply, i.e. only one of ..., and it's still machine parseable. I will end this suggestion with what is likely obvious to all of us, which is that curation is difficult because humans are difficult and humans create version strings that are difficult to parse, even for machines. The more flexible the spec can be, the better we can represent all classes of vulnerabilities from all databases. /soapbox

(Also, selfishly, that would solve so many problems on our translation side)

I do think we want to optimise more for the consumers of these entries to be able to consume/edit them more simply. As @rsc also explored in https://github.com/ossf/osv-schema/issues/31#issuecomment-1036266822, there are other reasons to not add operators like "last_known_good", including lack of CVE 5.0 support and inaccurate encodings.
Given the compatibility constraints of our schema, adding new fields/semantics is expensive and I think we should be a bit cautious here in introducing too many new fields at once.

I agree with @oliverchang about being very selective in how many different constraints we add, for all the reasons he enumerated. I suggest we start with just "last_affected".

@oliverchang I'm just in the process of implementing support for last_affected and wanted to check if the last example in your OP is correct or not:
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.0.0",
              "last_known_affected": "2.0.6"
            },
          ],
        },
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.1.0",
              "last_known_affected": "2.0.6"
            },
          ],
        },

Should that last last_known_affected really be 2.0.6, or should it be 2.1.5 (based on the example above it)?

@oliverchang I'm just in the process of implementing support for last_affected in osv-detector and wanted to check if the last example in your OP is correct or not:
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.0.0",
              "last_known_affected": "2.0.6"
            },
          ],
        },
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.1.0",
              "last_known_affected": "2.0.6"
            },
          ],
        },

Should that last last_known_affected really be 2.0.6, or should it be 2.1.5 (based on the example above it)?

Good catch, thanks! That was indeed a bad copy/paste. I've fixed up the original post, and renamed this to the actual field name we went with (last_affected).

@oliverchang awesome, thanks for that! I've landed support for last_affected in v0.7.0 of osv-detector


[SPARK-48606] Upgrade google-java-format to 1.22.0

What changes were proposed in this pull request?
This PR aims to upgrade google-java-format from 1.17.0 to 1.22.0.
Why are the changes needed?
google-java-format plugin of Spark Kubernetes Operator repository is too old and may hit old bugs like the following. The latest version is recommended.
java.lang.Exception: google-java-format 1.17.0 is currently being used, but outdated.
google-java-format 1.19.2 is the recommended version, which may have fixed this problem.
google-java-format 1.19.2 requires JVM 11+.

Releases:

https://github.com/google/google-java-format/releases/tag/v1.22.0
https://github.com/google/google-java-format/releases/tag/v1.21.0
https://github.com/google/google-java-format/releases/tag/v1.20.0
https://github.com/google/google-java-format/releases/tag/v1.19.2
https://github.com/google/google-java-format/releases/tag/v1.19.1
https://github.com/google/google-java-format/releases/tag/v1.19.0
https://github.com/google/google-java-format/releases/tag/v1.18.1
https://github.com/google/google-java-format/releases/tag/v1.18.0

Does this PR introduce any user-facing change?
No.
How was this patch tested?
Pass the CIs.
Was this patch authored or co-authored using generative AI tooling?
No

Thank you, @viirya !

Merged to main.


VPATH make fails

Tried to do a VPATH make in a separate directory (../../build/p4c-bm)
cd ../../build/p4c-bm
../../src/p4c-bm/configure --prefix=...
make
It produced the following error:
$ make
make  all-recursive
make[1]: Entering directory `/home/vgurevich/test/build/p4c-bm'
Making all in .
make[2]: Entering directory `/home/vgurevich/test/build/p4c-bm'
rm -f p4c_bm/config.py p4c_bm/config.py.tmp
sed -e 's|@pkgdatadir[@]|/home/vgurevich/test/install/share/p4c_bm|g' ../../src/p4c-bm/p4c_bm/config.py.in >p4c_bm/config.py.tmp
/bin/bash: p4c_bm/config.py.tmp: No such file or directory
make[2]: *** [p4c_bm/config.py] Error 1
make[2]: Leaving directory `/home/vgurevich/test/build/p4c-bm'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/vgurevich/test/build/p4c-bm'
make: *** [all] Error 2

The reason seems to be that configure forgets to create p4c_bm subdirectory in the build directory.
Once I create it manually, the build process works fine.

Fixed by 7c6352036ac30994d28b37f33badd9d180a2a47a


[SPARK-14467][SQL] Experiments: Async I/O in FileScanRDD

What changes were proposed in this pull request?
Builds on https://github.com/apache/spark/pull/12243 to help benchmark improvements by interleaving CPU and I/O in FileScanRDD.
How was this patch tested?
Existing Tests

Test build #56922 has started for PR 12667 at commit f3a2167.

Test build #56922 has finished for PR 12667 at commit f3a2167.

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

Merged build finished. Test PASSed.

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

test this please

Test build #57265 has started for PR 12667 at commit 796d5eb.

Test build #57265 has finished for PR 12667 at commit 796d5eb.

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

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

Merged build finished. Test PASSed.


Create OutputParser.test.ts [Needs Review]

Issue
SubQuestionOutputParser is not working as expected, writing some tests to check it out.
QuestionGenerator outputs a list of objects in string format, which is unexpected.
In particular:
"[{prompt: "smth", response: "nothing"}]"
Why we have this issue
LLMs are not guaranteed to return outputs in an exact format, even when prompted to. See the test script for examples.
To-dos

[x] Write tests
[x] Fix bug
[x] Confirm the tests pass/Review both tests and code

Files to change

src/tests/OutputParser.test.ts
src/OutputParser.ts

@sourabhdesai @logan-markewich there is a question here about what we should be doing if no subquestion tool (or OpenAI function) is the correct one to select. I think maybe we should handle that explicitly?

For the parser:  if no subQuestion tool is the right one to select, we still get a String of List[JSON object] representation back (as this is the output from SubQuestion generator).
Solution:

Doesn't matter if we have ```json specified from PromptTemplate or not, we just need a list of JSON objects wrapped by square brackets.
Trimming the string before the first "[" and after the last "]" fixes this, is pretty general, and is fast.

Okay fixed.


Integrate PPP specific evidence parsers with the other parsers

So far the data update, and therefore the evidence generation of the PPP was not particularly regular, which made the integration of these parsers not essential. Although the snakefile contained the rules to run these parsers, it gave the false impression that once we run the --until all rule, PPP evidence is also updated in the right buckets. But that was not the case.
Task:

[ ] Integrate the PPP specific rules into the main evidence parser pipeline.

From the parser's snakefile:
# At this point parsing the PPP datasources are not yet as integrated as to add these files to the complete set of output:
PPP_sources = [
    ('ot_crispr.json.gz', GS.remote(f"{config['OT_CRISPR']['outputBucket']}/ot_crispr-{timeStamp}.json.gz")),
    ('validation_lab.json.gz', GS.remote(f"{config['ValidationLab']['outputBucket']}/validation_lab-{timeStamp}.json.gz")),
    ('encore.json.gz', GS.remote(f"{config['Encore']['outputBucket']}/encore-{timeStamp}.json.gz"))
]


NullPointerException upon calling OAuth2TokenValidationService - validate operation (Oracle DB)

Steps to reproduce the issue:

In a fresh IS pack use an Oracle database as the primary for IS. (IDN tables should be in this database)
Configure as per the following doc[1] to get the user claims of the authorized user as a JWT token with the validation response.
Set the DefaultCacheTimeout in carbon.xml to 0 to avoid waiting for 15min
Enable support by default for an identity claim like lastLogonTime to see the claim in the user profile.
Register a new SP application.
Create a new user. Update the new user's profile. (Leave the identity claim blank)
Obtain an access token for the new user and call the OAuth2TokenValidationService - validate operation.( A NullPointerException is seen, you might have to tail the logs to see it)

Analysis and cause of the issue:
When a new user is created and you update the user's details in the user profile, these values will get added to a cache and then persisted in the database. In an Oracle database, an empty string will be added as a null value, therefore all the empty values in the user's profile will be persisted in the database as null values. Upon JWT token generation the null value returned from the database for the identity claims causes a NullPointerException.
The above issue occurs only for identity claims, for other claims, the empty and null check is carried out.
[1]https://docs.wso2.com/display/IS560/JWT+Token+Generation

This affects SCIM patch operations as well


Remove the need for plaintext PostgreSQL credentials

Currently, in values.yaml, the credentials for the PostgreSQL users are specified as follows:
credentials:
  admin: cola
  # the postgres and standby users are vital for Patroni, and therefore should not be
  # removed altogether.
  postgres: tea
  standby: pinacolada

The password for postgres is not strictly needed - Patroni connects using a socket locally and uses the standby user remotely.
pgBackrest also connects locally through the socket, which again does not require a password.
The standby user does need a way to authenticate over the network - we might be able to use certificates here instead of passwords.
There is no easy solution for the admin user: Somehow an application will need to connect with a secret.
Some possibilities:
Allow a secret to be referenced for the passwords
Inform users that providing a hash also works
This does not seem very user friendly, but this does already actually work, and would remove
the strict need of a literal password in the values.yaml:
credentials:
  admin: SCRAM-SHA-256$4096:PXzHoUaqasigcbsBiXi5MQ==$Eguayat8bXgwC19CvH1dAlsmh2Mkj2C7wtOOLsISkEI=:YtyaUsh7sYrdYZlcHVB/HUlIzg/du67PFiOILfcrf1c=

Remove postgres password altogether
The major downside of this approach is that some extensions require superuser privileges to be created/updated etc.
That mostly can be mitigated by configuring pgextwlist.
Allow standby to authenticate using an SSL certificate.
As all pods of the StatefulSet use the same Secret as their TLS certificate this sounds easy, however we need to take care of the case where the certificate changes, for example:

Cert A is issued to the StatefulSet.
Every PostgreSQL server will allow standby to connect using certificate A
Cert A is replaced with Cert B

If a replica pod is rescheduled, it cannot connect to the primary, as it only accepts A
If a master pod is rescheduled, a replica will become master, which only accepts A

Possible solution: Keep a list of certificates that are allowed, not only the last one.

The solution we use: helm-secrets.

This has been mostly addressed and released with https://github.com/timescale/timescaledb-kubernetes/releases/tag/v0.6.1
The only thing we may wish to reconsider is to use certificates for the internode replication connections at some point, removing the need for even a standby user credential.


Issue installing requirements.txt

Hey, thanks @ramisra. Good catch! Cleaning this up.

Hey @ramisra, pls try again. I updated the installation instructions - the best way to install is through pyproject.toml. Once you pull the latest, you should be able to install by running pip install . in knowledge-table/backend/. Please let me know if you experience any other issues.

This solves the issue, thanks for updating the readme.


Delete PS_Transcripts in VM-Remove-DesktopFiles

Details
I would like to delete the PS_Transcripts folder in the VM-Remove-DesktopFiles function (called by VM-Clean-Up) as I want to delete any log files (including PowerShell logs) when executing this function. However, as explained in https://github.com/mandiant/VM-Packages/pull/754, deleting PS_Transcripts while Powershell is open is an issue as VM-Remove-DesktopFiles/VM-Clean-Up are PowerShell functions. @emtuls any ideas how we could do this? I wouldn't like to complicate it the logic/code too much, but it would be nice to have.

One relatively simple idea is to delete files in the directory if deleting the whole directory is not possible, this may delete part of the files in PS_Transcripts

I remember us discussing this in #706 , I think maybe we should just move PS_Transcripts folder to the Start Menu

Ok got it, that makes sense!


Spot Perpetual Arbitrage - Funding bug

Describe the bug
the bot  closed the trades after funding  at a loss even that the maximize_funding_rate: false
always happen after funding time
Release version
0.43.0
Attachments
2021-09-18 00:00:34,002 - 1 - hummingbot.strategy.spot_perpetual_arbitrage.spot_perpetual_arbitrage - INFO - Current spread: 2.18%, minimum convergence spread: 1.00%.
2021-09-18 00:00:35,677 - 1 - hummingbot.connector.derivative.binance_perpetual.binance_perpetual_derivative - INFO - Funding payment of -0.08835693 paid on COTI-USDT market.
2021-09-18 00:00:35,686 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>000, "market": "binance_perpetual", "trading_pair": "COTI-USDT", "amount": "-0.08835693", "funding_rate": "-0.00009814", "event_name": "FundingPaymentCompletedEvent", "event_source": "binance_perpetual"}
2021-09-18 00:00:35,686 - 1 - hummingbot.strategy.spot_perpetual_arbitrage.spot_perpetual_arbitrage - INFO - Executing second arbitrage after funding payment is received!:
Kucoin:  Sell  2300.0000 COTI at 0.383831 USDT.
Binance_perpetual:  Buy  2300 COTI at 0.39251 USDT.
2021-09-18 00:00:35,688 - 1 - hummingbot.strategy.spot_perpetual_arbitrage.spot_perpetual_arbitrage - INFO - Placing SELL order for 2300.0000 COTI at kucoin at 0.383831 price [clock=2021-09-18 00:00:35+00:00]
2021-09-18 00:00:35,689 - 1 - hummingbot.strategy.spot_perpetual_arbitrage.spot_perpetual_arbitrage - INFO - Placing BUY order for 2300 COTI at binance_perpetual at 0.39251 price to CLOSE position. [clock=2021-09-18 00:00:35+00:00]
2021-09-18 00:00:35,968 - 1 - hummingbot.connector.derivative.binance_perpetual.binance_perpetual_derivative - INFO - Created market buy order x-3QreWesy-SCIUT1631923235689369 for 2300 COTI-USDT.
2021-09-18 00:00:35,976 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "type": "OrderType.MARKET", "trading_pair": "COTI-USDT", "amount": "2300", "price": "0.39251", "order_id": "x-3QreWesy-SCIUT1631923235689369", "exchange_order_id": null, "leverage": 8, "position": "CLOSE", "event_name": "BuyOrderCreatedEvent", "event_source": "binance_perpetual"}
2021-09-18 00:00:35,985 - 1 - hummingbot.connector.exchange.kucoin.kucoin_exchange - INFO - Created OrderType.LIMIT sell order sell-COTI-USDT-1631923235688844 for 2300.0000 COTI-USDT.
2021-09-18 00:00:35,991 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "type": "OrderType.LIMIT", "trading_pair": "COTI-USDT", "amount": 2300.0, "price": 0.383831, "order_id": "sell-COTI-USDT-1631923235688844", "exchange_order_id": "61452c2391ba0d0006537159", "leverage": 1, "position": "NILL", "event_name": "SellOrderCreatedEvent", "event_source": "kucoin"}
2021-09-18 00:00:36,049 - 1 - hummingbot.connector.exchange.kucoin.kucoin_exchange - INFO - Filled 1699.0362 out of 2300.0000 of the order sell-COTI-USDT-1631923235688844.
2021-09-18 00:00:36,071 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "order_id": "sell-COTI-USDT-1631923235688844", "trading_pair": "COTI-USDT", "trade_type": "TradeType.SELL", "order_type": "OrderType.LIMIT", "price": "0.383831", "amount": "1699.0362", "trade_fee": ["0.001", []], "exchange_trade_id": "61452c2391ba0d0006537159", "leverage": 1, "position": "NILL", "event_name": "OrderFilledEvent", "event_source": "kucoin"}
2021-09-18 00:00:36,072 - 1 - hummingbot.connector.exchange.kucoin.kucoin_exchange - INFO - The market sell order sell-COTI-USDT-1631923235688844 has completed according to KuCoin user stream.
2021-09-18 00:00:36,078 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "order_id": "sell-COTI-USDT-1631923235688844", "base_asset": "COTI", "quote_asset": "USDT", "fee_asset": "USDT", "base_asset_amount": "1699.0362", "quote_asset_amount": "652.1427636822", "fee_amount": "0", "order_type": "OrderType.LIMIT", "exchange_order_id": "61452c2391ba0d0006537159", "event_name": "SellOrderCompletedEvent", "event_source": "kucoin"}
2021-09-18 00:00:36,472 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.866, "order_id": "x-3QreWesy-SCIUT1631923235689369", "trading_pair": "COTI-USDT", "trade_type": "TradeType.BUY", "order_type": "OrderType.MARKET", "price": "0.39254", "amount": "519", "trade_fee": ["0.0004", []], "exchange_trade_id": 35456474, "leverage": 8, "position": "CLOSE", "event_name": "OrderFilledEvent", "event_source": "binance_perpetual"}
2021-09-18 00:00:36,531 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.866, "order_id": "x-3QreWesy-SCIUT1631923235689369", "trading_pair": "COTI-USDT", "trade_type": "TradeType.BUY", "order_type": "OrderType.MARKET", "price": "0.39254", "amount": "234", "trade_fee": ["0.0004", []], "exchange_trade_id": 35456475, "leverage": 8, "position": "CLOSE", "event_name": "OrderFilledEvent", "event_source": "binance_perpetual"}
2021-09-18 00:00:36,588 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.866, "order_id": "x-3QreWesy-SCIUT1631923235689369", "trading_pair": "COTI-USDT", "trade_type": "TradeType.BUY", "order_type": "OrderType.MARKET", "price": "0.39257", "amount": "1528", "trade_fee": ["0.0004", []], "exchange_trade_id": 35456476, "leverage": 8, "position": "CLOSE", "event_name": "OrderFilledEvent", "event_source": "binance_perpetual"}
2021-09-18 00:00:36,606 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.866, "order_id": "x-3QreWesy-SCIUT1631923235689369", "trading_pair": "COTI-USDT", "trade_type": "TradeType.BUY", "order_type": "OrderType.MARKET", "price": "0.39258", "amount": "19", "trade_fee": ["0.0004", []], "exchange_trade_id": 35456477, "leverage": 8, "position": "CLOSE", "event_name": "OrderFilledEvent", "event_source": "binance_perpetual"}
2021-09-18 00:00:36,606 - 1 - hummingbot.connector.derivative.binance_perpetual.binance_perpetual_derivative - INFO - The market TradeType.BUY order x-3QreWesy-SCIUT1631923235689369 has completed according to websocket delta.
2021-09-18 00:00:36,613 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "order_id": "x-3QreWesy-SCIUT1631923235689369", "base_asset": "COTI", "quote_asset": "USDT", "fee_asset": "BNB", "base_asset_amount": "2300", "quote_asset_amount": "902.88860", "fee_amount": "0.00079875", "order_type": "OrderType.MARKET", "exchange_order_id": null, "event_name": "BuyOrderCompletedEvent", "event_source": "binance_perpetual"}
2021-09-18 00:00:45,000 - 1 - hummingbot.strategy.spot_perpetual_arbitrage.spot_perpetual_arbitrage - INFO - Current spread: 1.31%, minimum divergence spread: 2.00%.
2021-09-18 08:00:38,001 - 1 - hummingbot.strategy.spot_perpetual_arbitrage.spot_perpetual_arbitrage - INFO - Current spread: 3.22%, minimum convergence spread: 1.00%.
2021-09-18 08:00:38,803 - 1 - hummingbot.connector.derivative.binance_perpetual.binance_perpetual_derivative - INFO - Funding payment of -0.85555856 paid on COTI-USDT market.
2021-09-18 08:00:38,810 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>000, "market": "binance_perpetual", "trading_pair": "COTI-USDT", "amount": "-0.85555856", "funding_rate": "-0.00090124", "event_name": "FundingPaymentCompletedEvent", "event_source": "binance_perpetual"}
2021-09-18 08:00:38,811 - 1 - hummingbot.strategy.spot_perpetual_arbitrage.spot_perpetual_arbitrage - INFO - Executing second arbitrage after funding payment is received!:
Kucoin:  Sell  1150.0000 COTI at 0.411798 USDT.
Binance_perpetual:  Buy  1150 COTI at 0.42548 USDT.
2021-09-18 08:00:38,812 - 1 - hummingbot.strategy.spot_perpetual_arbitrage.spot_perpetual_arbitrage - INFO - Placing SELL order for 1150.0000 COTI at kucoin at 0.411798 price [clock=2021-09-18 08:00:38+00:00]
2021-09-18 08:00:38,813 - 1 - hummingbot.strategy.spot_perpetual_arbitrage.spot_perpetual_arbitrage - INFO - Placing BUY order for 1150 COTI at binance_perpetual at 0.42548 price to CLOSE position. [clock=2021-09-18 08:00:38+00:00]
2021-09-18 08:00:39,086 - 1 - hummingbot.connector.exchange.kucoin.kucoin_exchange - INFO - Created OrderType.LIMIT sell order sell-COTI-USDT-1631952038812997 for 1150.0000 COTI-USDT.
2021-09-18 08:00:39,094 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "type": "OrderType.LIMIT", "trading_pair": "COTI-USDT", "amount": 1150.0, "price": 0.411798, "order_id": "sell-COTI-USDT-1631952038812997", "exchange_order_id": "61459ca629830900064ee58e", "leverage": 1, "position": "NILL", "event_name": "SellOrderCreatedEvent", "event_source": "kucoin"}
2021-09-18 08:00:39,148 - 1 - hummingbot.connector.derivative.binance_perpetual.binance_perpetual_derivative - INFO - Created market buy order x-3QreWesy-SCIUT1631952038813485 for 1150 COTI-USDT.
2021-09-18 08:00:39,155 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "type": "OrderType.MARKET", "trading_pair": "COTI-USDT", "amount": "1150", "price": "0.42548", "order_id": "x-3QreWesy-SCIUT1631952038813485", "exchange_order_id": null, "leverage": 8, "position": "CLOSE", "event_name": "BuyOrderCreatedEvent", "event_source": "binance_perpetual"}
2021-09-18 08:00:39,157 - 1 - hummingbot.connector.exchange.kucoin.kucoin_exchange - INFO - Filled 1150 out of 1150.0000 of the order sell-COTI-USDT-1631952038812997.
2021-09-18 08:00:39,176 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "order_id": "sell-COTI-USDT-1631952038812997", "trading_pair": "COTI-USDT", "trade_type": "TradeType.SELL", "order_type": "OrderType.LIMIT", "price": "0.411798", "amount": "1150", "trade_fee": ["0.001", []], "exchange_trade_id": "61459ca629830900064ee58e", "leverage": 1, "position": "NILL", "event_name": "OrderFilledEvent", "event_source": "kucoin"}
2021-09-18 08:00:39,176 - 1 - hummingbot.connector.exchange.kucoin.kucoin_exchange - INFO - The market sell order sell-COTI-USDT-1631952038812997 has completed according to KuCoin user stream.
2021-09-18 08:00:39,183 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "order_id": "sell-COTI-USDT-1631952038812997", "base_asset": "COTI", "quote_asset": "USDT", "fee_asset": "USDT", "base_asset_amount": "1150", "quote_asset_amount": "473.567700", "fee_amount": "0", "order_type": "OrderType.LIMIT", "exchange_order_id": "61459ca629830900064ee58e", "event_name": "SellOrderCompletedEvent", "event_source": "kucoin"}
2021-09-18 08:00:39,254 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.003, "order_id": "x-3QreWesy-SCIUT1631952038813485", "trading_pair": "COTI-USDT", "trade_type": "TradeType.BUY", "order_type": "OrderType.MARKET", "price": "0.42540", "amount": "1000", "trade_fee": ["0.0004", []], "exchange_trade_id": 35737056, "leverage": 8, "position": "CLOSE", "event_name": "OrderFilledEvent", "event_source": "binance_perpetual"}
2021-09-18 08:00:39,616 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.004, "order_id": "x-3QreWesy-SCIUT1631952038813485", "trading_pair": "COTI-USDT", "trade_type": "TradeType.BUY", "order_type": "OrderType.MARKET", "price": "0.42541", "amount": "71", "trade_fee": ["0.0004", []], "exchange_trade_id": 35737057, "leverage": 8, "position": "CLOSE", "event_name": "OrderFilledEvent", "event_source": "binance_perpetual"}
2021-09-18 08:00:39,634 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.004, "order_id": "x-3QreWesy-SCIUT1631952038813485", "trading_pair": "COTI-USDT", "trade_type": "TradeType.BUY", "order_type": "OrderType.MARKET", "price": "0.42543", "amount": "79", "trade_fee": ["0.0004", []], "exchange_trade_id": 35737058, "leverage": 8, "position": "CLOSE", "event_name": "OrderFilledEvent", "event_source": "binance_perpetual"}
2021-09-18 08:00:39,634 - 1 - hummingbot.connector.derivative.binance_perpetual.binance_perpetual_derivative - INFO - The market TradeType.BUY order x-3QreWesy-SCIUT1631952038813485 has completed according to websocket delta.
2021-09-18 08:00:39,640 - 1 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "order_id": "x-3QreWesy-SCIUT1631952038813485", "base_asset": "COTI", "quote_asset": "USDT", "fee_asset": "USDT", "base_asset_amount": "1150", "quote_asset_amount": "489.21308", "fee_amount": "0.19568522", "order_type": "OrderType.MARKET", "exchange_order_id": null, "event_name": "BuyOrderCompletedEvent", "event_source": "binance_perpetual"}
2021-09-18 08:00:49,002 - 1 - hummingbot.strategy.spot_perpetual_arbitrage.spot_perpetual_arbitrage - INFO - Current spread: 3.47%, minimum convergence spread: 1.00%.
logs_conf_spot_perpetual_arbitrage_1.log
conf_spot_perpetual_arbitrage_1.txt
Optional: your discord username:
bazickoff#9469
┆Issue is synchronized with this Clickup task by Unito

Hi @bazickoff, We will try and test this further on our end. I ran a quick test on my end, let it ran for an hour.
I set it to lower-order amount and did not encounter these closing trades.
config spot.txt
Logs.log

Hi @Jurelll
this problem happen when you stop and start the strategy while the trade still open ( for example if you stop  the strategy while it open to change the settings like minimum convergence)  when you stop and start the strategy the bot think that the trade are closed (but the trade still open)  and because there is somthing wrong with the code the bot will close the trade and open it again after the funding time , I hope this info will help to identify the bug

@bazickoff Could you please send a screenshot of the whole terminal when this error showing?
Tried to replicate and looks like for now I'm unable to replicate the issue.

@nikspz this issue happen after  the funding time 8.00, 12.00, 16.00 UTC   , when the orders get filled stop and start the strategy and wait after the funding time the bot will close the open orders regardless of minimum convergence     ,  like it shows on the log file 2021-09-18 08:00:38,803    and     2021-09-18 00:00:35,677

@nikspz
I think this is the responsible code for the bug
when you stop and start the strategy while the order still open  on binance derivative (deriv_position)    the "if len(self.deriv_position) > 0:"   become True and that will force to close the trade after funding time
if self.current_proposal.is_funding_payment_time():
if len(self.deriv_position) > 0:
if self._maximize_funding_rate:
execute_arb = not self.would_receive_funding_payment(self.deriv_position)

Thanks for posting this @bazickoff , our team is currently doing a rework of this strategy as defined in this issue: https://github.com/CoinAlpha/hummingbot/issues/3791
We think this should address most of these issues in the strategy also those that are mentioned here: https://github.com/CoinAlpha/hummingbot/issues/3679

Hi @bazickoff, we recently released version 0.46.0, and spot perpetual arbitrage has been also refactored on the previous versions. Just checking if you can have a look at it again and let us know if this is still an ongoing issue. Thanks!

We haven't received any response since the previous comment, will be tagging this ticket as resolved for now since Spot perpetual arbitrage has been refactored and available on the current version 0.46.0. Thank you


Sticky error message on SelectionScreen

Demonstrate how sticky error message looks like on SelectionScreen
web:
https://github.com/software-mansion-labs/expensify-app-fork/assets/61014013/50c4c9fd-10a4-48bc-a7d0-06c5a4e7f2a1
ios:
https://github.com/software-mansion-labs/expensify-app-fork/assets/61014013/b3ee597b-7398-49ba-b711-0ba7eb7435ae

I'm pulling those changes into https://github.com/Expensify/App/pull/44739


HTML in Error Messages

I found a need to embed some html tags in my error messages. The change to xeditable was very simple - add a dependency on $sce, mark the msg as trusted html in setError ($sce.trustAsHTML()), and then change the error div ng-bind to ng-bind-html.
I only mention it as a possible enhancement and for anyone else who might need this. Also, apologies in advance if I've violated some github protocol here - I'm new to this platform.

+1, waiting for this

Is this still an issue?


feat: Top view and side view polygon changes Linkage

文件头建议添加文件描述
计算函数风格统一，并补全注释

:tada: This PR is included in version 1.0.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Sanitize query property names in JSON/YAML.mapping

Closes #4129

Can you also add support to getter! as in {foo!: "bar"} ?

@bew no, I was thinking about it, but haven't found valid usecases.

@bcardiff @RX14 @bew Could you please spare a review?

Will it merge? :)

I'm not sure I like this safe_key field in value. We already have key field in value, which represent the JSON/YAML key name. To me safe_key is not explicit that it is the instance's variable name.
I know it's an implementation detail, but from reading the code it's not easy to understand what this safe_key field is for.

@bew I'm not fond of it either, feel free to propose better name :) btw, it doesn't only resprent ivar name, since it's used for example in <key>_present? query methods.

Last recommended action was changing key name from :safe_key to sth more apt by @bew, yet no proposals for a better name was posted. Is it GTG as is then?

What about key_id? It essentially replaces key.id...

@straight-shoota 👍  changed, thx.

@jhass @mverzilli @ysbaddaden plz review ❤


Add Template modal (and the first React components!)

Adds about 20% of the total map templates. Includes a highly visible way to encourage people (who speak english) to send in more maps

hope it will help - supporter from france

hope it helps!

hope it helps!

thank you for this amazing app!

Here's a recreated map.


Newer NodeJS Support (v4.x)

I had to upgrade my node but now docular is broken. Any chance that newer versions of Node will be supported?
Using 4.2.1 I get this error if I include anything in my group's documentation (removing everything finishes file).
Error: EISDIR: illegal operation on a directory, read
at Error (native)
From previous event:
at Class.extend.loadFiles (...project path.../node_modules/docular/lib/scripts/core/group.js:152:18)
at node.js:961:3
{ [Error: EISDIR: illegal operation on a directory, read] errno: -21, code: 'EISDIR', syscall: 'read' }

I want to post a workaround for anyone who comes across this:
					sections: [
						{
							id: "myapi",
							title: "Project API",
							scripts: grunt.file.expand({}, userConfig.app_files.js),
							docs: [
							],
							rank : {}
						}
					]

userConfig.app_files.js is a list of file glob patterns that match all my angular js files that I already used to concatenate and and minify elsewhere in the build. The important thing is you don't pass any directories to docular or it tries to read them like a file and blows up.


html-webpack-plugin crashes when using with stylelint-webpack-plugin

Hi,
when I am using html-webpack-plugin with stylelint-webpack-plugin and there are errors reported by stylelint, then html-webpack-plugin returns a bunch of errors and the app can't be run.
ERROR in   Error: Child compilation failed:
  undefined

  - compiler.js:88
    [app]/[html-webpack-plugin]/lib/compiler.js:88:16

  - Compiler.js:214 Compiler.<anonymous>
    [app]/[webpack]/lib/Compiler.js:214:10

  - Compiler.js:403
    [app]/[webpack]/lib/Compiler.js:403:12

  - Tapable.js:67 Compiler.next
    [app]/[tapable]/lib/Tapable.js:67:11

  - CachePlugin.js:40 Compiler.<anonymous>
    [app]/[webpack]/lib/CachePlugin.js:40:4

  - Tapable.js:71 Compiler.applyPluginsAsync
    [app]/[tapable]/lib/Tapable.js:71:13

  - Compiler.js:400 Compiler.<anonymous>
    [app]/[webpack]/lib/Compiler.js:400:9

  - Compilation.js:577 Compilation.<anonymous>
    [app]/[webpack]/lib/Compilation.js:577:13

  - Tapable.js:60 Compilation.applyPluginsAsync
    [app]/[tapable]/lib/Tapable.js:60:69

  - Compilation.js:572 Compilation.<anonymous>
    [app]/[webpack]/lib/Compilation.js:572:10

  - Tapable.js:60 Compilation.applyPluginsAsync
    [app]/[tapable]/lib/Tapable.js:60:69

  - Compilation.js:567 Compilation.<anonymous>
    [app]/[webpack]/lib/Compilation.js:567:9

  - Tapable.js:60 Compilation.applyPluginsAsync
    [app]/[tapable]/lib/Tapable.js:60:69

  - Compilation.js:563 Compilation.<anonymous>
    [app]/[webpack]/lib/Compilation.js:563:8

  - Tapable.js:60 Compilation.applyPluginsAsync
    [app]/[tapable]/lib/Tapable.js:60:69

  - Compilation.js:525 Compilation.seal
    [app]/[webpack]/lib/Compilation.js:525:7

  - Compiler.js:397 Compiler.<anonymous>
    [app]/[webpack]/lib/Compiler.js:397:15

  - Tapable.js:103
    [app]/[tapable]/lib/Tapable.js:103:11

  - Compilation.js:445 Compilation.<anonymous>
    [app]/[webpack]/lib/Compilation.js:445:10

  - Compilation.js:417
    [app]/[webpack]/lib/Compilation.js:417:12

  - Compilation.js:332
    [app]/[webpack]/lib/Compilation.js:332:10

  - async.js:52
    [app]/[webpack]/[async]/lib/async.js:52:16

  - async.js:236 Object.async.forEachOf.async.eachOf
    [app]/[webpack]/[async]/lib/async.js:236:30

  - async.js:209 Object.async.forEach.async.each
    [app]/[webpack]/[async]/lib/async.js:209:22

  - Compilation.js:185 Compilation.addModuleDependencies
    [app]/[webpack]/lib/Compilation.js:185:8

  - Compilation.js:170 Compilation.processModuleDependencies
    [app]/[webpack]/lib/Compilation.js:170:7

  - Compilation.js:412 Compilation.moduleReady
    [app]/[webpack]/lib/Compilation.js:412:9

  - Compilation.js:408 Compilation.<anonymous>
    [app]/[webpack]/lib/Compilation.js:408:16

  - Compilation.js:123
    [app]/[webpack]/lib/Compilation.js:123:4

  - Array.forEach

I tried to change their order in plugins array but I still can't make them work together.

Does it work if you specify a loader for your template?
E.g. !!html!template.html?

hi @jantimon, thanks for your reply. I am not sure I completely understood what you mean. Did you mean to set like this?
new HtmlWebpackPlugin({
      chunks: ['app'],
      filename: 'index.html',
      hash: true,
      template: '!!html!index.html'
    })

then it can't find template file because it understands !!html! as a part of the template name.

template is just following the webpack require syntax so !! means skip all other loaders html means use the html-loader ..

@jantimon unfortunately, it didn't work

Could you please provide more information than "does not work"?


Fix issue with sinatra listener trying to add an exception to the tra…

…nsaction when AppSignal is not active

:+1:


Release: Setup Homebrew support

cargo-dist includes generation of homebrew packages. This was generated in https://github.com/memorysafety/river/releases/tag/v0.2.0, but we haven't set up publishing this yet.
We should figure out how to get the aarch64 mac builds available there.

https://github.com/Homebrew/homebrew-core/blob/2b59118b7ba6dbbe700400d12ead8ed8040a5ffd/Formula/r/river.rb

Thank you @Fexiven for submitting this upstream!
I'm not so familiar with the homebrew project's practices, but is there a reason not to use the formula generated by cargo-dist? We already prepare sha256 signed artifacts and pre-built binaries, visible in the dist-manifest.json. There is also a generated river.rb script generated automatically as part of the cargo-dist process, which seems not to have been used.
Additionally, is there some way we can ensure that future releases stay up to date in homebrew's package tracker?
Like I said - this is outside my current expertise, so I'm happy to be pointed to any docs or other best practices I can learn from.

I'm not so familiar with the homebrew project's practices, but is there a reason not to use the formula generated by cargo-dist?

Yes, would work as it is, but the generated file does not comply with the "brew audit --strict" and "brew test"
neccessary for getting it pushed to the core repo. If there would be a custom river homebrew "tap" it would have worked.

Additionally, is there some way we can ensure that future releases stay up to date in homebrew's package tracker?

It should be automatically updated, its in the autobump file https://github.com/Homebrew/homebrew-core/blob/2b59118b7ba6dbbe700400d12ead8ed8040a5ffd/.github/autobump.txt#L1909. In the next release it should be updated to 0.3.0 or whatever it will be.
Here's the documentation of the fomulas: https://docs.brew.sh/Formula-Cookbook

Thanks! I've passed this up to the cargo-dist folks: https://github.com/axodotdev/cargo-dist/issues/1093, I also appreciate the docs link :)

The autobump seems to work as expected, just one thing to keep in mind is https://github.com/Homebrew/homebrew-core/blob/6ade34390ee819819b31f995ceaf5ecfa3fc86ac/Formula/r/river.rb#L40
if anything should change in the config structure (probably will) in the future, or if there will be a better way to check for functionality this should get updated

Thank you @Fexiven, I was going to look into this and you beat me to it! I'll keep that in mind, and likely add it to the release checklist so we don't forget.
Is there a proper ordering to this to avoid broken builds? e.g. if I DO change the config file details, should I make a PR to homebrew before or after I do the GH tagged release?

I would say first release, then create a new PR with a revision https://docs.brew.sh/Formula-Cookbook#formulae-revisions
They are usually quite fast reviewing it.


Added space between text and link in Get Started page

Fixes #926
Changes:
There was no space between text and link, which was making it difficult to read.
Screenshots of the change:
Previously:

After Fix:

The space shouldn't be added in the templates themselves as it would be problematic when it comes to translating this page, not all languages uses spaces to delineate individual words. The space should be added in the language data files for English and possibly Spanish instead.

The space shouldn't be added in the templates themselves as it would be problematic when it comes to translating this page, not all languages uses spaces to delineate individual words. The space should be added in the language data files for English and possibly Spanish instead.

Hi @limzykenneth, I removed that space from templates, and instead, I added that space in English translation only as Spanish translation seems all fine to me.

Hi @limzykenneth, I removed that space from templates, and instead, I added that space in English translation only as Spanish translation seems all fine to me.

Perfect, thanks!

Perfect, thanks!


⚠ Bofrost.at has degraded performance

In 7fc0688, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 955 ms

Resolved: Bofrost.at performance has improved in dfa6cc6.


Report hashes are different for the very same report

Steps to reproduce:

Ubuntu 16.04, boost 1.65
CodeChecker analyze the project at https://github.com/martong/graphisoft_competition_2017

[HIGH] stl_uninitialized.h:83:19: Forming reference to null pointer [core.NonNullParamChecker]
    std::_Construct(std::__addressof(*__cur), *__first);
                    ^
  ReportHash: b378379a1773641e430c27a0cad9d1c6
  Steps:
    1, vector.tcc:429:4: Null pointer value stored to '__new_finish'
    2, vector.tcc:434:7: Passing null pointer value via 3rd parameter '__result'
    3, vector.tcc:432:8: Calling '__uninitialized_move_if_noexcept_a'
    4, stl_uninitialized.h:304:5: Entered call from 'vector::_M_realloc_insert'
    5, stl_uninitialized.h:312:52: Passing null pointer value via 3rd parameter '__result'
    6, stl_uninitialized.h:310:14: Calling '__uninitialized_copy_a'
    7, stl_uninitialized.h:286:5: Entered call from '__uninitialized_move_if_noexcept_a'
    8, stl_uninitialized.h:289:55: Passing null pointer value via 3rd parameter '__result'
    9, stl_uninitialized.h:289:14: Calling 'uninitialized_copy'
    10, stl_uninitialized.h:114:5: Entered call from '__uninitialized_copy_a'
    11, stl_uninitialized.h:134:33: Passing null pointer value via 3rd parameter '__result'
    12, stl_uninitialized.h:131:14: Calling '__uninitialized_copy::__uninit_copy'
    13, stl_uninitialized.h:75:9: Entered call from 'uninitialized_copy'
    14, stl_uninitialized.h:79:4: '__cur' initialized to a null pointer value
    15, stl_uninitialized.h:82:15: Entering loop body
    16, stl_uninitialized.h:83:19: Forming reference to null pointer
--
[HIGH] stl_uninitialized.h:83:19: Forming reference to null pointer [core.NonNullParamChecker]
    std::_Construct(std::__addressof(*__cur), *__first);
                    ^
  ReportHash: 072e5edbba314a5bdd1babd3e293defa
  Steps:
    1, vector.tcc:429:4: Null pointer value stored to '__new_finish'
    2, vector.tcc:434:7: Passing null pointer value via 3rd parameter '__result'
    3, vector.tcc:432:8: Calling '__uninitialized_move_if_noexcept_a'
    4, stl_uninitialized.h:304:5: Entered call from 'vector::_M_realloc_insert'
    5, stl_uninitialized.h:312:52: Passing null pointer value via 3rd parameter '__result'
    6, stl_uninitialized.h:310:14: Calling '__uninitialized_copy_a'
    7, stl_uninitialized.h:286:5: Entered call from '__uninitialized_move_if_noexcept_a'
    8, stl_uninitialized.h:289:55: Passing null pointer value via 3rd parameter '__result'
    9, stl_uninitialized.h:289:14: Calling 'uninitialized_copy'
    10, stl_uninitialized.h:114:5: Entered call from '__uninitialized_copy_a'
    11, stl_uninitialized.h:134:33: Passing null pointer value via 3rd parameter '__result'
    12, stl_uninitialized.h:131:14: Calling '__uninitialized_copy::__uninit_copy'
    13, stl_uninitialized.h:75:9: Entered call from 'uninitialized_copy'
    14, stl_uninitialized.h:79:4: '__cur' initialized to a null pointer value
    15, stl_uninitialized.h:82:15: Entering loop body
    16, stl_uninitialized.h:83:19: Forming reference to null pointer

Are you sure the bug is indeed the same? There could be some hidden heuristics not visible in the bug path events which results in clang generating a different hash.

This is probably related to template instantiation. The hash is perhaps dependent on the template parameters. If that is the case then we should synthesise the hash based on the primary template and not based on the instantiation.

I think this should be handled better in the clang static analyzer. In CodeChecker the base of the comparison is the bug hash and the path comes only after it.
At the UI there is the similar bugs option (same hash multiple path) or uniqueing where the bug hash is used to find the unique reports.

The original problem occurred while I was using clangsa with version 3.8 which comes with ubuntu 16.04. However, this issue is still existing in latest Ericsson/Clang (ctu-clang5) but in a different form. In the following example the paths are 1 step long and they still have different hashes:
± CodeChecker parse --print-report-hash --print-steps ./reports | grep "\[HIGH\] general.hpp:39:28" -A6
[HIGH] general.hpp:39:28: Called C++ object pointer is null [core.CallAndMessage]
    static void failed() { ((Model*)0)->~Model(); }
                           ^
  ReportHash: a3a006a092b6b22ab645838608864665
  Steps:
    1, general.hpp:39:28: Called C++ object pointer is null

--
[HIGH] general.hpp:39:28: Called C++ object pointer is null [core.CallAndMessage]
    static void failed() { ((Model*)0)->~Model(); }
                           ^
  ReportHash: 130a65208a92e0447200706262b33e52
  Steps:
    1, general.hpp:39:28: Called C++ object pointer is null

--
[HIGH] general.hpp:39:28: Called C++ object pointer is null [core.CallAndMessage]
    static void failed() { ((Model*)0)->~Model(); }
                           ^
  ReportHash: 6dad39fc8b1877a199485b346eb58634
  Steps:
    1, general.hpp:39:28: Called C++ object pointer is null

--
[HIGH] general.hpp:39:28: Called C++ object pointer is null [core.CallAndMessage]
    static void failed() { ((Model*)0)->~Model(); }
                           ^
  ReportHash: 129a42075d72608f23fe1905cbc2b0fd
  Steps:
    1, general.hpp:39:28: Called C++ object pointer is null

--
[HIGH] general.hpp:39:28: Called C++ object pointer is null [core.CallAndMessage]
    static void failed() { ((Model*)0)->~Model(); }
                           ^
  ReportHash: 130a65208a92e0447200706262b33e52
  Steps:
    1, general.hpp:39:28: Called C++ object pointer is null

Agreeing with @gyorb, this issue is part of Clang, and thus needs to be fixed either on Ericsson/Clang or instead in the Phabricator system.
CodeChecker has no access to the syntax tree and the insides of how the hash is generated.


Add Borgomatic configuration to Infra

Install and configure Borgmatic and if possible setup backups all in the playbooks.

Completed


Update Website

update website to reflect current product offerings and direction.

Automation of IT tasks
Single pane of glass / integration
Comprehensive, network-wide QoE monitoring and pinpointing


Broken with nix-darwin

If you use nix-darwin, it breaks stylix, even just the home-manager module.
Evaluation fails with:
error: attribute 'stylix' missing

       at /nix/store/axhqicv10hg6zvp6sp2wh506q8mnblj9-source/stylix/fromos.nix:4:26:

            3| path: default:
            4| if (args ? "osConfig" && args.osConfig.stylix.homeManagerIntegration.followSystem)
             |                          ^
            5|   then lib.attrByPath path default args.osConfig.stylix
(use '--show-trace' to show detailed location information)

Seems like this could be mitigated by there being a module for Darwin like there is one for NixOS.

This is due to the fact that you're using the home-manager module from a NixOS config (thus the osConfig part), but the stylix module is not imported on NixOS. I'll try to fix this.
I don't know anything about nix-darwin, but how would a nix-darwin module differ from a NixOS one ?

I don't know anything about nix-darwin, but how would a nix-darwin module differ from a NixOS one ?

It would be in a darwinModules flake output, as opposed to nixModules, and looking at the current NixOS module, the only change you'd need is to remove the defaultFonts setting as that isn't available.
The docs can also help to figure out whether an option is available in nix-darwin: https://daiderd.com/nix-darwin/manual/index.html#sec-options
I can try writing the module and making a PR

I can try writing the module and making a PR

Please do, I'll review it but I won't be able to test it.

Note that, while #71 will resolve this issue for nix-darwin, IMO the expression in fromos.nix should also be fixed so that it doesn't fail to eval in the scenario above.


Broken Link

I would like to report a broken link:
Network Switch Team Cmdlets in Windows PowerShell
https://docs.microsoft.com/en-us/powershell/module/network-switch-team/index

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

ID: 9af6298a-44a5-255f-f459-8151878492a0
Version Independent ID: 8a0de308-4ee0-a603-11d3-379ce995a993
Content: Hyper-V Virtual Switch
Content Source: WindowsServerDocs/virtualization/hyper-v-virtual-switch/Hyper-V-Virtual-Switch.md
Product: windows-server-threshold
GitHub Login: @shortpatti
Microsoft Alias: pashort

Thank you, @Moe1976, for letting us know about the broken link.  Is this the link you were trying to find?

While links in comments above work, the link in the docs page is still not fixed.


[firebase_messaging] firebase_messaging plugin causing build error in android

Whenever I apply the firebase_messaging plugin, The compiler throws deprecated error on building for android. I tried to change the gradle version, it works in debug mode but not in release. Kindly help regarding this, Its very crucial for me. Thank you.

error: method findAppBundlePath in class FlutterMain cannot be applied to given types;
String appBundlePath = FlutterMain.findAppBundlePath();
^
required: Context
found: no arguments
reason: actual and formal argument lists differ in length
1 error
Finished with error: Gradle task assembleDebug failed with exit code 1

same error?

what is your flutter version? Upgrading to Flutter (Channel stable, v1.9.1+hotfix.2) fixed the same. FlutterMain.findAppBundlePath(Context applicationContext); is marked as deprecated in the update.

But what if I don't want to change the Flutter version at all? We are on the verge of completing a project. I am using the version ^1.7.8+hotfix.4.
Until yesterday evening everything worked fine.

The same issue

@DagobertDokate by any means did you run flutter pub upgrade? that might have downloaded the latest plugin (5.1.6). For now you can manually update FlutterMain.findAppBundlePath() to send context.getApplicationContext() / context in the FlutterFirebaseMessagingService.java file and see if it helps. (Is not recommended but worth trying)

@satyen893 Not that I'm aware of. Flutter --version also says version 1.7. The only thing I did was flutter pub cache repair.

@DagobertDokate  you can change you dependency to firebase_messaging: ">=5.0.2 <5.1.5"
Works with v1.7

psa 1.0.0+1
|-- cupertino_icons 0.1.2
|-- flutter 0.0.0
|   |-- collection 1.14.11
|   |-- meta 1.1.6
|   |-- sky_engine 0.0.99
|   |-- typed_data 1.1.6
|   '-- vector_math 2.0.8
|-- flutter_common 1.0.0
|   |-- cockpit_base 1.0.1
|   |   |-- flutter...
|   |   |-- http...
|   |   |-- intl...
|   |   |-- rxdart...
|   |   '-- tracking_client 0.0.1
|   |       |-- firebase_analytics 4.0.2
|   |       |   |-- flutter...
|   |       |   '-- meta...
|   |       |-- firebase_core...
|   |       |-- firebase_crashlytics 0.1.0+3
|   |       |   |-- flutter...
|   |       |   '-- stack_trace...
|   |       |-- firebase_performance 0.3.0+5
|   |       |   '-- flutter...
|   |       |-- flutter...
|   |       |-- http...
|   |       '-- sentry 2.2.0
|   |           |-- http...
|   |           |-- meta...
|   |           |-- stack_trace...
|   |           '-- usage 3.4.1
|   |               '-- path...
|   |-- deal_client 1.1.0
|   |   |-- cockpit_base...
|   |   |-- flutter...
|   |   '-- rxdart...
|   |-- firebase_dynamic_links 0.5.0+1
|   |   '-- flutter...
|   |-- flare_flutter 1.5.8
|   |   |-- flare_dart 1.4.6
|   |   '-- flutter...
|   |-- flutter...
|   |-- flutter_html 0.11.0
|   |   |-- flutter...
|   |   '-- html 0.14.0+2
|   |       |-- csslib 0.16.1
|   |       |   '-- source_span...
|   |       '-- source_span...
|   |-- flutter_swiper 1.1.6
|   |   |-- flutter...
|   |   |-- flutter_page_indicator 0.0.3
|   |   |   '-- flutter...
|   |   '-- transformer_page_view 0.1.6
|   |       '-- flutter...
|   |-- flutter_widgets 0.1.5
|   |   |-- collection...
|   |   |-- flutter...
|   |   |-- html...
|   |   |-- intl...
|   |   |-- meta...
|   |   '-- quiver...
|   |-- intl 0.15.8
|   |   '-- path...
|   |-- like_client 1.0.0
|   |   |-- cockpit_base...
|   |   |-- flutter...
|   |   '-- shared_preferences...
|   |-- push_messaging_client 1.1.0
|   |   |-- cockpit_base...
|   |   |-- firebase_core 0.4.0+9
|   |   |   |-- flutter...
|   |   |   '-- meta...
|   |   |-- firebase_messaging 5.1.6
|   |   |   |-- flutter...
|   |   |   |-- meta...
|   |   |   '-- platform 2.2.1
|   |   |-- flutter...
|   |   |-- flutter_notification_channel 0.0.1
|   |   |   '-- flutter...
|   |   |-- http 0.12.0+2
|   |   |   |-- async...
|   |   |   |-- http_parser 3.1.3
|   |   |   |   |-- charcode...
|   |   |   |   |-- collection...
|   |   |   |   |-- source_span...
|   |   |   |   |-- string_scanner...
|   |   |   |   '-- typed_data...
|   |   |   |-- path...
|   |   |   '-- pedantic...
|   |   '-- shared_preferences...
|   |-- rxdart 0.22.2
|   |-- share 0.6.2+1
|   |   |-- flutter...
|   |   '-- meta...
|   |-- shared_preferences 0.5.3+4
|   |   |-- flutter...
|   |   '-- meta...
|   '-- url_launcher 5.1.3
|       '-- flutter...
'-- flutter_test 0.0.0
|-- async 2.2.0
|   '-- collection...
|-- boolean_selector 1.0.4
|   |-- source_span...
|   '-- string_scanner...
|-- charcode 1.1.2
|-- collection...
|-- flutter...
|-- matcher 0.12.5
|   '-- stack_trace...
|-- meta...
|-- path 1.6.2
|-- pedantic 1.7.0
|-- quiver 2.0.3
|   |-- matcher...
|   '-- meta...
|-- source_span 1.5.5
|   |-- charcode...
|   |-- path...
|   '-- term_glyph...
|-- stack_trace 1.9.3
|   '-- path...
|-- stream_channel 2.0.0
|   '-- async...
|-- string_scanner 1.0.4
|   |-- charcode...
|   |-- meta...
|   '-- source_span...
|-- term_glyph 1.1.0
|-- test_api 0.2.5
|   |-- async...
|   |-- boolean_selector...
|   |-- collection...
|   |-- matcher...
|   |-- meta...
|   |-- path...
|   |-- pedantic...
|   |-- source_span...
|   |-- stack_trace...
|   |-- stream_channel...
|   |-- string_scanner...
|   '-- term_glyph...
|-- typed_data...
'-- vector_math...

Still not working with 5.1.4 & 5.1.5. Yesterday all works fine with 5.1.4

I don't see the problem directly:
I have the following pubspec:
There I refer to 5.1.5
name: push_messaging_client

description: A new Flutter package.
version: 1.1.0
author:
homepage:

environment:
  sdk: ">=2.1.0 <3.0.0"

dependencies:
  flutter:
    sdk: flutter
  firebase_core: ^0.4.0+9
  firebase_messaging: ^5.1.5
  http: ^0.12.0+2
  shared_preferences: ^0.5.3+4

  cockpit_base:
    git:
      url<EMAIL_ADDRESS>      ref: develop
  flutter_notification_channel:
    git:
      url<EMAIL_ADDRESS>      ref: master

dev_dependencies:
  flutter_test:
    sdk: flutter
  mockito: ^4.1.0

# For information on the generic Dart part of this file, see the
# following page: https://www.dartlang.org/tools/pub/pubspec

# The following section is specific to Flutter.
flutter:

  uses-material-design: true

But the dependency tree says 5.1.6. Why? oO

Dart SDK 2.4.0
Flutter SDK 1.7.8+hotfix.4
push_messaging_client 1.1.0
|-- cockpit_base 1.0.1
|   |-- flutter...
|   |-- http...
|   |-- intl 0.15.8
|   |   '-- path...
|   |-- rxdart 0.22.2
|   '-- tracking_client 0.0.1
|       |-- firebase_analytics 4.0.2
|       |   |-- flutter...
|       |   '-- meta...
|       |-- firebase_core...
|       |-- firebase_crashlytics 0.1.0+3
|       |   |-- flutter...
|       |   '-- stack_trace...
|       |-- firebase_performance 0.3.0+5
|       |   '-- flutter...
|       |-- flutter...
|       |-- http...
|       '-- sentry 2.2.0
|           |-- http...
|           |-- meta...
|           |-- stack_trace...
|           '-- usage 3.4.1
|               '-- path...
|-- firebase_core 0.4.0+9
|   |-- flutter...
|   '-- meta...
|-- firebase_messaging 5.1.6
|   |-- flutter...
|   |-- meta...
|   '-- platform 2.2.1
|-- flutter 0.0.0
|   |-- collection 1.14.11
|   |-- meta 1.1.6
|   |-- sky_engine 0.0.99
|   |-- typed_data 1.1.6
|   '-- vector_math 2.0.8
|-- flutter_notification_channel 0.0.1
|   '-- flutter...
|-- flutter_test 0.0.0
|   |-- async...
|   |-- boolean_selector 1.0.4
|   |   |-- source_span...
|   |   '-- string_scanner...
|   |-- charcode 1.1.2
|   |-- collection...
|   |-- flutter...
|   |-- matcher 0.12.5
|   |   '-- stack_trace...
|   |-- meta...
|   |-- path...
|   |-- pedantic...
|   |-- quiver 2.0.3
|   |   |-- matcher...
|   |   '-- meta...
|   |-- source_span 1.5.5
|   |   |-- charcode...
|   |   |-- path...
|   |   '-- term_glyph...
|   |-- stack_trace 1.9.3
|   |   '-- path...
|   |-- stream_channel 2.0.0
|   |   '-- async...
|   |-- string_scanner 1.0.4
|   |   |-- charcode...
|   |   |-- meta...
|   |   '-- source_span...
|   |-- term_glyph 1.1.0
|   |-- test_api 0.2.5
|   |   |-- async...
|   |   |-- boolean_selector...
|   |   |-- collection...
|   |   |-- matcher...
|   |   |-- meta...
|   |   |-- path...
|   |   |-- pedantic...
|   |   |-- source_span...
|   |   |-- stack_trace...
|   |   |-- stream_channel...
|   |   |-- string_scanner...
|   |   '-- term_glyph...
|   |-- typed_data...
|   '-- vector_math...
|-- http 0.12.0+2
|   |-- async 2.2.0
|   |   '-- collection...
|   |-- http_parser 3.1.3
|   |   |-- charcode...
|   |   |-- collection...
|   |   |-- source_span...
|   |   |-- string_scanner...
|   |   '-- typed_data...
|   |-- path 1.6.2
|   '-- pedantic 1.7.0
|-- mockito 4.1.1
|   |-- collection...
|   |-- matcher...
|   |-- meta...
|   '-- test_api...
'-- shared_preferences 0.5.3+4
|-- flutter...
'-- meta...

@DagobertDokate comment out firebase_messaging: ^5.1.5 run flutter pub get, then add firebase_messaging: 5.1.4 and run flutter pub get. This should get you the correct version

@DagobertDokate comment out firebase_messaging: ^5.1.5 run flutter pub get, then add firebase_messaging: 5.1.4 and run flutter pub get. This should get you the correct version

Does not solve the problem.
Deleting the .pub-cache directory also does not improve the situation. I am open for further suggestions.^^

did you remove the caret sign before the version number ?

Now I'm really confused. The instructions for Flutter always say very clearly: 'firebase_messaging: ^5.1.6'.
But if I omit '^', it uses the right version.
Should I now remove this from all dependencies? Is this a Flutter/Pub error or do I just not understand the instructions?

I have the latest flutter version-
Flutter 1.9.1+hotfix.2 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 2d2a1ffec9 (13 days ago) • 2019-09-06 18:39:49 -0700
Engine • revision b863200c37
Tools • Dart 2.5.0

Only happens when compiling on release mode for android. It works in debug though.
Current configuration -
classpath 'com.android.tools.build:gradle:3.3.2'
classpath 'com.google.gms:google-services:3.2.1'
Build failed LOG------------------------------------>
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':location:verifyReleaseResources'.

java.util.concurrent.ExecutionException: com.android.builder.internal.aapt.v2.Aapt2Exception: Android resource linking failed
/Users/sumitsmac/Desktop/LIVE/build/location/intermediates/res/merged/release/values/values.xml:276: error: resource android:attr/fontVariationSettings not found.
/Users/sumitsmac/Desktop/LIVE/build/location/intermediates/res/merged/release/values/values.xml:277: error: resource android:attr/ttcIndex not found.
error: failed linking references.

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 1m 54s
Finished with error: Gradle task assembleRelease failed with exit code 1
Kindly Help

Now I'm really confused. The instructions for Flutter always say very clearly: 'firebase_messaging: ^5.1.6'.
But if I omit '^', it uses the right version.
Should I now remove this from all dependencies? Is this a Flutter/Pub error or do I just not understand the instructions?

No you don't need to remove it from all your dependencies. It is just in this case that you need 5.1.5 twhich is compatible with flutter v1.7.
5.1.6 needs flutter v1.9

Yes, but the install guid cleary said 'firebase_messageing: ^5.15'. In every dep is '^'. What i should remove it in this case? I don't understand oO

error: method findAppBundlePath in class FlutterMain cannot be applied to given types;
String appBundlePath = FlutterMain.findAppBundlePath();
^
required: Context
found: no arguments
reason: actual and formal argument lists differ in length
1 error
Finished with error: Gradle task assembleDebug failed with exit code 1

same error?

no, Not the same

I have upgraded to firebase_messaging : ^5.1.6 and the error has changed -
Note: /Users/sumitsmac/Documents/Important_flutter/flutter/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-0.12.9+3/android/src/main/java/io/flutter/plugins/firebase/cloudfirestore/CloudFirestorePlugin.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /Users/sumitsmac/Documents/Important_flutter/flutter/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-0.12.9+3/android/src/main/java/io/flutter/plugins/firebase/cloudfirestore/CloudFirestorePlugin.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':location:verifyReleaseResources'.

java.util.concurrent.ExecutionException: com.android.builder.internal.aapt.v2.Aapt2Exception: Android resource linking failed
/Users/sumitsmac/Desktop/LIVE/build/location/intermediates/res/merged/release/values/values.xml:276: error: resource android:attr/fontVariationSettings not found.
/Users/sumitsmac/Desktop/LIVE/build/location/intermediates/res/merged/release/values/values.xml:277: error: resource android:attr/ttcIndex not found.
error: failed linking references.

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 2m 3s
Finished with error: Gradle task assembleRelease failed with exit code 1

@DagobertDokate for now to make your application up and running remove '^' from the firebase_messaging dependency, for more information on this please read What is the caret sign (^) before the dependency version number in Flutter's pubspec.yaml?

firebase/cloudfirestore/

this issue is with cloudfirestore plugin

bad 5.1.6 version....

I get this error in ios now o pushing notification -
nw_connection_receive_internal_block_invoke [C4] Receive reply failed with error "Operation canceled"

Kindly help !

same here. Did anyone resolved this issue??

forcing the package version "firebase_messaging: 5.1.5" (remove ^) has solved the issue for me.
i think package v5.1.6 is only compatible with the new flutter v1.9.

Hi @Peteritor
I see there's an open issue addressing the case you described.
Please follow up on that issue,
I'm closing the current one as duplicate.
If you disagree please write in the comments
and I will reopen it.
Thank you

@DagobertDokate by any means did you run flutter pub upgrade? that might have downloaded the latest plugin (5.1.6). For now you can manually update FlutterMain.findAppBundlePath() to send context.getApplicationContext() / context in the FlutterFirebaseMessagingService.java file and see if it helps. (Is not recommended but worth trying)

we have to add context.getApplicationContext().toString to work properly

Old version supports
"FlutterMain.findAppBundlePath()"
New upgraded versions supports
"FlutterMain.findAppBundlePath(context)"


Checks should run on PR commits and after push to main branch

Previously we were running tests on PR but on the base commit on the target branch. Modified it to run the tests on the commit on the PR merge branch.
Also, the tests should only run when they are targeting main branch.

The checks are failing because of the langchain, It'll be fixed in this PR https://github.com/refuel-ai/autolabel/pull/374


Failed setup

Hi. After I configured region, username and password, i get this message.

Username and password are correct.

Thanks for raising this.
Do you know what version of sock you have? My guess is that it's a v2 sock that is connected to your account, currently only the V3 sock (and dream sock) are supported. If you do have a V2 sock and would be happy to provide your JSON responses from the api then I'd be happy to add support for the V2 sock.
Let me know if you need any help with any of the above.

Closing as no response for 1 month

Hi, I have the same problem like @LassPar
I got the following log message

Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht
Logger: custom_components.owlet.coordinator
Source: helpers/update_coordinator.py:290
Integration: Owlet Smart Sock
First occurred: 20:35:37 (3 occurrences)
Last logged: 20:36:00
Unexpected error fetching owlet data: 'LOST_POWER_ALRT'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 290, in _async_refresh
self.data = await self._async_update_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/owlet/coordinator.py", line 44, in _async_update_data
properties = await self.sock.update_properties()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pyowletapi/sock.py", line 242, in update_properties
self._properties = await self.normalise_properties()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pyowletapi/sock.py", line 180, in normalise_properties
properties = {
^
File "/usr/local/lib/python3.11/site-packages/pyowletapi/sock.py", line 181, in
key: type(self._raw_properties[property]["value"])
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
KeyError: 'LOST_POWER_ALRT'

Do you know this kind of problem?
We use the socks and both are v3 accordingly to the packing.
Thanks!


APE_REQ.2-9 (Virt 1.0)

"The evaluator shall examine the statement of security requirements to determine that each dependency of the security requirements is either satisfied, or that the security requirements rationale justifies the dependency not being satisfied."
All dependencies are either explicitly met or implicitly justified in addendum.
Please draft an implicitly satisifed appendix.

Done.


Add ignoreOverridden support for BooleanPropertyNaming rule

Expected Behavior of the rule
When overriding a Boolean property from a 3rd party library, the BooleanPropertyNaming will flag the override if it does not adhere to the rule. Since this is out of the developer's control, there should be a way to set the ignoreOverridden flag to true for such cases.
Context
One example of this is when overriding the PagingSource#keyReuseSupported property from the Android Paging 3 Library.
Yes, one could configure the rule to accept the naming conventions of the 3rd party library but that may be too invasive if the code base under the dev's control wishes to adhere as close to the default config as possible.

Yup that's a valid addition 👍 Do you want to send a PR?

Sure. Please feel free to assign to me.

Closing as this was already addressed.


Speed setting

As of now the animations are way slower than in the original. An option to increase speed (or faster default) would be pretty important.

Here TombOfVARN (the ru translator) said the same thing. My reply:
https://github.com/arcomage/arcomage-hd/pull/17#issuecomment-814843355
The speeded up version was just deployed 5 minutes ago.
If it's still slow to you, then it must be a browser performance issue that I can't solve on my side, but requires you to change to Chrome or Chrome engine-based browser (or update your computer 😂).
Tell me if it still feels slow.

When I test the game with Firefox in Windows, when I click a card, it suddenly moves to the center. I removed an unnecessary box-shadow effect, now the latest version correctly shows the animated movement, everything seems to be fine with Windows Firefox in my 2015 gamer PC. I don't know if you and @TombOfVARN can see improvement in your browsers (TombOfVARN uses Firefox, not sure about GrayFace).
The latest version also fully supports tablet / mobile screen, you can try it.

I didn't really planned for a Desktop Version but here is it:
https://github.com/arcomage/arcomage-hd#desktop-version
(Windows for now, I'll do MacOS and Linux later...)
(https://github.com/arcomage/arcomage-hd/issues/3)
I made it partly, no, mainly, because Firefox & Safari do not run the game very well. With Desktop Version, non Chrome-like browser user can play the game smoothly.
However it's just a Chrome wrapper that visits arcomage.github.io, if you can use Chrome, you don't need this Desktop Version.
cc @TombOfVARN

See also #66 [Tutorial / solutions] What to do if the game is slow? which I've just written.  If it's still slow in Chrome, the "Solution 2 Force Chrome to use dedicated GPU" might be worth a try on dual-GPU PCs.
I saw Is there any way to force MM7 with grayface's to not use the integrated intel card? today and found forcing dedicated GPU might be a solution for ArcoMage HD being slow on some dual-GPU PCs. Indeed, by default Chrome does not use dedicated GPU at all when ArcoMage HD is running.


Assert exception if no changelog destination specified

If the caller failed to provide a changelog destination, then the JGit and CliGit implementations handled the failure differently.  The CliGit implementation is considered authoritative, so the JGit implementation was extended to match CliGit.
@reviewbybees

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

Infrastructure problem caused a test failure.  Closing and reopening to execute tests again.


Save failing when there are spaces in the file path

When opening or trying to save a .f95 file with Atom the attached error appears.  Removing all spaces in the file path fixes the error.  Note, saving and loading still work fine, that error just appears.

Thanks for the report. I just released an updated version (0.7.1) that should fix this issue. Check it out and let me know if the issue persists.

Ok, I have a question and I don't know if it's a bug or if I am being dumb.  The Diagnostics panel doesn't show any issues even when I intentionally put issues it's supposed to catch into my code.  Am I doing something wrong?  I've attached a screen shot and my code, note that the variable start_time is declared twice.

MODULE helper
CONTAINS
    FUNCTION probability_finder(n)
        !   Purpose:
        !       To find the probability of n people in a room having the same birthday

        ! declarations
        REAL :: probabiity_finder
        INTEGER, INTENT(IN) :: n            ! number of people
        INTEGER, DIMENSION(n) :: bdays ! the array of birthdays
        INTEGER :: bday ! one single birthday in the array
        REAL, DIMENSION(n) :: rndm ! birthdays normalized between 0 and 1
        INTEGER, PARAMETER :: nsims = 5000 ! number of simulations to run
        INTEGER :: n_dupe ! number with duplicates
        INTEGER :: i,j        ! loop indices

        ! reset variables
        n_dupe=0

        ! loop over each simulation
        sim_loop: DO i = 1, nsims
            ! generate array of birthdays
            CALL RANDOM_NUMBER(rndm)
            bdays = INT(1 + 364*rndm)

            ! check for duplicates
            dup_loop: DO j = 1, n
                bday = bdays(j)
                IF (ANY(bdays(i+1:) == bday)) THEN
                    n_dupe = n_dupe + 1
                    EXIT
                END IF
            END DO dup_loop
        END DO sim_loop

        probability_finder = (REAL(n_dupe) / REAL(nsims))

    END FUNCTION probability_finder

END MODULE helper
PROGRAM birthday_problem
USE helper
IMPLICIT NONE !requires me to declare all variables
!   Purpose:
!       To find the probability of n people in a room having the same birthday and do so for many values of n
!       Source: Exercise 7-28

!   Variable Declarations
INTEGER :: start_time   ! execution start time
INTEGER :: end_time     ! execution end time
REAL    :: prob         ! probability of two people having the same birthday in a group of n people
INTEGER :: n            ! number of people
REAL :: start_time
!	start timer
CALL SYSTEM_CLOCK(start_time)

DO n = 1,40
    prob = probability_finder(n)
    WRITE (*,100) n, 100*prob
    100 FORMAT ('The chance that two people in a group of ', I3, ' people will have the same birthday is ', F6.2,' percent')
END DO

!   Finish up.
CALL SYSTEM_CLOCK(end_time)
! execution time
end_time = end_time - start_time
WRITE (*,999) end_time/1000., end_time/60000., end_time/3.6E6
999 FORMAT (/,'Program complete. Time to execute ', F7.3, 's or ', F7.3, 'min or ', F7.3, 'hrs')

END PROGRAM birthday_problem

You're right.  As soon as I saved the file the diagnostics showed up.  Sorry to waste your time, I'm new to Atom and Fortran and haven't quite figured either one of them out yet :)