feat(eslint): alphanumeric sorting

Alphanumeric sorting of imports, PropTypes, Component props in JSX, and destructured props.
I'd like to talk about what I think is a very important change and uses a few rules to accomplish and that is alphanumeric sorting throughout.
Every developer has a different idea about what a "logical group" is. I used to group my props by what I thought made logical sense. However, even that thought process evolves, and I found myself looking back at old code and reordering props to match my more recent opinion about it. This created a lot of fragmentation over time.
There's one logical grouping that everyone knows instinctively, and that is alphanumeric. There's no debating it. It's not a matter of opinion that the letter B comes before the letter P, or that 4 is greater than 2. We don't have to think about it. It's automatic.
Alphanumerically sorting imports, props, destructured object properties, (and react hook dependency arrays) results in everything being super easy to find when looking at your and other people's code because it's sorted by a pattern that we all agree on without thinking. The great news is that with the exception of the import sorting rule, the sorting rules are all --fix-able.

This one I could see being part of a eslint-config-amex/strict addon, with more opinionated rulesets.
It would be fun to watch editor autofix with these on.

(Reupping my comment from the closed PR.)
I'm not opposed to this rule in theory, but I have concerns because:
a) it directly contradicts our previous import order rule (which was "builtin", "external", "internal")
b) there is no auto-fix for some reason (why?)
As a practical matter, I'm not sure what the path would be to getting rid of these warnings in every single existing file.

I just looked into it and it looks like the import/order eslint rule has autofix. I will configure it to behave the same and test it.
https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/order.md
As for your previous import order rule, I explained why that ordering is problematic in my post above, but to expand on it a little, I proffer this to you.
If you didn't know what the ordering rule was, and you looked at a file with a lot of imports, how long would it take you to figure out what the ordering was so that you could find the import that you were looking for? I mean, even if you knew what the ordering rule was, how long would it take you to figure it out?
Now, how long does it take you to think about whether B comes before K? Or that 4 is greater than 1? The answer is effectively zero. You don't have to learn and remember the sorting rule. It's your default.

There's no debating it.

I'd like to be careful here. There's no debating the algorithm (well, even then, is it ASCII/UTF code sorted or character sorted? ex: a,à,b or a,b,à) but the main debate for using the rule is: is the algorithm useful (to the maintainers of the code)?
The order someone chooses might be based off of dependencies being relevant to each other, if their names start with different letters then the logical association is broken. Currently we're using "builtin", "external", "internal" as @smackfu mentioned to ease identification of what should and should not be installed as a dependency (ex: check out the downloads of fs).

There's no debating it.

I'd like to be careful here.

Let me be clear about this point.
There's no debating that human beings know that 4 is greater than 1. You don't have to think about it.
There's no debating that human beings who use the English alphabet know the order of letters in the alphabet A through Z. In order to write Javascript, you have to write in English even if your native tongue uses a different alphabet.
Any concerns about proper ordering of unicode characters with accents in the context of this rule are unfounded. Using extended unicode characters for variable names in Javascript is a no-no.
You do not have to think about alphanumeric. It's automatic.
As far as imports are concerned, you have to think about what is internal and external, but more importantly, how is that grouping relevant? I would argue that it's not. It really doesn't matter if the code you're importing comes from a node_modules export or one of your own. You needed that function so you imported it. You use it like any other Javascript, there's no special treatment. So grouping by that classification doesn't impart any value and is therefore arbitrary.
As far as ordering by relevancy, what does it meant to be relevant? It's circumstantial. And what's relevant to you while you're writing it may not be relevant to somebody else (or future you) when reading it.
This rule, for me, is about making code consistently readable and reducing unnecessary refactoring. The need to quickly find what you're looking for in your or other people's code. Logical relevance is a matter of opinion. Alphanumeric is not.
What seems logical right now might change tomorrow or a week from now. Rather than reorder things in the future based on what is logical at that time, alphanumeric means I don't need to worry about reordering in the future. It saves unnecessary refactoring, which makes code reviews and git diffs easier.
Believe me, I empathize with the desire to order by logical relevance. I still sometimes want to group like that. But, I know through experience in using this methodology that alphanumeric ordering applied consistently throughout code makes it much easier for myself and others to quickly be able to read code and find what I'm looking for and results in less "fiddling" with stuff that doesn't really matter.


use docker run, but http://localhost:8080/ is not work.

docker run -p 8080:80 -p 8443:443 -p 102:102 --name softplc fbarresi/softplc:latest-linux
Initializing plc service...
plc server started on port 102!
info: Microsoft.Hosting.Lifetime[14]
Now listening on: http://[::]:8080
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
Content root path: /app
but use browser to http://localhost:8080/  not work. can't see anything.

You should run
docker run -p 8080:8080 -p 8443:443 -p 102:102 --name softplc fbarresi/softplc:latest-linux

Since the internal server is listening on port 8080, you should bind to it.


Adds GH actions

Changes made:

Adds two GitHub Actions:

One workflow (lint) checks if the source code (bioprov/) is black formatted
The other workflow (tests) tests the package using pytest in python 3.6-3.8 in ubuntu and macOS

Makes some changes to the way badges are displayed in the README

This is mostly dumb cosmetic stuff and I'd be happy to revert it if you don't like it.

The badges for the actions are not showing up yet just because they aren't in your master branch, but they should show up after the merge.

Looks good to me, thanks @jvfe !


Why delete the interface SSL_CTX_set_tmp_ecdh_callback, which interface replaces it?

Why delete the interface SSL_CTX_set_tmp_ecdh_callback, which interface replaces it?

It is still there, as a macro.  To update your code, look at the CHANGES file.

It is still there, as a macro.

To be precise, SSL_{CTX}_set_tmp_ecdh() is (and was) a macro wrapping a SSL_CTX_ctrl(...) call (but the implementation changed in 6977e8ee4a718a76351ba5275a9f0be4e530eab5). The functions SSL_{CTX}_set_tmp_ecdh_callback() were removed in 6f78b9e824c053d062188578635c575017b587c5, see CHANGES, 1278-1274.

To answer the original question, per that CHANGES entry, you should use SSL_{CTX_}set1_curves and configure your curve preferences with OpenSSL. SSL_CTX_set_tmp_ecdh_callback doesn't interact with TLS negotiation correctly and can result in connection failures.


Fix for WFLY-14279, Failing bootable EE9 microprofile-tck tests

Issue: https://issues.redhat.com/browse/WFLY-14279
Make sure to use wildfly-preview FP.

https://ci.wildfly.org/viewLog.html?buildId=237267&tab=buildResultsDiv&buildTypeId=WF_Ee9BootableJarLinuxJdk8 passed and the regular CI runs (which are irrelevant really) are passing so I'm going to merge this.

https://ci.wildfly.org/viewLog.html?buildId=237267&tab=buildResultsDiv&buildTypeId=WF_Ee9BootableJarLinuxJdk8 passed and the regular CI runs (which are irrelevant really) are passing so I'm going to merge this.


Automatically load startup data when netopeer2-serer is started

Hi All,
how to enable automatically load startup data when netopeer2-serer is started ?
Thanks in adavance

That is not possible, startup DS is automatically copied to running DS only after machine boot. After that it must be performed manually.

Ok Thanks @michalvasko for help
Got This


Julia

There have been some changes in the organization of ValidatedNumerics.jl, including a Julia organization for everything related to Intervals (JuliaIntervals). Currently, ValidatedNumerics.jl is a meta-package which involves other functionality (still under development), while IntervalArithmetics.jl has the basic implementation related to interval arithmetic. This PR reflects those changes.
Yet, I would like to wait for https://github.com/JuliaIntervals/IntervalArithmetic.jl/pull/57 be merged before merging this.
CC: @dpsanders

Incidentally, I noticed that there are new functions (expm1, log1p, etc) included, though it seems that they are not tested...


Support Logging Exclusions

The recent PR #1804 updated the Logging GAPIC/Protobuf code and added a new resource and API calls for exclusions. Should exclusions be supported in the high-level Ruby API?
The PR also added the following new values to existing resources:

HttpRequest#protocol
LogEntry#receive_timestamp

Moving to wiki/Feature-backlog since this request is now more than 180 days old.


Links in docs/integrate are 404'ing

(Original issue 1134 created by jeffwidman on 2015-08-06T00:22:28.917649+00:00)
https://bitbucket.org/birkenfeld/pygments-main/src/1835fdd773a43477c51d5d4242ffee03e65aa15a/doc/docs/integrate.rst?at=default
The top two articles about integrating with GTK and Wordpress lead to 404's.
Happy to submit a PR to fix, but wasn't sure of best solution:

delete the links

point to the archive.org version of the links

find new articles relevant to the topics and replace old links with the new links

I'd probably just go with number 1 for simplicity, as users are used to googling for how to integrate. Also, google will generally provide better answers, since integrations are dependent not only on pygments but also on a third-party, any information that gets linked to could become outdated at any time without pygments having ever changed.

(Original issue was assigned to birkenfeld)

(Original comment by tshatch on 2015-10-17T01:55:07.012256+00:00)
I think Georg voted for deleting, but I'll let him handle it.

(Original comment by birkenfeld on 2015-10-17T05:46:12.156904+00:00)
Closes #1134: remove nonworking links from docs/integrate
→ <<cset 61b80f8c1df7>>


Add documentation for using git inside docker container

Description
Add relevant instructions for developers in order to contribute to PyBaMM (setting up git configuration, setting a git remote
Fixes # (issue)
Type of change
Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #) - note reverse order of PR #s. If necessary, also add to the list of breaking changes.

[ ] New feature (non-breaking change which adds functionality)
[ ] Optimization (back-end change that speeds up the code)
[ ] Bug fix (non-breaking change which fixes an issue)

Key checklist:

[ ] No style issues: $ pre-commit run (or $ nox -s pre-commit) (see CONTRIBUTING.md for how to set this up to run automatically when committing locally, in just two lines of code)
[ ] All tests pass: $ python run-tests.py --all (or $ nox -s tests)
[ ] The documentation builds: $ python run-tests.py --doctest (or $ nox -s doctests)

You can run integration tests, unit tests, and doctests together at once, using $ python run-tests.py --quick (or $ nox -s quick).
Further checks:

[ ] Code is commented, particularly in hard-to-understand areas
[ ] Tests added that prove fix is effective or that feature works

Related to #3312

@agriyakhetarpal any ideas why the readthedocs check is not running on this PR?

Given that the readthedocs workflow is a required check, we cannot merge this PR (GitHub won't allow us). Maybe @tinosulzer can bypass the rule and merge this in.

Makes sense. If required we could trigger another build if someone pushes a further commit or rewrites the commit history


stream_cat io priority config

enable configurable io priority for stream cat. e.g. ensure writeback has a higher priority

commited --io-priority in stream_cat


WIP JAV-90 fixed manager

Coverage remained the same at 93.75% when pulling 4c64e805574604916eaeba482aa9532bc7bcaef7 on JAV-90_fix_manager into 20efafa4f55166578c4324456113c2e7461dd864 on master.


why is apple clangd an intel application?

I'm using MacBook Pro M1. When I use the builtin apple clangd, from activity monitor I see it's an intel application. Why is it not an apple arm64 application?

it's because I'm using an intel terminal application...


Reason behind starting service in container start?

I'm wondering what the reason behind putting the start of the SQL Server service in the container startup is, versus having it already running within the image itself?

Are you referring to the Windows container images?

Yes I am.

OK, SQL Server on Windows has been something that has run as a Windows service primarily for a long time.  It wasnt really designed to run as a process except for a few specific troubleshooting and configuration scenarios.  For now it runs as a Windows service because "that's how it's always been".  The SQL Server on Linux images have SQL Server running as a process as you would expect.  As we come around to investing more in SQL Server in Windows containers at some point we will change it to be a process-based container image there too.


fix(core): Fix some NPEs in validation and config generation

fix(core): Fix some NPEs in validation and config generation
In a few places in the config validation and translation we were dereferencing a potentially nil pointer. This happens when we we need to reach more than a level deep in the HalConfig and that top-level field is nil.
A while back we discussed how to handle this, and considered seeing if we could deserialize as values instead of pointers so we could always rely on the zero value. But if I recall we decided against that because:
(1) It is actually useful to have the nil value because it indicates something was not present in the config and should not be serialized to the service config
(2) This problem will only happen in cases where we're reaching into the hal config, so the amount of places we need to do this nil check should be reasonable.
Looking at the generated protos, it looks like there are actually nil-safe accessor generated. If you call x.GetY() it will first check if x is nil, and if so return nil; if not it will return x.y. This took a minute for me to wrap my Java brain around, because the (bad) analogy is basically an instance method on an object checking whether the object is nil. But somehow this works for receivers (I guess because type inference means we know the type of the receiver so which function to call, and we just get the receiver as a possibly-nil object). But this is really nice because it lets you write nil-safe chains as x.GetY().GetZ() that return nil at the end if anything was nil but never throw a nil-pointer panic.
Also add some test to the validation and parsing modules to validate correct behavior in various edge cases (empty hal config, hal config with providers field but no providers, etc.)

refactor(core): Standardize on using pointers
For a while we weren't sure whether to pass by value or by reference. Given that we're passing around structs whose nested fields are all themselves passed around by reference, it seems logical to do the same at the top level (as it's confusing that the top-level thing is sometimes passed around by value).
This also resolves a bunch of 'go vet' warnings because the generated structs contain a mutex somewhere, which really should not be copied, and generates a warning when we pass these around by value. If I didn't think that it probably makes sense to pass by value anyway I'd probably spend more time seeing if that warning shoudl be suppressed, but given that I think it makes sense anyway to pass by value, let's do that.

This took a minute for me to wrap my Java brain around, because the (bad) analogy is basically an instance method on an object checking whether the object is nil. But somehow this works for receivers (I guess because type inference means we know the type of the receiver so which function to call, and we just get the receiver as a possibly-nil object). But this is really nice because it lets you write nil-safe chains as x.GetY().GetZ() that return nil at the end if anything was nil but never throw a nil-pointer panic

Wow, amazing discovery!
Maybe Typescript optional chaining is a more useful analogy?

If I didn't think that it probably makes sense to pass by value anyway I'd probably spend more time seeing if that warning shoudl be suppressed, but given that I think it makes sense anyway to pass by value, let's do that.

Just want to make sure you meant "reference" instead of value in the last sentence of the second commit; otherwise I understand nothing 🤡

Ha, good catch on my typo---yes I did mean that we should pass by "reference" so you are understanding correctly!


Web console: replace (and remove) old consoles

Fixes #8150
This PR replaces and removes the legacy coordinator and overlord consoles and replaces them with the new console. The new console has been adapted to have smart capability detection with graceful fallback mode when running on services where not all the APIs are available.

Reasons for doing this:

To provide a much better experience to new users with fewer components to understand. This is especially true with coordiantor.asOverlord mode being the new config default.
The old consoles are not maintained and have a lot of "code rot" (the Coordiantor console has 10s of errors thrown in the JS console and the Overlord console uses a five year old version of jQuery with 23 LGTM alerts)
The old consoles do not look good and are not visually consistent with each other.
Fewer dependancies. The old consoles depend on some really old libraries.

I believe that the new console has full functional parity with what it is replacing but if I missed anything speak up and it will be addressed ASAP.

+1000
(not sure if my review counts since i made one of the commits 😜)

@vogievetsky I think this is failing web console UT

On the java side of things, I added a new WebConsoleJettyServerInitializer utility method that takes a ServletContextHandler and sets it up for serving the new web console, so that the same initialization code is now shared between router, coordinator, and overlord.
Additionally, there was a coordinator config that looked like it allowed specifying a custom location for the newer old coordinator console for development purposes, that has been removed.

@clintropolis could you please add these redirects to Jetty:
/index.html -> /unified-console.html
/old-console/index.html -> /unified-console.html
/console.html -> /unified-console.html

@vogievetsky I have added the redirects from the old pages. While doing this I noticed that the 'coordinator' mode actually is not working if the overlord is down, presumably something related to the secret overlord proxy that it has if it is not running in the combined coordinator+overlord mode. Anyway, it makes the coordinator mode non-functional, so I think we need to fix that.

Thanks @clintropolis fixed and pushed.

What is the deal here? What does the notice: key represent and should script/licenses be updated to generate it?

The notice sections are manually maintained, and in fact must be, because we don't automatically include the entire notice, rather the part that is relevant to the code being used by Druid. These parts generate Druids own source and binary NOTICE files at distribution build time, so are really important to be correct and maintained.
I think we  should probably modify the script to indicate to whoever runs it whenever a version of a dependency is updated that had a notice entry so that it can be manually updated. We went through all of the web dependencies as part of previous releases, but whenever we add new dependencies we should ensure that if they have a NOTICE file that the relevant contents make it into licenses.yaml. I don't think this script modification needs to be done as part of this PR, but we should at least preserve (and probably update) the notice entry for tslib.

I edited script/licenses to make sure it preserves the notice and dedupes the libraries

I think given the conversation on<EMAIL_ADDRESS>this is good to go


Add project/domain to context for metric labeling

TL;DR
Add project/domain to context for metric labeling.
Type

[x] Bug Fix
[ ] Feature
[ ] Plugin

Are all requirements met?

[x] Code completed
[x] Smoke tested
[ ] Unit tests added
[ ] Code documentation added
[x] Any pending items have an associated Issue

Complete description
Added this line of code
ctx = contextutils.WithProjectDomain(ctx, wfDeepCopy.GetExecutionID().Project, wfDeepCopy.GetExecutionID().Domain)

Tracking Issue
NA
Follow-up issue
NA

Codecov Report

Merging #130 into master will decrease coverage by 0.01%.
The diff coverage is 0.00%.


LibpodAPI.BuildImage: don't require a name for the new image

When we finish building an image, we try to look up its ID by looking up the image using the name that we were asked to assign to the image.  If we weren't asked to assign a name to the image, that would produce an error.  The BuildImage() API we're using returns the image's ID anyway, so we can skip the lookup and just return the ID directly.

LGTM

LGTM

/approve

/lgtm


sendcoins erroring out

Background
Describe your issue here.
Cannot send funds on chain.
Your environment

version of lnd commit hash ed2b5692a23821c43ce686fced4c25904355453a

which operating system (uname -a on *Nix) x86_64 GNU/Linux

version of btcd, bitcoind, or other backend:tom btcd

any other relevant environment details

Steps to reproduce
Tell us how to reproduce this issue. Please provide stacktraces and links to code in question.
I have an un-broadcasted pending open channel:
{
"channel": {
"remote_node_pub": "030a7edba83a52414807aaf46f1c6efc6ff87994b6328d503a785a56c753648c57",
"channel_point": "7043005938fc3cffe382aad2fb10d4f77330286c5ad3b06706e35cd58bd608da:0",
"capacity": "11555792",
"local_balance": "11554525",
"remote_balance": "0"
},
"confirmation_height": 0,
"commit_fee": "1267",
"commit_weight": "600",
"fee_per_kw": "1750"
}
],
lncli sendcoins --sat_per_byte 1 32rAsENdG4damhGoQ1gptuqAe3rDi2k5AG 16233000
[lncli] rpc error: code = Unknown desc = -22: TX rejected: orphan transaction 2fb6145958b993557ef103cad36adca30b9d6312861f6e766271da9256030608 references outputs of unknown or fully-spent transaction 61d4d996361583571dd10fcf635d695e7356c2595a24f9a838a918577ed383c1
Expected behaviour
Tell us what should happen
Actual behaviour
Tell us what happens instead

What chain backend are you using? On start up, do you see that channel attempted to be re-broadcast?

btcd, still using your fork.
And yeah.
Here's some startup logs.
https://paste.ubuntu.com/p/NnGHFrFKN5/
I see it inserting unconfirmed every startup, but it may be referencing already spent inputs as well?
And as you can see lnd attempts to broadcast a load of other transactions long confirmed.
The negative ones being from the small channels that I need to forget once there's an forget channel rpc.

2018-06-11 20:06:28.206 [DBG] LNWL: Could not resend transaction c5a9f8f27bb87212d8281e392e30baf41a174077acb015ffeeea6349b1147ec0: -22: TX rejected: transaction already exists

Ah ok, I see which error we're missing from btcd now, will be an easy fix, I can actually send you a patch for my fork to apply, as we want to switch over to btcsuite/btcwallet this week.

Actually, "already exists" is fine. That just means that the transaction is already in the mempool of the node.

Ran:
cd $GOPATH/src/github.com/roasbeef/btcwallet/cmd/dropwtxmgr
dropwtxmgr --db ~/.lnd/data/chain/bitcoin/mainnet/wallet.db
Rescanned all wallet transactions and can send funds fine now. I just have the two lingering pending open channels referencing already spent outputs.

Cool, so will close this for now, but make a new issue to ensure that we remove these pending channels if we fail to actually broadcast the final funding transaction.


added ide directories to gitignore

added ide directories to gitignore

This was one of the first things I did when I started contributing but was shown another way
Have a look at this PR that was rejected
https://github.com/django/djangosnippets.org/pull/116
A good option is to use .git/info/exclude
If you need to exclude files such as those generated by an IDE, use
$GIT_DIR/info/exclude or the core.excludesFile configuration variable as
described in https://git-scm.com/docs/gitignore


Python: Number of Squares in an N * N Grid

In Cpp - https://github.com/Py-Droid/Edabit-Solutions/issues/16
Before jumping into Pr first comment for assign.
Create a function that calculates the number of different squares in an n * n square grid. :
https://edabit.com/challenge/ncqFJAp4bBiGwfBcg :
Choose one Category - Easy
question category : Math

Before submitting a PR please Check some details.

[x] fileName formet should be in camelcase
example- returnTheNextNumber.py
[x]  Choose label for Problem , example- "good first issue", "easy"
[x]  In file there should be problem statement and link to problem

'''
Problem-Task : This program will add two numbers
Problem Link : https://edabit.com/challenge/SFzHtm63XT6EYNHWY
'''
def main():
    return a + b

This repository is vaild for HacktoberFest2020
Read before making PR - How to contribute on Github
Good Luck,

@aayushi-droid Can I work on it?

[✓ ]  Tasl Assigned
@jayanthj737

#21 @aayushi-droid

A quick doubt how to get the PR done in the same issue itself?

Delete .DS_Store as mentiond

add, commit and push it will get automaticlly to PR

Done yeah!


VQE energy evaluation is not simulating sampling error

Information

Qiskit Aqua version: '0.8.0.dev0+06f3958'
Python version: 3.6.8
Operating system: Ubuntu 18.04

What is the current behavior?
When calling VQE._energy_evaluation for a fixed set of parameters, the same energy value is returned
Steps to reproduce the problem
import numpy as np
from qiskit import Aer
from qiskit.circuit.library import RealAmplitudes
from qiskit.quantum_info.operators import Pauli
from qiskit.aqua import QuantumInstance
from qiskit.aqua.algorithms import VQE
from qiskit.aqua.components.initial_states import Zero
from qiskit.aqua.components.optimizers import SPSA
from qiskit.aqua.operators.primitive_ops import PauliOp

quantum_instance = QuantumInstance(Aer.get_backend('qasm_simulator'), shots=100)
var_form = RealAmplitudes(num_qubits=2, reps=1, entanglement='linear', initial_state=Zero(2))
paulis = Pauli(label='ZZ')
vqe = VQE(PauliOp(paulis), var_form, SPSA(max_trials=10), initial_point=np.zeros(4), quantum_instance=quantum_instance)
results = vqe.compute_minimum_eigenvalue()
print(results)
optimal_point = results['optimal_point']
energies = []
for i in range(10):
    energies.append(vqe._energy_evaluation(optimal_point))
print("Estimated variance: {}".format(np.var(energies)))

What is the expected behavior?
When using QasmSimulator, I expect noise in the energy evaluation, at least due to sampling error. I expect the estimated variance to be larger than machine precision.
Suggested solutions
Make sure that VQE is not caching the circuit evaluations?

Hey Stuart - in the new Aqua we use the Aer Snapshot Expectation by default for improved performance, which has zero variance because it works by statevector matrix multiplication. To use shot-based expectations, add the following expect argument to VQE:
from qiskit.aqua.operators import PauliExpectation

vqe = VQE(PauliOp(paulis),
                   var_form,
                   SPSA(max_trials=10),
                   expect=PauliExpectation(),
                   initial_point=np.zeros(4),
                   quantum_instance=quantum_instance)

Let me know if that works!

Yep, that does it! Thanks


etcdserver: not reuse connections for peer transport

etcd uses timeout listener, and times out the accepted connections
if there is no activity. If we use idle connections in
transport, the connection may have timed out, and return error when
doing any request. So we do not reuse connections.
This fixes the problem that etcd fail to get version of peers.
fixes #3723

Why does it work previously? The peer listener has always been time out one, no?

Why does it work previously?

The peer transporter was a timeout transport, which sets maxIdleConnections as -1 for itself.

The peer listener has always been time out one, no?

yes

then why do not create a timeout transport instead? also can you please fix all the transport that works with peer url?

then why do not create a timeout transport instead?

it doesn't need read timeout and write timeout in connection because it is not a stream. I could create a timeout transport with no read/write timeout though.

@yichengq

it doesn't need read timeout and write timeout in connection because it is not a stream.

Why only stream can have read/write timeout?

Why only stream can have read/write timeout?

The read/write timeout has the assumption that following reads/writes will happen soon.
And it is general to use request timeout or ResponseHeaderTimeout instead of read/write timeout for HTTP request IMO.

The read/write timeout has the assumption that following reads/writes will happen soon.
And it is general to use request timeout or ResponseHeaderTimeout instead of read/write timeout for HTTP request IMO.

I do not think you are solving the root problem. The root reason is that the underlying listener for peer http is a timeout listener. It expects the transport to send/recv fast and never reuse the connection. We built the other pair of transport for it already. We really should just use it instead of creating something new with some new reasons.
Please use the correct pairs of transport/listener. Thanks.

We built the other pair of transport for it already.

ok. They are used as a pair.
So I changes to use timeoutTransport, and fixes other transport that has the same problem. PTAL.

Per xiang's suggestion, we want to avoid the same bug in the future.
New commit moves the code to create listener and transport for peer communication
at the same place, and use explicit functions to build them. This prevents
possible development errors in the future.

I changed the function name to NewHTTPTransport because it returns a HTTP transport to do request targeting remote rafthttp listener.
We thought about the idea that makes the new function named NewTransport, and changes the naming of existing Transport struct. But that is a super time-consuming one, so I would like to give the new function a different name.
PTAL.

@xiang90 points out that NewHTTPTransport still may bring confusing considering rafthttp has Transport struct already. I am targetting to return RoundTripper instead.

@xiang90 Changed it to NewRoundTripper and this eliminates confusion of duplicate Transport word. PTAL.

Based on discussion OOL, moved new functions into util.go and add comments about 0 read/write timeout.

LGTM


docs: Update repository README

Specifically, updates notes about build requirements around node-gyp and Execution Policy on Windows.

These notes are based on issues I ran into on a fresh dev environment, that were not immediately apparent reading the onboarding docs.
I would love any feedback about how and where I have added these, or any other docs that you can think of that should be updated alongside the README.


Source Code Editor: scrollbars are covered by the text area

Describe the bug
see screenshot
To Reproduce
Steps to reproduce the behavior:

Open the "Edit" menu (far left in the corner)
Go to 'open source code editor'
Make your window smaller, so that the vertical and the horizontal scrollbars appear
scroll until you observe what is in the screenshot

Expected behavior
Scrollbars should be outside the text area
Screenshots

Ubuntu Chrome + Firefox, others not tested yet

Can you show me the file to work on this.

i am a beginner cna i work on this issue ? can you  tell me from where should i start

I would like to work on this issue. Actually, I am an open-source enthusiast but I am new in this field. So, can you please guide me on how to understand the codebase and exactly how to make my contribution here?

@CarefoDragneel , it seems to be an issue of bad / wrong css, Are you familiar with debugging in a browser? That might help a lot

i am interested can you assign this issue to me

works as expected


Directives handling for #47, #48, #49, #50

Drafting this one early in case there are any comments on the implementation, to be able to handle these early.
It's still a work in progress, all changes to the generator of actually pushing directives from the original schema, to the api-schema is still missing etc..
Ignore the white space changes, VS went dumbmode when I copied code between files, and I will try to revert those changes later...
The interesting part for now, is the function at the very button; addPostCodeDirectivesForTypes. This function will be responsible for enforcing all directives, at the very end of any transaction.  This will allow the user to do some very strange things during the actual transaction, as long as the results are consistent. I.e. a user may temporary create something that breaks the @noloops directive, as long as they change it to not break it later, during the same transaction. It may not really make sense now, but it may become useful once #52 is done.
ctxt.trans.postCode is, just like .code, a simple string array, that is appended at the very end of .code, just before the transaction is executed.
Using this approach we do not have to push the directives to any input fields, as suggested in e.g. https://github.com/LiUGraphQL/woo.sh/issues/47#issuecomment-627230501 (which I would otherwise have agreed with). Instead we can keep the directives at the fields they are defined on.
This might not be the simplest approach, checking the inputs of a mutation is probably easier, but this approach should never fail, and it gives us/the user the greatest flexibility as we only enforce the directives at the very end.
@hartig

It is great to see that you are looking at the issue with the broader picture in mind! (..namely, that the constraints should not be checked on a per operation basis but, instead, at the end of the whole transaction.)
I have only two comments at this point:

You say that by "using this approach we do not have to push the directives to any input fields [...] Instead we can keep the directives at the fields they are defined on." Proposing to copy them to the input types in the API schema rather than to the object types was deliberate. From the perspective of an API, the constraints are relevant only for the mutations but not for the queries. Hence, for the object types in the API schema (which specify what can be asked for in queries), the constraints are irrelevant. In contrast, they are relevant for the input types that are used in the mutations. That's why I want the constraints-related directives from a type in the DB schema to be carried over to the corresponding input types in the API schema rather than to the corresponding object type.

A minor thing:  The name "postCode" is a bad choice for two reasons: First, it reminds me of the English word postcode (a short form for postal code). Second, this name does not explicitly capture what this code is about. I think a better name would be finalConstraintChecks.

On your point 1:
While I in theory do agree with you  that it makes more sense to have the directives on the input types instead of the object types, it is easier in practice to keep them at the object types. Firstly our calls to create, update etc. contains returnType and the functions uses returnType for all type and interface checks anyway. Secondly we don't have direct access to the _InputTo... types, only direct access to the objects and implicite access to the input types. So we would have to interpret the _InputTo... type from returnType in any case. This becomes even more apparent for recursive calls to create. Thirdly we would have to have different interpreters for updates and creates, as the input types differ. Only using the returnType and keeping the directives to the object types hence seems neater in practice.
In short: we already break this practice by using the object type instead of the input types to handle everything.

I look at this question from the perspective of a user of GraphQL API generated by woo.sh. As such a user, I would find it strange that the input types which I use when writing my mutation request do not contain any indication of such constraints.
Your argument that we are already using the returnType in the implementation of create, update, etc., is also not totally convincing: It would be very easy to also pass the corresponding input type into these functions. The only thing that would be necessary to do that is to extend the template based on which 'resolvers.js' is generated. For instance, instead of generating the following resolver
createAudioFile: (parent, args, context, info) =>
    driver.create(true, context, args.data, info.schema.getType('AudioFile'), info),

we may generate a resolver that looks as follows:
createAudioFile: (parent, args, context, info) =>
    driver.create(true, context, args.data, info.schema.getType('AudioFile'), info.schema.getType('_InputToCreateAudioFile'), info),

For me this now turned into two (connected but different) questions:

I look at this question from the perspective of a user of GraphQL API generated by woo.sh. As such a user, I would find it strange that the input types which I use when writing my mutation request do not contain any indication of such constraints.

I.e. should the input types contain the directives? They indeed should and it's a good thing you pointed it out. I'd probably not have thought about it otherwise.
Should the object types still contain the (input relevant) directives? In some cases they of course have to be in the object type as well (specifically for @requiredForTarget currently). For the others I don't see any problem if they do. If anything it gives the user slightly more information about the object(s) they are querying

Should we pass the input types to the functions handling the mutations? We don't need to do it unless the object types does not contain the input relevant directives. It's not really an issue, but a matter of convenience.

I see your point, and I agree. Please proceed.

I almost thought I had this one done. Then I reread our earlier discussion and realized that I forgot to push directives onto the input types.
@hartig if you have the time, can you take a quick peek at https://gitlab.com/spirit-tools/arangodb-graphql-server/-/commit/c4f1bd553b8bb78d5d0158fc554ab24500e6a1e3 and see if there is anything that should be different in the formatting of the api-schema.
My biggest question is probably if the @keys directives should still be part of the api-schema.
Note that I have already added changes solving https://gitlab.com/spirit-tools/utils/graphql-schema/-/issues/62 there (I.e. removed some @requiredForTarget directives), but my question about the schema in the discussion of that issue still stands.

Continuing the discussion from before
I look at this question from the perspective of a user of GraphQL API generated by woo.sh. As such a user, I would find it strange that the input types which I use when writing my mutation request do not contain any indication of such constraints.

This actually turned a bit more complicated then I thought. For example @required can't be used on input fields, and hence we can't clearly show that this field is required for say a create mutation.
For the four directives we define ourselves, we would need to mark those as usable on INPUT_FIELD_DEFINITION to be able to have them on the fields of the input types.
So do we still want to do this for all our directives, even though the "standard" ones can't be used in this way? Or do we even want to extend the "standard" directives to be usable on fields of the input types too?

Hi Leif, I am first responding to your remarks and questions in your latest comment above.

For example @required can't be used on input fields, and hence we can't clearly show that this field is required for say a create mutation.

I assume you mean input types rather than "input fields." Then, @required does not need to be carried over to the input types. Instead, in input types, adding the exclamation mark ("!") to the type of a field in an input type means that this is a mandatory field that has to be provided.

For the four directives we define ourselves, we would need to mark those as usable on INPUT_FIELD_DEFINITION to be able to have them on the fields of the input types.

Good point. Yes. While this extended definition of these four directives should not be in the DB schema, it should be in the API schema. Hence, when carrying over the definitions of these four directives, they need to be extended with the INPUT_FIELD_DEFINITION option.
Similarly, the definition of the @key directive has to be extended in a similar way, assuming we want to carry over the given @key directives from the DB schema to the corresponding input types in the API schema.

So do we still want to do this for all our directives, even though the "standard" ones can't be used in this way? Or do we even want to extend the "standard" directives to be usable on fields of the input types too?

Even if I am not sure what you mean by "standard" directives, my answer to the first of these two questions is probably yes.

What about inputs for updates?

All the directives that are carried over to the input types for create operations need to be carried over in the same way also to the input types for the update operations. In this context, note again that @required does not need to be carried over. Instead, this is captured by the exclamation marks, and if you look at the input types generated for the update operations, your will see that there are no exclamation marks.

then we would need something similar for all directives to differ between object field directives and input field directives to clearly indicate what the directives actually mean.

Not sure what you mean here. Can you elaborate this a bit more?

Leif, in your other comment you had one more question:

My biggest question is probably if the @keys directives should still be part of the api-schema.

Yes, I think it makes sense to carry over the @keys directives to the corresponding input types similar to the other of our constraint-related directives.

Even if I am not sure what you mean by "standard" directives, my answer to the first of these two questions is probably yes.
I just mean the four directives that are always available in graphql: @required, @deprecated, @skip and @include.

then we would need something similar for all directives to differ between object field directives and input field directives to clearly indicate what the directives actually mean.

Not sure what you mean here. Can you elaborate this a bit more?

Take the (half bad) example of the @requiredForTarget directive: if some input _inputA which is used to create objects of type A where both A and _inputA has a field marked with a @requiredForTarget directive. Does that mean that the target does actually require an edge from an object off _inputA, or does this directive just mark that the target requires an edge from an object off type A? It might be a bad example, as it's quite clear what we mean in this example. @required directives are actually even more confusing, but we have already said that they do not appear in input types, so that's already solved.
It might very well be a non-issue as of now, as non of the current directives (except @required, which is already handled by not using it for inputs) is open for misunderstanding.

Leif,

I just mean the four directives that are always available in graphql: @required, @deprecated, @skip and @include.

Ah, right, the directives that are defined in the GraphQL spec. By the way, @required is not one of them: http://spec.graphql.org/June2018/#sec-Type-System.Directives

Take the (half bad) example of the @requiredForTarget directive: if some input _inputA which is used to create objects of type A where both A and _inputA has a field marked with a @requiredForTarget directive. Does that mean that the target does actually require an edge from an object off _inputA, or does this directive just mark that the target requires an edge from an object off type A?

Our notions of constraints are defined only for DB schemas not for API schemas. Additionally, input types do not really have a presence in the DB. So, in this sense, I would not worry so much about this question.

(How did I miss that we actually define @required ourselves?)
Olaf,

Our notions of constraints are defined only for DB schemas not for API schemas. Additionally, input types do not really have a presence in the DB. So, in this sense, I would not worry so much about this question.

In the terms of actual implementation there is no issue here. But your earlier comment of

I look at this question from the perspective of a user of GraphQL API generated by woo.sh

is what got me thinking about this. Is it clear for the user what the directive actually means when it's placed on a field in an input type?

Is it clear for the user what the directive actually means when it's placed on a field in an input type?

I would say yes.

Good, then I wont complicate things any further.

No worries. It is good to have these questions asked ;-)

I'm marking this as ready for review (and hence for pending merge) now.
To see actual output format (in the SPIRIT case), see https://gitlab.com/spirit-tools/mediator-service/-/commit/c4f1bd553b8bb78d5d0158fc554ab24500e6a1e3. Note that we currently push basically all directives to both inheriting types, as well as input types.
Issue #55 should be solved by this one (as I had to do some changed to that part anyway), issue #47, #48, #49 and #50 are all partially solved. As some functions are missing (update-edge operations for example), I can not claim that they are completely solved. But adding calls to addfinalDirectiveChecksForType when they are implemented should be enough.
client_tests.js is now stating in the description that it does not handle directives and process.env.DISABLE_DIRECTIVES_CHECKING have been introduced to disable directives checks in driver.js.
I guess we should start with Olaf quickly checking the formatting of the API schema before someone takes the time to do a full review.
@hartig @keski @rcapshaw

Leif, all,
Leif, thanks for your efforts so far. I have looked at the generated API schema and noticed that some things are missing:

Directives are not copied to the relevant input types. For instance, in the DB schema, the type field locations in the type TimelineRegionsInVideoFile has both the @uniqueForTarget directive and the @requestForTarget directive. These directives have been carried over to TimelineRegionsInVideoFile in the API schema, as we have agreed in our discussion above. However, these directives have not been copied to the corresponding input types, _InputToCreateTimelineRegionsInVideoFile and _InputToUpdateTimelineRegionsInVideoFile.
Similarly, the new automatically added directives @_requiredForTarget_AccordingToInterface and @_uniqueForTarget_AccordingToInterface are not at the corresponding input types.
The @key directives should also be copied to the corresponding input types (but they are not at the moment).
The declaration of these directives in the API schema is not extended with the INPUT_FIELD_DEFINITION option as discussed above.

@hartig
1-2. Good catch. I actually thought I checked these. Apparently not.
3-4. I actually linked an old commit by mistake. These two where actually already fixed.
Should have linked https://gitlab.com/spirit-tools/mediator-service/-/compare/master...directives?w=1 instead (to see all changes), or https://gitlab.com/spirit-tools/mediator-service/-/commit/c72bca6edfb68f347bde4823e75c8b2aacc828e4 to see that 1-2 is now solved.
I was now able to remove the strange on ARGUMENT_DEFINITION I for some reason needed before. Was never able to pinpoint why they were needed, as they should not have been needed.

Thanks Leif. I have checked again and confirm that now this looks good in terms of the API schema.

As far as I can tell, the schema generator works as intended. However, checking the functionality with respect to the ArangoDB driver is not so straightforward. I think we need to set up individual tests for these. Still I think we can merge this feature branch into master at this point, and open a separate issue for the tests, since there's an option to disable the directive checks.

Sounds good. Please set the default value of the config option for the constraint checks to disabled for the moment and, after that, merge.


Failed to push signature to registry

Hey, I hope this is the right place to ask questions.
I'm trying to build a plugin to notation, the plugin seems to work but ultimately I cannot push the signature to the repo (I'm trying to work with dockerhub).
I did the following:

Logged into docker and pushed a tag to my personal repo.
Logged into notation with the same credentials.
Added a key to notation with the plugin.
Trying to run notation sign docker.io/ranisharim/signtest@sha256:6ce9a9a256a3495ae60ab0059ed1c7aee5ee89450477f2223f6ea7f6296df555
Keep getting Error: failed to push signature to registry with error: failed to push manifest: PUT "https://registry-1.docker.io/v2/ranisharim/signtest/manifests/sha256:db974e5c6f5e7991edb6923b65c45bbc0340d41f14ba3e5aae565ff06a218bb9": response status code 404: notfound: not found (Sha is different each time)

Seems like all the plugin steps work ok? I don't understand why the sha signature keeps changing though, and returning 404.
I'm attaching here the debug log.
debug.txt
Would appreciate any help with this.

Sorry seems like this is the wrong project.


handle large reserve ratio expansion

tested on simulator, if you buy before expansion and sell after you get less


Avklare veien videre for fagforum

Review the latest update and respond here: New Comment
This is critical—take action now.
Stay secure!


[Q] Did you reach Docker API call limit when scrape often?

Hi,
I think Docker Webhooks for automated builds are really poor and found that this project exposing docker_hub_image_last_updated could be a good choice for image build notifications.
My concern is that I've seen in the past Docker rejecting API calls if those exceed some quantity by hour, I wonder how often are you getting metrics from Docker to avoid such a limitation.
How it works internally? Does have Docker-Hub-Exporter a polling interval different from the scrape interval by Prom? Does it occur sync/async ?
Thanks!

To be honest, i've not hit a limit yet. The documentations isn't really there but the response doesn't indicate any sort of rate limit.
Prometheus hits the /metrics page on the webserver, this then calls the 'Collector' class in script. Only actually does anything when the page is hit by the scrape.

Thanks @Rucknar for clarifying!


"Izvoarele" is listed in the drop-down menu

Description:
"Izvoarele" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Izvoarele" in the search bar.

Expected results
The location is listed in the drop-down menu as "Izvoarele, Alba (Blaj)".


Fix package.json

This commit fixes duplicated when statement in package.json
ONE-vscode-DCO-1.0-Signed-off-by: dayo09<EMAIL_ADDRESS>

Functionality Check
On UI (linux, local pc)


passing in "100%" to pv_static for width

hi,
i'd like to show a Network graph that has the parameter width="100%" with pv_static(), but currently pv_static() only takes "[number]px" as a valid string for the width parameter. i would really like to see this changed so that it can also take in any general percentage of width and height, not just reading in the number of pixels.
thanks!
zach

hi josé! thank you for your quick reply! i look forward to seeing the results - pv_static() has been a wonderfully easy function to work with.


travis fails with rake command

The CI for this project is broken. See a snippet from a recent run below:
$ git clone --depth=50 https://github.com/IBM/personal-wealth-portfolio-mgt-bot.git IBM/personal-wealth-portfolio-mgt-bot
Cloning into 'IBM/personal-wealth-portfolio-mgt-bot'...
remote: Counting objects: 492, done.
remote: Compressing objects: 100% (228/228), done.
remote: Total 492 (delta 273), reused 474 (delta 261), pack-reused 0
Receiving objects: 100% (492/492), 3.21 MiB | 19.01 MiB/s, done.
Resolving deltas: 100% (273/273), done.
$ cd IBM/personal-wealth-portfolio-mgt-bot
0.25s$ git fetch origin +refs/pull/29/merge:
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 2), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), done.
From https://github.com/IBM/personal-wealth-portfolio-mgt-bot
 * branch            refs/pull/29/merge -> FETCH_HEAD
$ git checkout -qf FETCH_HEAD
rvm
3.89s$ rvm use default
Using /home/travis/.rvm/gems/ruby-2.4.1
** Updating RubyGems to the latest version for security reasons. **
** If you need an older version, you can downgrade with 'gem update --system OLD_VERSION'. **
ruby.versions
$ ruby --version
ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]
$ rvm --version
rvm 1.29.3 (latest) by Michal Papis, Piotr Kuczynski, Wayne E. Seguin [https://rvm.io]
$ bundle --version
Bundler version 1.16.1
$ gem --version
2.7.6
0.16s$ rake
rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
/home/travis/.rvm/gems/ruby-2.4.1@global/gems/rake-12.3.0/exe/rake:27:in `<top (required)>'
(See full trace by running task with --trace)
The command "rake" exited with 1.
Done. Your build exited with 1.

@stevemart - ok Travis is passing now....

@ljbennett62 it's passing, but looking at the output (https://travis-ci.org/IBM/personal-wealth-portfolio-mgt-bot/jobs/415217367) it's not doing anything :)
$ npm test
><EMAIL_ADDRESS>test /home/travis/build/IBM/personal-wealth-portfolio-mgt-bot
> echo 'Error: no test specified'
Error: no test specified
The command "npm test" exited with 0.


Bombchus not marking as gotten

I have tried everything I could think of but no matter what I do whenever I click on bombchus it will not be marked as collected it will just remain as it was.

Thanks for the report! Should be fixed now.

Thanks for the report! Should be fixed now.

Thank you so much it does indeed work now


Error: Could not find band_publish style. This is available on Github.

When running GaAs example, I get the following error:
Could not find band_publish style. This is available on Github.
usage: spaghetti [-h] [--code {wien2k,vasp}] [-b BANDS] [--character CHARACTER] [--atoms ATOMS [ATOMS ...]] [--orbitals ORBITALS [ORBITALS ...]] [--fermi FERMI]
[--ymin YMIN] [--xmin XMIN] [--xmax XMAX] [--ymax YMAX] [--kpath KPATH [KPATH ...]] [--klabels KLABELS [KLABELS ...]] [--colors COLORS [COLORS ...]]
[--weight_factor WEIGHT_FACTOR [WEIGHT_FACTOR ...]] [--save SAVE]
spaghetti: error: unrecognized arguments: --switch fatbands

I'll address this issue and the previous one in the next commit.

I wrote a small installer so that if this style sheet can not be found it will add it to your matplotlib installation and then re import matplotlib. This should work, but I haven't tested yet.

Thank you for your follow-up. I will test the changes soon.

I think minor fixes need to be made to the band.py module.
line 288:
if len(glob.glob("spaghetti.init")) == 0:                          # checks for init file
to
if len(glob.glob("w2kplot.init")) == 0:                          # checks for init file

There are few things that I found that I will need to fix. Thanks for this. I’ll make the changes this evening.

On Nov 21, 2021, at 12:38, Shahram_Yalameha @.***> wrote:

I think minor fixes need to be made to the band.py module.
line 288:
if len(glob.glob("spaghetti.init")) == 0: # checks for init file
to
if len(glob.glob("w2kplot.init")) == 0: # checks for init file
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

I think everything should be working now!


updating RecyclerTelemetryInfo to use SList

Changing Recycler telemetry to use SLIst instead of own simple linked-list.  This has benefit of JD support.

@dotnet-bot test
OSX static_osx_osx_debug  please


ISSUES

Good job so far! Your project looks almost like Figma design. The only thing that I've seen in your project I that:

[ ] I think it would look better if you use Figma images for the desktop version and for the pop up.

Your project looks excellent 👍💯,  I see that you worked hard but, I have a few comments:

You must stop storing the data in the local storage when the email field has invalid input.

Well done! Just one thing I'd like to mention:

[ ] Your localStorage data should be loaded to the input fields when page is loaded

it's fix


Fix plugin warning/debug/info logging

What does the code in this PR do / what does it improve?
This PR aims at fixing logging messages that did not show up during the simulation. The problem is described here: https://github.com/XENONnT/fuse/issues/247
Please include the following if applicable:

[ ] Tests to check the (new) code is working as desired.
[ ] Does it solve one of the GitHub open issues?

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

16 of 35 (45.71%)  changed or added relevant lines in 11 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.5%) to 80.044%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

fuse/plugins/detector_physics/csv_input.py
4
5
80.0%

fuse/plugins/detector_physics/s1_photon_propagation.py
2
3
66.67%

fuse/plugins/micro_physics/yields.py
2
3
66.67%

fuse/plugins/pmt_and_daq/pmt_afterpulses.py
0
1
0.0%

fuse/plugins/micro_physics/electric_field.py
0
2
0.0%

fuse/plugins/pmt_and_daq/pmt_response_and_daq.py
0
2
0.0%

fuse/plugins/detector_physics/s2_photon_propagation.py
1
4
25.0%

fuse/plugins/micro_physics/input.py
4
12
33.33%

Totals

Change from base Build<PHONE_NUMBER>:
-0.5%

Covered Lines:
2531

Relevant Lines:
3162

💛  - Coveralls


KeyError and Worker already exists

I'm trying to setup dask with tpot.
My code looks like this:
  from dask_jobqueue import LSFCluster
cluster = LSFCluster(cores=1, memory='3GB', job_extra=['-R rusage[mem=2048,scratch=8000]'],
                    local_directory='$TMPDIR',
                    walltime='12:00')

from dask.distributed import Client
client = Client(cluster)
cluster.scale(10)

from tpot import TPOTRegressor

reg = TPOTRegressor(max_time_mins=30, generations=20, population_size=96,
                    cv=5,
                    scoring='r2',
                    memory='auto', random_state=42, verbosity=10, use_dask=True)
reg.fit(X, y)

and I keep getting those annoying errors:
distributed.scheduler - ERROR - '74905774'
Traceback (most recent call last):
File "/cluster/home/abrahalo/.local/lib64/python3.6/site-packages/distributed/scheduler.py", line 1306, in add_worker
    plugin.add_worker(scheduler=self, worker=address)
File "/cluster/home/abrahalo/.local/lib64/python3.6/site-packages/dask_jobqueue/core.py", line 62, in add_worker
    self.running_jobs[job_id] = self.pending_jobs.pop(job_id)
KeyError: '74905774'

distributed.utils - ERROR - Worker already exists tcp://<IP_ADDRESS>:35780
Traceback (most recent call last):
File "/cluster/home/abrahalo/.local/lib64/python3.6/site-packages/distributed/utils.py", line 648, in log_errors
    yield
File "/cluster/home/abrahalo/.local/lib64/python3.6/site-packages/distributed/scheduler.py", line 1261, in add_worker
    raise ValueError("Worker already exists %s" % address)
ValueError: Worker already exists tcp://<IP_ADDRESS>:35780

I think there might be a problem with LSFCluster because it puts a lot of workers in cluster.finished_jobs that are still running according to bjobs and even to the dask.distributed web interface.

See #117, this error is seen when workers die and are being restarted. This is often due to out of memory errors.
The message should be corrected on master branch, but the underlying issue coming from your dask process will remain.
Try increasing memory per worker and also using dashboard to monitor your worker processes and see if you spot something wrong.

Thank you! Yes, I see the memory increasing a bit too much, I'll try increasing the limit in a few hours and hope it will solve my problem.
However, if a node unexpectedly encounters a problem that causes the worker to restart, shouldn't dask restart the computation as well?

Dask proposes a mechanism that will relaunch your failed tasks. I believe it should try to launch the tasks three times, but I'm not sure exactly in which cases. However, the memory problem in your case will probably shows up every time, and eventually your computation should fail.
Glad the problem is identified here, I will close this issue, but feel free to raise something upstream in dask or distributed if you believe there is a problem in task retrial mechanism!

Yes, you were right, the used memory grows a lot before the KeyError happens.
It seems that tpot tries PolynomialFeatures on data with 800 columns :)
I think the problem comes from tpot, but at the same time I don't understand how it is handled when executing locally.
A good test to identify those issues is:
grep Restarting dask-worker.err

In my case it shows some
Worker exceeded 95% memory budget. Restarting

and exactly 4 so I think you were right about the three restarts.
What is funny is that it will only crash after the 4 attempts, while executing other tasks in the meantime.
Thank you a lot for your help!

A pleasure to help!

Is there a way to signal that there is a memory error? Not a message but an exception or a special return type.

You should try to ask this upstream in distributed, I imagine there has been some thought in this behavior.

Yes, I can confirm it happens with a LocalCluster, so nothing to do with dask-jobqueue!

A reproducible example (perhaps using one of the sklearn make_dataset
functions) that replicated this with local cluster would be a great
contribution if you have time.
On Sat, Oct 6, 2018 at 6:01 PM louisabraham<EMAIL_ADDRESS>wrote:

Yes, I can confirm it happens with a LocalCluster, so nothing to do with
dask-jobqueue!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-jobqueue/issues/169#issuecomment-427609428,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASszJB44qGxDstroX2mnqZTjftlRrMOks5uiSgzgaJpZM4XLaEa
.

I think the problem comes from tpot that doesn't handle the memory errors.
The problem might come from dask_ml.model_selection._search.build_graph because the argument error_score=float('-inf') was used but didn't seem to have an effect.
https://github.com/EpistasisLab/tpot/blob/507b45db01e8f88651f4ce8e03b607a5b50146f5/tpot/gp_deap.py#L443-L454
A reproducible example with tpot that runs fast enough involves restricting the operators to force it to run PolynomialFeatures.
I should be able produce an example that causes an error in dask_ml. Maybe I should open an issue there?

I think I need some help to produce a reproducible example that runs without a cluster.
I am not sure how to trigger a memory error on my laptop. I fear that it will either use the swap memory or restart the computer.
I produced an error with a LocalCluster on a notebook started with LSF bsub with a soft memory limit.
Maybe using ulimit will work?

Probably the error doesn't strictly require a memory error, but perhaps
just needs a worker to remove itself during computation?
Alternatively if you think you can identify the failure and submit a fix
without creating a minimal reproducer that would also be useful.
On Sun, Oct 7, 2018 at 11:51 AM louisabraham<EMAIL_ADDRESS>wrote:

I think I need some help to produce a reproducible example that runs
without a cluster.
I am not sure how to trigger a memory error on my laptop. I fear that it
will either use the swap memory or restart the computer.
I produced an error with a LocalCluster on a notebook started with LSF
bsub with a soft memory limit.
Maybe using ulimit will work?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-jobqueue/issues/169#issuecomment-427663602,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASszF0tnvG9zBBrdMhbAmTR56qTteN2ks5uiiL_gaJpZM4XLaEa
.

I think that setting a dask-worker with the --memory-limit option will do the trick.
ulimit doesn't work at all on macos and doesn't limit effectively the memory on linux.


Zoom

What is the vendor's name?
Zoom
What is the vendor's pricing site?
https://zoom.us/pricing
What is the base pricing? Use the lowest tier that looks sane for a small business customer, not free or personal tiers.
19.99/u/m
What is the minimum pricing for SSO support?
19.99/u/m
Does this pricing info come from a quote or other non-public source?
Add any additional pricing context here.
Business, Education, and Enterprise

Looks like a typo as the non-SSO plan is $14.99, but seems valid.

pretty good!

Came here to add Zoom if they are not listed - they only provide SSO to Business plans, with minimum 10 users, which is a bit steep, when a small business only needs 5 or 6... 😡
Please add them to the wall.


Fix '-Wignored-qualifiers'

Fix -Wignored-qualifiers in rx-subscription.hpp:
/rpmbuild/BUILD/RxCpp-4.0.0/Rx/v2/src/rxcpp/rx-subscription.hpp: In constructor 'rxcpp::composite_subscription::composite_subscription()':
/rpmbuild/BUILD/RxCpp-4.0.0/Rx/v2/src/rxcpp/rx-subscription.hpp:382:66: warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
         , subscription(*static_cast<const inner_type* const>(this))
                                                                  ^

This is reprocible with gcc-8.0.1 on Fedora 28:
gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This is great! - I am dealing with some access issues at the moment, I will merge once everything is working again.


Unable to add specific metadata field/value to item

Describe the bug
We are unable to add the metafield 'dc.description' to an item in the edit item page in the UI. The field does not appear in the dropdown, and it gives the error message 'Please choose a valid metadata field'. This is despite us having the metadata field registered, and we have tried removing adding back the field in the registry but the issue still remains. It seems to be only this field that has the issue.

We have a customised instance of DSpace 7.5 installed currently. We first noticed this issue before production release last year but are unable to diagnose the issue.
To Reproduce

Login as an admin
Find an item and then edit the item
Add new field in the edit item view and type 'dc.description'

Expected behavior
Field 'dc.description' is accepted as a valid metadata field to be added
Related work
N/A

Have done some extensive digging, and here is what I've found:
On our instances of DSpace 7.5, our non-qualified metadata fields appear at the end of the dropdown list. Pair this with the querying of metadata field options only bringing back 10 results, this seemingly causes the 'Please choose a valid metadata field' error to occur. Upon checking the demo site (running 7.6.2), this is not the case there.
I suspect this was fixed in 7.6, with the DSpace backend fix #8758. We will be updating to 7.6.1 later in the year, at which point I may be able to provide an update on resolution. For now I'm happy to close this issue.

We had a very similar issue which was fixed with a '~/bin/dspace index-discovery'
The problem was that these were stored in the solr index, which needed to be rebuilt.

We had a very similar issue which was fixed with a '~/bin/dspace index-discovery'
The problem was that these were stored in the solr index, which needed to be rebuilt.

We have unfortunately tried that command many times and no resolution (and done many rebuilds usign the -b option). As I noted, I suspect the real fix lies in the changes from 7.5 to 7.6. May I know which version of DSpace you were running when you had the issue @stuartayeates?

This is in 7.6.

For what it's worth, this bug doesn't seem to be reproducible on https://demo.dspace.org (which is currently running pre-7.6.2 code from the dspace-7_x branch).  It's unclear to me if it occurred in earlier versions, but it doesn't seem to be occurring anymore.


nuxi dev infinite refresh loop

Environment

Operating System: Windows_NT
Node Version:     v16.13.1
Nuxt Version:     2.16.0-27358576.777a4b7f
Package Manager<EMAIL_ADDRESS>Bundler:          Webpack
User Config:      head, srcDir, css, plugins, components, buildModules, modules, moment, tailwindcss, pwa, i18n, axios, proxy, router, build, alias, server, bridge
Runtime Modules<EMAIL_ADDRESS>8n<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
Reproduction
As much as I cannot publicly share the repository containing the project's source code, I'd be more than happy to provide access through e.g. TeamViewer to one of the Nuxt team members.
Describe the bug
I have recently attempted to "experience Nuxt 3 features on existing Nuxt 2 projects" by following the instructions:
https://v3.nuxtjs.org/getting-started/bridge/
When running npm run dev (nuxi dev), the project builds successfully, but is stuck in an infinite refresh loop, as shown on the below video:
https://drive.google.com/file/d/1Ce0Qv67EvyBbucwgFj5pmAy5o5Y73RHD/view?usp=sharing
UPDATE
This is the piece of code that triggers an infinite loop:

Additional context
package.json file content:
{
    "name": "(...)",
    "version": "1.0.0",
    "private": true,
    "scripts": {
        "dev": "nuxi dev",
        "build": "nuxi build",
        "start": "nuxi preview"
    },
    "dependencies": {
        "@chenfengyuan/vue-countdown": "^1.1.5",
        "@googlemaps/js-api-loader": "^1.13.4",
        "@nuxtjs/axios": "^5.13.6",
        "@nuxtjs/i18n": "^7.2.0",
        "@nuxtjs/proxy": "^2.1.0",
        "@nuxtjs/pwa": "^3.3.5",
        "@pinia/nuxt": "^0.1.8",
        "@popperjs/core": "^2.11.2",
        "@tailwindcss/forms": "^0.4.0",
        "@vueform/slider": "^2.0.8",
        "@vuelidate/core": "^2.0.0-alpha.34",
        "@vuelidate/validators": "^2.0.0-alpha.26",
        "animate.css": "^4.1.1",
        "browser-image-compression": "^1.0.17",
        "cookie-universal-nuxt": "^2.1.5",
        "core-js": "^3.19.3",
        "lodash.get": "^4.4.2",
        "mitt": "^3.0.0",
        "nuxt-edge": "latest",
        "pinia": "^2.0.11",
        "portal-vue": "^2.1.7",
        "reading-time": "^1.5.0",
        "swiper": "^7.4.1",
        "v-calendar": "^2.3.4",
        "vue": "^2.6.14",
        "vue-agile": "^2.0.0",
        "vue-awesome-swiper": "^4.1.1",
        "vue-clamp": "^0.4.0",
        "vue-ellipse-progress": "^1.3.1",
        "vue-infinite-loading": "^2.4.5",
        "vue-lottie": "^0.2.1",
        "vue-material-design-icons": "^5.0.0",
        "vue-server-renderer": "^2.6.14",
        "vue-tailwind": "^2.5.0",
        "vue-template-compiler": "^2.6.14",
        "vuedraggable": "^2.24.3",
        "webpack": "^4.46.0"
    },
    "devDependencies": {
        "@babel/eslint-parser": "^7.16.3",
        "@nuxt/bridge": "npm<EMAIL_ADDRESS>        "@nuxt/postcss8": "^1.1.3",
        "@nuxt/types": "^2.15.8",
        "@nuxtjs/eslint-config-typescript": "^6.0.1",
        "@nuxtjs/eslint-module": "^3.0.2",
        "@nuxtjs/moment": "^1.6.1",
        "@nuxtjs/stylelint-module": "^4.1.0",
        "@types/gapi": "^0.0.41",
<EMAIL_ADDRESS>"^4.4.6",
        "@vue/runtime-dom": "3.2.30",
        "autoprefixer": "^10.4.2",
        "eslint": "^7.29.0",
        "eslint-config-prettier": "^8.3.0",
        "eslint-plugin-nuxt": "^3.1.0",
        "eslint-plugin-vue": "^7.12.1",
        "moment-duration-format": "^2.3.2",
        "postcss": "^8.4.4",
        "postcss-html": "^1.3.0",
        "prettier": "^2.5.1",
        "prettier-plugin-tailwindcss": "^0.1.5",
        "sass": "^1.49.7",
        "sass-loader": "^10.2.1",
        "stylelint": "^14.1.0",
        "stylelint-config-prettier": "^9.0.3",
        "stylelint-config-standard": "^24.0.0",
        "tailwindcss": "^3.0.16"
    }
}

tsconfig.json file content:
{
    "extends": "./.nuxt/tsconfig.json",
    "compilerOptions": {
        "types": [
            "@nuxt/types",
            "@nuxtjs/i18n",
            "@nuxtjs/axios",
            "@types/node",
            "@nuxtjs/moment",
            "@types/gapi",
            "@pinia/nuxt"
        ]
    }
}

nuxt.config.ts file content:
import path from "path";
import { defineNuxtConfig } from "@nuxt/bridge";

export default defineNuxtConfig({
    // Global page headers: https://go.nuxtjs.dev/config-head
    head: {
        title: "(...)",
        meta: [
            { charset: "utf-8" },
            {
                name: "viewport",
                content: "width=device-width, initial-scale=1"
            },
            { hid: "description", name: "description", content: "" },
            { name: "format-detection", content: "telephone=no" }
        ],
        link: [{ rel: "icon", type: "image/png", href: "/favicon.png" }],
        script: [
            {
                src: "https://apis.google.com/js/api.js"
            }
        ]
    },

    // Nuxt source directory location
    srcDir: "./src/",

    // Global CSS: https://go.nuxtjs.dev/config-css
    css: [
        "~/assets/css/fonts.css",
        "~/assets/css/main.css",
        "~/assets/css/tailwind.css",
        "animate.css/animate.min.css"
    ],

    // Plugins to run before rendering page: https://go.nuxtjs.dev/config-plugins
    plugins: [
        "~/plugins/bus.client.ts",
        "~/plugins/v-calendar.client.ts",
        "~/plugins/variant-js.ts",
        "~/plugins/vue-agile.ts",
        "~/plugins/vue-ellipse-progress.client.ts",
        "~/plugins/vue-tailwind.ts"
    ],

    // Auto import components: https://go.nuxtjs.dev/config-components
    components: [
        (...)

But from what I can tell in my app it's the proxy-module that's not working properly. I'm proxying http://localhost:3000/api/* to http://my-api-url/*, but since the proxy-module is not working in bridge (from what I can tell?), the nuxt-app is calling itself instead of the proxied url, which leads to a redirect loop.

I have found a fix for this issue, at least for me. I was using a remote development environment, and Visual Studio Code only port-forwarded port 3000. For the vite-websocket, port 24678 is also required.
You can fix this by going down to your console in VSC, and clicking on the Ports tab. Then you can add the port.
Hope this helps!

I was proxying Nuxt in development mode on a subdomain and this caused the infinite loop issue:
[Warning] [HMR] Cannot find update (Full reload needed)
[Warning] [HMR] (Probably because of restarting the server)
[Warning] [HMR] Reloading page

In my case the issue was caused by Cloudflare's cache. Disabling the cache fixed the problem.

#29 (comment)

I have found a fix for this issue, at least for me. I was using a remote development environment, and Visual Studio Code only port-forwarded port 3000. For the vite-websocket, port 24678 is also required. You can fix this by going down to your console in VSC, and clicking on the Ports tab. Then you can add the port. Hope this helps!

This one fix the problem for me!

Yes!!! You saved my life, I used VSC in remote dev environment, it refreshes infinitely, and your suggestion is priceless!

I have found a fix for this issue, at least for me. I was using a remote development environment, and Visual Studio Code only port-forwarded port 3000. For the vite-websocket, port 24678 is also required. You can fix this by going down to your console in VSC, and clicking on the Ports tab. Then you can add the port. Hope this helps!

also solved it for me in docker-compose environment

Thank you.
Really, thank you.

You deserve some beers.

#29 (comment)

I have found a fix for this issue, at least for me. I was using a remote development environment, and Visual Studio Code only port-forwarded port 3000. For the vite-websocket, port 24678 is also required. You can fix this by going down to your console in VSC, and clicking on the Ports tab. Then you can add the port. Hope this helps!

This one fix the problem for me!

Thank you.
Really, thank you.

You deserve some beers.

I have found a fix for this issue, at least for me. I was using a remote development environment, and Visual Studio Code only port-forwarded port 3000. For the vite-websocket, port 24678 is also required. You can fix this by going down to your console in VSC, and clicking on the Ports tab. Then you can add the port. Hope this helps!

Thank you.
Really, thank you.

You deserve some beers.

For me the problem was the nuxt.config.ts file was included in the content[] array in Tailwind config.


When I enable the sauce service in my test suite, it sets the suite name and not the test case name

I added the following lines in my wdio.config.js file to enable the sauce service:
   services: ['sauce'],
   user: <username>,
   key: <access_key>

When I run the tests on sauce, while the test is executing, the test case name is not set. Once the job is complete, the test case name gets set to the suite name in the sauce and not the full title of the test case.

@deeptiagrawa this is exactly what it suppose to do. WebdriverIO runs one spec in one session so it only makes sense to set the suite name of that spec as job name.


Generate two-step construction for all forms

Description:

Explanation (tldr; see Problem)
In wxWidgets, all classes that inherit from wxWindow internally perform two-step construction. If you create an instance of the class with parameters, wxWidgets will first call Init() and then call Create(). If you create an empty constructor, then wxWidgets will call Init() and then it's up to the dev to make the call to Create() before attempting to change anything in the class that assumes the window has been created.
For wxDialog and any classes that inherit from it (such as wxWizard), if you need to call SetExtraStyle() then you must create the instance with no parameters, call SetExtraStyle() and only then call Create().
For wxWizard, wxUiEditor only provides a constructor with all parameters, however the constructor itself creates an empty instance of wxWizard, calls SetExtraStyle() if needed along with a few other non-Window settings, and then calls Create(). Invoking a wizard from a main window is quite easy with the generated code:
    MyWizard wizard(this);
    wizard.Run();

The other advantage of the generated-code using a two-step construction for wxWizard is that it also generates the necessary code to load the image handler for the type of bitmap that will be used. So for example, if you use a .png file, then before Create() is called, the following code gets executed:
    if (!wxImage::FindHandler(wxBITMAP_TYPE_PNG))
        wxImage::AddHandler(new wxPNGHandler);

Problem
Currently, code generation for wxDialog always generates it's a Create() which is then used to call the base wxDialog::Create() function. While it does work, both the header and source files look unexpected. While the wxWizard-generated code can be copied and pasted into any custom wizard the dev might want to create, the wxDialog generated code is both unusual and I wouldn't recommend a dev implement their custom dialog that way.
The default for wxDialog and all other form code generation should be the same as the wxWizard method. It should look like one-step construction to the dev, and generate code that performs two-step construction.
Open question
If a dev creates code using two-step construction, there is an inherent risk to maintaining the code. Before Create() is called, you can only modify class properties that don't require the window to be already created. That's not obvious, and attempting to do that will typically crash the program. In addition, assuming that you can recover if Create() returns false is also not correct. If Create() failed because the operating system is out of window resources, then even trying to put up a message box to inform the user can crash or simply hang.
I am reluctant to generate code that could potentially cause a problem for a project later in it's lifetime because a new person working on the code base didn't understand that two-step construction requires you to be extremely careful about how you modify the class before calling Create(). I would rather generate code that is maintainable for the life of the project wxUiEditor was used to create code for.
This issue is related to the discussion #849

I've marked this for the 1.1.1 release -- one way or another, this should be decided in that release time frame.
I also just ran into a scenario for an internal project that requires 2-step, and therefore the wxFrame class cannot be created by wxUiEditor. The class is for full-screen display of an image. It needs to have a public function that loads the image before the Window is created so that it can notify the user and terminate the program if the requested image file does not exist. It cannot be a static function, and the window should not be created first. Anyways, that's one significant argument in favor of exposing 2-step construction, in spite of the risk to long-term maintenance of the project.

The way our wxDialog is created, the user has the option of either 1-step or 2-step construction (2-step requires the dev to call the dialog's Create(...) function). That means for the last two releases, we already generate code that has the issues mentioned above about a user not understanding the extra function call required for 2-step construction.
Adding 2-step construction to wxFrame and the form version of wxPanel doesn't require any code changes for existing projects. The only difference is that the full constructor works the same way as wxWidgets -- it does any processing needed in the constructor and then calls Create(...). The change provides the option for the dev to use 2-step construction, making it consisten across wxDialog, wxFrame and wxPanel.
Changing wxWizard would break compatability with every project created with version 1.0 and 1.1 becayse it would require adding an additional parameter to the constructor.


🚧 Remove the need to track peeked token

This PR removes the need for AssumeTokenRead on the wrapper Utf8JsonReader. As a result, the Skip and TrySkip methods become simple forwards to the inner reader.
The removal comes from changing JSON readers to be more aligned with how Utf8JsonReader behaves. When a reader reads a JSON value, it is no longer expected that the reader moves past the value. If a reader sees that Utf8JsonReader.TokenType is JsonTokenType.None then it assumes a freshly initialized Utf8JsonReader and will call Read on it. If it sees another token type then it will simply read it and leave the reader on the token. The exception to this rule is if the value is a JSON object or array. In those cases, the reader is left positioned on JsonTokenType.EndObject or JsonTokenType.EndArray, respectively.
There are two additional benefits of this change:

Jacob's Utf8JsonReader is aligned with how the one from .NET behaves and can be used interchangeably.
It may be possible to remove Jacob's Utf8JsonReader entirely in the future, if the stack in its reader state can be moved to a parameter of the Read method.

Codecov Report
Base: 88.68% // Head: 87.81% // Decreases project coverage by -0.86% :warning:

Coverage data is based on head (109889f) compared to base (f660f7a).
Patch coverage: 99.24% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #19      +/-   ##
==========================================
- Coverage   88.68%   87.81%   -0.87%
==========================================
  Files           5        5
  Lines         866      829      -37
==========================================
- Hits          768      728      -40
- Misses         98      101       +3

Impacted Files
Coverage Δ

src/JsonReader.g.cs
69.39% <97.87%> (-2.89%)
:arrow_down:

src/ArrayReadStateMachine.cs
100.00% <100.00%> (ø)

src/JsonReader.cs
96.57% <100.00%> (-0.49%)
:arrow_down:

src/Utf8JsonReader.cs
63.63% <100.00%> (-11.74%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Asynchronous Callbacks

Is there a way to return a result asynchronously like so?
Restivus.addRoute 'people',  authRequired:true,
  post:
    action: ->
      person = new Person()
      person.save (err, result)->
        if err?
          statusCode: 400
          body: status: "fail", message: "Unable to create person"
        else
          "Person saved!"

In my understanding, there is nothing inherently in HTTP that will allow an asynchronous response to be made. Once the connection is made during an HTTP request, the only way to respond to that client is within that same HTTP response. The connection is not like a two-way DDP connection (from my currently superficial understanding of DDP). In your example, of course, person would be returned in the response, instead of waiting on the callback. Managing async callbacks seems to be beyond the scope of Restivus and any other REST library that I've researched. For more on asynchronous REST operations, check this out.
Anyhow, I don't think that saving a person is such a long running operation that you actually need an asynchronous response here. I think what you might be looking for is just a way to wait on that callback before returning the endpoint response. For that, you should just be able to use Meteor's wrapAsync() or arunoda's  Async.wrap() to wrap that async person.save function to run "synchronously". It will look something like this:
Restivus.addRoute 'people',  authRequired:true,
  post:
    action: ->
      person = new Person()
      syncSave = Async.wrap person, 'save'
      result = syncSave()
      "Person saved!"

Without getting into the finer (and quite awesome) details, the result of this is that the previously asynchronous person.save() is now able to be called "synchronously", allowing you to wait on the result of the callback function you would normally pass into person.save() before having to return your endpoint response (as a bonus it does this without blocking the event loop).
The one thing that may not be acceptable about this solution is (again, in my understanding - don't just take my word on this) it does not give you control over the error response. They automatically throw the errors in those wrapped synchronous functions. If they're meteor errors, I think they'll include whatever message is generated in the error; otherwise, I think any other error may just get sent back as a 500 response. In the case of a server error, this is typically acceptable, but that alone may not suffice for your use case. Of course, if some other type of error can be inferred from the result of the wrapped async function, you could have finer control over those responses. I use this pattern when sending notifications to Android devices using GCM, so I know it works if you're okay losing control over the callback errors.
Let me know if that's unclear or just not a satisfactory solution for you.

This is great, just what I was looking for. I'm hitting one small snag that I'm currently working through (nothing to do with restivus).
Seriously, thanks for the ultra detailed response and explanation, I really appreciate it!

No problem! Glad I could help. It sounds like you're all set so I'll go ahead and close this. As always, feel free to open another issue if you have any other questions, bugs, or feature requests.


Fix JWT signatures for ES256

Commits in this PR
06addcaa88a2e7f09d2dbf637ff038606c83b242 - Fixes the unit tests that regressed from https://github.com/weka/jwtd/pull/1
27bd2ed72b2e355943d44643bb96f13774e4a49c - Fixes the signatures for ES256
Why this change?
This is needed for https://github.com/weka/wekapp/pull/28019 . If we are to use ES256 from now on (or any algorithm that depends on ECDSA signatures) we need this.
How was this uncovered?
While iterating on https://github.com/weka/wekapp/pull/28019 I realized that random operations that use and verify our JWTs like weka events started throwing 401 (Unauthorized) errors. Upon further analysis I realized that the signatures of our JWTs were a couple of bytes longer than the example signatures shown on websites for ES256. This lead me to look into the code of the jwtd package where I found out that the wrong format was used.
How was this tested?
By pointing the respective weka changes (https://github.com/weka/wekapp/pull/28019) to this commit and make sure that the tests pass. Also manually by ensuring that weka events works again.

This needs to be merged before the wekapp one should.

Closing this.
Yes the JWT standard expect the signatures to have ther R||S format but apparently a lot of libraries just use the DER format. Thus, Regardless of what we end up doing (either using my change or not) there will always be some JWT libraries that think that our signatures are invalid. Given this situation and the fact that I'm not a crypto expert I think it's better to leave the code as is for now until we hit problems (if that ever happens).


Update setup-edison.md

Can you re-target this as master? Thanks.

(also already fixed via other PRs)


cpp generator

Why we need m_bufferLength and m_actingVersion private variables in generated class MessageHeader? This members not used inside MessageHeader.

Variable m_actingBlockLength in other classes also unused

MessageHeader is generated from a fixed flyweight. Those fields are used by other flyweights. Or I should say, might possibly be used depending on schema. m_bufferLength probably should have a getter. Agreed. Feel free to add that or I will eventually.

@tmontgomery Thank you! When you release new version?

We will be releasing this shortly.

@mjpt777
The same for messages - m_bufferLength should have public getter. Could you please fix?

Done.

Thanks


Align names of REST API schema Chart and TypeScript data model ChartType

I am planning to change all the internal references to "chart" since it is slightly easier to work with. The UI can still call the object whatever we decide is most clear


add packer template

fixes #51
To add extensions, simply include them in the EXTENSIONS environment variable as shown below:
EXTENSIONS=timescaledb,pgvector,postgis,zombodb,pg_repack,pgautofailover,hll,citus

cc: @singhalkarun

Hey @singhalkarun, could you please review the changes?

@PiyushRaj927 Can you please check why the actions are running infinitely? Also can you brief in the description of PR itself what the action does? Generally, going forward, please brief all the changes done in PR Description.

@singhalkarun I have made updates to the PR description and included a workflow to test each extension individually. Please review these changes.

Regarding the issue with the infinitely running action, it appears that there was an outage on GitHub (you can check the details here: GitHub Status). This outage might have caused a bug to arise while running the specific action. I'm not entirely sure how to fix it.

@PiyushRaj927 Can you raise a new PR with squashed commit, I merged by mistake, I will merge new PR


[SUGGESTION] GitHub plugin collections

Hi there,
it would be great to have more (hopefully all) open source plugins in OP !
I've contributed with many resources to the HyMPS project's collection, so check out the AUDIO section \ Effects page for some of my efforts (OP is under Tools \ Misc instead).
I've also listed other collections that may help too.
Hope that inspires !

Hello,
Thanks for these suggestions, I'll take a look 🙂

@MarcoRavich https://github.com/RustoMCSpit/awesome-linux-clap-list

Hi there, it would be great to have more (hopefully all) open source plugins in OP !
I've contributed with many resources to the HyMPS project's collection, so check out the AUDIO section \ Effects page for some of my efforts (OP is under Tools \ Misc instead).
I've also listed other collections that may help too.
Hope that inspires !

what is this? im so confused lol


ci: Fix change detection (part 3)

Signed-off-by: Ryan Northey<EMAIL_ADDRESS>
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

@alyssawilk the idea with this Pr is that we remove all the requirements on checks from branch protection and replace them with just the complete job - that way the other jobs can either run or be skipped without failing the pipeline


Finds the mean of a list of numbers

Please, read this repo's contribution guidelines. If you had followed them, you'd know that your code doesn't work in its current form - the tests would show it.

The file should include a module-level doc-comments, the minimal requirement is the module's name in the first line for auto populating the directory.
Examples used in the documentation should be runnableExamples for additional testing. One example is enough, the rest should be tests.
The module lacks tests. Follow the minimal example and merged algorithms on how to implement them.
nums should be an openArray[SomeNumber]. You'll have to use a loop or std/sequtils.foldl, or import the std/math.sum which works on openArrays.

Sums had a specific module in the stdlib, but were changed to a nimble package.
Anyway, I would keep a similar version with openArray[SomeFloat] and maybe have a more complex version with openArray[SomeNumber]. I might only keep the second version but I would like to compare both.
I second @ZoomRmc : tests from the documentation could be changed copied under the when isMainModule.
Please, mark your PR as draft if you are not done. The following code indicates so:
when isMainModule:
  discard


Gallery, Slider: Zero-end of continuous slider should be an empty circle

The zero-end of the slider looks like it should be an empty circle.
https://www.google.com/design/spec/components/sliders.html#sliders-continuous-slider
From the spec:

From the app:

Is this from a design review?  I didn't do that because none of the other material implementations I found did that.

Yup, from a review with material designers.


What is "Load Custom" in the pysilon rat thing?

Does it let you choose any file to disguise the trojan as or am i getting stuff wrong here? Please help

its to load custom configuration


chore(entities) adjust tags schema

Summary
Yes, tags schema is kinda abstract, but it was a bit confusing for me to see a field with type=string and then having elements too. This commit just changes the schema to a bit less confusing.

will it be a breaking change?

@guanlan tags entity is readonly, so having a different a typedef for it won't affect current behaviour. Actually, a string
with element of UUID doesn't make sense after all (and will break somewhere if it's actually being type-checked).


sideload bundler and add address manager

:clipboard: Add associated issues, tickets, docs URL here.
Overview
Shows how to build Bundler service and loads it in the docker compose side. Integrates our Address Manager to retrieve deployed contracts done in a separate pr from @souradeep-das
Changes
Describe your changes and implementation choices. More details make PRs easier to review.

Alpine image with two layers
Import address manager from contracts and use it to retrieve two registered contracts if address manager is present

Testing
Will add more tests once things are tied together with @souradeep-das

Codecov Report
Base: 48.51% // Head: 48.51% // No change to project coverage :thumbsup:

Coverage data is based on head (906bc26) compared to base (d9f8756).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #531   +/-   ##
========================================
  Coverage    48.51%   48.51%
========================================
  Files          132      132
  Lines         5551     5551
  Branches      1123     1123
========================================
  Hits          2693     2693
  Misses        2858     2858

Flag
Coverage Δ

coverage
48.51% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

was the force push intentional @InoMurko ?

was the force push intentional @InoMurko ?

yep, rebase

all the tests pass! can we run the tests on ci too?
apparently we only run coverage tests on ci, on test:coverage

all the tests pass! can we run the tests on ci too?
apparently we only run coverage tests on ci, on test:coverage

omg, I thought they were. are we missing others too?

that should be all of the packages - just @boba/monitor isn't run with coverage, which i'm adding to the next pr!


added redox for some reason

i was board so i ported over this from something even tho redox doesent have bash it uses dash i think and it doesent use those {c1} thingys but those colors looked worse so maybe this doesent comply to your contrib rules but eh it works

i got board and fixed it

hm conflicting files instead of doing this properly ima just redo the files

welp idk why its saying my conflicting files are bad what ever