[CSRanking] Favour concrete members over protocol requirements

This PR comes in two pieces:
1. A narrow Swift 4.1 compatibility hack that favours properties in concrete types over protocol requirements
This was unintentionally regressed by #15412, and is tracked by SR-7425. This is added as a ranking tie-breaker in order to ensure we don’t introduce any new ambiguities.
2. A new Swift 5 mode ranking rule that favours arbitrary concrete type members over protocol requirements
We already have a similar rule that prefers concrete members over protocol extension members – IMO this new rule is a natural extension of it.
This allows the following code to become unambiguous in Swift 5 mode:
protocol X {
  func baz() -> Int
}

class Y {
  func baz() -> Int { return 0 }
}

func foo(_ x: X & Y) {
  // currently ambiguous, will be made unambigous in Swift 5 mode (favouring Y's `baz()`)
  x.baz()
}

Note that this new rule isn’t applied to overloads found through dynamic lookup in order to ensure we keep cases such as SR-7299 ambiguous.
Note also that this new rule is potentially source breaking (hence why it requires Swift 5 mode) – for example, the following contrived case is currently unambiguous, but will be made ambiguous by the change:
protocol P {
  static func foo() -> Int
}

class C {
  func foo() -> Int { return 0 }
}

extension P where Self : C {
  static func bar() {
    let m = foo // currently unambiguous, will be made ambiguous in Swift 5 mode
  }
}

Arguably this change is unifying the behaviour with that of protocol extensions, where a similar example is already ambiguous:
protocol P {}
extension P {
  static func foo() -> Int { return 0 }
}

class C {
  func foo() -> Int { return 0 }
}

extension P where Self : C {
  static func bar() {
    let m = foo // error: Ambiguous use of 'foo()'
  }
}

And currently, adding static func foo() as a protocol requirement to the above suddenly resolves the ambiguity – with this Swift 5 mode change, the ambiguity is kept in both cases, which seems more consistent.
I’m happy to split this PR up if the Swift 5 mode change requires more discussion.
Resolves SR-7425.

Build failed
Swift Test Linux Platform
Git Sha - 2e6ba53ebcc20fc1c943f46a79f7604ee005dbb3

Just fixed the Linux failure. The source compatibility suite succeeded, though looking through the projects I realise that we wouldn't have exercised -swift-version 5 at all. Is there a way to do so?

@hamishknight No. What I would suggest is removing the version check for the sake of running the compat suite to check that there aren't any unexpected breaks (and see what actually will break for people moving to Swift 5).

@rudkx Thanks, I've gone ahead and done that – could you kick off the compat suite again?

@swift-ci Please test source compatibility

Can you split the changes up into separate PRs we get some feedback from the source compatibility suite?
I'll take a closer look at each once that's done. I am a little concerned that at first glance some of the changes remind me of https://github.com/apple/swift/pull/17995

Sure thing – I've split it up into #18952 & #18951. Shall I go ahead and close this PR?

@rudkx As this branch stands today it preserves behavior when it comes to protocol vs. protocol extension declarations, and would always pick declaration on protocol...

@hamishknight Yes, we can close this out in favor of the two new PRs. Thanks!


Editable option seems to be not taken in count

Hello,
First of all, thanks for this project !
I use tox with tox-pipenv inside the virtualenv of the project to run tests. I know that it's originally designed to be used outside the virtualenv but I admint that it's easier not to exit the virtualenv each time I run tox.
Everything is working nicely besides a warning "WARNING:test command found but not installed in testenv" but I think it's related to the issue #6 (even if this warning is appearing since the first time for me).
My problem is that it seems to change the editable option of a package in the virtualenv. Before running tox I have a pip list like this :
....
flake8                   3.5.0
gibica                   0.5.0     /Users/matthieu/Documents/Informatique/python/gibica
idna                     2.7
...

And after have run tox :
...
flake8                   3.5.0
gibica                   0.5.0
idna                     2.7
...

My Pipfile looks like this :
...

[packages]
click = "*"
gibica = {editable = true, path = "."}

[dev-packages]
"flake8" = "*"
tox = "*"
tox-pipenv = "*"
pytest = "*"
pytest-cov = "*"
coverage = "*"
coveralls = "*"
mypy = "*"
bumpversion = "*"
black = "*"
Sphinx = "*"
sphinx_rtd_theme = "*"
gibica = {editable = true, path = "."}

...

So I don't know why but It seems that tox-pipenv modifies the actual virtualenv and doesn't handle the editable option properly... or maybe I miss something !
After a pipenv install --dev inside the virtualenv the package is in editable option again.
Have a good day,
Matthieu.
EDIT:
Oh and this is the content of my tox.ini configuration file :
[tox]
envlist = format, lint, type, test

[testenv]
commands =
    format: black --py36 --line-length 88 --skip-string-normalization gibica tests
    lint: flake8 gibica tests
    type: mypy gibica
    test: py.test --cov=gibica

I just made a fix in #56 which I think will fix your issue


Don’t add  height & width attributes

On my test page, the following Liquid tag:
{% cloudinary /assets/test.png alt="beautiful!" %}

Produced an image with width and height attributes. These don't make sense for a couple of reasons.

They represent the dimensions of the full-size image; often we will be loading one of the smaller-downscaled versions in srcset.
The intrinsic width is over-ridden by the standard max-width: 100%; display rule. Without the height, the image would be scaled proportionately, but with it, it is only scaled horizontally, and distorted to fit both the 100% width, and the 1012 height.

height and width are often more trouble than they're worth on responsive layouts. Get rid of them?

The aim was to let the browser know the image ratio so that it can reserve the necessary space, even before the image is loaded, which would limit content "jump".
It looks like the browser don't do it, after all, so you're right, I should remove them.

I now remember why I did this.
If the image is small, c_scale will enlarge it, so setting width and height attributes show it at the right size.
I just read the image cropping documentation once again, and it seems I should use c_limit instead of c_scale.
I could even remove rmagick dependency, letting Cloudinary do its magic even more… ;-)
@eeeps any advice?

Parts of what I said in previous comment are false.
Yes, c_scale will enlarge the image, while c_limit won't, so the later might be safer. But I still need rmagick anyway, because I try to prevent using superfluous Cloudinary URLs, like the ones where the required width is larger than the natural one. If I succeed, c_limit should not be required.
The main objective of width and height attributes was to show an image at its natural size if it is smaller than its container, because —as @eeeps says— "naturalWidth will always report the evaluated sizes value".
I see two options to show the image at its true natural size when the container is larger:

keep <width> and <height> attributes on the image, easy.
add a breakpoint to sizes for before and after the image is exactly the width of the container. Really more difficult, even maybe impossible, because it means the sizes attribute must be different for each image, but it depends on the design, which is the reason the user currently has to set it manually in_config.yml.

::just spent a half hour testing things and being surprised::
OK so I agree with you, leave these attributes!
I thought that width= set the intrinsic width, and was trumped by sizes. It doesn’t! It sets the layout width, and it + sizes are independent. CSS layout width: trumps HTML layout width= for layout... but the HTML width=, and not the intrinsic width (as I thought), provides the upper limit for max-width:.
 Too many “widths!” Anyways, the system works as you describe, and my mental model was all wrong.
As you say, if I just set the CSS height: to auto for all of my responsive images, the height= attribute wouldn't distort my image. And, as you say, it turns out that while space isn't actually reserved on the layout until the image is loaded, the spec has an example that tells you that it is, advocating for exactly the pattern that you’re using... so who knows maybe that'll work some day too.
TL;DR if you don’t want to upscale,* max-width: and height: auto + width= and height= is the best pattern. Use it!
* I’m weird, and in the habit of setting width: instead of max-width: on my images and treating layout width and resource width totally independently...but that's unusual I think

Awesome, I'll put the width and height back… ;-)
Maybe there's an interesting example to build, with both large and small images, and discuss with @respimg people?

After reading the discussion, I am still uncertain what is proposed here. Having width and height attributes screws up my rendering and I can't see a way of removing them.
Adding height: auto to my CSS fixed the rendering issues, though.


Group with role/rolebinding cause Error: empty namespace

Describe the bug
If a group has role binding to a role, command will fail with the following error.
 > Error: an empty namespace may not be set when a resource name is provided.
 > Run kubectl rolesum -h command for the usage.

Might be the same as the following issue.
https://github.com/Ladicle/kubectl-rolesum/issues/24
To Reproduce
Steps to reproduce the behavior:

Create a role.
Create a role binding to the role with Group.
Use rolesum to look for the summary for the Group.

Expected behavior
The summary for the Group should be shown.
Screenshots
None
Desktop (please complete the following information):

OS: Ubuntu
Kubernetes: 1.18.2
Version: 1.5.0

Additional context
Add any other context about the problem here.

https://github.com/Ladicle/kubectl-rolesum/blob/master/cmd/cmd.go#L117
Namespace will only be set, when kind is ServiceAccount.
However, the following line will be called when

Kind is Group
Group is binded with a role

https://github.com/Ladicle/kubectl-rolesum/blob/master/pkg/explorer/explorer.go#L72
Thus, causing reference to the namespace variable, which is not set in the context.


[QUERY]

What SDG is this improvement about:
SDG 4
What Target within that SDG is this improvement about:
target 4.6
What is the change you are proposing, and why?:
some UDE results for 4.6 in the version that is currently online at https://aurora-network.global/project/sdg-analysis-bibliometrics-relevance/ show publications related to internet literacy, financial literacy and health literacy. They do not, however, refer to (basic) literacy as I interpret target 4.6. Therefore my suggestion would be to add something like: AND IS NOT ("computer literacy" OR "internet literacy" OR "financial literacy" OR "YXZ literacy").
// [not using proper querry language here I guess, but wanted to highlight the issue anyhow]

Thanks len-art for the query suggestion.
Op di 1 feb. 2022 13:23 schreef Len-nart @.***>:

What SDG is this improvement about:
SDG 4
What Target within that SDG is this improvement about:
target 4.6
What is the change you are proposing, and why?:
some UDE results for 4.6 in the version that is currently online at
https://aurora-network.global/project/sdg-analysis-bibliometrics-relevance/
show publications related to internet literacy, financial literacy and
health literacy. They do not, however, refer to (basic) literacy as I
interpret target 4.6. Therefore my suggestion would be to add something
like: AND IS NOT ("computer literacy" OR "internet literacy" OR "financial
literacy" OR "YXZ literacy").
// [not using proper querry language here I guess, but wanted to highlight
the issue anyhow]
Search Tips:
For a more precise definition of the concept you want to retrieve papers
on, reducing false positives:

use quotation marks " , to combine keywords
use proximity operators W/3 , to find terms that typically occur in
a sentence.
use parenthences and logical operators (("..." OR "...") AND ("..."
OR "...")) to find combinations of terms that are synonyms or antonyms in
the same context.

For more relevant papers, increase recall by:

using wildcards * or ? to find papers with concepts that are in
different english dialects.

more tips:
https://blog.scopus.com/posts/6-simple-search-tips-lessons-learned-from-the-scopus-webinar
—
Reply to this email directly, view it on GitHub
https://github.com/Aurora-Network-Global/sdg-queries/issues/11, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCQ6A76B4XWO7Q2VNU2MB3UY7GDPANCNFSM5NI7UMXA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Update sphinx version to get better openssl

Partial resolution to #702

She sphinx targeted builds are working, im going to merge this to get them to build and keep debugging the rest of it.


Make servlet-api optional

set the servlet-api to optional in order to be still able to compile

👍

👍


Reassigning presentation mode shortcuts

Not sure if this plugin is still being maintained, but I'm having issues advancing through slides using the Presentation plugin for RemNote. How can I remove a keyboard shortcut? I am trying to remove/reassign two presentation mode shortcuts, but selecting the "X" to remove the shortcut does nothing. Using the shortcuts that appear by default also do not work. Any suggestions?

Hey @bnleez1 I replied here: https://github.com/bjsi/presentation-mode/issues/3. Please let me know if you still have issues!


Make documentation available on the interwebs

Documentation can be generated by cloning the repo and running grunt docs.
It should also be available without these steps - probably on http://vissense.github.io/vissense

Now available on vissense.github.io/vissense.


CARDS-2329 / CARDS-2330 - Heracles add a new question to the CPET Interpretation Form & update cpet_prot field answer options

https://phenotips.atlassian.net/browse/CARDS-2329
https://phenotips.atlassian.net/browse/CARDS-2330

CARDS-2329 Question :
Is the free text option also required for the newly added Cardiopulmonary Assessment Type?

As far as I can see from the diff the display mode has not been changed by this PR (only options have been added) so I assume it's intentional to have an input there as there always was one, but @Hajany should confirm.

As far as I can see from the diff the display mode has not been changed by this PR (only options have been added) so I assume it's intentional to have an input there as there always was one, but @Hajany should confirm.

Cardiopulmonary Assessment Type is a brand new field. I am assuming the free text is expected, as it is commonly an option on other questions.

@sashaandjic it should just be the two answer options (Usual Care or Apple protocol) for Cardiopulmonary Assessment Type, no free text. I've updated the Display Mode to just "list"


Stacked bar chart mixed with line renders line in wrong position

Description
I am trying to render an equivalent of something like this (rendered with Chart.js)

Using the demo chart here, with modifications to make it stacked, produces something close, but the chart line is rendered in the wrong place
Expected Behavior
The line should represent the data in the series it represents
Actual Behavior
The line renders below the zero (0) value, but none of the data in its series are negative
Screenshots

Reproduction Link
https://codepen.io/jasonpolites/pen/VwJYKoR

You have a multi-axis chart configured and the Y-axis scale for your chart is on the right side and appears to be correct, at least for the first point  at 1.4.

OK.. that's fair


Not able to make clips in vod

Not able to make clips in vod, when I click the clips button, it will lead me to https://clips.twitch.tv/clips/500

Hi, unfortunately I can't make clips working


fix memset bug

following a call to memset(buf, 0x41, 8)
In [1]: buf
Out[1]: <BV32 0xc0000c20>
In [2]: buf_bytes7 = results.found[0].state.memory.load(buf, 7)
In [3]: buf_bytes8 = results.found[0].state.memory.load(buf, 8)
In [4]: print buf_bytes7
<BV56 0x41414141414141>
In [5]: print buf_bytes8
<BV64 0x41414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141>

Thank you! This is a legit bug fix. We'll merge it in prior to the next big release.

It seems that someone was busy and didn't get to this PR soon enough. Just merged. Thanks!


Fix textAlign check on

@keybase/react-hackers
Oops -- I added a commit to allow both left-aligned (for the menubar widget) and center-aligned (for pinentry)  text fields, but the syntax doesn't do what I thought it did, and it made everything left-aligned.  I'll use the verbose syntax since I've tested that.  Please could I get a thumb tonight, since the bug's in master now?  Sorry for the hassle!

This is really my fault :+1:


standardize JSON error responses

Use the global errors object (defined in utils.js) to define the specific errors (maybe its own module), as well as a global JSON error function, which takes two arguments: an error object and the response object. If the error object is null, returns a generic 500.

more graceful error handling in general, converting the lower-level errors close to the database into more standardized errors for consumption by the api and the client


Begin SearchSheet component

Adds new SearchSheet component to OperatorMode component
Not yet wired to actually search anything
Future TODOs:

Keyboard handling (ESC and Enter)
Results view

https://user-images.githubusercontent.com/353/234398275-ff618fca-d884-4580-86dc-d833d249dcf4.mov

@burieberry wrote:

I don't understand why we can't put this component in the boxel-ui package. The logic should be in host but shouldn't the presentational components go there?

I was on the fence about it. On Monday, I wrote in boxel-internal:

I'm picking up https://linear.app/cardstack/issue/CS-5314/in-operator-mode-search-bar-shows-on-bottom-of-screen. My question is whether the components for the search bar belong in boxel-ui or in the host app? I'd lean toward them belonging in the host app. If that's the case, should we have a freestyle guide there as well, to support component development in the host package?

And @habdelra replied

yeah, that's probably a good idea

And so I took this path. The reason I was leaning toward host is the idea that boxel-ui will be a component library of things that a card author might want to use in his or her card templated (isolated, embedded or edit). By that definition, this search sheet definitely does not belong.


Mark an exited worker as aborted

We launch UI/Web Service/Web Socket workers using puma.
Puma has it's own signal handlers, so if a puma based worker gets a SIGINT/etc,
puma will handle it and exit cleanly without running our normal worker signal
handling, which cleans up the worker row to say it's exited cleanly.
Before this change, we'd wait for the exited process' worker row heartbeat timeout
to be reached before we marked it as not responding and eventually restart a
replacement.
Since we check the worker's status each iteration of monitor_workers, marking the
worker as aborted based on a Errno:ESRCH (No Such Process) exception greatly
speeds up the process of starting a replacement worker.
Note: processInfo should raise Errno::ESRCH for "No such process"
The handling of a RuntimeError with an empty message for ps on a missing process
was added in def8f129976f11c22 back in 2008.  That was probably on ruby 1.8.x
on ubuntu.  This should not happen in 2016 with ruby 2.2+ / CentOS 7+ / Fedora /
OSX.  We'll treat any StandardError exceptions as unexpected, catch and log them
but not abort the worker.
@Fryguy @gtanzillo Please review, the middle commit is the primary one.  Reviewing commit by commit is much easier to follow.  The first and third commit is related code cleanup.
cc @mkanoor @abellotti @skateman @imtayadeway (in case you have seen this behavior locally)
@mkanoor I saw this while digging into the worker issue you're seeing where puma workers are sticking around (not exiting cleanly)... it's not the issue but certainly a bug.

@jrafanie I commented commit-by-commit, so some comments seem to have been collapsed away.  Let me know your thoughts on the above 3 comments.

re: leaving/removing the rescue: I'm just concerned with this change that we went from "swallow any error on status_update", to "blow up on anything except Errno::ESRCH on status_update".  If we blow out all the way, what will that prevent from happening...since this is called from monitor_workers, my guess is that workers would stop getting monitored...would it be worse and bomb out the evm_server.rb itself?

Ok, @Fryguy you convinced me.  processInfo uses different libraries for different platforms so it's probably best to rescue them to prevent the server from going casters up.
I squashed into the middle commit and applied your slice suggestion as the 3rd commit.  It's still best to review each commit.  The first commit "Test the fields we expect, not all specific values" is unchanged.


net: TestLookupNullByte is failing on macOS (and maybe other non-Windows ports)

CL 173362 was a part of Go 1.14 changes and fixed a crash in net.LookupHost on Windows. It added the test TestLookupNullByte. A part of that test is not compatible with non-Windows ports such as darwin/amd64, causing the test to fail:
$ go test net -run=TestLookupNullByte
--- FAIL: TestLookupNullByte (0.00s)
    lookup_test.go:1188: unexpected success
FAIL
FAIL	net	0.234s

Marking as release-blocker because it's a regression, and the test failure is very reproducible. The fix will be small.

The test's primary goal is was to ensure net.LookupHost("foo\x00bar") doesn't crash on Windows. Additionally, it happens to check that err != nil on Windows:
// Issue 31586: don't crash on null byte in name
func TestLookupNullByte(t *testing.T) {
	testenv.MustHaveExternalNetwork(t)
	testenv.SkipFlakyNet(t)
	_, err := LookupHost("foo\x00bar") // used to crash on Windows
	if err == nil {
		t.Errorf("unexpected success")
	}
}

On darwin/amd64, net.LookupHost("foo\x00bar") on my machine/network returns a nil error even with Go 1.13.7:
package main

import (
	"fmt"
	"net"
	"runtime"
)

func main() {
	fmt.Println(runtime.Version())
	_, err := net.LookupHost("foo\x00bar")
	fmt.Println(err)
}

// Output:
// go1.13.7
// <nil>

/cc @bradfitz @golang/osp-team I plan to update the test so it either runs only on Windows, or relax the err == nil check. Let me know if there are preferences between those two fixes.
/cc @bradfitz Is it normal that net.LookupHost("foo\x00bar") can succeed on macOS? If it's not expected, I believe a separate issue should be filed for that.

What is the net.Lookup call returning for the non-error result?

It's returning the same IP that I get if I do ping foo or ping foobar on my corp machine.

This might be related to the network I'm on more than to the choice of operating system. If that's the case, a better fix is to remove the "unexpected success" check rather than make it Windows only.


Make IMixedRealityControllerVisualizer less implementation-specific

Overview
Not all visualizers will be driven by a pose synchronizer. Implementations that want to be (like MixedRealityControllerVisualizer) are still able to implement both interfaces.

Needs to have a design discussion

@keveleigh, can you describe a concrete example of how this is helpful?

Also let's focus on bug fixes for stabilization.
This isn't something we need to release on beta.

Re-targetted back to development for further discussion. Not a beta candidate

@keveleigh do you think you could close this PR and start up a new task to discuss the requirements for this change, reasons why the current implementation is not sufficient and any other alternatives you've considered.
That is supposed to be the process for introducing change in to the framework as I understand it.

Agreed. Also, visualization is going to need to be synced with the controller pose. I'm not sure this is a change we should be making.


client: improve automatic protocol switching

(https://github.com/aler9/rtsp-simple-server/issues/1105)
when a camera receives a UDP request and replies with a TCP responses, switch protocol from UDP to TCP.

Codecov Report

Merging #169 (cf2c5ca) into main (ca3ab98) will decrease coverage by 0.02%.
The diff coverage is 80.00%.

:exclamation: Current head cf2c5ca differs from pull request most recent head e7b25d2. Consider uploading reports for the commit e7b25d2 to get more accurate results

@@            Coverage Diff             @@
##             main     #169      +/-   ##
==========================================
- Coverage   85.22%   85.21%   -0.02%
==========================================
  Files         101      101
  Lines       10634    10663      +29
==========================================
+ Hits         9063     9086      +23
- Misses       1198     1202       +4
- Partials      373      375       +2

Impacted Files
Coverage Δ

client.go
74.52% <80.00%> (+0.03%)
:arrow_up:

serverconn.go
91.23% <0.00%> (+0.25%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


refactor: use generic ResourceMap

The ResourceSpecs and ResourceMaps have been made generic through the
use of a ResourceMap. This simplifies the interactions with these
resources.
As part of this change, the ResourceSpecs no longer require the use of
an async mutex. Instead, a sync mutex is used.
Resolves: CAS-1010

bors try


why in ci/cd engagment when i upload a report i find the old ones and i cant know which is new and which is old

i think in ci/cd engagment there should be 1 report for each tools which is the latest one because i wanna look at how the application is doing right now so is there a way to acheive this

Please come to Slack for support. You can use Reimport to keep uploading updated reports into the same test.


Support for: CSS Template Layout Module

Support for: CSS Template Layout Module

This issue was imported from Google Moderator
Moderator votes: +5
Issue added by Maujor on 2012-10-20
To vote this issue up or down, simply include +1 or -1 in your comment.

Duplicate of #1077


Upgrades httpclient to version 4.5.1 and fixes deprecated methods

This pull request upgrades httpclient library to version 4.5.1 and removes all deprecated methods usages from SimpleHttpFetcher. This class is in process of being deprecated, but this can still be useful and it would be good to have this in the next version.

Thank you very much @aecio for this. Nice job :)
Folks, I've checked out the proposed changes and I am +1 to merge them.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 21.997 s
[INFO] Finished at: 2015-10-05T21:04:54-07:00
[INFO] Final Memory: 22M/253M
[INFO] ------------------------------------------------------------------------

Thanks @lewismc. I added the changes in CHANGES.txt file in a new commit.

Any comments folks?

I'm a bit leery of committing changes to deprecated classes, but agree that it's worthwhile to get the mods in now, before it gets moved to a new project.

I reviewed the changes in this PR once more, and found some problems. For some reason, my IDE was not showing some of the deprecated APIs and all tests were passing when I submitted this pull request. Also, the maven build is configured to not fail when tests fail, so this message BUILD SUCCESS doesn't mean that all tests passed.
So, two tests were still failing due to changes in httpclient 4.5. In this version, Request/Response Interceptors do not always work to get the remote host address because either the connection is not available, or it's already released when the interceptors run.
Anyway, I just pushed a few commits more that fixes all these problems.

There are still two test failing, but they are related to issue #103.

OK that is not good. I didn't realize that failed tests were skipped in the
build.
Can you add this to the PR please? We can then take from there.
Thanks for following up.
Lewis
On Tue, Oct 6, 2015 at 10:33 PM, Aécio Santos<EMAIL_ADDRESS>wrote:

There are still two test failing, but they are related to issue #103
https://github.com/crawler-commons/crawler-commons/issues/103.
—
Reply to this email directly or view it on GitHub
https://github.com/crawler-commons/crawler-commons/pull/98#issuecomment-146080884
.

--
Lewis

Sure. I just pushed a change in the pom.xml in commit 333afe4. Also, I already pulled the fix for issue #103, so all tests are passing now.

@aecio Any chance you could squash the commits into one?

@jnioche Do you mean (soft) reset the commits, make another single commit, and force push? I can try to do it, if force push is not a problem.

@aecio see [http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html]
Force push should not be a problem as you'd be operating on your own branch/repository

Thanks @jnioche! Just did it. Github now says there's a merge conflict, but it should be a pretty simple conflict in CHANGES.txt file. I can do one more commit (merge) to solve the conflict, if you want.

I merged & pushed - thanks Aécio!

Great! Thanks.


OCaml 5 system

We should add OCaml 5 as a system in place of Multicore OCaml.

Perhaps in addition to Multicore OCaml (or some fork of OCaml 5) so as to benchmark multi-shot handlers?

The plan is to add vanilla OCaml 5 and the multicont library that support multi-shot handlers as a separate system

I should had written out the full plan. As Filip said the plan is to have two system instances of OCaml: OCaml 5 (vanilla) and OCaml 5 + multicont for multi-shot continuations.


Start time for a single demographic scenario

Hi,
I was wondering if it was possible to have a start time for a single demographic scenario i.e:
description: A single population model with epochs of exponential growth and decay.
doi:
  - https://doi.org/10.1038/ng.3015
time_units: generations
demes:
  - name: generic
    epochs:
    - {start_time: 0, start_size: 7156}
    - {start_time: 25,599.98 , start_size: 71560} # 25,599.98 (= 34133.31 - 8533.33 + 0)
    - {start_time: 31,999.98, start_size: 7156} # (= 8533.33 - 2133.33 + 25,599.98)
    - {start_time: 33,599.98, start_size: 7156}
    - {start_time: 33,999.98, start_size: 71560}
    - {start_time: 34,099.98, start_size: 7156}
    - {start_time: 34133.31, start_size: 71560}

If not would it be worth adding to the API ?

Unless I am misunderstanding something, I believe you want all of those start times to be end times?

Here is a version of your model that leads to a valid graph:
import demes

model = """
description: A single population model with epochs of exponential growth and decay.
doi:
  - https://doi.org/10.1038/ng.3015
time_units: generations
demes:
  - name: generic
    epochs:
    - {end_time: 34133.31, start_size: 71560}
    - {end_time: 34099.98, end_size: 7156}
    - {end_time: 33999.98, end_size: 71560}
    - {end_time: 33599.98, end_size: 7156}
    - {end_time: 31999.98, end_size: 7156}
    - {end_time: 25599.98, end_size: 71560}
    - {end_time: 0, end_size: 7156}
"""

g = demes.loads(model)

A start time is in the past.  And epochs must be written in order of past to present.  The final start time must be "infinity", meaning "the start size of this epoch is this value indefinitely until the common ancestor is reached". (Or until the burn in time of something like a forward simulation first started.)

I understand the msprime is a coalescent simulator so it processes generations going back in time, but for forward simulations I would like to invert the generations.  So the initialize population size following the zig-zag population model example is 7156 and then there is an inflection point at 25,999 generations moving the population size of 71560 and so on.

For forward simulations, you need to reinterpret the model forwards in time, meaning you read in the graph and then convert time as needed. Examples of this include fwdpy11, which converts the backwards-time graph to the forward time objects and a rust crate that provides a forward-time representation of such graphs that may be used in forward simulations.  (Currently, fwdpy11 is being refactored to use that rust crate.)

There is also a C API for the rust crate.  I may write a Python interface but haven't had the time/need yet.

This appendix gives a recipe.

Okay thanks for the responses!  I did not know it was a separate package.   I thought it would be useful to have in the demes API just for exporting to YAML files.

Just to clarify: it is not a separate package but rather something that I wrote because other projects need it.  We could have something akin to it in the current demes-python API, but it wouldn't change the YAML file.  The YAML that you wrote above will never be a valid demes input (barring an unforeseen reason to introduce a version 2 of the spec).

Going to close this one as there is nothing actionable:

demes is a backwards-time specification
The paper discusses why
How to handle forward time models is documented.

Feel free to reopen if necessary.


chore(deps): upgrade runtime dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-runtime-dependencies-2.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 2912

Questions ?
Please refer to the Backport tool documentation


pmxbot does not reconnect if network connection is lost

If pmxbot loses it's network connection, it does not realize this and will not reconnect (at least not that I have seen).
You can replicate this pretty easily by running pmxbot, then blocking it's inbound and outbound ports with iptables, wait for the bot to disconnect the IRC server due to a ping timeout and then unblock the ports.
I would propose that the bot should have functionality to ping the IRC server every so often, and if it does not get a reply, either reconnect OR do a sys.exit() (and hope that people are running it through a process supervisor that will restart it).  The "friendliest" option would likely be to just do a disconnect and reconnect.
I am unsure if this should be reported here, or to the jaraco/irc project...

Bitbucket: https://bitbucket.org/yougov/pmxbot/issue/33
Originally reported by: Chris Jowett
Originally created at: 2014-09-23T16:16:23.259

It could be reported either place. I'm sure it applies to the underlying library as well. I recall this being reported and possibly even addressed in the IRC library, but perhaps the fix didn't automatically enable the functionality.
Do feel free to explore the codebases and devise a solution. I think it would be quite reasonable for the service to periodically poll the server and timeout.

Original comment by: Jason R. Coombs

Add example for TCP keepalive (ref #33)
→ <<cset 47d9b62af494>>

Original comment by: Jason R. Coombs

pmxbot has a keepalive feature. Set TCP keepalive in the config to some value (numeric seconds or a string like "5 minutes") and it will ping the server every interval, which should provide the necessary signal to fail the connection, crash, and thus restart.
Let me know if that doesn't fix the issue.

Original comment by: Jason R. Coombs


With multiple sub-request, calls count is invalid

With multiple sub-request, calls count is invalid we need to reset data for each symfony request.

@BenoitLeveque PR tagged as stable in the version 1.1.0


Update dependencies

📖 Description
Many updates were released in the last weeks/months, here a few lib updates; getting the boilerplate ready for Elixir 1.11 that will follow next!

Erlang 23.1
Alpine 1.12
Ecto 3.5
Phoenix 1.5
Absinthe 1.5

📝 Notes
erlang-crypto is not required with the update to Alpine 1.12.0, so I deployed the app to Heroku to validate FORCE_SSL and DATABASE_SSL are still fully functional!
https://elixir-boilerplate.herokuapp.com

🦀 Requesting reviewers for this pull request:

@charlesdemers (contributor with 0 commits in the last 90 days and 2 commits overall)
@garno (expert reviewer for the elixir stack)

Has not Elixir 1.11 been out officially as well?

Yes, I wanted to do the upgrade in a separate PR on purpose!


Wrong version strings

So, TypeScript 1.4.0 was released.
NPM tells me that there is a version 1.4.1, but no 1.4.0. The installed version 1.4.1 tells me Version <IP_ADDRESS> using tsc --version.
λ tsc --version
message TS6029: Version <IP_ADDRESS>

This can happen if you've installed Typescript tools for visual studio along with npm for example. Try verifying tsc is in your path
In my case for example i have this :
where  tsc

D:\Users\[your_username]\AppData\Roaming\npm\tsc
D:\Users\[your_username]\AppData\Roaming\npm\tsc.cmd
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.4\tsc.exe
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.4\tsc.js

In case the first result is for example C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.1\tsc.exe, that can be the reason you're have version <IP_ADDRESS>.
You can fix this by putting the path D:\Users\[your_username]\AppData\Roaming\npm\tsc after the one from visual studio in your path variable.

Thanks for the useful hint! The wrong version was due to I ran npm install typescript instead of npm install -g typescript. My bad.
Closed: Not an issue.

TypeScript 1.4.0 was released. NPM tells me that there is a version 1.4.1, but no 1.4.0.

@hastebrot This is still true and perhaps this issue should not be closed and just the body updated crossing out sections that were invalid.

@basarat typescript latest package published on NPM is version 1.4.1.

@erichillah yes. But its not a tagged release : https://github.com/Microsoft/TypeScript/releases and its unclear if its different from the v1.4.0 that comes with Visual studio.

I'll create a separate issue


OCPBUGS-22616: [release-4.14] Bump go.opentelemetry.io dependencies

/jira refresh

@ankitathomas please update your commit message to start with UPSTREAM: . Is there a corresponding PR to operator-framework/operator-controller that makes/made this change? We'd want the prefix to be UPSTREAM: 1234 with 1234 being replaced with whatever the upstream PR was. If there isn't an upstream PR, we should probably have one?

/label backport-risk-assessed

/label qe-approved

/label cherry-pick-approved


fix(POPUP): merge tile defaults when passing newly created tile object

We've overlooked the fact that user can pass a newly created tile object
to $scope.showPopup() in which case the tile defaults were not merged.
Explicitly merge defaults from the showPopup() call but avoid doing it
multiple times for tiles that have already had defaults merged by
checking a special cache key.
Fixes #553

It looks like openDoorEntry is actually broken now, although I do remember that it was calling openPopup internally. Unfortunately I don't have access to a PC to investigate.

When calling it programmatically, you mean?
This test tile appears to work for me:
                  {
                     position: [0, 8],
                     width: 2, height: 2,
                     type: TYPES.DOOR_ENTRY,
                     id: {},
                     icon: 'mdi-phone',
                     title: 'DOOR_ENTRY',
                     state: false,
                     layout: {
                        camera: {
                           type: TYPES.CAMERA,
                           objFit: 'contain',  // https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit
                           id: 'camera.weather',
                           refresh: 5000,
                           bgSize: 'contain',
                           fullscreen: {
                              type: TYPES.CAMERA,
                              refresh: 15000, // can be number in milliseconds
                              bgSize: 'contain',
                           },
                        },
                        page: {},
                        tiles: [
                           {
                              position: [0, 0],
                              theme: ITEM_TRANSPARENT,
                              title: 'SCRIPT',
                              id: 'script.test_script',
                              type: TYPES.SCRIPT,
                              state: false,
                              variables: {
                                 value: 'value from script',
                              },
                           },
                        ],
                     },
                  },

And if I add:
                     secondaryAction(item, entity) {
                        this.$scope.openDoorEntry(item, entity)
                     },

then that also opens the popup on long-click.

I am calling it is a similar way, popup opens up but none of the tiles inside are clickable.

I could probably envision some problems if the tiles are generated dynamically but otherwise not sure what might be the issue. I guess we can investigate when you have access to your code.

Ok, what I have is a CAMERA tile which has an action assigned to open the door entry:
 action: function(i) {
     this.$scope.openDoorEntry(TILES.DOOR_ENTRY_FRONT_GATE, {});
 }

For some reason it does look like defaults are not being merged as even item-clickable is not present but history does popup on long-press.

I guess that's because TILES is not part of the initial tiles configuration. We are doing a sweep over registered tiles on load to extend them with default values but that won't extend tiles that are "outside".
Will have to think how to fix that.

For some reason this also does not work:
action: function(item, entity) {
    this.$scope.openDoorEntry({
        type: TYPES.DOOR_ENTRY,
        ...
    });
}

So I'm not too sure about TILES.

Fixing in #664


equinix_metal_precreated_ip_block is not filtering by project_id

equinix_metal_precreated_ip_block should use ?include=project to capture the Project ID (or use Project Href to capture the ID and improve the performance of the API request).
Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Terraform Version

Affected Resource(s)

equinix_metal_precreated_ip_block

Terraform Configuration Files

data "equinix_metal_precreated_ip_block" "private_ipv4" {
  metro          = equinix_metal_device.controller.metro
  project_id     = local.metal_project_id
  address_family = 4
  public         = false
}

Debug Output
Error: could not find matching reserved block, all IPs were [ {}, {} ]

(Within the IP Reservation list, the project is missing the ID: Project:packngo.Href{Href:"/metal/v1/projects/a6295813-af11-462a-8dbe-84b05d9c1ead"})

Panic Output

Expected Behavior

Actual Behavior

Steps to Reproduce

terraform apply

References

#0000

My initial interpretation of the problem was incorrect.
Project ID is a required field when using this datasource. The project ID is part of the URL path used in the API query. There is no client-side filtering by project, it is server-side.
I'll start investigating this by adding tests that confirm the problem exists and then find a solution that resolves the broken tests.

=== CONT  TestAccDataSourceMetalPreCreatedIPBlock_basic
    data_source_metal_precreated_ip_block_acc_test.go:14: Step 1/2 error: Error running apply: exit status 1

        Error: could not find matching reserved block

          with data.equinix_metal_precreated_ip_block.test_metro_pubv4,
          on terraform_plugin_test.tf line 81, in data "equinix_metal_precreated_ip_block" "test_metro_pubv4":
          81: data "equinix_metal_precreated_ip_block" "test_metro_pubv4" {

        Error: could not find matching reserved block

          with data.equinix_metal_precreated_ip_block.test_metro_priv4,
          on terraform_plugin_test.tf line 88, in data "equinix_metal_precreated_ip_block" "test_metro_priv4":
          88: data "equinix_metal_precreated_ip_block" "test_metro_priv4" {

I believe the test here may be inaccurately assuming that the device public IPs should be accessible through this datasource. The IP API that we are using in this data source does not return those IPs, however.
We may just want to update the test to remove this and update the documentation to avoid confusion.


add flag crdts

added:

a wrapper flag DT
an Enable-Wins flag CRDT
a Disable-Wins flag CRDT

Thanks for the PR and sorry for the late reply.
I have two questions:

It looks like the enable-wins flag does not need the DisableTokens and the disable-wins flag does not need the EnableTokens. Is that correct or am I missing something? Is it needed to distinguish resets from other operations? If it is not needed, the implementation could be simplified a bit.

Do we need the tuple type included in this PR? I think a map datatype can be used whenever a tuple is required. So I would only add it, if it has some benefits over maps.

Regarding the flags, you're right.
Regarding the tuple, well it is a different data type than a dict:
(This tuple is a container of other elements. On create the number of elements, type and position of each element are fixed and what follows are updates/resets on these elements. A tuple forwards all operations to the relative embedded CRDTs. Deleting/removing an element of the tuple is not allowed, i.e. the tuple size id always fixed. Resetting the tuple means resetting all nested elements)

I cherry-picked the flag-crdt commits without the tuple. Maybe you can create a new pull request for the tuple, where we can continue the discussion about it.


header/store: Use RLock instead of Lock inside Append during adjacency verification

Ref https://github.com/celestiaorg/celestia-node/issues/861#issuecomment-1167378119

While syncLoop syncs and appends new headers to the store, the Lock might betaken by the processIncoming in Syncer for a fraction of a millisecond on every new header rcvd from the network, every  ~30-60sec, which is negligible so I would say this have pretty low priority and very minor optimization.


Remove unnecessary verification

In the function handle_challenge, both of the variables (enr, node_address) points to the same instance of NodeContact:

enr comes from the request_call.contact
node_address comes from the request_call.contact

So I think that the verification can be omitted. 💡

Yes, this looks right. The verification is not necessary as we're using the outbound identification.
I think this is an issue with the spec, in that we can't id the source in challenges.
I'm currently writing the update to v5.1. In v5.1 this check will be valid.
If you can fix the fmt formatting issues and get tests to pass, will merge this in.
Thanks!

Thanks for your review! I've fixed the formatting issue.


fix get active webview url

https://developer.apple.com/documentation/webkit/wkwebview/1415005-url?language=objc
by the way, close #150

@mathieudutour Can you review this?


Semihosting and STD*_FILENO

Hello,
when using semihosting and trying to send a message to stdout via write(STDOUT_FILENO,...), output goes to nowhere under pyocd, openocd does the expected output.
This is because "STDOUT_FILENO=1" according to C standards but pyocd expects it to be "2".  The sources (https://github.com/pyocd/pyOCD/blob/main/pyocd/debug/semihost.py#64) shows "STDOUT_FD=2" .
If one uses "2" on the target, the output appears.  In the sources mentioned, it is stated that "The fds must be non-zero according to the ARM semihosting spec".  (I've searched the spec but cannot find it)
Now I'm wondering who is mistaken?  C lib defines "STDOUT_FILENO=1" for ages and this is certainly an incompatibility.

Perhaps I have found the place in the spec: https://developer.arm.com/documentation/dui0471/g/Semihosting/SYS-OPEN--0x01-?lang=en
It states
Return

On exit, R0 contains:

    a nonzero handle if the call is successful

    -1 if the call is not successful.

But writes to stdout do not need any open().  So the spec is wrong as well at https://developer.arm.com/documentation/dui0471/g/Semihosting/SYS-WRITE--0x05-?lang=en when it says:
Entry

On entry, R1 contains a pointer to a three-word data block:

word 1

    contains a handle for a file previously opened with SYS_OPEN

Because, as said, stdout/stderr don't have to be opened.
For compatibility with the C library correct behavior on pyocd side would be to use the same values for the std* handles as the C lib does.

Newlib definitely does the expected behaviour in regards to opening stdio prior to its use, eg opening a file called ":tt" with various modes. Hopefully it's possible to support both behaviours.

Hmmm... I guess the spec of the C library is a little bit older than the Arm semihosting spec.  The values of the special file descriptors for stdio made it even into wikipedia, see https://en.wikipedia.org/wiki/File_descriptor.
Even the comment in https://github.com/pyocd/pyOCD/blob/main/pyocd/debug/semihost.py#105 says, that the values are 0/1/2.  But effectively they are 1/2/3, which is clearly wrong.
OpenOCD behaves as expected: "write(1, buf, sizeof(buf))" sends characters to stdout, pyOCD needs "write(2, buf, sizeof(buf))".
Greatest compatibility has to be achieved with the values 0/1/2 for stdin/stdout/stderr.
PS: I agree that handling of ":tt" is as expected.  But standard file descriptors 0/1/2 actually don't have to be opened

This is all kind of beside the point, but to be clear about what I'm thinking: What you're describing is the POSIX behaviour. But embedded systems are not POSIX compliant, and semihosting is not a standard feature of C. So the C library is responsible for complying with the semihosting specification. And actually, write() and read() are POSIX APIs, not part of the standard C library. So you could even go so far as to say it's a bug in the C lib because it provides POSIX APIs but doesn't correctly map them to the chosen I/O interface. But again, all beside the point because it doesn't help anyone.
The openocd behaviour is best thought of as an undocumented and uncommon extension. For instance, QEMU's Arm semihosting implementation doesn't appear to support it (just quickly checked the code). Nor do the other Arm semihosting implementations I'm familiar with in several debuggers.
Could you create a pull request to implement this? I'd be happy to merge it in. Otherwise it'll probably take a while to get implemented just because of the backlog.

I doubt that it was the point of Arms spec to rewrite POSIX.  But... I'm not Arm and perhaps they wanted it... incompatible.
I will prepare a PR and check the side effects of changing the constants.

Well, knowing a little of the history here… the semihosting spec was created back in the day of the early Arm RealView IDE and toolchain (>20 years ago). It had a custom C library (which is still included with AC5 and AC6) and a lot of semihosting integration. POSIX compatibility was probably far from their minds, as is true with most embedded systems even today. The details of the semihosting interface were published as a spec, got picked up by other tools, and was eventually ported to M-profile.
Anyway, thanks for your work on this. I'm all for being compatible with as many tools as possible. My apologies if I seemed to push back or be overly pedantic; I regularly work a lot with software and hardware specifications (at Arm, no less) so the details of how specifications are interpreted and implemented are a prime concern for me. 😄

Don't worry about the tone.  I already thought that I was too insisting ;-)
Your response times are quite refreshing which is very motivating.  Comparing to several other projects were you get the feeling talking to dead walls.
The actual patch is very simple.  But I'm currently struggling with the tests.  "test/unit/test_semihosting.py" seems to be at the wrong place.  It requires a probe to work.  And that's were I'm stuck: my probe/target doesn't seem to be accepted (it currently provides no target auto detect).  Any hints how to setup the probe/target under test manually to get the test run?

Well, my response times vary a lot depending on . Sometimes I'm really bad, and completely miss issues, and get far behind. So I definitely can't be commended about that… 😔 Otoh, I'm almost always quite responsive in the pyocd Slack workspace.
Thanks for the patch! And thanks for the comments about the test environment. It does have lots of issues, though.

PR merged, so closing this issue.


Failed to Set up Error after a month of trouble free use

The problem
I checked my devices screen to see my Nest Protect devices have an error showing a "Failed to set up" Error. I havent changed or done anything since my initial set-up where everything worked fine.
What version of this integration (ha-nest-protect) has the issue?
0.3.12
What version of Home Assistant Core has the issue?
i dont know
Device / Model
Nest Protect Battery, Nest Protect Hard Wire
Diagnostics information
No response
Home Assistant log
Logs
```
This error originated from a custom integration.
Logger: homeassistant.config_entries
Source: custom_components/nest_protect/init.py:126
Integration: Nest Protect (documentation, issues)
First occurred: 3:44:43 PM (1 occurrences)
Last logged: 3:44:43 PM
Error setting up entry Nest Protect for nest_protect
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 387, in async_setup
result = await component.async_setup_entry(hass, self)
File "/config/custom_components/nest_protect/init.py", line 126, in async_setup_entry
hass.config_entries.async_setup_platforms(entry, PLATFORMS)
AttributeError: 'ConfigEntries' object has no attribute 'async_setup_platforms'

</details>

### Additional information

Home Assistant Core
2023-05-13 15:43:22.445 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration nest_protect which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-05-13 15:44:43.023 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Nest Protect for nest_protect
File "/config/custom_components/nest_protect/__init__.py", line 126, in async_setup_entry
2023-05-13 18:08:04.475 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Nest Protect for nest_protect
File "/config/custom_components/nest_protect/__init__.py", line 126, in async_setup_entry

This happens when you do not run version 0.3.12. Please reinstall 0.3.12 and this issue should be gone.
.

@emersonsc try to be a bit more polite next time and perhaps people actually want to help you.
See here the code of version 0.3.12, https://github.com/iMicknl/ha-nest-protect/blob/v0.3.12/custom_components/nest_protect/init.py. It does not contain async_setup_platforms. Previous versions did contain this.
Perhaps you are using a fork where they modified the version number? Otherwise I would be clueless how you can have this error and run 0.3.12.

@emersonsc try to be a bit more polite next time and perhaps people actually want to help you.
See here the code of version 0.3.12, https://github.com/iMicknl/ha-nest-protect/blob/v0.3.12/custom_components/nest_protect/init.py. It does not contain async_setup_platforms. Previous versions did contain this.
Perhaps you are using a fork where they modified the version number? Otherwise I would be clueless how you can have this error and run 0.3.12.

I'm not sure how I was being rude, I was simply pointing out the fact you told me to use a version I'm already running.
As far as using another fork, I don't see how that would be possible. The install was done directly for your github page using your instructions. Unless you readme files happen to have links to forks other than your own, I just dont see how that would be possible.

Can you make a zip file of the component (via your custom_components folder) and share this via email? (see my profile).
Did you install the integration manually via GitHub, or did you use HACS? When did you update the integration for the last time?

@iMicknl if it helps, I'm having the exact same issue as OP down to the same error. I even re-installed the latest version from HACS today to re-confirm I'm up-to-date.
Logger: homeassistant.config_entries
Source: custom_components/nest_protect/init.py:126
Integration: Nest Protect (documentation, issues)
First occurred: 1:09:54 PM (1 occurrences)
Last logged: 1:09:54 PM
Error setting up entry Nest Protect for nest_protect
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 387, in async_setup
result = await component.async_setup_entry(hass, self)
File "/config/custom_components/nest_protect/init.py", line 126, in async_setup_entry
hass.config_entries.async_setup_platforms(entry, PLATFORMS)
AttributeError: 'ConfigEntries' object has no attribute 'async_setup_platforms'
Happy to assist if you need anything else to evaluate this, as I find this to be a valuable integration I'd like to keep stable.

@hindsight2021 could you perhaps make the zip file as requested above? Are you sure you are using my version? Don't you have a custom repository set up in HACS? The community fork did use the same README and name, so hard to distinguish.
Did you use cookie method or the previous auth method?

@iMicknl sent you my zipped components folder (email).
It's been a LONG time since I've set this up, but I want to say I followed your guide, I did add a custom repository, so this could be a factor.
I'm 99% sure I used the cookie method, and it was stable up until this past couple of weeks much like OP.

@hindsight2021 you are using version 0.4.0 according to your manifest.json... So not 0.3.12. You are actually using a fork, and not the code from this repository.
Please migrate back to my repository / install https://github.com/iMicknl/ha-nest-protect/releases/tag/v0.4.0b1 manually. This version is for the cookie authentication, and doesn't break on 2023.5.

I had a sneaking suspicion.
I've obliterated the fork, manually installed your latest beta/release in custom_components and removed the custom repository that somehow made it into my system in the past, I will attempt re-authing and advise as soon as I can. Thanks for your help!

@iMicknl all set, I didn't even need to re-auth, it picked up on restart where it left off on my previous authorization before the 2023.5 update.
This will probably be OP's resolution too.

Used 0.4.0b1 after it broke and it seems happy now

I ended up having to delete the integration from HACS. Restart HA, reinstall through HACS, then use the 0.4.0b1 version because the 0.3.12 still wouldnt work.


Internal Server Error on service principal credential reset and delete

Describe the bug
When using the az cli, an internal server error is thrown when using az ad sp credential delete --id xxxxx --key-id xxxxx --verbose and az ad sp credential reset --id xxxxx
Related command
az ad sp credential delete, az ad sp credential reset
Errors
Encountered an internal server error.
Issue script & Debug output
urllib3.connectionpool: Starting new HTTPS connection (1): graph.microsoft.com:443
urllib3.connectionpool: [https://graph.microsoft.com:443](https://graph.microsoft.com/) "POST /v1.0/servicePrincipals/xxxxx/removePassword HTTP/1.1" 500 None
cli.azure.cli.core.util: Response status: 500
cli.azure.cli.core.util: Response headers:
cli.azure.cli.core.util:     'Cache-Control': 'no-cache'
cli.azure.cli.core.util:     'Transfer-Encoding': 'chunked'
cli.azure.cli.core.util:     'Content-Type': 'application/json'
cli.azure.cli.core.util:     'Content-Encoding': 'gzip'
cli.azure.cli.core.util:     'Vary': 'Accept-Encoding'
cli.azure.cli.core.util:     'Strict-Transport-Security': 'max-age=31536000'
cli.azure.cli.core.util:     'request-id': 'xxxxx'
cli.azure.cli.core.util:     'client-request-id': 'xxxxx'
cli.azure.cli.core.util:     'x-ms-ags-diagnostic': '{"ServerInfo":{"DataCenter":"North Central US","Slice":"E","Ring":"4","ScaleUnit":"003","RoleInstance":"CH01EPF0002DB15"}}'
cli.azure.cli.core.util:     'x-ms-resource-unit': '1'
cli.azure.cli.core.util:     'Date': 'Tue, 16 Jul 2024 12:33:03 GMT'
cli.azure.cli.core.util: Response content:
cli.azure.cli.core.util: {"error":{"code":"Service_InternalServerError","message":"Encountered an internal server error.","innerError":{"date":"2024-07-16T12:33:03","request-id":"xxxxx","client-request-id":"xxxxx"}}}

Expected behavior
When a user has the proper permissions to delete or reset the credentials on a service principal, they would be able to do this without encountering an internal server error.
Environment Summary
azure-cli                         2.62.0
core                              2.62.0
telemetry                          1.1.0
Extensions:
account                            0.2.5
aks-preview                      0.5.174
kusto                              0.5.0
Dependencies:
msal                              1.28.1
azure-mgmt-resource               23.1.1
Python location '/usr/local/Cellar/azure-cli/2.62.0/libexec/bin/python'
Extensions directory '/Users/jpacheco/.azure/cliextensions'
Python (Darwin) 3.11.9 (main, Apr  2 2024, 08:25:04) [Clang 15.0.0 (clang-15<IP_ADDRESS>)]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.
Additional context
This occurred for all team members who attempted to delete or reset credentials.

Thank you for opening this issue, we will look into it.

I'd like to ping this as I'm also encountering the "Internal Server Error" attempting to reset the sp credential of an App Registration linked to an Enterprise App.
(Specifically I'm attempting to generate a Client Secret via the CLI)
This works for other App Registrations, but gives Encountered an internal server error for the app registration that's linked to the Enterprise App, in this case for our AWS Organisation (SSO).


Missing midi.h

Fresh install of Arduino IDE does not have a midi.h file and end up with compile error.
Please update repo or add a page to the docs that one will need to download a lib

Also, as I found out, it seems like you miss LoopMidi installation. But that is a mandatory part of putting it all together,

Added to the readme thanks 👍🏻


Support in landscape mode in tablets

[ ] I have checked that a similar feature request does not already exist.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Scrcpy is not supporting landscape mode in Tablets
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

I don't understand the issue. Scrcpy rotates automatically according to the device orientation.
And there is absolutely zero explanation in this issue, so I'm closing. Feel free to reopen with more information.


Some deployed cni plugins are not statically compiled

Describe the bug
On an alpine-based native server (which is itself based on busybox), /opt/cni/bin/antrea cannot execute due to being dynamically linked to some system libraries. This is not the case for some other standard plugins, such as loopback.
To Reproduce
Try to run antrea cni plugin binary on a busybox system or alternatively with incompatible libpthread or libc. In particulary, it didn't work on k3os.
Expected
As with other cni plugins, it should be statically compiled so that Antrea can be deployed on any system.
Actual behavior
Antrea cannot be deployed successfully (spawning non-host containers fails when network plugin is calling /opt/cni/bin/antrea).
Versions:

Antrea version: 1.0.0
Kubernetes version: 1.20
Container runtime: containerd
Linux kernel version: 5.4.0

Additional context
None.

Hi @nitrotm, thanks for the report! Making antrea cni binary statically compiled makes sense to me. It applies to other binaries that will run out of container too, e.g. antctl, antrea-octant-plugin.
Or maybe we could just compile all of the binaries statically if no real drawbacks. What do you think? @jianjuns @antoninbas
@nitrotm would you be willing to create a PR for this?

And to confirm, I assume the issue could cause the container runtime fail to call antrea cni, but it shouldn't fail on initContainer of antrea-agent while installing cni. Could you paste the failure of initContainer if there is? I couldn't reproduce it with k3os.

Agreed on compiling Antrea CNI statically.

@tnqn sorry, that's right, not related to initContainer. I was trying a whole bunch of different cni solutions (calico, cilium, kube-ovn, etc) and forgot the exact root cause of the error. I did the deploy from scratch again and here is more detailed info:
If you deploy antrea and start a simple pod (eg. busybox), then you'll see the following in the events:
│   Warning  FailedCreatePodSandBox  48s   kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "aa771c57bc881ace3ec1548653ca27f7382940d4c312893576a5432d5b46af9d": netplugin failed with no error message: fork/exec /opt/cni/bin/antrea: no such file or d │

But the file is there on the host /opt/cni/bin/antrea, simply not executable, and ldd reports:
$> ldd /opt/cni/bin/antrea
        /lib64/ld-linux-x86-64.so.2 (0x7f30d161b000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f30d161b000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f30d161b000)

which indicates some kind of library issue (eg. it looks like libc/libpthread linkage are impossible to satisfy in this busybox setup).

As per the question about creating a PR, I am probably not the right person for doing this right now because I feel I don't know yet enough about CNI internals and practically nothing about the way antrea is built and packaged.
I'll give antrea a try when this is solved and eventually will replace calico in my self-provisioned k8s clusters, depending upon how well it will fit my use-case. In the case a migration to antrea makes sense, I would be more keen on contributing to the project in the future.

Thanks for reporting this @nitrotm. I can look into this before the next release (Antrea v1.1). Will assign this to me, but if someone wants to start working on this, please comment here and I can assign the issue to you.


The link to MBIM v1.0 is no longer valid...

The updated link should be: https://usb.org/document-library/mobile-broadband-interface-model-v10-errata-1-and-adopters-agreement

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

ID: 1613c72c-8238-610e-8ed8-9faeff44f339
Version Independent ID: 391c4c45-1d34-fbe1-3fea-b3eb55e279ed
Content: Mobile Broadband Implementation Guidelines for USB Devices - Windows drivers
Content Source: windows-driver-docs-pr/network/mobile-broadband-implementation-guidelines-for-usb-devices.md
Product: windows-hardware
GitHub Login: @tedhudek
Microsoft Alias: windowsdriverdev

Thanks, @jefsong.
Updated link. Should be live shortly.

Thanks for taking care of that @EliotSeattle!


Implement the Geek theme so that we can take advantage of their UI/UX patterns

Describe your change in plain English.
This PR installs the https://geeksui.codescandy.com/ stylesheets and modifies a few pages as a short proof of concept. A few notable bits:

Removes all custom CSS in favor of trying to keep it consistent with the theme (we can in a future PR just update styling later, imo)
This doesn't include the JS from GeeksUI. I think we can handle that later if we need it
Adds https://github.com/comfy/active_link_to which handles adding 'active' to nav links easily.

Demo

Link to the issue
N/A

I love the look already. I also learned why coupling tests with DOM elements may not be ideal...makes front end changes harder to make.

@kasugaijin all good :) -- I recorded a quick video of where the state of this PR is - https://jam.dev/c/d3d87a13-3add-423d-bdfb-2d97f51c9da5. In summary, I'am wanting this to be a foundational spot that we can start building ontop of. That being said there are some rough spots that we can address as we  develop further.
If this is looking good to you could you toss me an approve and we'll start picking parts to enhance?


websockets: Count pings from server as activity for idle_timeout

If the stream is receiving control packets like ping, don't count it as idle. This means you can enable timeout_opt.keep_alive_ping on only one side to get heartbeat.
Addresses issue #2716

Can't this be configured already?
beast::websocket::stream_base::timeout to;
my_ws.get_option(to);
to.keep_alive_pings = true;
my_ws.set_option(to);

This PR changes the behavior when keep_alive_ping is false.
Without the change: receiving control frames does not count as "activity"
With the change: receiving control frames counts as activity
I could make that behaviour change another config member of the timeout struct if wanted.

I understand that - but why? Isn't setting the option achieving the same thing? What's the difference?

Ah. The setting makes you send ping frames at an even interval. This change counts incoming control frames as activity regardless of whether or not you are sending pings yourself.

Receiving control frames is not activity.
So we would need another option to allow the pings to be counted as such. This all seems off to me, why don't you just send pings or increase the timeout?

I first reported this because I was confused by the idle_timeout / keep_alive_pings config options; Since a pong is activity when you've sent a ping, shouldn't a ping be activity as well?
If not, timely disconnect detection needs ping and pong to be sent in both directions, doubling the number of packets sent/received for no additional benefit.
Not a big issue, but I feel counting ping as activity is the more intuitive behaviour. Adding this as a bool incoming_ping_keepalives = false option also makes sense if keeping the old behaviour as default is a priority.

Updated the PR with tests, @ashtum
I feel using a second wall clock time may be excessive, but seems to be somewhat in line with what other tests have done

Can/should I add/change documentation somehow? Is it sufficient that I update the inline documentation in stream_base.hpp?

Yes, please update the docs here as well (if there is anything related).

@xim Anything I can help with?

Sorry, @ashtum, this just disappeared in the Big Pile of Stuff. I'll try to update docs on Monday

Apologies for forgetting about the documentation update. I rebased on develop, added documentation and pushed again.

I'm happy with this now. If you want me to squash all commits, or fixup my fixup, or anything, just give the word =)

This can be squashed on our side, this looks like a single commit.
From what I can tell @vinniefalco approves the behavioural change, so everything looks good to me.

Looks like one of the tests has a timer that's 500ms and expects it to have been triggered after 600ms. I'll make it more permissive.

Made that 750ms, effectively bumping the slack from 100ms to 250ms

Apologies for the noise. Tweaking these values is hard.

@xim Why did you alter the timing values in the tests? Did you encounter any failures as a result of the tight timings?

Yes. I had to increase/change margins many times before all the different CI builders were green at the same time. The original timing worked once across the board, but not on the next run. The current timing should be stable.
I'd love to see these tests run with stubbed time, for stability and execution speed. But don't know if that's readily available.

Hey @xim, I wanted to let you know that I've decided to review and merge this after the 1.84 release. I reckon it might be risky to do it for 1.84.

I have, for now, implemented most of the desired behaviour on top of the control callback. Looking forward to cleaning up that code ^_^

Why shouldn't control frames count as activity?

Why shouldn't control frames count as activity?

 If so, we had a discussion in https://github.com/boostorg/beast/issues/2716. The idea is that receiving any form of frame from the other side can be an indication that it is still active.

No. I am asking what the rationale would be, if any, to NOT count control frames as activity. I cannot think of one. But that doesn't mean it does not exist (even if the rationale is weak).

I am asking what the rationale would be, if any, to NOT count control frames as activity.

Maybe if you want to throw out sessions that "aren't doing anything" at an application level?
Not arguing for this being sensible, just answering the hypothetical =)

Based on the source code, we have been treating the control frames as activity from the beginning (by setting idle_counter to zero). It is this branch in the code that has caused the timeout: https://github.com/boostorg/beast/blob/d0dd9c50694bcbb8836775e780eb046f66b3e1d7/include/boost/beast/websocket/impl/stream_impl.hpp#L572
I don't know whether this behavior has been intentional or accidental.

Based on the source code, we have been treating the control frames as activity from the beginning

Yes, but only when the option keep_alive_pings is set. So pings and pongs only count as activity if you're sending pings.

Yes, but only when the option keep_alive_pings is set. So pings and pongs only count as activity if you're sending pings.

I mean we have been setting idle_counter to zero unconditionally.

I mean we have been setting idle_counter to zero unconditionally.

Yes, but without keep_alive_pings the value of idle_counter is ignored and we go straight to timeout.

Yes, but without keep_alive_pings the value of idle_counter is ignored and we go straight to timeout.

Yeah, my point was that this might have been an unintentional behavior because we wanted to only send the ping message when keep_alive_pings is set and accidentally ignored the situation when idle_counter is zero and keep_alive_pings is unset.
Besides that, other parts of the code show that we have been counting control frames as activity (by unconditionally setting idle_counter to zero).

@xim, could you please squash these commits into a single commit?

Yeah, the timing there is apparently night-impossible to get correct in a way that always passes on all platforms. In that one case, a ping hasn't been processed within 400ms. I can increase everything 25% again so it's 500ms. But is anyone has a way of running these tests with stubbed time, that would be preferable...

The failures appear unrelated to my commit

@xim, I've removed the idle_counter assertions in the hope that this will reduce the chance of getting non-deterministic test results. Let's see if we can run CI multiple times with all tests passing.

Testing out a new docs servers, there may be another "automated preview" shortly on this pull request.


Terragrunt project failing to apply due to locks acquired when planning PR

I had this project that is failing to apply, seems to be around the locks due to the messages posted on the logs.
I checked the code, and it gets past line https://github.com/diggerhq/digger/blob/77ee0b1a082838696cb46dad872016790643f9ab/cli/pkg/digger/digger.go#L392 because of the message, then somehow it doesn't apply:
Following commands are going to be executed:
project: organizations_fastnorth_repositories_github-actions: commands: "digger apply",
project: organizations_fastnorth_repositories_github-docker-build: commands: "digger apply",
project: organizations_fastnorth_repositories_github-ecs-deploy: commands: "digger apply",
project: organizations_fastnorth_repositories_github-ecs-job-controller: commands: "digger apply",
project: organizations_fastnorth_repositories_github-stats: commands: "digger apply",
project: organizations_fastnorth_repositories_github-tf-static-analysis: commands: "digger apply",
project: organizations_fastnorth_repositories_github-utils: commands: "digger apply",
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-actions' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-actions
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-docker-build' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-docker-build
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-ecs-deploy' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-ecs-deploy
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-ecs-job-controller' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-ecs-job-controller
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-stats' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-stats
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-tf-static-analysis' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-tf-static-analysis
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-utils' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-utils
Lock result: false
Commands executed successfully
Digger finished successfully

Hi there, thanks for reporting! Seems you are using digger in backendless mode. Any more context around your workflow file and digger.yml would help debug firthwr the issue

This is my digger.yml:
---
allow_draft_prs: true
generate_projects:
  blocks:
    - block_name: fastnorth
      root_dir: organizations/fastnorth/
      terragrunt: true
      terragrunt_parsing:
        parallel: true
        createProjectName: true
  auto_merge: true

And this is my workflow file:
---
name: Digger terraform CI

on:
  pull_request:
    branches: ["main"]
    types: [closed, opened, synchronize, reopened]
  issue_comment:
    types: [created]
    if: contains(github.event.comment.body, 'digger')
  workflow_dispatch:

jobs:
  digger:
    permissions:
      actions: write        # required for plan persistence
      contents: write       # required to merge PRs
      id-token: write       # required for workload-identity-federation
      pull-requests: write  # required to post PR comments
      statuses: write       # required to validate combined PR status

    runs-on: ubuntu-latest
    timeout-minutes: 60  # Same as the OIDC validtity time for now

    steps:
      - name: digger run
        uses<EMAIL_ADDRESS>        with:
          setup-aws: true
          aws-role-to-assume: "arn:aws:iam::************:role/tf/github-terraform-digger"
          setup-terraform: false
          setup-tfenv: true
          setup-terragrunt: true
          terragrunt-version: 0.58.14
          configure-checkout: true
          no-backend: true
          cache-dependencies: true
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GITHUB_CONTEXT: ${{ toJson(github) }}
          TF_VAR_github_token: ${{ secrets.ADMIN_TOKEN }}

One more piece of information.
I just tried issueing a digger unlock first. And then another digger apply. Then it works.
But the lock was acquired when the PR was opened, and I believe that a digger apply for that same PR should re-use that same lock, and unlock when it's finished applying, and then merge.

I am having a similar issue, when I create a pull request my plan runs.  Once i have a successful plan, i have to run digger unlock and then digger apply to apply my terraform.

I rolled back to v0.5.10 and it's working as expected now. So the issue seens to have been introduced on 0.5.11

Thanks folks for chiming in with these details to repro. Thanks @carcunha for helping pinpoint the version of the error. I'm suspecting its related to our recently introduced flag in digger.yml to disable locking from there #1586 #1578 so will start to look from there for something that could have caused it.


in an array the last object is not allowed to have an empty array

Hi,
I'm getting an exception, if there is a json structure with an element with an empty array.
[INFO] --- spring-cloud-contract-maven-plugin:1.2.0.BUILD-SNAPSHOT:generateTests (default-generateTests) @ spring-cloud-contract-issue-reproducer ---
[INFO] Generating server tests source code for Spring Cloud Contract Verifier contract verification
[INFO] Will use contracts provided in the folder [/home/martin/development/git/spring-cloud-contract-issue-reproducer/src/test/resources/contracts/parsingproblem]
[INFO] Directory with contract is present at [/home/martin/development/git/spring-cloud-contract-issue-reproducer/src/test/resources/contracts/parsingproblem]
[INFO] Test Source directory: /home/martin/development/git/spring-cloud-contract-issue-reproducer/target/generated-test-sources/contracts added.
[INFO] Using null as base class for test classes
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.367 s
[INFO] Finished at: 2017-07-19T13:23:17+02:00
[INFO] Final Memory: 37M/437M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.springframework.cloud:spring-cloud-contract-maven-plugin:1.2.0.BUILD-SNAPSHOT:generateTests (default-generateTests) on project spring-cloud-contract-issue-reproducer: Execution default-generateTests of goal org.springframework.cloud:spring-cloud-contract-maven-plugin:1.2.0.BUILD-SNAPSHOT:generateTests failed: Parsed JSON [{"node":{"id":7268,"children":[{"id":7269,"children":[],"references":[{"id":7284}]},{"id":7274,"children":[],"references":[]}],"references":[]}}] with the JSON path [$.['node'].['children'][*].['references'][*]] is not empty! -> [Help 1]

I will post here the sample soon
is there any way to ignore the emptiness on generation?

Can you paste your contract?

https://github.com/mlem/spring-cloud-contract-issue-reproducer, second issue
org.springframework.cloud.contract.spec.Contract.make {
    request { // (1)
        method 'PUT' // (2)
        url '/fraudcheck' // (3)
        body([ // (4)
               clientId  : $(regex('[0-9]{10}')),
               loanAmount: 99999
        ])
        headers { // (5)
            contentType('application/vnd.fraud.v1+json')
        }
    }
    response { // (6)
        status 200 // (7)
        body( [
                node       : [
                        id             : 7268,
                        children           : [
                                [
                                        id             : 7269,
                                        children           : [],
                                        references: [
                                                [
                                                        id: 7284
                                                ]
                                        ]
                                ],
                                [
                                        id             : 7274,
                                        children           : [],
                                        references: []
                                ]
                        ],
                        references: []
                ]

        ]
        )
        headers { // (9)
            contentType('application/vnd.fraud.v1+json')
        }
    }
}

Ok I know why... That's because we use the following JSON Path
$.['node'].['children'][*].['references'][*]
That [*] means that we assume that there will be ANY entry that matches that JSON Path. In your case you have mutually exclusive values. One references array is empty and one is not. I guess your only way is to go with an additional testMatchers section and manually rule out the empty arrays.

thanks for that hint.
fixed by adding

        testMatchers {
            jsonPath("\$.['node'].['children'][*].['references'].[*]",byType { minOccurrence(0) })
        }

to response in contract

Yup that's a good approach!

one more thing.
such a response structure still delivers a wrong test:
			assertThatJson(parsedJson).field("['node']").array("['children']").array("['references']").isEmpty();
This test ist correct for the second child, but not for the first one. so my tests are breaking.
Do I need to add for each child a testmatcher? So if there are 6 children, I need to add six times a testmatcher or how does it map?

So when you're using a test matcher it will delete all automatically created tests. So if you manually want to test an array $.a.b that has c and d elements, then when you create a test matcher for $.a.b, then you'll have to create the matching for c and d yourself.
Remember that doing [*] will go through all elements of the array. That's why you have to be careful how you do matching by yourself. With such a matching
            jsonPath("\$.['node'].['children'][*].['references'].[*]",byType { minOccurrence(0) })

you'll have to do a test matcher for every single child. Or you can call byCommand and do the assertion in the code.

I've got the matcher wrong.
It was something like this:
 jsonPath("\$.['node'].['children'][*].['references'][*]",byType { minOccurrence(0) })
I shoud've done
 jsonPath("\$.['node'].['children'][*].['references']",byType { minOccurrence(0) })
or easier:
 jsonPath("\$.node.children[*].references",byType { minOccurrence(0) })
With such testMatchers it doesn't generate isEmpty checks anymore


get_validator

Coverage decreased (-0.01%) to 91.358% when pulling 4a2adf5b395dc212f2af685177ba8aef402021c7 on antgonza:get_validator into fe5e4dc78b840883dfc66f668262e979c7009b57 on biocore:master.

Coverage decreased (-0.02%) to 91.348% when pulling 9608bf6e84a35b4887dbfa2911a8f08e11ef3a6e on antgonza:get_validator into fe5e4dc78b840883dfc66f668262e979c7009b57 on biocore:master.


Cache tarpaulin on Travis CI

Currently the recommended instructions say to use cargo install -f, which always rebuilds tarpaulin even if it's already installed. Removing the -f caches the build if it already exists, which can speed  up builds by 10 minutes or more.

It's worth noting that prior versions of cargo did not update already-installed packages. I believe this is why the -f flag is needed; this ensures that you are always running the latest version of cargo-tarpaulin, which is helpful given the current behavior of Cargo.
In rust-lang/cargo#7560, soon to be released in Cargo 1.41.0 which is scheduled for approximately a month from now, the install-upgrade feature has been stabilized. With this feature, cargo install will also upgrade existing installations, and those running beta or nightly will already have this behavior.
However, since the install-upgrade behavior hasn't reached stable Rust/stable Cargo, I'd say this change to the README should wait until it has, just to avoid confusion.

I believe this is why the -f flag is needed; this ensures that you are always running the latest version of cargo-tarpaulin

As an end-user, I don't particularly care whether I'm running the latest and greatest version of tarpaulin. I do care about having builds run 10 minutes faster though.

Don't worry about what I think! :grin: I like this change, I was just adding some context to why -f is needed.
Digging further, I stand corrected. I think the main reason we needed the -f flag was actually nightly-to-nightly breakage which appears to no longer be a factor for us, as of daf432ab1c0ee774ff1c906fdd7ff6a934303d99, which removed the need to opt into the semver_exempt bits of proc-macro2.
I should expand on what I said, just for completeness, and note one other quirk with Cargo's current behavior. The current (stable) behavior of cargo install is that it exits angrily if you already have cargo-tarpaulin installed:
[kristofer@meson ~]$ cargo +stable install cargo-tarpaulin
    Updating crates.io index
error: binary `cargo-tarpaulin` already exists in destination as part of `cargo-tarpaulin v0.10.0`
Add --force to overwrite

(Here, Cargo exited with with status 101.) So if we remove the -f flag from the recommended Travis invocation right now (and people follow that change) they will start getting the above error message if they already have cargo-tarpaulin installed, e.g. if they are using a cached previous installation of cargo-tarpaulin. With beta Cargo, though, this changes to
[kristofer@meson ~]$ cargo +beta install cargo-tarpaulin
    Updating crates.io index
     Ignored package `cargo-tarpaulin v0.10.0` is already installed, use --force to override

which is printed before Cargo exits with status 0, indicating success. This is a much softer failure, and perfectly pairs with this PR.

I do see and wholeheartedly agree with the motivation here. An installation of cargo-tarpaulin with -f requires building from scratch 150+ packages, and doing this for every build is definitely wasteful.
My only nit is that if this change is released before v1.41.0 of Cargo is released, the (modified) recommended configuration would produce errors on stable (v1.40.0) Rust builds with cached cargo-tarpaulin installations until those builds get Cargo 1.41.
Perhaps a temporary change could be to
before_cache: |
  if [[ "$TRAVIS_RUST_VERSION" == stable ]]; then
    cargo install cargo-tarpaulin -f
  elif [[ "$TRAVIS_RUST_VERSION" == beta ]] || [[ "$TRAVIS_RUST_VERSION" == nightly ]]; then
    cargo install cargo-tarpaulin
  fi

Here stable still needs -f to prevent build failures, but the beta and nightly versions, with the new behavior, would skip installing if cargo-tarpaulin was already installed and up to date.

The reason force was in there was because before proc-macro stabilisation when you had to run tarpaulin on nightly it would only work on projects built with the same nightly version as it was built with which would cause CI crashes when a new nightly was released and tarpaulin was cached in CI.
That's no longer the case so I'll merge this :+1:

Ah hadn't realised that change wasn't in cargo stable currently. 1.41 is set to be released 2020-01-30 so if I'm set to release another version before then I'll add a note to the readme

Here, Cargo exited with with status 101

This doesn't cause a build failure because it's in before_cache.


feat: add different color on missing internal links + option to "hide" them

New to Quartz, I did a quick evolution to #454, hope it won't break anything ...
In quartz.config.ts color theme, a new 'error' color attribute is configured (default : #ff8484 = a light red) it modifies missing links color (if none is configured, it fallback to "--darkgray")
+ a new option hideMissingLinks: true (default = false) on Plugin.CrawlLinks() so the Popover Previews and clicks on missing links and CSS style is "unset"

closing due to staleness, feel free to let me know if you want to keep working on it!


Bindings/Commands not compatible with the browser

Right now we are using await fs.readFile for reading the modules content. However, that API will never work in a browser.
We need to move back to the new URL(base, imports.meta....) to make sure the code is usable in both the browser and servers

@SadraMoh sorry, I don't believe there is a workaround for this - you would need to fix the underlying code. Unfortunately, I no longer work at Wasmer and don't believe this project is being actively worked on by the Wasmer team.


feat: add cdn conf

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)

@raisedadead this is modelled on the devdocs config, albeit simplified a bit. I'd like to test this out on a staging instance before deploying for real, but I think it's basically fine.

Can I take a look at the devdocs configs for comparison?

Sure, https://github.com/freeCodeCamp/devdocs-nginx-config is what's currently live on the proxies.

Hi @ojeytonwilliams
While I am happy with these changes. I think as discussed; we can use CF to S3 Mapping directly. If you are interested please go ahead and tighten the bucket permissions as you see fit like you mentioned during the call.


Modbus: During tx some line drivers have interference on the rx line …

…this causes the rx callback to be triggered which will then corrupt the tx buffer since it is shared between rx and tx
Since there is only ever supposed to be a send or receive interrupt at once we can make them exclusive.
Signed-off-by: Erik Kallen<EMAIL_ADDRESS>

Replaces #17


Fix for MacOS/Darwin Arch

Starting with version 0.24.0 the artifact name for Darwin (MacOS) changed the architecture name to all.
This implements a check to try and pick the right arch version for Darwin based on the new naming scheme.
Additional shell check fixes

Hi @johnhamelink, here's a PR that tries to work around the new naming for tekton-cli artifacts.

Thank you! Merged


Support links to sidebar sections

In Notion, you can of course link to one of the pages that serve as sections in the outline. But when docu-notion sees such a link, it doesn't find the page, and logs

Could not find the target of this link. Note that links to outline sections are not supported. ded7393e-8194-4a68-ac04-81839baadac3

Docusaurus does now support links to sidebar sections that have auto-generated table of contents for the direct children. So if a project turned on that capability, it would make sense for docu-notion to be able to generate the link to get to it.

You did figure out to make this work for https://docs.bloomlibrary.org/Release-Notes, but I'm not sure how to document what you did here.
Is it simply that you created an index page with a slug which matches the title of the group?

Right. To make this work in Docusaurus, you have to add an index page for the folder, and set the slug to the folder.
Example: when you click here:

that takes you to https://docs.bloomlibrary.org/Release-Notes, and this works because there is this Notion document:


The skybox makes the second view of the camera disappear

Link to this subject:
https://forum.babylonjs.com/t/gizmo-multiview-and-skybox/13329/2?u=dad72
Repro

Bug repro on playground:
Expected: Display of both views
Current result: The skybox makes the second view of the camera disappear

Well this is expected as the viewport of the camera1 is overlapping. The solution is to add camera1 first but I guess this introduces another issue right?

Yes exactly
The second problem that this produces is on this PG :
https://www.babylonjs-playground.com/#Z4ZGAY#18

For more information, the Gizmo should be on camera1
But the cameraGIzmo disappears and the GizmoManager is found on Camera2

Here is your fix:
You need to tell the gizmo layers to pick the camera1:
https://www.babylonjs-playground.com/#Z4ZGAY#22
Line 43 / 44


Custom checkbox for Identity/Ego.

Create custom checkbox for adding/removing Identity and Ego from Party.
Place it in the top right corner of item to free up space for additional information in the middle.

Created custom RemoveFromPartyButton and InPartyCheckBox.