Supporter System

Related: #16
This will be heavily based on osu!'s supporter system, and we will leverage PCI-compliant transaction handlers for this.
the supporter system is a voluntary, non-subcription pledge service that allows people to name their price on the platform. The only cap we have for supporter is 5 USD for minimum, which equates to one month.
Being said so, we have a flow that would allow Sayonika to understand the transactions went well:

On supporter page,  have them pick a specific pledge amount, 5 being the minimum, custom being the last option.

If picked from predetermined values: Invoice them with the amount stated.
If custom, Invoice with their own valued cost.

Listen to the callback the provider returns in-API. Show a Error page if not successful, show a successful page if successful, of course
When successful, set supporter badge and time it based on the pledge amount. Reminder that 5US$ is equivalent to 1 month, as to be fair with our development efforts for this.

Forgot about the system when they lose supporter:

If they lose supporter, existing mods they have uploaded files upon will have the uploads enabled to them regardless if they have supporter or not.

This is it for now at the moment, but we'll come up of new features for paying people soon


Simplify and update project template

This basically removes the docker double dutch deploy routine and instead suggests to use our new automated builds for drtools which already includes dask and sparsity.
The goal is to move from a hacky docker-compose deployment (which is ment to run services not tasks) to the new deployment form where docker/kubernetes jobs/task are ran/handled via luigi. Meaning luigi actually manages docker containers which run click commands to execute certain functions. This will ease the luigi run function which just runs the docker container with a certain command.
Furthermore the project template is expected to become more general and thus fit more projects such as recommenders and scorers, which often include APIs too.
Furthermore we incorporate the structure module which gives an overview of paths or path templates used in the project and allows us to move from local or distributed storage by changing the ROOT key in the settings file.

@vitords
@michcio1234

How do these changes affect drtools-deploy? Is the provisioning playbook still up-to-date?

No the only requirement to run this on a instance is to have the following packages installed:

docker
luigi
docker-compose

Did we reach a conclusion on what to do with setup.py? I think a simple open('requirements.txt') will not work if we want to specify github links to our private repos in requirements file. You mentioned something about removing setup.py at all. Should we discuss it?

Yes, probably we should remove setup.py and add a dockerfile that installs the package with PYTHONPATH...

@vitords are you going to review it?

@michcio1234 Update


Updated German Translations

German translation impovements by a freaking lot. Was basically unusable and insulting before, tho still not done yet.

Thank you for your update to the German translation! We truly appreciate your contribution and are glad to improve the quality of our product with your help.


iOS: closing webview with 'Done' trigger no callback

I've used the plugin to authenticate through Microsoft AAD.
The login work well (as well as on Android) but I've faced an issue after clicking on 'Done' on the webview.
In fact, nothing happen, no promise rejection, no callback at all.
It seems to be related to the following behavior: 'Done' click remove all observers (see here, and https://github.com/OAuthSwift/OAuthSwift/issues/223#issuecomment-234893564 too).
Is it possible to know from a web point of view when this happen?
Edit: Maybe this could help: https://github.com/OAuthSwift/OAuthSwift/pull/558 but it seems to be related to a more recent pod version: 2.1.0!

The "delegate" did the trick. Thx for the hints.


Breaking changes

Shouldn't we increase major version on breaking changes? see : http://semver.org

Yes from one side... from another they are really tiny and in my mind they are not enough for major release... I'v just removed unnecessary generics... Build will fail but it is 1 minutes to fix.

yes, but i think people think that they need to change nothing on a dll replacement when only minor versions were changed...
i think we should change or strategy to only do non breaking changes if we will not increase major version.

ok, you a right! :)
we'll follow this in next releases.


Teams Configuration Latency

It seems there is a delay in updating the Teams Apps settings when making changes to what apps are viewable from within the Teams site.
Is it possible to find out from the PG whether there is a known time-delay before seeing these changes take effect? I've not waited too long (~5 minutes after changing the settings), but unsure if I should wait xx minutes/hours before seeing the changes take effect.
Please advise.

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

ID: 143108bb-d6e6-48a8-a7cb-d11b89ebeaab
Version Independent ID: 145773e2-149e-1c1c-5797-433c13f13b22
Content: Admin settings for apps in Microsoft Teams
Content Source: Teams/admin-settings.md
Service: msteams
GitHub Login: @LolaJacobsen
Microsoft Alias: lolaj

Okay, so I waited about 10 minutes, and noticed that my changes have taken effect. Should this be updated in the documentation? Thanks!

Hi @dhoegl
Thanks for your feedback! We really appreciate it!
I tested the scenario you described and the app showed up with no delay to users, so in this case we do not see the need to update the documentation to reflect some delay.
Thank You

@get-itips  Thank you very much for the contribution and sharing this explanation. @dhoegl
Hope this comment is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.

	👍🏼

	Thank you!

On Mon, Mar 11, 2019 at 6:22 AM -0400, "Yogesh Kumar"<EMAIL_ADDRESS>wrote:
@get-itips  Thank you very much for the contribution and sharing this explanation. @dhoegl
Hope this comment is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


Finish rewriting legacy code

This builds on a few PRs that are open and ready for review.  Only the latest commit a7fcb43 is relevant.
What is this
This finishes removing the legacy wasm.main module.
This includes

formalization of some mechanisms for instantiating wasm modules, and running module functions
extracting all of the logic functions for individual opcodes
expansion of the API around various datatypes to support the opcode logic functions.
conversion of all value types to use numpy data types.
proper implementation of the floating point operations.

I'll spend some time tomorrow filling in docstrings and will check in with you guys before merging.


Request - Publish crate to crates.io

I have pinged #cargo as a quick check, and there's no issue with publishing this crate.
Use case: I have a plugin that uses this crate to ensure it works, but can't publish with those tests active (becuase cargo requires all dependencies to be on crates.io before you can publish)

I'll get right on it :smile:

@thepowersgang it seems I'll be forced to change the name of the crate - compiletest is a reserved name: https://github.com/rust-lang/crates.io/blob/master/src/reserved_crates.txt
Any suggestions for a new name?

ctest
compiletestrs
rust_compiletest
petulant-lana
shiny-ironman
@Munksgaard @Manishearth Any suggestions?

I'd actually prefer compiletest_rs
I can publish this if you want; but I'll need access to the repo.

Ooops, hit the wrong button

Published here: https://crates.io/crates/compiletest_rs
@Manishearth Can I add you as owner as well?

\o/ Sure, feel free to add me as an owner :)

@llogiq @Munksgaard @thepowersgang I'm just letting you know the crate name has changed from compiletest to compiletest_rs, which is a breaking change.
The crate is also on crates.io now, so you could consider referencing that instead. If I'm not mistaken you should just add
[dev-dependencies]
compiletest_rs = "*"

to Cargo.toml

Cool. Thank you.

:+1:


Fix typo in comment

PR against wrong branch, sorry -- moved to https://github.com/django/django/pull/6121


Custom parsing of dates when allowInput=true

Is is possible to add custom parser for user entered dates when allowInput=true?
For example, user could enter 'tomorrow' or "-5m" or "+2d3m" and custom user provided function would parse and convert it into Date object and pass it to flatpickr.
Would this be possible to achieve using a plugin?
It looks to me that such mapping function should go here:
https://github.com/flatpickr/flatpickr/blob/master/src/index.ts#L1489
Is there any other place where such mapping should happen?
Thanks,
gorazd

@bh213 Yes. You should use the parseDate config option. See https://github.com/flatpickr/flatpickr/blob/master/src/types/options.ts#L213
If you want to fallback on flatpickr's default parser in your own parser, you can just call flatpickr.parseDate(date, format)

Closing this due to inactivity. Please reopen if the problem persists or if you require additional help


93 pyqode alt

What are the issues this pull addresses (issue numbers / links)?
#93
Did you add tests to cover your changes (yes/no)?
No
Did you update the documentation accordingly (yes/no)?
Yes
Did you read the CONTRIBUTING document (yes/no)?
Yes
Summary
Removed Metal IDE functionality (PyQode)
Adds "Developer Mode" which means a  filewatcher will alert the user if any of the QComponent source files are edited while the GUI is running
Details and comments
Anyone using an environment created using PyQode should have no trouble using Jupyter Notebook or even running tests in the terminal.
However, even though the code produces correct output, being run in the terminal with a pyqode-installed environment can cause "Error processing line 1 of ~/opt/anaconda3/envs/qf392/lib/python3.7/site-packages/pyqode.qt-nspkg.pth:" to be continuously thrown meaning perhaps this PR should be saved for a next release. We could consider adding a develop branch alongside main.

The Deep Dive tutorial is failing on gui.rebuild()

On Crum, I am getting the same error with other notebook, tutorials/8 Full Design Flow Examples/Full_Chip_Design_01.ipynb

The Deep Dive tutorial is failing on gui.rebuild()

On Crum, I am getting the same error with other notebook, tutorials/8 Full Design Flow Examples/Full_Chip_Design_01.ipynb

That error will occurs anywhere rebuild is called.

Spent some time offline with @grace-harper-ibm discussing "developer mode" feature of updating a qcomponent after they have already been imported in QDesign.
Hot-topic: When a qcomponent  has been updated on hard-drive, but was  already imported into Metal, the user experience was discussed.   I suggest that a warning be given to user, if an user wants the updated import, they should delete all the qcomponents in the design and add them again.  This could be done manually by adding them in the GUI, or through cells which have the qcomponents in the notebook.  Otherwise, pins, connections, and qgeometry tables may become outdated.
Possible user experience in GUI: If a component has been added to design, the GUI will indicate if the component has been updated on the hard-drive, in developer mode, the tree in qlibrary will have red for files there were edited.  The only way to use the updated qcomponent, is to delete the components in QDesign and then add them back in with updated imports.

Spent some time offline with @grace-harper-ibm discussing "developer mode" feature of updating a qcomponent after they have already been imported in QDesign.
Hot-topic: When a qcomponent has been updated on hard-drive, but was already imported into Metal, the user experience was discussed. I suggest that a warning be given to user, if an user wants the updated import, they should delete all the qcomponents in the design and add them again. This could be done manually by adding them in the GUI, or through cells which have the qcomponents in the notebook. Otherwise, pins, connections, and qgeometry tables may become outdated.
Possible user experience in GUI: If a component has been added to design, the GUI will indicate if the component has been updated on the hard-drive, in developer mode, the tree in qlibrary will have red for files there were edited. The only way to use the updated qcomponent, is to delete the components in QDesign and then add them back in with updated imports.
@ThomasGM4 thoughts?

I think the delete / over_write would be required, since one couldn't presume how extensive the component has been changed (in theory they could completely modify the options, pins, qgeometry, etc.). So not just a rebuild probably.


Samplegen: honor sample argument name

Fix #2366

PTAL @pongad @vchudnov-g @beccasaurus

Codecov Report

Merging #2420 into master will increase coverage by <.01%.
The diff coverage is 94.11%.

@@             Coverage Diff              @@
##             master    #2420      +/-   ##
============================================
+ Coverage     86.75%   86.75%   +<.01%
- Complexity     5261     5264       +3
============================================
  Files           460      460
  Lines         20936    20947      +11
  Branches       2255     2260       +5
============================================
+ Hits          18162    18172      +10
  Misses         1971     1971
- Partials        803      804       +1

Impacted Files
Coverage Δ
Complexity Δ

...gle/api/codegen/transformer/SampleTransformer.java
98.97% <ø> (ø)
19 <0> (ø)
:arrow_down:

.../java/com/google/api/codegen/util/SymbolTable.java
100% <100%> (ø)
11 <1> (+1)
:arrow_up:

.../com/google/api/codegen/metacode/InitCodeNode.java
86.66% <93.75%> (+0.18%)
79 <8> (+2)
:arrow_up:

Continue to review full report at Codecov.

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

PTAL @pongad @vchudnov-g

Oh, I'm signed off. My approval remains in place. ;-)


Mark node modules as external

Bundling node modules is not really required for execution with node. In some cases (using a lib with bindings) bundling would fail too.

Thanks!


Various compiler and syntax design issues

// syntax for line comments directly conflicts with python's native // syntax for integer division (discarding remainder)

print(4 // 3)

returns 1.
However
print(4 // 3);

compiles to
# ...
print(4

; operator works weirdly

print(3); print(4);

results in an indent after compilation:
# ...
print(3)
 print(4)

This is not ideal, since usually user-injected whitespace after a ; would be ignored by the compiler, but in this case it isn't

comments seem to cut off code

consider
// blah blah blah
print(4);

you would expect the compiler to turn this into
# ...
print(4)

however, it compiles to
# ...
rint(4)

(notice the missing first character)
This only seems to affect c-style line comments (//).

# ... refers to:
import builtins
class AbstractError (builtins.Exception, metaclass=builtins.type("AbstractError", (builtins.type,), {"__repr__": lambda self: self.__name__})): pass

anyways i kinda made my own version of python with braces so feel free to use it yall
https://github.com/SlyceDF/nestpy


extracting features from ur trained network

Hi Julian,
I am more interested in your learned features rather than predicting the final outcome through the network. I was wodnering if it would possbile to extract features from the intermediate layers of ur 3D network? Or do you by any chance know any of these trained networks (preferably trained on 3D images) that can be used easily for feature extraction.
Thanks for your help in advance,
laleh

Yes you can.
Other networks would be C3D (see my article) but this one is trained on video's and does not give good features for CT.


aiosonic node transport

Proposal for adding aiosonic as transport layer
I'm the autor of aiosonic, I may add updates to it if required

Hey, sorry for the delay! I'd like to wait before aiosonic is a bit better established before adding a fourth (!) HTTP client.


Allow flexible survivor numbering

For example, have a war with a single survivor whose name is ${survivorName}2

The ticket wording was unclear, my bad 😳
Last year, we only allowed to change survivor 2 after the first submission, while the first survivor remained the same in all subsequent wars.
The steps we took to implement this rule were:

Declare a war with one survivor
Manually rename all of the survivors from groupname1 to groupname2.

Instead, there should be a configuration option that allows setting the survivor naming to groupname2 so we don't have to manually rename everyone's survivors in the second battle.


Error when running example with ruby 2.0.0-p648

Hi,
I have just been trying out your gem, but got an error when I ran the following example:
require 'worker'

# Initialize a worker pool.
pool = Workers::Pool.new(:on_exception => proc { |e|
  puts "A worker encountered an exception: #{e.class}: #{e.message}"
})

# Perform some work in the background.
100.times do
  pool.perform do
    sleep(rand(3))
    raise 'sad face' if rand < 0.5
    puts "Hello world from thread #{Thread.current.object_id}"
  end
end

# Wait up to 30 seconds for the workers to cleanly shutdown (or forcefully kill them).
pool.dispose(30) do
  puts "Worker thread #{Thread.current.object_id} is shutting down."
end

The error was:
/Users/njh/.rbenv/versions/2.0.0-p648/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:135:in `require': /Users/njh/.rbenv/versions/2.0.0-p648/lib/ruby/gems/2.0.0/gems/worker-0.6.0/lib/worker.rb:91: syntax error, unexpected keyword_rescue, expecting keyword_end (SyntaxError)
      rescue Exception => ex
            ^
/Users/njh/.rbenv/versions/2.0.0-p648/lib/ruby/gems/2.0.0/gems/worker-0.6.0/lib/worker.rb:99: syntax error, unexpected '.'
    @thread&.kill
             ^
        from /Users/njh/.rbenv/versions/2.0.0-p648/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:135:in `rescue in require'
        from /Users/njh/.rbenv/versions/2.0.0-p648/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:144:in `require'
        from worker-test.rb:28:in `<main>'

Is this a ruby 2 compatibly bug?

I recommend you try the latest version of the gem (0.6.1) and see if it works. Also Ruby 2.0.0 is unsupported. I recommend you try 2.2.x or newer. I'll update the readme.

Thanks for the fast response. The problem was actually because I stayed up too late and typed worker instead of workers! Which happens to have a very similar version number. If you install the right gem, it works fine 😞
I am using ruby 2.0.0, because that is the default ruby that comes with CentOS 7 / RHEL 7 but I will think about upgrading.


Enable make_randpop to accept country as parameter

Right now https://github.com/institutefordiseasemodeling/covasim/blob/develop/covasim/people.py#L315 is hardcoded on Seattle. We could use https://github.com/neherlab/covid19_scenarios/blob/da1381c429471c3d57b02cd5a7b6dc46e645c0b3/src/assets/data/country_age_distribution.json to get per-country ratios. Later we can write our own scraper.

I will look into this.

We could use this with CLI too - covasim --country USA --state Oregon

Fixed in one of the many PRs


Create udhtu.txt

Hi, please add my educational institution (udhtu) to your list. Thank you.

@SomethingNice2016 I am closing this request as a duplicate to #10461

@SomethingNice2016 I am closing this request as a duplicate to #10461


Resolves inconsistency between readme and the on_message signature

alligns readme signature with RFC1549/client.py

closes #80

I just noticed #50 existed and that the issue is moot for the asyncio branch. #80  was using the documentation on master which does not have this fix.
this Pr is moot.


Unset-value Vulnerability

We have found vulnerability in unset-value, the cache-base library internally uses unset-value, and unset value version below 2.0.1 are vulnarable. is there any plan to fix this issue and release a new version.
Please refer
https://security.snyk.io/vuln/SNYK-JS-UNSETVALUE-2400660 @jonschlinkert

I too am running into this -- scary part is that most folks are on version 1.0.1 of this lib. It doesn't look like the change made to unset value should be breaking unless one was relying on the prototype pollution to break things.
Three options exist in my eyes
Fix in userland
Effort to fix heavily relied on upstream packages. For me this is https://github.com/base/base 0.11.2 -- which exists nowhere in git history.
Publish a semver fix as 1.0.2.
I was able to fix in userland by adding a yarn resolution.
{
   // ...package.json
  "resolutions": {
    "unset-value": "^2.0.1"
  }
}


Automator: update<EMAIL_ADDRESS>in<EMAIL_ADDRESS>

Generated by Automator - 2023-02-15T20:56:10+00:00

@istio-testing: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-security-istiodremote_istio_release-1.16
7bca781f91ba010377e0903d145a66aa447b6c4c
link
true
/test integ-security-istiodremote

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-security-istiodremote


Add lsb-release dependency to mgmt server and agent on Debian/Ubuntu.

New version of #1412, based on the 4.7 branch.

@ProjectMoon please close and reopen to kick off travis again.  Thanks...

Merge this back to 4.7? Will we release a new 4.7 version?
Anyway, LGTM

CI RESULTS
Tests Run: 85
  Skipped: 0
   Failed: 1
   Errors: 0
 Duration: 8h 37m 08s

Summary of the problem(s):
FAIL: test_03_vpc_privategw_restart_vpc_cleanup (integration.smoke.test_privategw_acl.TestPrivateGwACL)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/git/cs1/cloudstack/test/integration/smoke/test_privategw_acl.py", line 274, in test_03_vpc_privategw_restart_vpc_cleanup
    self.performVPCTests(vpc_off, restart_with_cleanup = True)
  File "/data/git/cs1/cloudstack/test/integration/smoke/test_privategw_acl.py", line 303, in performVPCTests
    vpc_2 = self.createVPC(vpc_off, cidr = '<IP_ADDRESS>/24')
  File "/data/git/cs1/cloudstack/test/integration/smoke/test_privategw_acl.py", line 472, in createVPC
    self.fail('Unable to create VPC due to %s ' % e)
AssertionError: Unable to create VPC due to Job failed: {jobprocstatus : 0, created : u'2016-05-26T23:28:40+0200', jobresult : {errorcode : 530, errortext : u'Failed to create VPC'}, cmd : u'org.apache.cloudstack.api.command.admin.vpc.CreateVPCCmdByAdmin', userid : u'd11a1719-2357-11e6-92ce-5254001daa61', jobstatus : 2, jobid : u'7ae0f8ed-b922-46fc-b651-5fe657510310', jobresultcode : 530, jobresulttype : u'object', jobinstancetype : u'None', accountid : u'd119fe06-2357-11e6-92ce-5254001daa61'}
----------------------------------------------------------------------
Additional details in: /tmp/MarvinLogs/test_network_6QAMPX/results.txt

Associated Uploads
/tmp/MarvinLogs/DeployDataCenter__May_26_2016_17_40_22_9UMTAF:

dc_entries.obj
failed_plus_exceptions.txt
runinfo.txt

/tmp/MarvinLogs/test_network_6QAMPX:

failed_plus_exceptions.txt
results.txt
runinfo.txt

/tmp/MarvinLogs/test_vpc_routers_ITAGDW:

failed_plus_exceptions.txt
results.txt
runinfo.txt

Uploads will be available until 2016-07-27 02:00:00 +0200 CEST
Comment created by upr comment.

Yes @wido, this will be merged into 4.7 and then forward merged.  This test has been flaky recently, so I think this is PR is ready since we have LGTMs from the previous PR as well.


doc: Improve docs for Resource* classes

Also moves module-specific classes to their own module's doc_classes
folder.
Reviews welcome, figuring out these many classes is not trivial ~and their inconsistent naming doesn't help either (should definitely be harmonized for 4.0).~

Rebased on top of #29872 which removed all the unnecessary ResourceFormatLoaders and Savers.
So what remains is an improvement and completion of the docs of the actually useful resource APIs.

Cherry-picked for 3.1.2.


Add comments and readme on how the userprofile works

Dan,
Can you add comments and create a readme file how the userprofile variable is stored and updated in the server and locally?

Dealt with in PR #53


fix(crux-ui): change rolling version deployment error to warning

Fixed change rolling version deployment error to warning.
Fixed change already have preparing deployment with the same prefix error to warning.
Fixed show the warning message at least 5 seconds (only in these events).
Fixed storage home button opens storages page instead of registries.
Fixed switch the order of arguments and commands in the common config section.

works, tested locally


Add isort to eolearn

Changes:

sorted the packages in the requirements files alphabetically
black was missing from the requirements-dev.txt
added also isort and ran it on the repo

sentinelhub was added as a first party package - higher than local, lower than third party

There are some issue relating to the relative imports (examples below). What is the direction in which eo-learn is going with these? My personal preference would be to always use absolute imports. I know there are pros and cons to both, but the community seems to prefer the absolute imports over relative ones.
************* Module eolearn.visualization.eopatch
visualization/eolearn/visualization/eopatch.py:23:0: C0411: third party import "from eolearn.core import EOPatch, FeatureType" should be placed before "from .eopatch_base import BaseEOPatchVisualization, BasePlotConfig" (wrong-import-order)
************* Module eolearn.visualization.extra.hvplot
visualization/eolearn/visualization/extra/hvplot.py:40:0: C0411: third party import "from eolearn.core import EOPatch, FeatureType, FeatureTypeSet" should be placed before "from ..eopatch_base import BaseEOPatchVisualization, BasePlotConfig" (wrong-import-order)
visualization/eolearn/visualization/extra/hvplot.py:41:0: C0411: third party import "from eolearn.core.utils.parsing import parse_feature" should be placed before "from ..eopatch_base import BaseEOPatchVisualization, BasePlotConfig" (wrong-import-order)

Ah, I get it, the absolute imports in this case look really messy. I solved this using a custom section in isort:
third party > first party > local absolute > local relative

Codecov Report

Merging #387 (6a19cd0) into develop (563288d) will not change coverage.
The diff coverage is 91.78%.

@@           Coverage Diff            @@
##           develop     #387   +/-   ##
========================================
  Coverage    82.79%   82.79%
========================================
  Files           54       54
  Lines         5172     5172
========================================
  Hits          4282     4282
  Misses         890      890

Impacted Files
Coverage Δ

core/eolearn/core/utils/logging.py
100.00% <ø> (ø)

...istration/eolearn/coregistration/coregistration.py
61.58% <ø> (ø)

features/eolearn/features/clustering.py
98.30% <ø> (ø)

.../eolearn/features/doubly_logistic_approximation.py
97.05% <ø> (ø)

io/eolearn/io/extra/geodb.py
33.33% <ø> (ø)

io/eolearn/io/geometry_io.py
81.81% <ø> (ø)

mask/eolearn/mask/cloud_mask.py
96.88% <ø> (ø)

ml_tools/eolearn/ml_tools/extra/plotting.py
0.00% <ø> (ø)

ml_tools/eolearn/ml_tools/train_test_split.py
100.00% <ø> (ø)

...isualization/eolearn/visualization/extra/hvplot.py
0.00% <0.00%> (ø)

... and 37 more

Continue to review full report at Codecov.

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

There are some issue relating to the relative imports (examples below). What is the direction in which eo-learn is going with these? My personal preference would be to always use absolute imports. I know there are pros and cons to both, but the community seems to prefer the absolute imports over relative ones.
************* Module eolearn.visualization.eopatch
visualization/eolearn/visualization/eopatch.py:23:0: C0411: third party import "from eolearn.core import EOPatch, FeatureType" should be placed before "from .eopatch_base import BaseEOPatchVisualization, BasePlotConfig" (wrong-import-order)
************* Module eolearn.visualization.extra.hvplot
visualization/eolearn/visualization/extra/hvplot.py:40:0: C0411: third party import "from eolearn.core import EOPatch, FeatureType, FeatureTypeSet" should be placed before "from ..eopatch_base import BaseEOPatchVisualization, BasePlotConfig" (wrong-import-order)
visualization/eolearn/visualization/extra/hvplot.py:41:0: C0411: third party import "from eolearn.core.utils.parsing import parse_feature" should be placed before "from ..eopatch_base import BaseEOPatchVisualization, BasePlotConfig" (wrong-import-order)

We tend to use relative imports for same package and absolute for other packages (since eolearn.core and eolearn.visualisation are not submodules but different packages).

We tend to use relative imports for same package and absolute for other packages (since eolearn.core and eolearn.visualisation are not submodules but different packages).

Would it be better then if other eolearn packages are treated as first party packages, alongside sentinelhub ?

I added the isort check, but if you'd prefer to have both checks under check-code-formatting, I can put them under the same action.

So far we're going for separate actions (so that if isort fails you'll still see that black fails as well). Might change in the future if it becomes unwieldy


DROOLS-3763: New API codegen prototype

API we discussed together:

RuleUnit<T>/RuleUnitInstance<T>
one KieSession per RuleUnitInstance
generated Module class with  code-generated create${T}RuleUnit()
refactored Maven plugin

see examples for reference https://github.com/kiegroup/submarine-examples/pull/5

Was the "Simple" untyped <Object> Unit implemented?

not yet, I'll add it soon. We'll have to think a little bit about implication (if it's library-based you can't "discover it" as source code but look in classpath etc etc)

Jenkins please retest this

Jenkins retest this please

after discussion with @mariofusco I am merging this.


Fix for the post-GLR Perl 6

Things need explicit flattening sometimes. This also works on pre-GLR rakudo

Applied and pushed


raw JSON causes dual initial entries on datagrid

Raw JSON identical to the one defined on form.io,
However, raw JSON using [form]='...rawJSON...' is rendered differently than src="...formio.url..."
(with raw JSON, dual initial empty entries are rendered in the datagrid)
For example: use this in the home.html for the ng2-app-starter
 <formio src='https://auicqnmuwlxvnoh.form.io/form2'></formio>
  <formio [form]='{"_id":"59227af9ad3ba1005dae9541","machineName":"auicqnmuwlxvnoh:testingTwinDatagridEntry","modified":"2017-05-22T06:24:50.776Z","title":"testing twin datagrid entry","display":"form","name":"testingTwinDatagridEntry","path":"form2","project":"5917b4c2ad3ba1005dae5d21","created":"2017-05-22T05:45:29.834Z","components":[{"input":true,"tree":true,"components":[{"input":true,"tableView":true,"inputType":"text","inputMask":"","label":"name","key":"name","placeholder":"","prefix":"","suffix":"","multiple":false,"defaultValue":"","protected":false,"unique":false,"persistent":true,"hidden":false,"clearOnHide":false,"validate":{"required":false,"minLength":"","maxLength":"","pattern":"","custom":"","customPrivate":false},"conditional":{"show":"","when":null,"eq":""},"type":"textfield","hideLabel":true,"tags":[]}],"tableView":true,"label":"theirdatagrid","key":"theirdatagrid","protected":false,"persistent":true,"hidden":false,"clearOnHide":false,"type":"datagrid","tags":[],"conditional":{"show":"","when":null,"eq":""},"condensed":true,"addAnother":""}],"owner":"589279d62c8ee6006c1e2ed4","submissionAccess":[],"access":[{"type":"read_all","roles":["5917b4c2ad3ba1005dae5d22","5917b4c2ad3ba1005dae5d23","5917b4c2ad3ba1005dae5d24"]}],"tags":[],"type":"form"}'></formio>

Should be fixed in rc15

@travist still seems to be an issue for me with rc15. the above code still shows duplicated fields for the direct JSON

(@travist - may want to reopen the ticket as it's still exhibiting the behaviour)

Should be fixed in RC18.

unfortunately, not fixed....


Create a Page Demonstrating How To Build a Form with Legos

https://github.com/HausDAO/sdk-docs/pull/52

Closed by https://github.com/HausDAO/sdk-docs/pull/52
Will continue to add more to this, but the content is in


[Sprint 5] Post tool to NIST Privacy Framework

Draft:
https://docs.google.com/document/d/1aNvZ-pBpe2Bz1eBhllvb-SUeGZ9sWHkPxh7TOtiWPtg/edit#

https://www.nist.gov/privacy-framework/resource-repository/contribute-resources
https://github.com/usnistgov/PrivacyFrmwkResources/blob/master/contribution-forms/guidance-tool-form.md

Forked and submitted a pull request for NIST to review and include: https://github.com/usnistgov/PrivacyFrmwkResources/pulls

Katie suggested we add the slide deck and video to the 'related documentation' section -- will update the PR after we edit and upload video.


[$500] Settings - Height of the name input field in the Settings page changes upon returning from the Get Assistance page

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Go to staging
Navigate to Settings > Workspaces and select any Workspace.
Choose "Settings."
Click the question mark icon and then go back.
Observe that the name input field flickers.

Expected Result:
The height of the name input field should remain consistent without any flickering
Actual Result:
The height of the name input field flickers after returning from the Get Assistance page
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[x] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number: 1.3.73-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/8137cb68-1157-4bf9-a3ae-6c5c7322507d
https://github.com/Expensify/App/assets/93399543/202deeb5-e5e5-4c90-9945-75f94d4e040e
https://github.com/Expensify/App/assets/93399543/d2f7c94a-88c1-4cb0-a2ad-3af38fa79d65
Expensify/Expensify Issue URL:
Issue reported by: @daraksha-dk
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1695501792775439
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~018dd0d2c305a6b136
Upwork Job ID:<PHONE_NUMBER>133660672
Last Price Increase: 2023-10-03

Proposal
Please re-state the problem that we are trying to solve in this issue.
Height of the name input field changes, when returning to the field containg the text input.
What is the root cause of that problem?
The text input field is getting default prop value props, and switching screens it's causing the field to re-render, due to which a slight delay is caused between getting the props and populating the textfield. Due to which the height of the text input changes.
What changes do you think we should make in order to solve the problem?

I propose to add a autoGrowHeight field to the text input which will fix the above issue.
https://github.com/Expensify/App/assets/55692562/d1084714-d3e0-4b50-a19c-0950f44e1f60
What alternative solutions did you explore? (Optional)

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~01df188f0ecefae56c

@Rosh008's proposal looks good to me!

Autogrow input container height based on the entered text

This is the exact intended usage of autoGrowHeight prop
🎀👀🎀 C+ reviewed!

Hm, I'm not a very big fan of that solution, though I agree it would fix the problem. I think it only fixes a symptom and not the root cause. For me, the root cause is that onLayout() is being triggered when the view is hidden. If a view is hidden, there should be no reason to trigger onlayout (or anything that would visually change the render).
I think a better solution would be to do something to prevent that from being triggered (or maybe add a flag so that onLayout knows that the view has been hidden and can have an early return).
What do you think about incorporating something more like the above into your solution @Rosh008 ?

@tgolen Then we can check  for layout.height in onLayout if it's invisible that is 0 we will simply return,  that fixes the problem.

Is it possible at all the prevent onLayout from being called when it's hidden?

I don't think we can suppress the callback from getting fired.

OK, thanks! I have a hunch that there are better and less-hacky solutions, so for now, I'm going to hold off on accepting the current proposal to see if we can get some more ideas for this. If in the end, your proposal is still the best, then we will go with it.

I just realized I made a mistake with my previous comments. I missed the fact that there were two proposals and I was actually responding to the layout.height proposal instead of the autoGrowHeight proposal, and then I got you both mixed up. I really apologize for that!
@tienifr if you go through my previous comments, it'll probably be more clear knowing that I am in fact responding to your proposal for layout.height and not the C+ accepted proposal from @Rosh008.
Now, to address the C+ accepted proposal for autoGrowHeight, I also don't feel like it is acceptable currently. My main concerns (for both of these proposals really) are:

It feels like we really haven't gotten to the root of the problem yet, let's dig deeper. Why is the layout not being set properly when coming back to this view?
Why don't we have this problem with other inputs on other settings pages?

I guess it's intention behavior of RN navigation

Looks like this is a bug (https://github.com/facebook/react-native/issues/10743), but the discussion ended in 2016. There isn't a consensus on whether this is caused by react-native or react-navigation, but I agree, let's dig deeper to figure out the actual root cause for this

Issue not reproducible during KI retests. (First week)

@abekkala I think this is ready to have its price increased. It would be especially helpful if we could learn if this is indeed no longer reproducible also.

bump @abekkala

Thanks, all. Closing this one out.


Go latest update to 1.14   crashes into machine code on mac os 10.11.6

What version of Go are you using (go version)?

$ go version

Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

What did you do?

What did you expect to see?
What did you see instead?

Here is the crash info in the terminal after I followed all instruction on updating go on mac osbuild hello.go
SIGILL: illegal instruction
PC=0x1066040 m=0 sigcode=1
goroutine 1 [running, locked to thread]:
runtime.asyncPreempt()
/usr/local/go/src/runtime/preempt_amd64.s:8 fp=0xc00004cef0 sp=0xc00004cee8 pc=0x1066040
fmt.init()
/usr/local/go/src/fmt/scan.go:465 fp=0xc00004cef8 sp=0xc00004cef0 pc=0x10e6540
runtime.doInit(0x1a80520)
/usr/local/go/src/runtime/proc.go:5414 +0x8a fp=0xc00004cf28 sp=0xc00004cef8 pc=0x1043aca
runtime.doInit(0x1a80ec0)
/usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc00004cf58 sp=0xc00004cf28 pc=0x1043a97
runtime.doInit(0x1a850c0)
/usr/local/go/src/runtime/proc.go:5409 +0x57 fp=0xc00004cf88 sp=0xc00004cf58 pc=0x1043a97
runtime.main()
/usr/local/go/src/runtime/proc.go:190 +0x1ce fp=0xc00004cfe0 sp=0xc00004cf88 pc=0x103702e
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc00004cfe8 sp=0xc00004cfe0 pc=0x10647d1
rax    0x1a80520
rbx    0xb
rcx    0x0
rdx    0x1a80578
rdi    0xc000092180
rsi    0x10e6540
rbp    0xc00004cf18
rsp    0xc00004cee8
r8     0x2910490d
r9     0x203000
r10    0x2
r11    0x11
r12    0xf5
r13    0x55555555555555
r14    0x171acac
r15    0x38
rip    0x1066040
rflags 0x10202
cs     0x2b
fs     0x0
gs     0x0

Dup of #37459.


Added additional Reply URL

Added additional Reply URL
https://SUBDOMAIN.Clarizen.com/Pages/Integrations/SAML/SamlResponse.aspx

cc: @jeevansd
GitHub Issue: https://github.com/MicrosoftDocs/azure-docs/issues/87662

@JamesTran-MSFT : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

@JamesTran-MSFT Adding additional Reply URL in our standard format as https://<SUBDOMAIN>.Clarizen.com/Pages/Integrations/SAML/SamlResponse.aspx in another PR. So closing this PR now.
#please-close

@JamesTran-MSFT Adding additional Reply URL in our standard format as https://<SUBDOMAIN>.Clarizen.com/Pages/Integrations/SAML/SamlResponse.aspx in another PR. So closing this PR now.
#please-close


Symbol tree has its symbol names clipped unnecessarily

Here is a screenshot:

We can see that the symbol names need not be clipped when the Symbol Tree window is widened.
Furthermore, it seems there is no consistency in the number of characters allowed before "..." appears.
Fixing this will greatly improve usability.

Folder names are always clipped to the longest common factor between all of the contents - for example, the folder you selected contains Cell<core--option--Option<std--thread--Thread>>, Cell<core--option--Option<usize>>, Cell<isize>, and Cell<std--thread--local--fast--DtorState>, so its name is Cell<....
Perhaps the Symbol Tree could be configured to specify a minimum folder name width so that symbols don't get grouped together as frequently?

Folder names are always clipped to the longest common factor between all of the contents - for example, the folder you selected contains Cell<core--option--Option<std--thread--Thread>>, Cell<core--option--Option<usize>>, Cell<isize>, and Cell<std--thread--local--fast--DtorState>, so its name is Cell<....

Ah thanks. My bad, I didn't note it.

Perhaps the Symbol Tree could be configured to specify a minimum folder name width so that symbols don't get grouped together as frequently?

Yes, this would be nice


Make an exception to space removal after ; for opening_hours

I noticed that the current iD editor on openstreetmap.org is removing the space characters after semicolons(;) from tag values. Spaces should not be removed, having space chars is essential for opening_hours http://wiki.openstreetmap.org/wiki/Opening_hours. Tools like http://osm24.eu stopped parsing the opening_hours tag correctly for opening_hours inserted in the last few days.

Reopening per @rjw62's request.


NixOS azure-agent outdated for Azure marketplace AIRA offer

While we used AIRA for in-house development we could integrate own private key for first login. Now we want to make an offer in Azure Marketplace and there is a lack of integration tools, especially for first login & configuration. We can currently make an image of AIRA with password-based root login (or integrate a common key with publishing a private pair, or make a web service that waits for a new key or something else), but it's not safe and not a common way for MS Azure users. There is a package azure-agent in nixpkgs, but it's outdated and don't work. Could someone help to update it?

There is a PR with update. Author told he need help with tests.


3.1.3 - RE2 Game Crash (Room 207) - Alexia magnum & Brad zombie

Version
v3.1.3
Seed
R720-MBUG-ZXYZM0W19Y760ZJZZZZZZZ1EXZNF5FVLGZYZZPYZZZZZ
Scenario
RE 2 (Claire B)
Player Character
Alexia
What happened?
Game crash in room 207 when I shoot Brad (zombie) using the Magnum. No problems with other enemies
https://github.com/IntelOrca/biorand/assets/122708115/630069a5-8565-4200-b41a-f60221942a2d

Duplicate of #426


feat: redesign refs popover

This PR...
Changes

Fixes

How to test it

Screenshots

Checklist

[ ] tested locally
[ ] added new dependencies
[ ] updated the docs
[ ] added a test

When clicking on View Graph it shows the source tab for the editor, we should show the graph one instead

Ohh, It saw showing it, let me check


Use native Ruby function for getting a string's length

Without this change, Ruby 3.2 was failing to correctly provide me with strings, because the length was always set to zero.
I'm not sure exactly what the change in 3.2 that triggered the problem, but given that rutie's rstring_len appears to be an implementation of a function in CRuby that's named rbimpl_ (which is a namespace meaning "no compatibility should be expected", I don't think this is Ruby's fault.

I'll try and set some time this week to get things update a bit on this project.

This will be considered for the Ruby 3 implementation.  For now I'm revamping the Ruby 2 CI support, then I'll move on to addressing these issues.


chore: update highlight logic to disregard empty layouts.

Description

Update drop zone calculation logic for highlights.
Discard highlights from empty non drop target layouts.
Use single rowGap value.
Fix multi delete issue, where ghost highlights are visible after deleting all widgets at once.

PR fixes following issue(s)
Fixes #28325
Fixes #28342
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Also list any relevant details for your test configuration.
Delete anything that is not relevant

[x] Manual
[ ] JUnit
[ ] Jest
[ ] Cypress

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test

/ok-to-test

/ok-to-test


Add AWS Lambda Section to Integrations Docs

Fix https://github.com/pydantic/pydantic/issues/9709

I pulled a lot of this info from the linked issue + my own experience getting a layer set up.
This is a pretty rough draft, but I think it'd be helpful for us to just get some information up about this that's more formalized than comments on an issue. I also don't think it's worth a ton of time investment for now.

I don't think we should add a section with AWS Lambda in the documentation because it's a product from a big company. I don't think open source projects should promote cloud products.

I think this section is more useful for the case of "I'm already using AWS Lambda, how do I use Pydantic with it". It feels less like an AWS Lambda promotion, and more like a Pydantic promotion.
The drawback of not having this section imo is that folks will just drop Pydantic, not AWS Lambda.

I'm not saying this content shouldn't exist. 🤷♂


test-branch/execute-job/wrong-commit-sha-on-pr/fd025a87-5dad-4a12-b208-1707c3d89559

PR for testing 37e9c87393b877a478df5b49a39d63654c2c946a

/canonical/self-hosted-runners/run-workflows 4f1c70cc3dad5370c365b76d0fa1a3c58185515e


Fit exception_handlers to exceptions_handlers

Application class doesn't have exception_handlers, the right name is     exceptions_handlers

Thank You!


Adding more information about the game currenty played

So currently the API only supports info about what someone is playing atm. Not more detailed info about the game (you can see this info in the uplay client if you go to the friendlist E.G. Rainbow six supports that). It would be great to find the backend where ubisoft is gathering this info from.

Is the same info available on the ubisoft website?

有兴趣参加节点

有兴趣参加节点

WHAT???


The contact email at the bottom of the README is outdated

Should probably be updated to @zackbloom

Should be able to field emails again 😄

YES!


RuntimeError: No such operator torchvision::nms

🐛 Bug
Ran into this issue when trying to use Faster R-CCC example on a Windows machine.
RuntimeError: No such operator torchvision::nms
To Reproduce
Steps to reproduce the behavior:
conda create -n pytorch
conda activate pytorch
conda install pytorch torchvision cudatoolkit=10.1 -c pytorch
python

and then
>>> import torch
>>> torch.ops.torchvision.nms
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\david\Miniconda3\envs\pytorch\lib\site-packages\torch\_ops.py", line 61, in __getattr__
    op = torch._C._jit_get_operation(qualified_op_name)
RuntimeError: No such operator torchvision::nms

Expected behavior
To be able to use torchvision.nms ...
Environment
Collecting environment information...
PyTorch version: 1.4.0
Is debug build: No
CUDA used to build PyTorch: 10.1

OS: Microsoft Windows 10 Pro
GCC version: Could not collect
CMake version: Could not collect

Python version: 3.8
Is CUDA available: Yes
CUDA runtime version: 10.0.130
GPU models and configuration: GPU 0: GeForce GTX 1070
Nvidia driver version: 436.48
cuDNN version: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.0\bin\cudnn64_7.dll

Versions of relevant libraries:
[pip3] numpy==1.17.4
[pip3] torch==1.4.0
[pip3] torchvision==0.5.0
[conda] blas                      1.0                         mkl
[conda] mkl                       2020.0                      166
[conda] mkl-service               2.3.0            py38hb782905_0
[conda] mkl_fft                   1.0.15           py38h14836fe_0
[conda] mkl_random                1.1.0            py38hf9181ef_0
[conda] pytorch                   1.4.0           py3.8_cuda101_cudnn7_0    pytorch
[conda] torchvision               0.5.0                py38_cu101    pytorch

and
nvidia-smi
Tue Feb 25 15:39:48 2020
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 436.48       Driver Version: 436.48       CUDA Version: 10.1     |
|-------------------------------+----------------------+----------------------+

Hi,
Thanks for the bug report!
There seems to be an issue with our binaries, at least for Windows.
@peterjc123 do you know if this is a known problem?

I updated my CUDA Toolkit to 10.1 update2 and matching cuDNN to v7.6.5
Collecting environment information...
PyTorch version: 1.4.0
Is debug build: No
CUDA used to build PyTorch: 10.1

OS: Microsoft Windows 10 Pro
GCC version: Could not collect
CMake version: Could not collect

Python version: 3.8
Is CUDA available: Yes
CUDA runtime version: 10.1.243
GPU models and configuration: GPU 0: GeForce GTX 1070
Nvidia driver version: 436.48
cuDNN version: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\bin\cudnn64_7.dll

Versions of relevant libraries:
[pip3] numpy==1.17.4
[pip3] torch==1.4.0
[pip3] torchvision==0.5.0
[conda] blas                      1.0                         mkl
[conda] mkl                       2020.0                      166
[conda] mkl-service               2.3.0            py38hb782905_0
[conda] mkl_fft                   1.0.15           py38h14836fe_0
[conda] mkl_random                1.1.0            py38hf9181ef_0
[conda] pytorch                   1.4.0           py3.8_cuda101_cudnn7_0    pytorch
[conda] torchvision               0.5.0                py38_cu101    pytorch

but I still get the same error.

Sorry, I could not reproduce this error with torch==1.4.0 and torchvision==0.5.0 with python=3.7 and cudatoolkit=10.1.
Python 3.7.4 (default, Aug  9 2019, 18:34:13) [MSC v.1915 64 bit (AMD64)] :: Anaconda, Inc. on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import torchvision
>>> import torch
>>> torch.ops.torchvision.nms
<built-in method nms of PyCapsule object at 0x0000029BF9F74150>

It seems that when I do
conda create -n torch
conda activate torch
python -V

I get Python 3.6.8
Then when I do
conda install pytorch torchvision cudatoolkit=10.1 -c pytorch
python -V

I get Python 3.8.1. This environment produces the RuntimeError: No such operator torchvision::nms
But
if I specifically create a python 3.7 environment
conda create -n torch37 python=3.7
conda activate torch37
python -V

I get Python 3.7.6
Then
conda install pytorch torchvision cudatoolkit=10.1 -c pytorch
python -V

I also get Python 3.7.6. In this environment I get no error
import torch
import torchvision
torch.ops.torchvision.nms
>>> <built-in method nms of PyCapsule object at 0x00000201B0AC9FC0>

So the issue seems to be with conda install pytorch torchvision cudatoolkit=10.1 -c pytorch choosing python 3.8 and causing this issue...

You mean it's Python 3.8 only issue, right? I'll check later.

Yes it seems so.

I have the same issue. I'll try @davidsteinar solution. I'll remove the environment and create a new one for that.
Thanks @davidsteinar.

I tried and it is actually a DLL loading problem for Python 3.8. The workground is to add the directory of cuda before importing torchvision using the following code.
import os
import sys
py_dll_path = os.path.join(sys.exec_prefix, 'Library', 'bin')
os.add_dll_directory(py_dll_path)

Still having this issue on Windows subsystem for Linux, same repro as the Python 3.8 steps above. The workaround suggested above doesn't work on WSL. Any ideas?

In Python 3.6 the solution will give the error:

AttributeError: module 'os' has no attribute 'add_dll_directory'
So I solved my issue adding this before importing torch and torchvision:

import os
import sys
py_dll_path = os.path.join(sys.exec_prefix, 'Library', 'bin')
os.environ['PATH'] += py_dll_path

@nicolas-gervais This shouldn't be needed for Python 3.6. Could you please tell me something about your env, like how did you install python, pytorch and torchvision?

I updated my CUDA Toolkit to 10.1 update2 and matching cuDNN to v7.6.5
Collecting environment information...
PyTorch version: 1.4.0
Is debug build: No
CUDA used to build PyTorch: 10.1

OS: Microsoft Windows 10 Pro
GCC version: Could not collect
CMake version: Could not collect

Python version: 3.8
Is CUDA available: Yes
CUDA runtime version: 10.1.243
GPU models and configuration: GPU 0: GeForce GTX 1070
Nvidia driver version: 436.48
cuDNN version: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\bin\cudnn64_7.dll

Versions of relevant libraries:
[pip3] numpy==1.17.4
[pip3] torch==1.4.0
[pip3] torchvision==0.5.0
[conda] blas                      1.0                         mkl
[conda] mkl                       2020.0                      166
[conda] mkl-service               2.3.0            py38hb782905_0
[conda] mkl_fft                   1.0.15           py38h14836fe_0
[conda] mkl_random                1.1.0            py38hf9181ef_0
[conda] pytorch                   1.4.0           py3.8_cuda101_cudnn7_0    pytorch
[conda] torchvision               0.5.0                py38_cu101    pytorch

but I still get the same error.

How to show the Environment?

python -m torch.utils.collect_env

Hello, I also encountered this issue with python3.6, here is my environment:
Collecting environment information...
PyTorch version: 1.4.0+cu100
Is debug build: No
CUDA used to build PyTorch: 10.0
OS: Ubuntu 18.04.4 LTS
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
CMake version: Could not collect
Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: Could not collect
GPU models and configuration:
GPU 0: Tesla P100-PCIE-16GB
Nvidia driver version: 384.130
cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.3
Versions of relevant libraries:
[pip3] numpy==1.18.2
[pip3] torch==1.4.0+cu100
[pip3] torchvision==0.5.0
[conda] Could not collect

I encountered the same issue in pytorch 1.5
I installed pytorch from source (tag v1.5.0), torchvison form source(master), python version is 3.6

torch.ops.torchvision.nms
op = torch._C._jit_get_operation(qualified_op_name)
RuntimeError: No such operator torchvision::nms

I also encountered the same error with PyTorch-1.5.0 and torchvision-0.5.0. Below are the details of my environment.
Collecting environment information...
PyTorch version: 1.5.0
Is debug build: No
CUDA used to build PyTorch: 10.2
OS: CentOS Linux release 7.7.1908 (Core)
GCC version: (GCC) 7.3.0
CMake version: version 3.8.2
Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 10.0.130
GPU models and configuration: GPU 0: Tesla P100-PCIE-12GB
Nvidia driver version: 440.33.01
cuDNN version: Could not collect
Versions of relevant libraries:
[pip3] numpy==1.17.4
[pip3] torch==1.5.0
[pip3] torchvision==0.5.0
[conda] blas                      1.0                         mkl
[conda] cuda80                    1.0                  h205658b_0    pytorch
[conda] mkl                       2019.4                      243
[conda] mkl-service               2.3.0            py36he904b0f_0
[conda] mkl_fft                   1.0.1            py36h3010b51_0
[conda] mkl_random                1.0.1            py36h629b387_0
[conda] pytorch                   0.4.1           py36_py35_py27__9.0.176_7.1.2_2    pytorch
[conda] torchvision               0.2.1                      py_2    pytorch

@yaw91 @plumtus you need to use PyTorch 1.5 together with torchvision 0.6.0, otherwise this won't work.

I am also having the same issue on PyTorch nightly build.
Collecting environment information...
PyTorch version: 1.6.0.dev20200424
Is debug build: No
CUDA used to build PyTorch: 9.2

OS: Ubuntu 18.04.3 LTS
GCC version: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
CMake version: version 3.10.2

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 9.2.88
GPU models and configuration:
GPU 0: Quadro GP100
GPU 1: Quadro GP100

Nvidia driver version: 418.116.00
cuDNN version: Could not collect

Versions of relevant libraries:
[pip] numpy==1.18.1
[pip] torch==1.6.0.dev20200424
[pip] torchvision==0.7.0a0+c031e28
[conda] blas                      1.0                         mkl
[conda] cudatoolkit               9.2                           0
[conda] mkl                       2020.0                      166
[conda] mkl-service               2.3.0            py37he904b0f_0
[conda] mkl_fft                   1.0.15           py37ha843d7b_0
[conda] mkl_random                1.1.0            py37hd6b4f25_0
[conda] numpy                     1.18.1           py37h4f9e942_0
[conda] numpy-base                1.18.1           py37hde5b4d6_1
[conda] pytorch                   1.6.0.dev20200424 py3.7_cuda9.2.148_cudnn7.6.3_0    pytorch-nightly
[conda] torchvision               0.7.0a0+c031e28           <pip>

Solved. In my case the error occurred because I used different machines with different GPUs for building torchvision and running training.
Specifying CUDA compute capability such as TORCH_CUDA_ARCH_LIST="6.0;6.1;7.0" when building torchvision resolved this.

Could you explain how do we can  Specifying CUDA compute capability such as TORCH_CUDA_ARCH_LIST="6.0;6.1;7.0" when building torchvision resolved this?

@ebrahim31 just pass
TORCH_CUDA_ARCH_LIST="6.0;6.1;7.0" python setup.py install

when compiling torchvision.

In Python 3.6 the solution will give the error:

AttributeError: module 'os' has no attribute 'add_dll_directory'

So I solved my issue adding this before importing torch and torchvision:
import os
import sys
py_dll_path = os.path.join(sys.exec_prefix, 'Library', 'bin')
os.environ['PATH'] += py_dll_path

Thank you, it worked for me the same way!

I tried and it is actually a DLL loading problem for Python 3.8. The workground is to add the directory of cuda before importing torchvision using the following code.
import os
import sys
py_dll_path = os.path.join(sys.exec_prefix, 'Library', 'bin')
os.add_dll_directory(py_dll_path)

I get another error that add_dll_directory is not an implemented function of os module.

@yustiks add_dll_directory is only present in Python 3.8+.
In torchvision we have a guard for this see https://github.com/pytorch/vision/blob/b93d5ee2ddcf2a9876b5871cbb958016e263336b/torchvision/extension.py#L27-L34
Please open a new issue if you hit an issue with torchvision

I also encounter the same issue. In my case, nvidia-smi: CUDA 11.0 and I installed pytorch using torchtoolkit 10.1.
So in order to solve, use this command:
conda install pytorch torchvision torchaudio cudatoolkit=11.0 -c pytorch
Hope this helps

I also encounter the same issue. In my case, nvidia-smi: CUDA 11.0 and I installed pytorch using torchtoolkit 10.1.
So in order to solve, use this command:
conda install pytorch torchvision torchaudio cudatoolkit=11.0 -c pytorch
Hope this helps

Install Python 3.7 instead of 3.8 will solve the problem


Removed unnecessary dcos-enterprise-cli installation.

High-level description
Removed unnecessary dcos-enterprise-cli installation.
Corresponding DC/OS tickets (obligatory)
These JIRA ticket(s) must be updated (ideally closed) in the moment this PR lands:

DCOS-54793 Retry Enterprise CLI download in integration test suite.

Related tickets (optional)
Other tickets related to this change:

DCOS- Foo the Bar so it stops Bazzing.

Related dcos-launch and dcos PRs
Is this change going to be propagated up into another repo? Test the change by bumping the dcos-test-utils SHA to point to these changes to test it. Link the corresponding PRs here:
Checklist for all PRs

[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain here:
[ ] Include a test in dcos-integration-tests in https://github.com/dcos/dcos or explain why this is not applicable:
[ ] Include a test in https://github.com/dcos/dcos-launch or explain why this is not applicable:

Integration tests were run and

[ ] Integration Test - Enterprise (link to job: )
[ ] Integration Test - Open (link to job: )

PLEASE FILL IN THE TEMPLATE ABOVE / DO NOT REMOVE ANY SECTIONS ABOVE THIS LINE
Instructions and review process
What is the review process and when will my changes land?
All PRs require 2 approvals using GitHub's pull request reviews.
Reviewers should be:

Developers who understand the code being modified.
Developers responsible for code that interacts with or depends on the code being modified.

It is best to proactively ask for 2 reviews by @mentioning the candidate reviewers in the PR comments area. The responsibility is on the developer submitting the PR to follow-up with reviewers and make sure a PR is reviewed in a timely manner.

@bamarni @cprovencher Can you please review?


Difference plotting

Allow to plot the difference as well, not just the ratio.

Codecov Report

Merging #263 (cae9be7) into master (55fd8af) will decrease coverage by 0.08%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #263      +/-   ##
==========================================
- Coverage   84.83%   84.74%   -0.09%
==========================================
  Files          75       75
  Lines        6226     6236      +10
==========================================
+ Hits         5282     5285       +3
- Misses        944      951       +7

Impacted Files
Coverage Δ

simtools/visualize.py
72.45% <50.00%> (-2.71%)
:arrow_down:

Continue to review full report at Codecov.

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


Added helpers for CassConsistency level

Description
Added two helper functions for determining the next weaker consistency level and also for comparing two consistency levels. This is very useful when the application needs logic to retry a statement at a lower consistency based on previous failure(s).
New functions added:

cass_consistency_level_compare()
cass_next_weaker_consistency_level()

New enum added:

CassOperationType

Note: This is a preliminary PR as i'm not 100% sure where the function definitions belong to. I put them under utils.cpp but they could go in a different location. Also there are no tests yet since I wasn't sure if the PR was going to approved to begin with. I can add some test cases inside test_consistency.cpp if need be.
A much simpler way to deal with this would be to re-arrange the CassConsistency enums in increasing order, but I feel this would break the API and there might be implementations out there relying on the current hard-coded values, hence these two helper methods.

Thanks of for the PR, but the ordering of consistency levels is application specific and can't be generalized in this way. For example,
CASS_CONSISTENCY_LOCAL_QUORUM --> CASS_CONSISTENCY_THREE doesn't make sense if the replication factor is less than five and that's pretty uncommon for a data model.

This is very useful when the application needs logic to retry a statement at a lower consistency based on previous failure(s).

Consistency level along with replication factor should be chosen based on the availability and consistency guarantees of your application and shouldn't be lowered based on node outages. For example, if your application's can tolerate the lower consistency of CASS_CONSISTENCY_ONE instead of  CASS_CONSITENCY_QUORUM then use CASS_CONSISTENCY_ONE.

Thanks of for the PR, but the ordering of consistency levels is application specific and can't be generalized in this way. For example,
CASS_CONSISTENCY_LOCAL_QUORUM --> CASS_CONSISTENCY_THREE doesn't make sense if the replication factor is less than six and that's pretty uncommon for a data model.

I agree with this, but just in the same way that the application can determine if the consistency should be lowered to say CASS_CONSISTENCY_TWO or ONE (because the replication factor is less than 6), it can also skip the THREE case if it knows it does not apply. These helpers are not generic across the board, they simply help establish, should the case apply, a guideline for lowering the consistency. An application can always make an improper determination (even today) and run a query at a consistency level which would "make no sense" - such as THREE in your example. That doesn't mean that the API should not allow overriding the consistency on a per-statement basis!

Consistency level along with replication factor should be chosen based on the availability and consistency guarantees of your application and shouldn't be lowered based on node outages.

I understand but this is purely application dependent and can be no more than a guideline. Based on the tests we have conducted and running in production with various outages, some would prefer a different approach, such as gradually lowering the consistency.

Perhaps a sensible thing would be to also pass-in the replication factor used, therefore consistencies which don't apply will be skipped.

Please take a look. The consistency levels should now be properly reported.

These helpers are not generic across the board, they simply help establish, should the case apply, a guideline for lowering the consistency.

I'd prefer not to include this as part of the cpp-driver's public API. As a general-purpose Cassandra/DSE driver we try to provide generic mechanisms for our users and avoid providing policies. The ordering outlined in cass_next_weaker_consistency_level() may work for your specific application, but it will likely not work well for other applications and is counter to our best practice of choosing the lowest consistency level for the specific guarantees of an application's availability/consistency.
Other issue more specific issues:

It's not clear if dc_replication_factor is the local DC or the remote DC(s). From the header docs it seems like it's the replication factor of each DC in the cluster, but not all applications use the same replication factor in all DCs.
Going from EACH_QUORUM --> QUORUM seems pretty dangerous because EACH_QUORUM give you a guarantees about data replicas in the remote DC(s) and with QUORUM all the replicas could happen in the local DC only.
Going from LOCAL_ONE --> SERIAL  is an increase in the consistency level, but the bigger issue is SERIAL is sort of tangential to other read consistency level because it implies the use of lightweight transactions.

Thanks @mpenick for the explanations. My downgrade policy was based on the following document which states that all the levels there are ordered from stronger to weaker.  In any case, based on your comment, are you saying that EACH_QUORUM is NOT a stronger consistency than QUORUM? I'm ok if these are not included in your lib...I'll keep them privately in our app (with changes based on your recommendations), although I would have preferred something more official.


Validate checkboxes with cypress

made the selectors less breakeable
this test is made to test in a localhost environment
To test the test, got to ..\react-vapor\packages\e2eTesting and use npx cypress open command

The tests CAN be in typescript, but they require a new package installed, but as of now, every time i install a package, the whole project explode so i'm gonna put them in JS for now, they can be changed later, but I feel you, typescript is way better.


[incubator/vault] Add service.externalTrafficPolicy value

Its needed for a proper IP address in Vault Audit Log's remote_address field.
Details: https://github.com/sethvargo/vault-on-gke/issues/29
Example (Kibana screenshots):
service.externalTrafficPolicy: Cluster - cluster Node's IP address

service.externalTrafficPolicy: Local - real user's IP address

Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] title of the PR contains starts with chart name e.g. [stable/chart]

@prydonius, @lachie83, can you take a look at this PR?

/assign

Please bump the chart version!

@kvolkovich-sc can you take a look at the outstanding checks?

Hi, can you please resolve the conflict so that we can get his merged?

@kvolkovich-sc, are you still interested in getting this PR merged?


unable to serialize JSON type logs

this is my log
{
"level": "info",
"time": "2024-03-28T10:34:44.345Z",
"req": {
"id": 6,
"method": "POST",
"url": "/xx/xx/xxx",
"query": {},
"headers": {
"x-request-id": "91d4b3e2fcdf23f1c6ccccccccc90cc",
"x-real-ip": "<IP_ADDRESS>",
"x-forwarded-for": "<IP_ADDRESS>",
"x-forwarded-host": "xxxx-sit.xxxx.cn",
"x-forwarded-port": "443",
"x-forwarded-proto": "https",
"x-forwarded-scheme": "https",
"x-scheme": "https",
"x-original-forwarded-for": "<IP_ADDRESS>, <IP_ADDRESS>",
"content-length": "59",
"user-agent": "Dart/3.1 (dart:io)",
"content-type": "application/json"
}
},
"context": "MessageService",
"error": "RESTEASY003210: Could not find resource for full path: https://ccc.ccc.ccc.com/api/v1/users.info?username=cccc",
"msg": "message log"
}
It is a JSON type log data, and my Flow configuration is this.
spec:
filters:
- tag_normaliser: {}
- parser:
key_name: message
parse:
type: json
remove_key_name_field: true
reserve_data: true
- record_transformer:
enable_ruby: true
records:
- app: ${record["kubernetes"]["labels"]["app"]}
- node: ${record["kubernetes"]["host"]}
- namespace: ${record["kubernetes"]["namespace_name"]}
remove_keys: $.kubernetes.labels,$.kubernetes.host,$.kubernetes.namespace_name
globalOutputRefs: []
localOutputRefs:
- output-alies
match:
- select:
container_names: []
hosts: []
labels:
idp.app.logging: 'true'
After being transmitted to Elasticsearch and displayed by Kibana, no logs can be displayed. However, if the Flow out configuration remains unchanged, my logs are
{"name":"John","age":30,"city":"New York","colors":{"first":"red","second":"blue"}}`
In Kibana, logs can be displayed and serialized.
{ "_index": "uat-2024-03", "_type": "_doc", "_id": "xxx", "_version": 1, "_score": null, "_source": { "stream": "stderr", "logtag": "F", "kubernetes": { "pod_name": "ginoneuat-xxxx-q8ht2", "pod_id": "b146652", "container_name": "ginoneuat", "docker_id": "b6f8c3cc", "container_hash": "xxxx", "container_image": "/go/goone:v15" }, "name": "John", "age": 30, "city": "New York", "colors": { "first": "red", "second": "blue" }, "app": "ginoneuat", "node": "uat-xxx-worker", "namespace": "idp", "@timestamp": "2024-03-28T23:30:14.336201933+00:00" }, "fields": { "@timestamp": [ "2024-03-28T23:30:14.336Z" ] }, "highlight": { "app": [ "@kibana-highlighted-field@ginoneuat@/kibana-highlighted-field@" ] }, "sort": [<PHONE_NUMBER>336 ] }
I confirm that I only modified the content of the logs and did not change any other configurations. Could you please help me understand why my actual system logs are not being displayed? Thank you!

my logging-operator version is v103.0.0+up3.17.10, installed by rancher

you should raise the log level and check the fluentd logs to understand.
also what does this mean?:

However, if the Flow out configuration remains unchanged, my logs are
does it mean you don't configure any filters?


Automated cherry pick of #5111: region: server list by host sn

Cherry pick of #5111 on release/2.13.
#5111: region: server list by host sn

/lgtm

/approve


Edges don't render when nodes are farther away

https://github.com/dagrejs/dagre/assets/3012311/65f8dda6-02fb-4997-865f-9627de2e752f
The edges between nodes don't render unless the nodes are close enough to each other. Any idea why or if there is a setting I am not using?
This error is thrown in the console:
react-dom.development.js:798 Error: <path> attribute d: Expected number, "M479 1 327.5,L499 1 327.5,L 5…".

Dagre Graph object:
{
  "_isDirected": true,
  "_isMultigraph": false,
  "_isCompound": true,
  "_label": {
    "rankdir": "LR",
  },
  "_nodes": {
    "node-north_tcp_server": {
      "width": 450,
      "height": 100
    },
    "node-north_http_server": {
      "width": 450,
      "height": 100
    },
    "node-north_wss_tls_server": {
      "width": 450,
      "height": 100
    },
    "node-north_mqtt_server": {
      "width": 450,
      "height": 100
    },
    "node-north_mqtts_tls_server": {
      "width": 450,
      "height": 100
    },
    "node-north_ws_server": {
      "width": 450,
      "height": 100
    },
    "node-north_mqtt_kafka_mapping": {
      "width": 450,
      "height": 100
    },
    "node-north_kafka_cache_client": {
      "width": 450,
      "height": 100
    },
    "node-south_kafka_cache_server": {
      "width": 450,
      "height": 100
    },
    "node-south_kafka_client": {
      "width": 450,
      "height": 100
    },
    "node-south_tcp_client": {
      "width": 450,
      "height": 100
    }
  },
  "_in": {
    "node-north_tcp_server": {},
    "node-bindings-group": {},
    "node-north_http_server": {
      "node-north_tcp_server\\u0001node-north_http_server\\u0001\\u0000": {
        "v": "node-north_tcp_server",
        "w": "node-north_http_server"
      },
      "node-north_wss_tls_server\\u0001node-north_http_server\\u0001\\u0000": {
        "v": "node-north_wss_tls_server",
        "w": "node-north_http_server"
      }
    },
    "node-north_wss_tls_server": {
      "node-north_tcp_server\\u0001node-north_wss_tls_server\\u0001\\u0000": {
        "v": "node-north_tcp_server",
        "w": "node-north_wss_tls_server"
      }
    },
    "node-north_mqtt_server": {
      "node-north_tcp_server\\u0001node-north_mqtt_server\\u0001\\u0000": {
        "v": "node-north_tcp_server",
        "w": "node-north_mqtt_server"
      },
      "node-north_mqtts_tls_server\\u0001node-north_mqtt_server\\u0001\\u0000": {
        "v": "node-north_mqtts_tls_server",
        "w": "node-north_mqtt_server"
      },
      "node-north_ws_server\\u0001node-north_mqtt_server\\u0001\\u0000": {
        "v": "node-north_ws_server",
        "w": "node-north_mqtt_server"
      }
    },
    "node-north_mqtts_tls_server": {
      "node-north_tcp_server\\u0001node-north_mqtts_tls_server\\u0001\\u0000": {
        "v": "node-north_tcp_server",
        "w": "node-north_mqtts_tls_server"
      }
    },
    "node-north_ws_server": {
      "node-north_http_server\\u0001node-north_ws_server\\u0001\\u0000": {
        "v": "node-north_http_server",
        "w": "node-north_ws_server"
      }
    },
    "node-north_mqtt_kafka_mapping": {
      "node-north_mqtt_server\\u0001node-north_mqtt_kafka_mapping\\u0001\\u0000": {
        "v": "node-north_mqtt_server",
        "w": "node-north_mqtt_kafka_mapping"
      }
    },
    "node-north_kafka_cache_client": {
      "node-north_mqtt_kafka_mapping\\u0001node-north_kafka_cache_client\\u0001\\u0000": {
        "v": "node-north_mqtt_kafka_mapping",
        "w": "node-north_kafka_cache_client"
      }
    },
    "node-south_kafka_cache_server": {
      "node-north_kafka_cache_client\\u0001node-south_kafka_cache_server\\u0001\\u0000": {
        "v": "node-north_kafka_cache_client",
        "w": "node-south_kafka_cache_server"
      }
    },
    "node-south_kafka_client": {
      "node-south_kafka_cache_server\\u0001node-south_kafka_client\\u0001\\u0000": {
        "v": "node-south_kafka_cache_server",
        "w": "node-south_kafka_client"
      }
    },
    "node-south_tcp_client": {
      "node-south_kafka_client\\u0001node-south_tcp_client\\u0001\\u0000": {
        "v": "node-south_kafka_client",
        "w": "node-south_tcp_client"
      }
    }
  },
  "_preds": {
    "node-north_tcp_server": {},
    "node-bindings-group": {},
    "node-north_http_server": {
      "node-north_tcp_server": 1,
      "node-north_wss_tls_server": 1
    },
    "node-north_wss_tls_server": {
      "node-north_tcp_server": 1
    },
    "node-north_mqtt_server": {
      "node-north_tcp_server": 1,
      "node-north_mqtts_tls_server": 1,
      "node-north_ws_server": 1
    },
    "node-north_mqtts_tls_server": {
      "node-north_tcp_server": 1
    },
    "node-north_ws_server": {
      "node-north_http_server": 1
    },
    "node-north_mqtt_kafka_mapping": {
      "node-north_mqtt_server": 1
    },
    "node-north_kafka_cache_client": {
      "node-north_mqtt_kafka_mapping": 1
    },
    "node-south_kafka_cache_server": {
      "node-north_kafka_cache_client": 1
    },
    "node-south_kafka_client": {
      "node-south_kafka_cache_server": 1
    },
    "node-south_tcp_client": {
      "node-south_kafka_client": 1
    }
  },
  "_out": {
    "node-north_tcp_server": {
      "node-north_tcp_server\\u0001node-north_http_server\\u0001\\u0000": {
        "v": "node-north_tcp_server",
        "w": "node-north_http_server"
      },
      "node-north_tcp_server\\u0001node-north_wss_tls_server\\u0001\\u0000": {
        "v": "node-north_tcp_server",
        "w": "node-north_wss_tls_server"
      },
      "node-north_tcp_server\\u0001node-north_mqtt_server\\u0001\\u0000": {
        "v": "node-north_tcp_server",
        "w": "node-north_mqtt_server"
      },
      "node-north_tcp_server\\u0001node-north_mqtts_tls_server\\u0001\\u0000": {
        "v": "node-north_tcp_server",
        "w": "node-north_mqtts_tls_server"
      }
    },
    "node-bindings-group": {},
    "node-north_http_server": {
      "node-north_http_server\\u0001node-north_ws_server\\u0001\\u0000": {
        "v": "node-north_http_server",
        "w": "node-north_ws_server"
      }
    },
    "node-north_wss_tls_server": {
      "node-north_wss_tls_server\\u0001node-north_http_server\\u0001\\u0000": {
        "v": "node-north_wss_tls_server",
        "w": "node-north_http_server"
      }
    },
    "node-north_mqtt_server": {
      "node-north_mqtt_server\\u0001node-north_mqtt_kafka_mapping\\u0001\\u0000": {
        "v": "node-north_mqtt_server",
        "w": "node-north_mqtt_kafka_mapping"
      }
    },
    "node-north_mqtts_tls_server": {
      "node-north_mqtts_tls_server\\u0001node-north_mqtt_server\\u0001\\u0000": {
        "v": "node-north_mqtts_tls_server",
        "w": "node-north_mqtt_server"
      }
    },
    "node-north_ws_server": {
      "node-north_ws_server\\u0001node-north_mqtt_server\\u0001\\u0000": {
        "v": "node-north_ws_server",
        "w": "node-north_mqtt_server"
      }
    },
    "node-north_mqtt_kafka_mapping": {
      "node-north_mqtt_kafka_mapping\\u0001node-north_kafka_cache_client\\u0001\\u0000": {
        "v": "node-north_mqtt_kafka_mapping",
        "w": "node-north_kafka_cache_client"
      }
    },
    "node-north_kafka_cache_client": {
      "node-north_kafka_cache_client\\u0001node-south_kafka_cache_server\\u0001\\u0000": {
        "v": "node-north_kafka_cache_client",
        "w": "node-south_kafka_cache_server"
      }
    },
    "node-south_kafka_cache_server": {
      "node-south_kafka_cache_server\\u0001node-south_kafka_client\\u0001\\u0000": {
        "v": "node-south_kafka_cache_server",
        "w": "node-south_kafka_client"
      }
    },
    "node-south_kafka_client": {
      "node-south_kafka_client\\u0001node-south_tcp_client\\u0001\\u0000": {
        "v": "node-south_kafka_client",
        "w": "node-south_tcp_client"
      }
    },
    "node-south_tcp_client": {}
  },
  "_sucs": {
    "node-north_tcp_server": {
      "node-north_http_server": 1,
      "node-north_wss_tls_server": 1,
      "node-north_mqtt_server": 1,
      "node-north_mqtts_tls_server": 1
    },
    "node-bindings-group": {},
    "node-north_http_server": {
      "node-north_ws_server": 1
    },
    "node-north_wss_tls_server": {
      "node-north_http_server": 1
    },
    "node-north_mqtt_server": {
      "node-north_mqtt_kafka_mapping": 1
    },
    "node-north_mqtts_tls_server": {
      "node-north_mqtt_server": 1
    },
    "node-north_ws_server": {
      "node-north_mqtt_server": 1
    },
    "node-north_mqtt_kafka_mapping": {
      "node-north_kafka_cache_client": 1
    },
    "node-north_kafka_cache_client": {
      "node-south_kafka_cache_server": 1
    },
    "node-south_kafka_cache_server": {
      "node-south_kafka_client": 1
    },
    "node-south_kafka_client": {
      "node-south_tcp_client": 1
    },
    "node-south_tcp_client": {}
  },
  "_edgeObjs": {
    "node-north_tcp_server\\u0001node-north_http_server\\u0001\\u0000": {
      "v": "node-north_tcp_server",
      "w": "node-north_http_server"
    },
    "node-north_wss_tls_server\\u0001node-north_http_server\\u0001\\u0000": {
      "v": "node-north_wss_tls_server",
      "w": "node-north_http_server"
    },
    "node-north_tcp_server\\u0001node-north_wss_tls_server\\u0001\\u0000": {
      "v": "node-north_tcp_server",
      "w": "node-north_wss_tls_server"
    },
    "node-north_tcp_server\\u0001node-north_mqtt_server\\u0001\\u0000": {
      "v": "node-north_tcp_server",
      "w": "node-north_mqtt_server"
    },
    "node-north_mqtts_tls_server\\u0001node-north_mqtt_server\\u0001\\u0000": {
      "v": "node-north_mqtts_tls_server",
      "w": "node-north_mqtt_server"
    },
    "node-north_ws_server\\u0001node-north_mqtt_server\\u0001\\u0000": {
      "v": "node-north_ws_server",
      "w": "node-north_mqtt_server"
    },
    "node-north_tcp_server\\u0001node-north_mqtts_tls_server\\u0001\\u0000": {
      "v": "node-north_tcp_server",
      "w": "node-north_mqtts_tls_server"
    },
    "node-north_http_server\\u0001node-north_ws_server\\u0001\\u0000": {
      "v": "node-north_http_server",
      "w": "node-north_ws_server"
    },
    "node-north_mqtt_server\\u0001node-north_mqtt_kafka_mapping\\u0001\\u0000": {
      "v": "node-north_mqtt_server",
      "w": "node-north_mqtt_kafka_mapping"
    },
    "node-north_mqtt_kafka_mapping\\u0001node-north_kafka_cache_client\\u0001\\u0000": {
      "v": "node-north_mqtt_kafka_mapping",
      "w": "node-north_kafka_cache_client"
    },
    "node-north_kafka_cache_client\\u0001node-south_kafka_cache_server\\u0001\\u0000": {
      "v": "node-north_kafka_cache_client",
      "w": "node-south_kafka_cache_server"
    },
    "node-south_kafka_cache_server\\u0001node-south_kafka_client\\u0001\\u0000": {
      "v": "node-south_kafka_cache_server",
      "w": "node-south_kafka_client"
    },
    "node-south_kafka_client\\u0001node-south_tcp_client\\u0001\\u0000": {
      "v": "node-south_kafka_client",
      "w": "node-south_tcp_client"
    }
  },
  "_edgeLabels": {
    "node-north_tcp_server\\u0001node-north_http_server\\u0001\\u0000": {},
    "node-north_wss_tls_server\\u0001node-north_http_server\\u0001\\u0000": {},
    "node-north_tcp_server\\u0001node-north_wss_tls_server\\u0001\\u0000": {},
    "node-north_tcp_server\\u0001node-north_mqtt_server\\u0001\\u0000": {},
    "node-north_mqtts_tls_server\\u0001node-north_mqtt_server\\u0001\\u0000": {},
    "node-north_ws_server\\u0001node-north_mqtt_server\\u0001\\u0000": {},
    "node-north_tcp_server\\u0001node-north_mqtts_tls_server\\u0001\\u0000": {},
    "node-north_http_server\\u0001node-north_ws_server\\u0001\\u0000": {},
    "node-north_mqtt_server\\u0001node-north_mqtt_kafka_mapping\\u0001\\u0000": {},
    "node-north_mqtt_kafka_mapping\\u0001node-north_kafka_cache_client\\u0001\\u0000": {},
    "node-north_kafka_cache_client\\u0001node-south_kafka_cache_server\\u0001\\u0000": {},
    "node-south_kafka_cache_server\\u0001node-south_kafka_client\\u0001\\u0000": {},
    "node-south_kafka_client\\u0001node-south_tcp_client\\u0001\\u0000": {}
  },
  "_nodeCount": 12,
  "_edgeCount": 13,
  "_parent": {
    "node-north_tcp_server": "node-bindings-group",
    "node-bindings-group": "\\u0000",
    "node-north_http_server": "node-bindings-group",
    "node-north_wss_tls_server": "node-bindings-group",
    "node-north_mqtt_server": "node-bindings-group",
    "node-north_mqtts_tls_server": "node-bindings-group",
    "node-north_ws_server": "node-bindings-group",
    "node-north_mqtt_kafka_mapping": "node-bindings-group",
    "node-north_kafka_cache_client": "node-bindings-group",
    "node-south_kafka_cache_server": "node-bindings-group",
    "node-south_kafka_client": "node-bindings-group",
    "node-south_tcp_client": "node-bindings-group"
  },
  "_children": {
    "\\u0000": {
      "node-bindings-group": true
    },
    "node-north_tcp_server": {},
    "node-bindings-group": {
      "node-north_tcp_server": true,
      "node-north_http_server": true,
      "node-north_wss_tls_server": true,
      "node-north_mqtt_server": true,
      "node-north_mqtts_tls_server": true,
      "node-north_ws_server": true,
      "node-north_mqtt_kafka_mapping": true,
      "node-north_kafka_cache_client": true,
      "node-south_kafka_cache_server": true,
      "node-south_kafka_client": true,
      "node-south_tcp_client": true
    },
    "node-north_http_server": {},
    "node-north_wss_tls_server": {},
    "node-north_mqtt_server": {},
    "node-north_mqtts_tls_server": {},
    "node-north_ws_server": {},
    "node-north_mqtt_kafka_mapping": {},
    "node-north_kafka_cache_client": {},
    "node-south_kafka_cache_server": {},
    "node-south_kafka_client": {},
    "node-south_tcp_client": {}
  }
}

I had the same problem with reactflow.

I had the same problem with reactflow.

@HiChen404 do you think it is a reactflow specific issue? My next plan is to change rendering libraries but want to avoid that work if possible.

@HiChen404 Thank you for the suggestion. That property didn't change anything for me but it did point me in the right direction.
I did find some code in a CustomEdge class that was doing bad math and building impossible edges.


VSCode freezes when closing Cmder as Integrated Terminal on Win10

VSCode Version: 1.41.1
OS Version: Windows 10 1909
Cmder Version: 1.3.13

Steps to Reproduce:
Configure settings.json as per https://code.visualstudio.com/docs/editor/integrated-terminal#_can-i-use-cmders-shell-with-the-terminal-on-windows with:
"terminal.integrated.shell.windows": "C:\\Windows\\System32\\cmd.exe",
"terminal.integrated.shellArgs.windows": ["/K", "C:\\Cmder\\vendor\\init.bat"]

Start Code
Ctrl + ~ to open integrated terminal
Close the terminal via the kill trash can icon without hiding the terminal ever <-- Code is now frozen and requires a reopen

Oddly enough, if you happen to minimize the integrated terminal before restoring it.  If you submit any commands in the terminal prior to trash can killing it, it will freeze Code too. It seems to only work if you hide/unhide the terminal right before killing it with no commands inbetween.

Does this issue occur when all extensions are disabled?: Yes

Duplicate of #71966
With upstreams: https://github.com/microsoft/terminal/issues/1810 & https://github.com/microsoft/node-pty/issues/375


Use new header, first attempt

Working on this with @SharonStrats

The dashboard is not yet working properly in this branch yet.
Requires further debugging.


Eliminate unnecessary leading ::

Another simplification.
The suggested script for CI is a simple one. A relative constant at the top level is resolved against Object, there is no need for :: here, and it is not really idiomatic.
You use :: when you are within some namespace and want to reach a top-level constant avoiding the risk of some other one being found during lookup.
But here, this is simple, you are not in a namespace.

/cc @technicalpickles


Don't execute the gradle-command when no arguments are given

I would like to separate some gradle tasks into their own steps to:

use other actions like gradle-wrapper-validation
allowing to read outputs from gradle into the environment
restricting sensitive env-tokens to specific steps

Separation is already possible if "arguments" only contains "--version". At least the following seems to work fine:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Build
      - name: Set up Java [...]
      - name: cache gradle
        uses<EMAIL_ADDRESS>        with:
          wrapper-cache-enabled: true
          dependencies-cache-enabled: true
          configuration-cache-enabled: true
          arguments: --version
      - name: store some config info in Environment
        run: echo "CONFIG_INFO=`./gradlew -q someConfigInfo`" >> $GITHUB_ENV
      - name: build and push
        env:
          USER: "..."
          TOKEN: "..."
        run: ./gradlew clean jib

It would be :tada: if this action does not force the usage of arguments and by this allowing users to only utilize the excellent caching-mechanism.

Hi @blatobi,
Thank you for your message.
The arguments input is not mandatory. When not specified Gradle is invoked without arguments. In that case it runs the default tasks declared by the build, see https://docs.gradle.org/current/userguide/tutorial_using_tasks.html#sec:default_tasks.
Running with --version will just cache the wrapper, nothing else as the build will not be configured. You could use the :help task instead to cache the build logic dependencies and possibly the build configuration if you are using Gradle's Configuration Cache.
The gradle-wrapper-validation action doesn't run any Gradle command thus is not sensitve to any cache managed by gradle-command-action.
The caches managed by gradle-command-action are reused between GitHub Actions executions. I wouldn't try to have a separate step to prime those cache but instead let the first run do that and subsequent runs profit.
The above being said I don't see any actionable work in this issue so I will close it. Please comment or clarify if I missed something.
Cheers


Add KCSEU2023 spotlight article

Add interview about organising a K8s contributor summit. Discussion and reviews are being done in the contributor-site PR - please add comments there, the final version will then be added here with any corrections that are done:
https://github.com/kubernetes/contributor-site/pull/449

Thanks
/lgtm
/approve


fix new bug that errors out on models with ragged arrays

Code such as:
     Z[t, 1:n_obs_y[t]] <- K[t, 1:n_obs_y[t], 1:n_grid] %*% X[t, 1:n_grid]

is causing an error because in my attempt to generate NaNs when an invalid dynamic index is used, I needed to determine the dimension of the LHS of model declarations, e.g. that y[2,3:7] is one dimension with length 5. I used makeSizeAndDimList(), which was really only intended for use with AD, and it errors out when seeing a ragged array.
In having thought a bit more, I don't think we should ever have a ragged array on the LHS with dynamic indexing on the RHS, since that would mean that as an observation shifted from cluster  to cluster, it  could be using a different number of elements from the RHS var than another observation that was also in the same cluster, e.g.,
y[i, 1:n[i]] ~ dmnorm(mu[k[i], 1:n[i]], ....)

and suppose k[1]=1, k[2]=1, n[1]=3, n[2]=4.
I suppose one could imagine such models, but not clear they make sense. This suggests that we could continue to use makeSizeAndDimList but only call it if we know the BUGSdecl involves dynamic indexing. (Currently we are calling it for every declaration, unnecessarily, since the output of makeSizeAndDimList is only being used for expressions with dynamic indexing.) And then if ragged array is detected we'd error out.
If this is a good path, we need:

to only call makeSizeAndDimList if dynamic indexing is turned on and if BUGSdecl$dynamicIndexInfo is not NULL
have the makeSizeAndDimList ragged array error message be more general to say that one can't use derivatives with ragged arrays (if derivs is enabled) and one can't have dynamically indexed ragged arrays.

Just laying out these initial thoughts. More discussion worthwhile.

also, we clearly need a test that at least minimally uses a model with a ragged array!

@paciorek I don't have the picture fully focused, but here is an idea.
We could make a version of makeSizeAndDimList that does not do the check for ragged arrays, assuming that is only relevant for AD. (Alternatively, we could add an argument to the current makeSizeAndDimList for whether to do the check.)  Would that solve the problem?
I am cautious about deciding that the combination you outlined could never be valid.  We've seen huge creativity in how people write models.  Unless we can prove it could never conceivably be valid, it would be nice to support it.

Fixed by PR #764


Add const references in String class

Using const references against non primitive types is faster. It's only missed in a few places.

Might be good to specify it's just in String and not all String arguments across the codebase, but should be obvious from the diff

Same comment as in your other PR.

Thanks!


add node links

prototype/proposal patch implementing functionality discussed in issue #20 for adding optional links (external and internal) to graph nodes. Link parameters format is similar to the details__ field:
link__{uniquename}__parameter = value

External Links

link__id__url, link__id__title

Internal Links

link__id__expr, link__id__uid, link__id__name, link__id__title

Format Sample
{
  "id": "1",
  "title": "Service1",
  "subTitle": "instance:#2",
  "detail__role": "load",
  "arc__failed": 0.7,
  "arc__passed": 0.3,
  "mainStat": "qaz",
  "link__external__url": "http://some/service",
  "link__external__title": "custom link",
  "link__internal__expr": "rate(traces_service_graph_request_total{server=\"${__data.fields.id}\"}[$__interval])",
  "link__internal__title": "request rate",
  "link__internal__uid": "prometheus"
}

@hoptical any suggestions or feedback? Thanks in advance!

@lmangani Thanks for your contribution and sorry for being very late in sending my feedback. I had a terrible internet connection in my country for months and couldn't investigate further steps of this repo.
BTW, I reviewed your branch and tried to get a run and check if I can see the links or context menu in the graph layout. The context menu wasn't shown yet and the problem was there. Maybe my input JSON wasn't correct.
Would you please send a full sample of the JSON served to the plugin?


Unclear error: unable to find metadata section in Cargo.lock

Describe the bug
Recently, my CI builds have failed with
2020-05-16 15:38:32 [ERROR] unable to find metadata section in Cargo.lock

It sounds like this is https://github.com/EmbarkStudios/cargo-deny/issues/56, but as far as I can tell, this has been resolved & a release published months ago (plus, the same code did run the action correctly before).
To Reproduce

cargo deny config: https://github.com/antifuchs/governor/blob/6eec6f36058faedc5b0be3228d65f7eb8191906d/deny.toml
github ci setup: https://github.com/antifuchs/governor/blob/6eec6f36058faedc5b0be3228d65f7eb8191906d/.github/workflows/cargo_deny.yml

Expected behavior
I would expect cargo deny to correctly parse my Cargo configuration and probably tell me some crate configs are wrong.
CI runs
Here's a failed run: https://github.com/antifuchs/governor/runs/681094137
Additional context / attempt at diagnosis
It looks like this is trying to use the 0.4.2 version of cargo deny: https://github.com/antifuchs/governor/runs/681094137#step:2:30 - but the Dockerfile pulls in 0.6.7! Is something wrong with the way the github action is configured, or is github itself having a hiccup there?

Oooooh oh no. I just saw that I'm configuring it as @v0 instead of a more recent release. Ooops.

We recently did release @v1 so was just about to suggest to try that out and see if this reproduces on it!

This totally fixes things - thanks for the quick follow-up! Also worth noting that dependabot has (alpha) support for github actions, which I've now enabled for this repo (-:

Awesome!


Notify users of privacy concerns when using a custom node

When a user uses a custom node, add a pop up after save that lets them know that they will leak private data at the following points:

viewing transactions via mempool (we can even add a small warning in the tx page if selected node is custom)
subscribing to zero-conf notifications

Currently we do not support zero conf notifications so only notify user about privacy implications of viewing a tx on mempool.
The message can be as follows:
Privacy Notice: Using your own node ensures that no third party can link your IP address, with your transactions.
However, if you view transactions via mempool by clicking your Transaction ID or Recipient Bitcoin Address in the Transaction Details page, this information will be known to BullBitcoin.

Content can be review and updated later.

Fixed in 0.1.96


!$ shortcut doesn't work in terminal , #could .. #should

it should

A duplicate of https://github.com/railsware/upterm/issues/1009