Bug: Extension doesn't detect problem is solved

I am using the new leetcode dynamic UI. (https://leetcode.com/discuss/feedback/4041069/Feedback%3A-Dynamic-Layout-is-technically-impressive-but-poor-design-and-UX.)
And now when I solve the leetcode gulag extension problem of the day the extension does not let me browse the internet.
Browser: Brave browser

Uploaded a new version to the public webstore with some small changes that should be coming in a few days. Let me know if that issue still happens when its public, or clone this repo to test it out right now. I've seen this happen sometimes, but I'm not too sure myself. Hopefully this minimizes/removes this bug.

still happening
https://youtu.be/Ot8Be4OPh6M

hmmm I'm not sure why this happens only sometimes. I'm curious if anyone can figure out where it's not working. It has to be in the checkIfUserSolvedProblem function in background.ts or the congratuationModal's handleClick function is not executing. I'll see if I can figure anything out. But if anyone wants to try it out too, feel free because I'm confused.

I'd appreciate anyone that's contributing to provide some logs for the checkIfUserSolvedProblem function to see what's happening for these submissions that aren't being accepted.

Having this issue as well using brave, first issue is that brave seems to be denying it access to certain content the extension needs to work, to fix this, go to the extension settings and enable the setting that says Allow access to file urls,  second on in the console in dev to

ols, it is stating:

I added a possible fix, no clue if that really worked. I tested it on Chrome and Brave and seemed to work. Added small console messages too when submitting. Let me know if that worked on the development build.

Hey, tried to load the extension from the repo to test but it doesn't have a manifest.json, would I be able to just use a basic one or are there certain scopes you are using.

That does not appear to have fixed the problem.  No errors have shown up in the console and I have given it all permissions.  If there is a logs file I can send you, please let me know so I can do so

I just checked it, the development code works fine, but the extension on the web store does not

hmmm that's interesting can you screenshot the logs or drag them into this discussion. Some people have this issue and some don't, really has me confused lmao

Here's a Vimeo link showing the issue https://vimeo.com/865414717/2d6403a421
There are also no logs for the extension on the web store, maybe removing the logs also removed an important logic with it

hmmm that's interesting can you screenshot the logs or drag them into this discussion. Some people have this issue and some don't, really has me confused lmao

you're already immersed in the normal problems of business!

hmmm that's interesting can you screenshot the logs or drag them into this discussion. Some people have this issue and some don't, really has me confused lmao

you're already immersed in the normal problems of business!

Yep already hate it lmao. So the web store version isn't working, but is this current development version working? If it is, I can publish this new version for now since it might minimize the problem

hmmm that's interesting can you screenshot the logs or drag them into this discussion. Some people have this issue and some don't, really has me confused lmao

you're already immersed in the normal problems of business!

Yep already hate it lmao. So the web store version isn't working, but is this current development version working? If it is, I can publish this new version for now since it might minimize the problem

but because of you I got into leetcode for the first time in 4 years and even already solved 5 problems.

Yeah, it does work👍
You could try creating sprints, goals to be accomplished at the end of the week and then do a code review before choosing to deploy the newest update to leetcode
I'm sure there are a lot of videos of that on YouTube, and GitHub has a Kanban board at the Projects tab
The main branch will only be updated after the code review, and maybe even write tests before the start of each week's sprint
and only accept code that passes the test

Awesome, I think that's a pretty good idea to organize things a bit more and have proper version releases. I'll do research and see how I could do it. Would probably need to start by having important extension tests

hmmm that's interesting can you screenshot the logs or drag them into this discussion. Some people have this issue and some don't, really has me confused lmao

you're already immersed in the normal problems of business!

Yep already hate it lmao. So the web store version isn't working, but is this current development version working? If it is, I can publish this new version for now since it might minimize the problem

but because of you I got into leetcode for the first time in 4 years and even already solved 5 problems. And it seems like that I'm not the only one who did this.

Just wanted to say that's amazing. Did not expect this extension to actually be used, it was just a funny idea I had and wanted to try it out.

That would be cool! I'm looking forward to it! If it gets exhausting, you could move the sprints to more weeks, and GitHub actions could also help a lot with the automation of the tests! You'll basically be a project manager

Apparently this bug is still happening, to the people that have had this bug.
can you let me know:

What problem set you used (all leetcode problems, neetcode 150, blind 75, etc)
The problem it was (if you remember)
Browser you used.

Problem set used: All problems
Problem it was: Was issue with any problems as I unoaded and reloaded the extension giving me a new problem each time
Browser: Brave

Hi,
I had this issue as well.
Problem set used: All problems
Problem it was: I don't remember (sorry 😔)
Browser: Chrome
Not sure if it will help but I also set the problem difficulty to easy.

alright I just pushed a change in the code, can anyone test this out like a bunch of times. just resave the code to generate a new problem. I'm hoping this fixed it or i'm gonna go crazy, this bug is so rare, but it happens enough that it affects the torture experience.

The development code always worked for me, but the extension on chrome web store didn't
I'll check the new one out!

yeah it took me like 30+ attempts to get it to happen and debug it, but when there's apparently 100s of users it was bound to happen to people (gotta love publicly used software)

On a side note could you walk me through setting up prettier? or that stuff you use to format the code, I tried setting it up but it never worked for me
Also, does it take a long time for the chrome web store to accept new updates?

I'm just using the prettier extension from vs code, and prettier just automatically detects the file in codebase.
Also Chrome takes like 1-2 days to update the extension which is really annoying.
Side note:
if you guys haven't already should probably join the discord if you want to talk with me and other people, so we don't spam these discussions lmao:
Here's the link Discord invite

Thanks!
Done, I joined the discord!
I tried about 10 times, and there doesn't seem to be a problem with the dev code.

people still had this problem, so I changed the logic a bit and it should've hopefully fixed it, if anybody can test it out for me I'd appreciate it

The recent changes have been updated on the extension, but it still doesn't work for me, I'll check if the new code in the repo works for me(it always has)

LOL, I think this issue mainly happens in the build version when you run npm run build. It looked like a service worker issue when it became inactive, so when you're testing leave the extension and don't solve the problem until you see it say service worker inactive on the extension page.

Got it! I'll do that now👍

I still have this issue, I solved more than 10 problems in order to get rid of the freaking tortures, but It's spread its webs over my throat. I forced to use safari instead of my dear Chrome, please ELP!

Hey!
Could you try this again? It works for me now

Hey!
Could you reinstall the extension and try it again? It works for me now👌

Yeah I just tested it today and yesterday.
When I try to load a webpage I get directed to the gulag's problem of the day (potd). I then solve it but I'm still not allowed to open other websites.
When I click on the extension's icon in the toolbar and open the potd and then resubmit my solution then I can browse freely.

Dang💔
That's next-level torture
Maybe there'll be a week where we just upgrade this extension
You could also get your hands dirty if you have some time on you
Good luck!

Hey!
Could you reinstall the extension and try it again? It works for me now👌

I did reinstall it but It doesn't work still :(

I solved the issue by disabling CORS with an ALLOW CORS extension. It should be fixed by setting the origin header tag to some requests in the code instead of allowing CORS globally (something like this: "Access-Control-Allow-Origin: *"). cheers!

I solved the issue by disabling CORS with an ALLOW CORS extension. It should be fixed by setting the origin header of some requests in the code instead of disabling the CORS globally (something like this: "Access-Control-Allow-Origin: *"). Cheers!

I'm still testing this. lmk if you want me to make a fresh issue.
My current issue is that

I try to browse the internet and am redirected to potd
I solve the problem after clicking around on the site, maybe reading the discussion and browsing devdocs.io (I always have the docs open in another tab)
I then reopen the potd from the extensions icon in the browser
I resubmit my solution to potd
Now I can browse freely.

Oh, I think it works perfectly for you!
You could go to the settings tab to change the difficulty or change the problem set you get your question from using the dropdown but that was coding sloth's actual plan of the extension, it's torture😎

@Tayomide so we're supposed to reopen the potd? why can't the extension detect you solved the problem the first time you open leetcode that day?

I switched to new layout and it works now


JBoss SOAP jars do not support latest Rosetta SDK

There's an issue with the JBoss client jars not working properly with the latest Rosetta SDK. This is causing exceptions with the Rosetta SDK is installed.
The fix seems to be to upgrade the entire jaxb/jaxws stack to 2.3.1 and use the jaxws-rt instead of the JBoss jars.

Resolved by https://github.com/DIA-NZ/webcurator/pull/98


Add an option to trust headers set by reverse proxies

eg Cloudflare, kubernetes ingresses etc
Going to tidy up and test this tomorrow, putting in a PR as a reminder

@carnage
Can you take another look, please?

Yep, just haven't had time yet


Remove Unused JavaScript (Tree Shaking)

Separate javascript related to different features in different files. For example, have one essential file to support the other features and keep those other features in separate files. Something like this:

bootstrap.essential.min.js
bootstrap.navbar.min.js
bootstrap.modal.min.js
bootstrap.tooltip.min.js
bootstrap.anotherFeature.min.js

And for those who don't want to reduce the size, can download bootstrap.bundle.min.js just like we already have.

https://getbootstrap.com/docs/4.5/getting-started/javascript/#individual-or-compiled


The driver does not currently work on Windows

There are some Linux specific assumptions in a few places, so this code will not currently work correctly on Windows. Since the SDK itself does, the driver should too. I tried to leave a note wherever I did something I know isn't cross-platform, but I can't guarantee I've marked everything.

The installation process in particular will need some attention.


version bump for recent lts

I'm using tisch in a sort of large project and am having dependency problems because of the aeson and lens versions. aeson doesn't seem to be used that heavily, so seems ok. With lens it's not clear to me, but your tests compile and my application's test still pass.

btw this makes your cabal file compatible with lts-8.9

@martyall thanks. I just removed all version bounds.


[5/5] Clustered Purge Implementation

Overview
This PR implements clustered purge. Its big.
There are roughly five large chunks for clustered purge:

Single shard APIs
Updates to couch_mrview
Internal replication
Read-repair
Clustered API

At the shard level the major changes are to add two new indexes for purge requests. These indexes store the history of purge requests to a shard (rather than the old method of just storing the most recent purge). This allows for secondary indices and internal replication to manage their eventual consistency. This is the bulk of the PR in that its adding both the implementation and a whole bunch of tests for clustered purge.
One note on naming internally and in commit notes is that a "purge request" is what's sent in a single HTTP request to the purge end point. A "purge info" is a single {DocId, Revs} entry. The new indexes in the shard deal with purge infos as they lose any notion of bundling from which request they came in after they're stored.
The changes to couch_mrview are fairly straightforward after the single node API changes. The only thing that will be interesting in this commit is how we use a _local doc to track where the secondary index has processed in the purge sequence. This is necessary so that compaction knows when it can discard purge infos.
Internal replication is fairly straightforward. This update just ensures that we synchronize our purge infos between each shard so that we don't inadvertently undo a purge request when synchronizing shards.
Read-repair is somewhat tricky. The thing to note here is that when we open a document we track which revisions came from which nodes. Then if read-repair is required we pass that information along with the update request. This way a node can filter out requests from any node that is either a) not up to date with its synchronization or b) we have explicitly purged a revision that has not been sent to the node from whence the revision came back. That last bit of logic may sound kind of odd but the thing to remember is that we could completely remove a revision from a cluster and then re-introduce it later on. This means that we have to reject re-application of a revision for a closed period of time (rather than rejecting it forever).
The clustered API is rather straightforward for anyone familiar any of the existing fabric coordinator and HTTPD handler code.
Testing recommendations
make check
Clustered purge comes with some fairly extensive testing though I'm very much open for suggestions on new tests.
Related Issues or Pull Requests
This PR depends on:
#1366
#1367
#1368
#1369
Checklist

[x] Code is written and works correctly (hopefully ;)
[x] Changes are covered by tests;
[ ] Documentation reflects the changes;

For docs this doesn't change the existing purge APIs but I will need to open a PR against the docs to write up some of the caveats and footgun warnings that we want to add for this.

Also of note, I highly recommend moving through this PR a commit at a time as its quite big and the commits are specifically written to try and separate out all of the major changes to ease review.

Thanks @kocolosk for your review. I tried to address most of your comments on commits 01, 02 and 03 in new commit 7e0dabb. Will work on other comments. @davisp hey Paul, feel free to add your response :-)

Very nice work all.
Historically one could think about external consumers of _changes and internal consumers of the sequence index as being on equal footing, and there's something appealing about that. The latter group has some efficiency advantages but fundamentally an external process could go and do everything that the internal consumers do using the node-local HTTP interface. The lack of HTTP access to the purge index breaks that. An external indexer, for example, has no way of knowing revisions have been purged from the main database short of checking the individual shard's purge sequence and rebuilding the entire index if it changes, whereas the internal consumers can be smarter.
All that said, I wouldn't change anything about this PR, as it contains everything needed to surface an external API to the purge structures if we should conclude there's a need for it at a later date.
I'm +1 pending resolution of my (minor) review comments.

Thanks again for your review @kocolosk
Hey @kocolosk @davisp, I tried to address comments related to code change in commit 9038557 and other previous commits. Any additional comments are highly welcome.

Very nice work. 💯 for a thorough test suite.

I just added commit https://github.com/apache/couchdb/pull/1370/commits/a5c1d1330c8051a9912871049ead60869745c4db to address issue of exposing verify_module and verify_function for unexpected execution. Currently couch_epi:any/5 is used to listen whether there is client reporting a valid index.
In addition, it looks that there is problem with couch_db:get_design_docs/1 and I stripped the suffix (the part after dot) before calling fabric:design_docs/1.

Hey @iilyak I used 1dae6af to adjust returned value from get_purge_seq/1 and get_oldest_purge_seq/1, and use 8a62f68 to add information about module and line. Also added explantation why we use proplists:get_value/2 in fabric_rpc.

I'm +1 pending resolution of my review comments. However I am concerned with deployment aspect of the PR. It is scary that we don't have a rollback. Could we at least have a documentation on what we would do if we would need to rollback to a version which doesn't have additional trees in the header? Ideally I would prefer to have a PR (which we would not be merging) with an implementation of a header downgrade.

thanks again @iilyak I added one response https://github.com/apache/couchdb/pull/1370#discussion_r201238042. Hopefully there is no pending comment from your side except for downgrade database. I am working on downgrade case, but this will be in different PR.

@davisp @jiangphcn With 2.2.0 down to just 4 open issues, and already with PSE in there, let's release that first.
Please hold merging these purge PRs until the 2.2.0 release is cut.
I anticipate that in the next 2 weeks or less.

okay @wohali thanks for letting us know.

Hi Paul, @davisp When using git log --oneline, the order is correct.
localhost:src jiangph$ git log --oneline
bf809a8 [10/10] Clustered Purge: Clustered HTTP API
110dcdc [09/10] Clustered Purge: Fabric API
4dcfb50 [08/10] Clustered Purge: Update read-repair
973a599 [07/10] Clustered Purge: Internal replication
a947b5c [06/10] Clustered Purge: Update mrview indexes
3279c38 [05/10] Clustered Purge: Add upgrade tests
a192aef [04/10] Clustered Purge: Update couch_pse_tests
ac8d0f6 [03/10] Clustered Purge: Update couch_bt_engine
4d695f1 [02/10] Clustered Purge: Update single node APIs
0254305 [01/10] Clustered Purge: Define new purge API
830240b Create new on_compact trigger
4c87d78 Enhance PSE tests with setup/teardown functions
c998aa4 Update to use new couch_pse_tests app
0d85abe Update PSE test definitions for new util module
3c94bc4 Rename PSE test modules
db28f4c Move PSE tests to their own app
f45c036 Rewrite the PSE test suite to use couch_server
da43788 Simplify logic in mem3_rep
aea2833 Update fabric_doc_open eunit tests
bb27d5e Fix race on couch_db:reopen/1
151b9b0 Fix default security object handling
da2e22a Fix bug during purge
3852a00 Fix typos in couch_db_engine.erl

Confirmed locally through not GitHub. Must be ordered on dates or something.
+1 to merge


docs(config): style update to webkit scroll bars

I tried pulling this against refactor-info-architecture but couldn't since changes didn't effect the branch. All this does is add a webkit scrollbar style to hide it as mentioned in this comment about the proximity of content to scroll bars.
this should only get looked at after #1612 is merged in.

NOTE:
this does not fix it for FF/IE as those browsers do not support this behavior. an alternative would be to add padding to both .sidebar__inner and .page__content


Inverter overreporting AC energy

Describe the feature
The AC energy reported by the inverter is overstated by 3.3%. I resolved it by adding a sensor that integrates the AC power into AC energy.
Due to the overreporting the energy dashboard shows a higher home electricity use and higher direct use of solar energy.
Screenshots

3 hour period at maxed out production 8840.8 to 8856.3 kWh gives 15.5 kWh in 3 hours whereas the maximum production of the inverter is only 5kW
Home Assistant (please complete the following information):

Home Assistant Core Version:  2023.9.1
solaredge-modbus-multi Version: 2.4.5
Inverter: SE5000H HD-Wave

Additional context
Add any other context about the request here.

The integration should only report the data given by the inverter, not manipulate it.
Adding a revenue grade meter with C0.6 current transformers is the typical solution, where the equipment is designed for high accuracy measurements. As far as I understand the inverter is not revenue grade on its own so inaccuracies should be expected without revenue grade metering.
Otherwise if you used a template sensor you can post your code to discussions and it's up to the user to determine if they want to alter sensor data.


Feature proposal: add support for more up-to-date Deno runtime

Hello,
Deno introduced the support for NPM packages in the 1.28 version. It makes the runtime way more powerful.
It would be great to implement a Deno runtime > 1.28 so we can use these new features. I don't think there is breaking change.
Also, what do you think about changing the default template to include types for the request and the response, such as:
import { sdk } from "./deps.ts";

interface Request {
  headers: { [key: string]: string };
  payload: string;
  variables: { [key: string]: string };
}

interface Response {
  send: (message: string, status: number) => void;
  json: (response: unknown, status: number) => void;
}

export default async function (req: Request, res: Response) {
  ...
}

I don't know if you work with external contributors, but I could get the job done.

@t0mm4rx thanks for raising this. open-runtimes now has deno 1.35!


Reproducible crash 1.2.15 - Switching no-signal combinator to depot mode

Error message:
Error while running event cybersyn::on_gui_selection_state_changed (ID 60)
__cybersyn__/scripts/gui.lua:95: attempt to index local 'signal' (a nil value)
stack traceback:
	__cybersyn__/scripts/gui.lua:95: in function 'handler'
	__flib__/gui-lite.lua:169: in function <__flib__/gui-lite.lua:152>

Repro steps:
Place a train stop and a cybersyn combinator facing it. Open the GUI; it will be in station mode by default. Right-click the signal selection ("virtual-A" by default) to clear it. Then use the drop-down to switch the combinator to depot mode. The game will immediately crash to main menu with the above message.
NB. The reason this can come up is it's nice to clear out the signal for non-station combinators, so that there's not a spurious "A" on the combinator graphics in alt-mode (maybe plus the relevant game setting to make combinators show signals in alt-mode?).

Suggested patch, not tested:
--- cybersyn/scripts/gui.lua
+++ cybersyn/scripts/gui.lua
@@ -91,8 +91,8 @@
 		set_comb_operation(comb, MODE_DEPOT)
 		--prevent the use of the each signal with depots
 		local network = element.parent.parent.bottom.network--[[@as LuaGuiElement]]
 		local signal = network.elem_value--[[@as SignalID]]
-		if signal.name == NETWORK_EACH then
+		if signal and (signal.name == NETWORK_EACH) then
 			network.elem_value = nil
 			set_comb_network_name(comb, nil)
 		end

Additional bug related to the same code (but probably not fixed with above patch):
Place train stop, combinator. Select "EACH" signal. Select "Depot" mode. Per the above code snippet, signal is cleared.
Now open the dropdown again. The dropdown visually opens but then the game immediately crashes to menu with:
Error while running event cybersyn::on_gui_click (ID 1)
__cybersyn__/scripts/gui.lua:95: attempt to index local 'signal' (a nil value)
stack traceback:
	__cybersyn__/scripts/gui.lua:95: in function 'handler'
	__flib__/gui-lite.lua:169: in function <__flib__/gui-lite.lua:152>

This is perhaps worse because the user never cleared the signal, so maybe is less culpable in causing the crash ;)

Verified this fix works. I'll create a PR with the patch unless you want to @adlerd?


TREC DL 2020

The task paper is out: https://arxiv.org/abs/2102.07662
Hopefully, qrels will be posted publicly soon as well.
Need to add qrels and update documentation -- pointing to paper and adding citation. Looks like */trec-dl-2019 are missing a link to the paper, so that can be added as well.
https://ir-datasets.com/msmarco-passage.html#msmarco-passage/trec-dl-2020
https://ir-datasets.com/msmarco-passage.html#msmarco-document/trec-dl-2020
Should add */trec-dl-2020/judged datasets too, since only 45 of the 200 task queries have human judgments.

The TREC PM 2020 qrels might be released at the same time. Can update those as well when released. Also update TREC PM 2020 docs with paper.


Majors appear as [{"S":"Mechanical Engineering"}]

Majors on the downloaded dynamoDB csv is displayed as the following format [{"S":"Mechanical Engineering"}]. This issue began appearing this way on 2/23/2022 was fine on 2/22/2022 if this is helpful.

I introduced this bug when I was changing the registration logic on the frontend. I had assumed the backend was accepting an array of strings for the Major and Minor fields, but it instead takes a comma delineated string of all of the majors and minors.
The sent json before the change I made...
{
     "Majors": "a,b,c,d"
}

compared to how it is now...
{
     "Majors": ["a", "b", "c", "d"]
}

which gets stored according to how dynamodb translates it to a string, [{"S":"a"},{"S":"b"},{"S":"c"},{"S":"d"}]; instead of the a,b,c,d it would have before.

Thank you! From what I see and your explanation it looks good. Can we merge this soon?

I just opened a PR for this change (#98). There may be a better solution to this problem, but reverting to the prior functionality is sufficient for now.


added cancelOrder to AsyncOrderModule

Looks good to me! Probably want another review though

yep. Waiting on sunny if we actually want that feature, cause there is no incentive to do so if you could just override your oder. Waiting on Sunny and Leo

hold on this. we have to add a new configuration parameter called executionTime, and we can only cancel after this time instead of settlement time. they will have different meanings now

alright. I will wait until I get the green light from you


Py::new might not need to return PyResult

At the moment Py::new returns PyResult<Py<T>>, though in discussion in https://github.com/PyO3/pyo3/pull/1074#issuecomment-669209757 we came to concensus that it can probably just return Py<T>. The only error situation which can occur is out-of-memory. Most other pyo3 constructors where this is the only error situation just panic on OOM. (This is the same in the Rust stdlib.)
At the moment this fallibility comes down to PyClassAlloc::new returning nullptr on any error. And also PyClassAlloc::new can allocate a subtype, which could run arbitrary code through the subtype's tp_alloc.
If PyClassAlloc::new was split into e.g. ::new and ::new_subtype, where ::new always allocates Self, then we should be able to refactor code enough to change semantics of Py::new so that it panics on OOM.
https://github.com/PyO3/pyo3/blob/f2ba3e6da753fadb948978a24212d5d1e42c9dfb/src/pycell.rs#L374-L377

It was interesting to note for pyclasses that x.into_py(py) is infallible, whereas Py::new(py, x) is fallible - which adds weight to the argument that Py::new doesn't need to return result.

Candidate for 0.12?

Would be cool but I'm slightly concerned the limited API may affect the code paths here, so I think we should coordinate this with the abi3 work in 0.13.

Further thinking on this subject is that perhaps Rust types which subclass Python types could be fallible to construct, so this issue probably shouldn't be implemented before #991.

I think with #4041 we are now thinking that into-python conversions will likely be fallible in the future, and given the subclassing issue above I think the general conclusion is that this should stay fallible (as it currently is).


add dependency command

Add depenencies, update dependencies commands.
User won't get the formatting right.

yeah, mkc add jacdac could use makecode cloud extension search; if it finds more than 1 package, then maybe we print them all out and exit with error? or ask the user which one they want (option 1, 2, or 3 ?)
otherwise mkc add microsoft/pxt-jacdac would be good too


Release notes/upgrade documentation?

Does Cargo have a recommended way of associating release notes with versions?
Some way of providing upgrade instructions to users when they upgrade packages via Cargo.
This came up in discussion when c_vec changed exposed type signatures, and I'm not sure where would be the right place for the project to inform users about that change.

Why not providing a message with a new crate version for example ?

There currently is not "official way" of doing this, it's done on a per-repo basis.

Does Cargo have a recommended way of associating release notes with versions?
Some way of providing upgrade instructions to users when they upgrade packages via Cargo.

These two things sound like different features potentially, if I'm understanding correctly.
The first feature I'm hearing is to have a key in Cargo.toml like release-notes = "CHANGELOG.md" that would be something like the readme key, where crate authors could indicate a file in the repo that contains release notes/change logs, and users could go look there, and crates.io could potentially display them somewhere, etc.
The second feature sounds like a thing rubygems has that it calls "post-install messages"-- library authors can put a message in their Cargo.toml equivalent that will get displayed on stdout when a user installs that library. While they can be used to inform the user about changes and point to release notes (the newrelic example in the link), they can also be used for silly things that annoy people (the httparty example in the link)
Could you clarify if you were thinking of one, both, or neither of these? :)

I was thinking about something displayed similarly to post-install messages, but only after an upgrade (so a "post-upgrade" message).

I'm not personally convinced displaying changelogs on the command line is worthwhile. On the other hand a field in Cargo.toml like release-notes (mentioned above) and an extra link when browsing packages on crates.io would be useful.
It may also be worth recommending some conventions: http://keepachangelog.com/en/1.0.0/

I'm going to close this issue because it's actually replaced by this RFC, which contains lots of discussion: https://github.com/rust-lang/rfcs/pull/2129


pqarrow/arrowutils: Use SortingColumns in MergeRecords

This allows to merge records in arbitrary orders and columns.

Weird, I thought we already did this?


added SynchronousLogstashHandler

Fix #59
Here are the necessary adjustments to work synchronous. Could you please check them out?

linter has been fixed aswell, so I hope that travis is satisfied with it :)

linter has been fixed aswell, so I hope that travis is satisfied with it :)

Thanks!

Sorry to bother you, do you already have a rough estimate when to include and release these changes? I wanted to include them in the next release of Psono and are wondering if I should wait or not.
Thanks again for the great work!

There you go: https://pypi.org/project/python-logstash-async/2.2.0/
Sorry for the delay.

Amazing. You are the best! 👍


Add feedback firebase function

Not sure why the checks have failed...

Can you compare with firebase_func_search on their implementation and use of singleton pattern just to align it's the same approach.

Certainly, I've used the same singleton approach as in firebase_func_search using the from fb_manager.firebaseManager import FirebaseManager logic. However I haven't put their stuff into this branch. I'm not entirely sure if I should be creating a pull request into firebase_func_search or stg? Currently it's straight into stg, but this means I don't have fb_manager.firebaseManager available in this branch.


Update select component width

This PR
Creates a govuk-!-width-full override (previously we only had width to reduce the size of 100% elements
Removes the width: 100% declaration on the select so they are the size of the content by default

Cool, I will do the changelog at the last minute if approved for minimal merge conflicts :)
Will discuss in channel about breaking change of not

@dashouse can you please update the PR summary to explain what problem you're solving?

@nickcolley Hopefully this covers it...

Updated changelog and merged, thanks


Calculate left/right window margins of zoomed in area

Hi there,
I am new to React and got here via Expo release notes. This isn't a bug but just trying to understand the code.
I'm trying to follow the Image example as I have a similar need (map).
I am trying to calculate the endpoints of the window as they end up after the transformations.
For example, for the sample image, if I zoom 2x with center of image, and move right by WIDTH/4,  my corners will be (B, edge, I, edge). I would like to calculate those corners so I can request the right things from the server.
I am unable to follow the math here. Is this based on a simper example somewhere else? Or is there a trick for using the transformation matrix to get those corners?
Thanks,

Hi there,
Any pointers here will be appreciated. I'm trying to make sense of this library but running into a lot of issues due to my poor lack of understanding.
How can I calculate the corners of the zoomed in section I'm in at the moment?
Thanks,

So sorry for keeping you waiting here. Ended up not having enough time today to get to this issue but hope to be able to give some pointers tomorrow

No worries.. thanks for looking into it. I really appreciate the feedback.
Here is a code sample of what I'm trying to do
https://gist.github.com/sanealytics/3425652255589dc04114d06ddb748ac5

Thanks! This is a great explanation. I will try and report back.

Unfortunately, this always finds the top-left corner of the parent image, not the top-left of the zoomed-in portion :(
I'm following your math, which is roughly reversing the transform, but I can't get it to work :(
Here is sample code to help reproduce the problem
https://gist.github.com/sanealytics/eae89a5397e6f036d5af3938b0953288
PS, nice improvement on being able to modify state in the new versions.

Closing the issue for now, changed the direction of how things are being used. Will reopen if I try this again.


What is the algorithm delay of WaveGlow

If I understand correctly, even though the WaveGlow has a parallel generative framework, it still need to take sufficient amount of speech samples before it can generate audio sample. Then what would be the algorithm delay of WaveGlow? If my input audio segment length is 16000, as the default value in config.json. Does it translate to the delay of WaveGlow is 16000 samples? @rafaelvalle

But as I understood, the inference starts with random sampling from z. Previous speech samples are not required.
Coming to the 16000 samples, as mentioned in the paper, the training is done using randomly chosen clips of 16000 samples. Probably the default value is for the wave chunks in the training phase.
The algorithm delay is also my question. I am also confused about the receptive field size. with 8 dilations (1, 2, ..., 128), filter_width=3 (taps), the receptive filed size is 511, according to rf=sum((fw-1)*dilation(i))+1.
Does groups of 8, in squeeze operation, multiplies the receptive field size by 8?

Closing due to inactivity.

I have done some investigations about the algorithm delay and the receptive fields.
The first thing is that the algorithm delay comes from the mel spectrogram, and when the inference begins, the mel is upsampled to the same size of audio and then split into 8 groups. So for 1 mel frame, it is upsampled to 256 timesteps, and becomes 32 (256/8) timesteps for each group.
So the 511 steps of delay observed by @AzamRabiee inside the wavenet structure would represent an 8(511/32)-frame delay.
However, I am somewhat confused by the receptive field of the entire waveglow. As I mentioned, every 1 flow would have 8 frames of delay, so that means, theoretically, the accumulated algorithm delay of waveglow should be 8 x 12flows = 96 frames. Also the receptive field should be 96*2+1 frames. But, the algorithm delay I observed in my experiment is only 16 frames, which is very weird.
Right now, I am not quite sure how waveglow reduces the accumulated algorithm delay.


R&D: Migrate project to gradle and use Muzzle OTEL Gradle plugin

Why?
The OpenTelemetry project uses gradle. It also provides a Gradle plugin - Muzzle, that detects resources (classes) that are necessary to be on the classpath when the javaagent is run (avoiding constant NoClassDefFound/ClassNofFound exceptions). It also helps finding and using Virtual fields which we use extensively. If we use gradle, we could just use it and have codebase reduced - currently we manually list classes that should be included which is cumbersome.
Other reasons:
Potentially new gradle plugins could be developed by OTEL project and we could use them too
Gradle is easier to use (and faster?)
Alternatives:
Write our own sbt Muzzle plugin. This would require us to maintain it though which is a downside imho and a big distractor.

Relevant findings - https://github.com/ScalaConsultants/mesmer/issues/353#issuecomment-1471633169.


Publishing latest version on npmjs

can you  publish latest version on npmjs

Sorry for the delay. I just released a new version, including your pull request. Thanks for your contribution.


ENH: Update conda, if running latest

This adds the command conda update -n base conda just before cleanup, if miniconda_version == 'latest'.
Immediately, this deals with the fact that Miniconda released on version 4.4.10, while 4.4.11 is a critical upgrade, and will help neurodocker be resilient to the differences in conda and miniconda release cycles.

Seems to be an unrelated error.

Thanks @effigies - the errors are related to docker-py releasing 3.x and me not accounting for it. Let me update requirements.txt (temporary fix) to restrict the compatible versions.
FYI neurodocker will support docker-py 3.x in the refactor (#143).

@effigies - can you merge current master?

@effigies - does this take care of https://github.com/conda/conda/issues/6811? Would this be necessary after miniconda 4.4.11 is released, assuming that release fixes the IsADirectoryError bug?

It should take care of conda/conda#6811. Travis updates conda, and is now passing in nipy/nipype#2455.
I don't know that there's going to be a 4.4.11. Check out the archive. It looks like they cut a release once a month.

Actually, should probably note that this doesn't seem to resolve the issue that caused us to drop off of 4.4. We still get version conflicts.
https://travis-ci.org/nipy/nipype/builds/344123797?utm_source=github_status&utm_medium=notification
So your call whether this is worth including.

Cancel that. I was looking at the wrong Travis run. This should be fixing nipy/nipype#2455 after all.

This looks good to me. Thanks @effigies!


isCapsed bug

Hello! I have code and when I type in chat only numbers, I every time get true. Can you fix it?
import { caps } from "@satont/text-utils";

caps.isCapsed(message.conent, { "percentage": 50 }) // return true if message.conetnt have only numbers.

Hi, thank you for your bug report.
Yea, i'll change algorithm a bit.


fix barricades not anchoring again after being unanchored

About the PR
Closes #2975. I don't really know if this was here for a reason and removing it will break everything, but by doing so it's possible to actually create a barricade, unanchor it, move it around and then anchor it again for good (that is, it can't be pulled even after being anchored like before)
Why / Balance
To make anchoring of barricades work as intended
Technical details
Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes
Changelog
:cl:

fix: Anchoring barricades now actually makes the barricade anchored to the floor.

believe that was for preventing the anchoring of barricades on dropships

so make it unanchor when its on a dropship instead of ALWAYS unanchoring

Is there a reason on why it should not be possible to make cades on dropships?

because maintainers dont want there to be buildable barricades on dropships, you use the dropship's door bolts for defense
and for CM13 parity i believe

you also cant build on dropships currently, so building it elsewhere then anchoring it on the ship would be a way to circumvent it

Mhh, I can kinda see why this was the fix then. I have no idea on how to discriminate whether anchoring is occuring inside a dropship or not. I guess I'll keep this open and I'll investigate it, maybe in the meantime someone comes up with an idea.

Mhh, I can kinda see why this was the fix then. I have no idea on how to discriminate whether anchoring is occuring inside a dropship or not. I guess I'll keep this open and I'll investigate it, maybe in the meantime someone comes up with an idea.

Need to get the transform component of the barricade and then check whether or not its grid uid has a dropship component, I forgot to do that when implementing it


KAFKA-13152: Add cache size metrics

Adds the new DEBUG metric cache-size-bytes-total

@vamossagar12 let me know when all the tests finish running and I'll merge this

@vamossagar12 let me know when all the tests finish running and I'll merge this

Thanks @ableegoldman . Oh weirdthe JDK 11/17 finished over friday itself. The other ones are still running.

Yeah that's weird...it might be stuck, triggered a new build, hopefully this one doesn't take days to finish 😄

@ableegoldman , looks like the tests ran this time. Error seem unrelated to this change.


CHEBI:189678 'modulator': merge with CHEBI:90710 'receptor modulator'?

Hi again,
CHEBI:189678 'modulator', annotated by a third party, is defined as "a group of substances that bind to a receptor to change that receptor's response to stimulus" and placed in the 'chemical entity' branch rather than the 'role' branch. It has no children. Should it be merged with (or obsoleted in favour of) CHEBI:90710 'receptor modulator'?
Thanks,
Paola

Both entries have now been merged.


can not install the package

Hi， when I install the package, there is an error said can not find vcvarsall.bat, please give me some suggestion, thanks

Hi @pariswu1988 can you give some details of your Windows & Python version & how your are attempting to install padua?

hi, I have installed successfully. Thanks！


added pagination information to the request headers

I took the work felipesnt had and put that information into the response headers, this should preserve backwards compatibility.


Ran apps:validate, got error: "Error: Authorization Failed, try logging in!"

Expectations
Running validate command validates package.
Reality
Got error message.
Steps to Reproduce

Install zcli with npm install @zendesk/zcli -g
Attempt to validate app with zcli apps:validate dev\download-all-attachments

Issue details

Command: zcli apps:validate dev\download-all-attachments
Version: @zendesk/zcli/1.0.0-beta.4 win32-x64 node-v12.13.1
OS: Windows 10

I don't generally do the zat create and zat update workflow, so this app doesn't know about any Zendesk accounts. LMK if you need any further information. Thanks!

Hey Chuck,
Thanks for the feedback. Currently, this is by design. The reason being is that we no longer include a gem (or module) inside the CLI package that does validation. This is because with ZAT this caused issues with being out of sync and sometimes not being accurate to the validations being done when uploading the app to the Marketplace.
This now requires authentication because it will use our server side authentication service to make sure that our validations are all being handled by the same place, and this endpoint is authenticated - not public. So while you don't have to connect to any specific account, you can log your ZCLI instance in to run the validations.
Chris

Thanks Chris! I'm realizing I didn't even see the login command or I probably would have just done that :|
I have one app in the marketplace ("Download All Attachments") and have also built a few private apps.

Hey Chuck,
I think we could improve that error message in that case to make it clearer how to authenticate 😄 and resolve it.
Chris

My process is pretty minimal, because I haven't built anything large and I don't build a lot of apps. I basically just use zat=true for testing (on my dev account), then zat package and install as a private app as a sanity check, and then that's about it. On the one marketplace app I have a python script that copies my README into the long description in translations (with the newlines escaped).


Show created repositories

Had to remove the CSS rule too because it took precedence over the one set in JS (since the stylesheet is injected), and apparently you can't set .css('display', 'block !important') either.
Fixes #184.

Why not just use CSS to hide the contents of the container and always show the parent? Is that not possible? It's the same net effect without JS.

I went with #189. It's more fragile, but so is pretty much everything we do here, even with JS.


Render fixes, HDR support, PMREM for correct radiance

Fixes #101, #120 render glitches from #94/skysphere depth test change. I think this fixes all the weird rendering issues I've seen.
Fixes CachedGLTFLoader instances sharing materials (and environment maps) resulting in race conditions to determine what envmap is displayed
Implements HDR equirectangular loader -- can load .hdr files now. Fixes #65
Adds Prefiltered-Mipmapped Radiance Environment Maps (PMREM) for provided background-image and default environment (images below)
Add HDR samples to the examples

Added HDR support for background-image

Generated PMREM for LDR background-images
This generates radiance maps so that rough, yet metallic surfaces, do not reflect the environment directly, but a mipmapped approximation -- notice the difference with the spheres on the right
Before, with a series of metalness (1) spheres, with increasing roughness:

After:

Generated PMREM for HDR background-image
Before:

After:

Generated PMREM for default environment
Most likely less useful and probably need more improvements on the default envmap (and caching/coloring), but this is applied here as well:
Before:

After:

Understandable if wanting to hold off landing this, but should pull out the render fixes at least!

Superceded by https://github.com/GoogleWebComponents/model-viewer/pull/237


enhancement(Timepicker) styling updates

Proposed changes
Updated timepicker styling towards Material M3 standards #558
Removed all modal related wrappers and selectors
Implemented m3 theme vars
Refactored positioning, replaced relative and absolute properties with flex
Implemented additional accessibility
Screenshots (if appropriate) or codepen:

Types of changes

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

Checklist:

[X] I have read the CONTRIBUTING document.
[X] My commit messages follows the conventional commit format
[ ] My change requires a change to the documentation, and updated it accordingly.
[ ] I have added tests to cover my changes.
[X] All new and existing tests passed.

Additionally implemented autosubmit that can be used for the docker timepicker and reverted exclusion of confirm button interaction for handling with modal
Since the deprecation of open close methods in #525 the following method can be used for interaction with timepicker and modal
html

        <input id="timepicker" type="text" class="timepicker">
        Time

<dialog class="modal" style="width: 620px"></dialog>

script
M.Timepicker.init(document.querySelectorAll('.timepicker'), {
    autoSubmit: false,
    container: '.modal',
    onInputInteraction: () => {
        toggleModal();
    },
    onDone: () => {
        toggleModal();
    },
    onCancel: () => {
        toggleModal();
    }
});

const modal = document.querySelector('.modal');
const toggleModal = () => {
    if (!modal.hasAttribute('open')) {
        modal.setAttribute('open', 'true');
    } else {
        modal.removeAttribute('open');
    }
}


Release gax-java v1.49.0

This pull request was generated using releasetool.
09-30-2019 09:47 PDT
Implementation Changes

Fix Race condition when shutting down executor/transport channel (#787)

New Features

Expose Batcher#sendOutstanding to provide async batch flushing (#786)

Dependencies

make opencensus consistent (#794)
update google-auth-library to 0.17.2 (#789)
Update opencensus, guava, and Truth (#788)
Update to Guava 28.1 (#791)

Internal / Testing Changes

Update repository_rules.bzl (#730)

Release is at https://github.com/googleapis/gax-java/releases/tag/v1.49.0

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


Fix support for file data (gulp-data)

Closes tracker1/gulp-header#56

@tracker1
I'll let you review / merge / publish.

Sorry this slipped through the cracks on my end... travis should publish from the tag I just made.

@demurgos would you be interested in being added as a collaborator?
All you'd need to do is accept the pull request, and run npm run publish patch (or minor, or major) in this repo after pulling the latest after a rebase/merge for PR.

Okay. Thanks for the details.
I preferred for you to take a look at it. I'll submit changes myself next time.

Totally understand... :-)


bugs in mac browsers

in my all broewers of mac (osx 10.11.3), the special day parse not correct:
on firefox (other brower has the save bug, but the hours is diffrent):
moment('1987-04-12').toDate() result to  Date {Sat Apr 11 1987 23:00:00 GMT+0800 (CST)}。
but the correct day is :
moment('1987-04-13').toDate() result to  Date {Mon Apr 13 1987 00:00:00 GMT+0900 (CDT)}。
it seems that new Date() has the same bug……

This is actually standard browser behavior in compliance with the ECMA standard. China did a DST transition at midnight on April 12 1987. This means that the date and time in question - 1987-04-12T00:00.00 - does not exist. Given an ambiguous time, the ECMA standard specifies that the time should be shifted by the amount of the transition, to result in a time that actually exists, but it does not specify in which direction. In this case, Firefox is shifting it back by one hour.
This behavior is explained in detail in this stack overflow post:
http://stackoverflow.com/questions/35879043/chrome-and-firefox-exhibit-different-handling-of-an-invalid-dst-time/35883858#35883858


Fix a problem with reading small molecule transition lists, where precursors with similar m/z but distinct isotope labels were being combined

The logic to simplify messy redundant transition lists wasn't thinking about labels properly: e.g.
Molecule Name,Molecular Formula,Precursor Adduct,Precursor Charge
Glutamine,C5H10N2O3,M2C13-H,-1
Glutamine,C5H10N2O3,M1C131N15-H,-1
Glutamine,C5H10N2O3,M1C131H2-H,-1
would result in a single precursor C5H10N2O3[M2C13-H] as all have similar m/z - but of course they have different isotope envelopes.
Reported by user Jamie

@nickshulman @brendanx67 this is a well-tested code area, I have high confidence that this change doesn't have unwanted side effects for the kinds of transition lists we've already seen


Correct Cocos Creator page

Corrected the Cocos Creator installation process. The previous one wasn't as straightforward as the process i replaced it with

Thanks, looks fine!


Grove 16*2 LCD problem

I use nrf52832 board ,
the issue I face in sample file,
i try to make a overlay file for i2c communication, the code is build succesfully and and flash also , but when i see in ythe terminal it show  Device is not ready .
is any one have the working code for  grove LCD share ......
i use sample code
my overlay code is this.
/ {
chosen {
zephyr,display = &glcd;
};
};
&pinctrl {
i2c0_default: i2c0_default {
group1 {
        psels = <NRF_PSEL(TWIM_SDA, 0, 26)>,
                <NRF_PSEL(TWIM_SCL, 0, 27)>;
    };
};

i2c0_sleep: i2c0_sleep {
    group1 {

        psels = <NRF_PSEL(TWIM_SDA, 0, 26)>,
                <NRF_PSEL(TWIM_SCL, 0, 27)>;
        low-power-enable;
    };
};

};
&i2c0 {
compatible = "nordic,nrf-twim";
status = "okay";
clock-frequency = <I2C_BITRATE_FAST>;
zephyr,concat-buf-size = <4096>;
glcd: glcd@3e {
    compatible = "seeed,grove-lcd-rgb";
    reg = <0x3e>;
    label = "GLCD";
    status = "okay";

};

};

Please use our bug template when reporting bugs. You need to edit this issue to include the information requested in https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/ISSUE_TEMPLATE/001_bug_report.md

That error likely means the device was not detected, ensure you have connected to the correct pins and have pull up resistors in place

@Ashu12Aj were you able to fix this issue?


Change documentation about pelias

It seems that pelias section had the same links as mapzen. Changed that so that it points to pelias github page.

Thanks for this! You're right that this should be updated. However, I think we can/should be more specific on a couple of items:

For API Key could we say something more specific, like "configurable"? I think the current text makes it sound like the API key is self-hosted, which doesn't make any sense.
For Terms of Service we can link to the data licenses page.
Limitations bullet should not be removed.

@alexreisner all your comments make sense. I was just reading through README and noticed that so I figured, why not send a PR :) Applied your comments.

Looks great! Thank you!


Question about csgo Network (not related to cheat)

dear @danielkrupinski,
I'm contacting you because I think you can answer one of my problem on csgo.
As you are writting one of the most prolific and used cheat for this game you should understand greatly how their client/server infrastructure works. My problem is the following:
At home I play on my game PC which is a high end one and I have a good internet connection 10Bgbit. All my infrastructure are behind a enterprise grade firewall and I dont have fixed internet IP address unfortunately. When I play in Lan, I can feel the bot are responding and my bullet hit very well my target. When I play faceit/MM, it is another story. I feel like my bullet are not hiting, I lose q lot of duel despite my skill is the same. I checked net_graph, no choke/loss, but after checking my firewall drop log, I see a lot of UDP packet 27000-27036 range dropped from Valve/facit IP. My question is, what are those packet for ? As my computer id sending each ticks user command to the server and I guess their server is responding using those udp ports. but as the UDP protocol is not stateful, my firewall doesn't to whom it belong and as no port is open on incoming, he dropped it. On normal router for home, how it works ? With Upnp protocol ?
Thanks for you help. and if you wanna talk we can do it on discord/twitter/whatever.

@dummys did you ever tried to factory reset your system?


[AIRFLOW-536] Schedule all pending DAG runs in a single scheduler loop

Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:

https://issues.apache.org/jira/browse/AIRFLOW-536

This issue was reported by @aoen.
Currently only a single DAG run is scheduled when a DAG file is parsed
by an iteration of the scheduler loop. Which means scheduling N pending
DAG runs will require N scheduler loop iterations (separated by
file_process_interval waits). Modify the logic to schedule all pending DAG
runs instead.
Testing Done:

Added a unit test test_schedule_multiple_dag_runs that fakes the current
date to a week after the start date of the test DAG. Running a single
iteration of the scheduler loop should schedule 7 task instances associated
with the DAG runs for each day.
Modified unit tests test_scheduler_reschedule and test_dag_with_system_exit
that implicitly assumed a single DAG run scheduled per scheduler loop, by
explicitly faking the current date.
Created a test DAG with a start date of 2016-11-24 and ran the scheduler on
2016-11-29. Verified on the tree view of the webserver that DAG runs from
2016-11-24 to 2016-11-28 got scheduled.

Current coverage is 66.62% (diff: 0.00%)

Merging #1906 into master will increase coverage by 0.02%

@@             master      #1906   diff @@
==========================================
  Files           136        136
  Lines         10130      10132     +2
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           6746       6750     +4
+ Misses         3384       3382     -2
  Partials          0          0

Powered by Codecov. Last update 6fb9463...ef04e6d

@vijaysbhat Really like this idea! I will try to get time to review this later today. Including other committers as well. @bolkedebruin @jlowin @criccomini

This has operational consequences which I can not fully oversee. Such as the scheduling now might be biased towards one dag (ie. do other dags run at all?). While this issue is already there it might become more prevalent because of this.
Can you supply operational metrics @vijaysbhat ?

@bolkedebruin what operational metrics are you looking for? Is there a reference workload I can run it against to get before / after metrics?
Inspecting the code, the task scheduling from the queue happens here - https://github.com/apache/incubator-airflow/blob/master/airflow/executors/base_executor.py#L98-L101. The queue is sorted by priority, but within a priority the order is undefined. One option is to add the execution date as a secondary sort key so DAGs of the same priority don't resource starve one another. Thoughts?

@vijaysbhat I think that very reasonable. Locally, we see the issue already popping up (workers being saturated with recent runs), so this change would be welcome.
With operational metrics I mean in this case scheduler round trip times, time for a task to become scheduled, time for a dagrun (ie. all tasks) to finish.

@bolkedebruin I submitted a new PR for generating operational metrics on the scheduler - https://github.com/apache/incubator-airflow/pull/1919. I'd like to get it into master ahead of this PR to run before / after tests. Can you please review it?

@bolkedebruin @r39132 apologies for the delay in getting to this.
I ran the scheduler operational metrics test to see the impact of the change, and it isn't very encouraging. The time taken to land the last partition is approximately the same before and after the change (~62 seconds). Inspecting the code, I see that the polling interval for the DAG file processor - https://github.com/apache/incubator-airflow/blob/master/airflow/jobs.py#L1423-L1427 - is set to 1 second by default - https://github.com/apache/incubator-airflow/blob/master/airflow/jobs.py#L472. Which means we don't really get much gain from scheduling all unblocked tasks in a single loop iteration, instead of one task per loop, since we have to wait only 1 second between iterations.
Thoughts? Based on these results, I don't think it makes sense to merge this PR.
@bolkedebruin you mentioned seeing delays with workers getting saturated with recent runs. Does the scheduler_ops_metrics test I wrote cover the scenario you had in mind? I can modify the test to be more representative.
Before
Performance Results
###################
DAG perf_dag_1
        dag_id      task_id execution_date  queue_delay  start_delay  \
0   perf_dag_1  perf_task_1     2017-01-06     1.140496     9.136975
1   perf_dag_1  perf_task_1     2017-01-07     2.342836    13.015723
2   perf_dag_1  perf_task_1     2017-01-08     5.527419    15.857666
3   perf_dag_1  perf_task_1     2017-01-09     7.543701    19.103145
4   perf_dag_1  perf_task_1     2017-01-10     9.663275    22.135860
10  perf_dag_1  perf_task_2     2017-01-06    15.636898    37.831450
11  perf_dag_1  perf_task_2     2017-01-07    21.169079    49.912082
12  perf_dag_1  perf_task_2     2017-01-08    24.576290    53.281170
13  perf_dag_1  perf_task_2     2017-01-09    29.674157    56.138260
14  perf_dag_1  perf_task_2     2017-01-10    29.708653    56.134583
20  perf_dag_1  perf_task_3     2017-01-06    15.646764    38.728427
21  perf_dag_1  perf_task_3     2017-01-07    21.180421    50.375639
22  perf_dag_1  perf_task_3     2017-01-08    24.591211    53.511253
23  perf_dag_1  perf_task_3     2017-01-09    29.688701    56.199246
24  perf_dag_1  perf_task_3     2017-01-10    29.718093    56.010452
30  perf_dag_1  perf_task_4     2017-01-06    15.656712    38.301950
31  perf_dag_1  perf_task_4     2017-01-07    21.193230    49.768993
32  perf_dag_1  perf_task_4     2017-01-08    24.795914    53.440903
33  perf_dag_1  perf_task_4     2017-01-09    29.698734    55.899546
34  perf_dag_1  perf_task_4     2017-01-10    29.728701    56.005161

    land_time  duration
0   14.240241   5.10327
1   18.085389   5.06967
2   20.921890   5.06422
3   24.164961   5.06182
4   27.200040   5.06418
10  42.907575   5.07613
11  55.245358   5.33328
12  58.490731   5.20956
13  61.202847   5.06459
14  61.197053   5.06247
20  44.145381   5.41695
21  55.711073   5.33543
22  58.782713   5.27146
23  61.259554   5.06031
24  61.074637   5.06419
30  43.374789   5.07284
31  55.008939   5.23995
32  58.699265   5.25836
33  60.968175   5.06863
34  61.073386   5.06822

DAG perf_dag_2
        dag_id      task_id execution_date  queue_delay  start_delay  \
5   perf_dag_2  perf_task_1     2017-01-06     1.163020     9.245094
6   perf_dag_2  perf_task_1     2017-01-07     2.358395    13.027325
7   perf_dag_2  perf_task_1     2017-01-08     4.429921    14.664663
8   perf_dag_2  perf_task_1     2017-01-09     7.560515    18.767401
9   perf_dag_2  perf_task_1     2017-01-10     9.679037    22.040062
15  perf_dag_2  perf_task_2     2017-01-06    16.740780    41.737864
16  perf_dag_2  perf_task_2     2017-01-07    19.899759    48.524348
17  perf_dag_2  perf_task_2     2017-01-08    23.293342    52.742876
18  perf_dag_2  perf_task_2     2017-01-09    28.353998    55.452271
19  perf_dag_2  perf_task_2     2017-01-10    35.861836    57.218208
25  perf_dag_2  perf_task_3     2017-01-06    16.759711    42.011334
26  perf_dag_2  perf_task_3     2017-01-07    19.916217    48.696821
27  perf_dag_2  perf_task_3     2017-01-08    23.309626    53.072318
28  perf_dag_2  perf_task_3     2017-01-09    28.365672    55.281199
29  perf_dag_2  perf_task_3     2017-01-10    35.874801    57.229588
35  perf_dag_2  perf_task_4     2017-01-06    16.780074    41.737872
36  perf_dag_2  perf_task_4     2017-01-07    19.932188    48.419331
37  perf_dag_2  perf_task_4     2017-01-08    23.325620    52.384252
38  perf_dag_2  perf_task_4     2017-01-09    28.375870    55.451723
39  perf_dag_2  perf_task_4     2017-01-10    36.065551    57.222251

    land_time  duration
5   14.308284   5.06319
6   18.230447   5.20312
7   19.815610   5.15095
8   23.826895   5.05949
9   27.099467   5.05940
15  47.103195   5.36533
16  53.807784   5.28344
17  57.808942   5.06607
18  60.596374   5.14410
19  62.283461   5.06525
25  47.290571   5.27924
26  53.964710   5.26789
27  58.225727   5.15341
28  60.504551   5.22335
29  62.292976   5.06339
35  47.147275   5.40940
36  53.881490   5.46216
37  57.456243   5.07199
38  60.649765   5.19804
39  62.283467   5.06122
###################

After
###################
DAG perf_dag_1
        dag_id      task_id execution_date  queue_delay  start_delay  \
0   perf_dag_1  perf_task_1     2017-01-06     1.246519    14.979915
1   perf_dag_1  perf_task_1     2017-01-07     1.263032    14.957130
2   perf_dag_1  perf_task_1     2017-01-08     1.283085    14.914688
3   perf_dag_1  perf_task_1     2017-01-09     1.300647    15.133457
4   perf_dag_1  perf_task_1     2017-01-10     1.320361    14.794539
10  perf_dag_1  perf_task_2     2017-01-06    21.429135    55.562884
11  perf_dag_1  perf_task_2     2017-01-07    21.488456    55.796245
12  perf_dag_1  perf_task_2     2017-01-08    21.597062    55.984442
13  perf_dag_1  perf_task_2     2017-01-09    21.759450    57.035027
14  perf_dag_1  perf_task_2     2017-01-10    21.861944    54.939747
20  perf_dag_1  perf_task_3     2017-01-06    21.449388    57.154344
21  perf_dag_1  perf_task_3     2017-01-07    21.516132    57.147256
22  perf_dag_1  perf_task_3     2017-01-08    21.627630    56.435563
23  perf_dag_1  perf_task_3     2017-01-09    21.779795    55.227636
24  perf_dag_1  perf_task_3     2017-01-10    21.903636    57.298717
30  perf_dag_1  perf_task_4     2017-01-06    21.466139    55.919517
31  perf_dag_1  perf_task_4     2017-01-07    21.544202    56.037767
32  perf_dag_1  perf_task_4     2017-01-08    21.707791    56.607409
33  perf_dag_1  perf_task_4     2017-01-09    21.824282    56.551322
34  perf_dag_1  perf_task_4     2017-01-10    22.058345    57.093742

    land_time  duration
0   20.159688   5.17977
1   20.104369   5.14724
2   19.978317   5.06363
3   20.194993   5.06154
4   19.873275   5.07874
10  60.631398   5.06851
11  60.868042   5.07180
12  61.307814   5.32337
13  62.098251   5.06322
14  60.262499   5.32275
20  62.223684   5.06934
21  62.218851   5.07160
22  61.499328   5.06377
23  60.569205   5.34157
24  62.340097   5.04138
30  60.990802   5.07128
31  61.103603   5.06584
32  61.704566   5.09716
33  61.630842   5.07952
34  62.187978   5.09424

DAG perf_dag_2
        dag_id      task_id execution_date  queue_delay  start_delay  \
5   perf_dag_2  perf_task_1     2017-01-06     1.257000    15.013954
6   perf_dag_2  perf_task_1     2017-01-07     1.272777    15.144719
7   perf_dag_2  perf_task_1     2017-01-08     1.289733    15.036155
8   perf_dag_2  perf_task_1     2017-01-09     1.310827    15.179102
9   perf_dag_2  perf_task_1     2017-01-10     1.333640    15.230561
15  perf_dag_2  perf_task_2     2017-01-06    21.441479    55.426200
16  perf_dag_2  perf_task_2     2017-01-07    21.508015    57.089314
17  perf_dag_2  perf_task_2     2017-01-08    21.609050    55.983079
18  perf_dag_2  perf_task_2     2017-01-09    21.770376    56.034015
19  perf_dag_2  perf_task_2     2017-01-10    21.883970    55.283578
25  perf_dag_2  perf_task_3     2017-01-06    21.458032    56.527121
26  perf_dag_2  perf_task_3     2017-01-07    21.526278    56.283534
27  perf_dag_2  perf_task_3     2017-01-08    21.662386    55.806114
28  perf_dag_2  perf_task_3     2017-01-09    21.805637    55.668554
29  perf_dag_2  perf_task_3     2017-01-10    21.963253    57.232332
35  perf_dag_2  perf_task_4     2017-01-06    21.475266    56.091603
36  perf_dag_2  perf_task_4     2017-01-07    21.563184    55.429493
37  perf_dag_2  perf_task_4     2017-01-08    21.733677    55.837962
38  perf_dag_2  perf_task_4     2017-01-09    21.853320    55.950427
39  perf_dag_2  perf_task_4     2017-01-10    22.073796    57.018459

    land_time  duration
5   20.074347   5.06039
6   20.201313   5.05659
7   20.103780   5.06763
8   20.249052   5.06995
9   20.282948   5.05239
15  60.495537   5.06934
16  62.187921   5.09861
17  61.350705   5.36763
18  61.503870   5.46985
19  60.351670   5.06809
25  61.597405   5.07028
26  61.353223   5.06969
27  60.871915   5.06580
28  60.737382   5.06883
29  62.298208   5.06588
35  61.438597   5.34699
36  60.497231   5.06774
37  61.182199   5.34424
38  61.393050   5.44262
39  62.084473   5.06601

The default time isn't necessarily the configured time, and also the loop is bottlenecked by the slowest-parsing DAG/the dag parsing timeout so I still think this change makes sense.

@aoen I agree that it is nice to have, but there are some caveats and concerns that are not addressed yet. As such for 1.8 I don't think it should go in as is.

Fair enough!

@aoen @bolkedebruin as discussed in my previous comments, I've made the sort order in the base executor explicit (priority descending, execution date ascending) that should address the issue of workers getting saturated with tasks from a single DAG.
I ran the ops metrics test with an underpowered airflow.cfg (parallelism = 4, dag_concurrency = 2) to exaggerate any scheduling bias. Neither DAG looks to be starved of resources compared to the other.
###################
DAG perf_dag_1
        dag_id      task_id execution_date  queue_delay  start_delay  \
0   perf_dag_1  perf_task_1     2017-01-17     1.184572     6.545812
1   perf_dag_1  perf_task_1     2017-01-18     1.212773     6.555075
2   perf_dag_1  perf_task_1     2017-01-19     1.233027    21.030931
3   perf_dag_1  perf_task_1     2017-01-20     1.274905    21.197270
4   perf_dag_1  perf_task_1     2017-01-21     1.292003    35.675495
10  perf_dag_1  perf_task_2     2017-01-17    13.520912    49.796394
11  perf_dag_1  perf_task_2     2017-01-18    13.606761    62.365872
12  perf_dag_1  perf_task_2     2017-01-19    27.458687    77.849013
13  perf_dag_1  perf_task_2     2017-01-20    27.592963   114.449361
14  perf_dag_1  perf_task_2     2017-01-21    41.883202   132.175372
20  perf_dag_1  perf_task_3     2017-01-17    13.535486    35.705199
21  perf_dag_1  perf_task_3     2017-01-18    13.618070    64.055766
22  perf_dag_1  perf_task_3     2017-01-19    27.468895    91.708144
23  perf_dag_1  perf_task_3     2017-01-20    27.608829   105.482663
24  perf_dag_1  perf_task_3     2017-01-21    41.895083   118.731730
30  perf_dag_1  perf_task_4     2017-01-17    13.549173    49.732500
31  perf_dag_1  perf_task_4     2017-01-18    13.631132    74.451257
32  perf_dag_1  perf_task_4     2017-01-19    27.489712    91.713198
33  perf_dag_1  perf_task_4     2017-01-20    27.619774   101.518246
34  perf_dag_1  perf_task_4     2017-01-21    41.904437   132.175476

     land_time  duration
0    11.610459   5.06465
1    11.616406   5.06133
2    26.090875   5.05994
3    26.254021   5.05675
4    40.731651   5.05616
10   54.854756   5.05836
11   67.435530   5.06966
12   82.896535   5.04752
13  119.497631   5.04827
14  137.222260   5.04689
20   40.763800   5.05860
21   69.098957   5.04319
22   96.749145   5.04100
23  110.540301   5.05764
24  123.811379   5.07965
30   54.796371   5.06387
31   79.496060   5.04480
32   96.756622   5.04342
33  106.573989   5.05574
34  137.222182   5.04671
DAG perf_dag_2
        dag_id      task_id execution_date  queue_delay  start_delay  \
5   perf_dag_2  perf_task_1     2017-01-17     1.201905     6.627039
6   perf_dag_2  perf_task_1     2017-01-18     1.221881     6.540273
7   perf_dag_2  perf_task_1     2017-01-19     1.253154    21.107255
8   perf_dag_2  perf_task_1     2017-01-20     1.264366    21.117644
9   perf_dag_2  perf_task_1     2017-01-21     1.303607    35.663917
15  perf_dag_2  perf_task_2     2017-01-17    13.569212    49.584564
16  perf_dag_2  perf_task_2     2017-01-18    13.647312    62.427735
17  perf_dag_2  perf_task_2     2017-01-19    27.506493    88.015437
18  perf_dag_2  perf_task_2     2017-01-20    27.550959   114.456142
19  perf_dag_2  perf_task_2     2017-01-21    41.920223   127.726694
25  perf_dag_2  perf_task_3     2017-01-17    13.581176    35.734139
26  perf_dag_2  perf_task_3     2017-01-18    13.658990    74.466790
27  perf_dag_2  perf_task_3     2017-01-19    27.518483    77.808606
28  perf_dag_2  perf_task_3     2017-01-20    27.562828   101.415495
29  perf_dag_2  perf_task_3     2017-01-21    41.931318   118.783812
35  perf_dag_2  perf_task_4     2017-01-17    13.596433    49.551888
36  perf_dag_2  perf_task_4     2017-01-18    13.671642    64.058028
37  perf_dag_2  perf_task_4     2017-01-19    27.531972    87.995953
38  perf_dag_2  perf_task_4     2017-01-20    27.576034   105.503011
39  perf_dag_2  perf_task_4     2017-01-21    41.948766   127.682500

     land_time  duration
5    11.663819   5.03678
6    11.599070   5.05880
7    26.170535   5.06328
8    26.175319   5.05767
9    40.719703   5.05579
15   54.655577   5.07101
16   67.489419   5.06168
17   93.071459   5.05602
18  119.500686   5.04454
19  132.764364   5.03767
25   40.790094   5.05595
26   79.513583   5.04679
27   82.857469   5.04886
28  106.480350   5.06486
29  123.857017   5.07320
35   54.615773   5.06389
36   69.104769   5.04674
37   93.048584   5.05263
38  110.547892   5.04488
39  132.725614   5.04311
###################

@aoen @bolkedebruin @r39132 do you think we should hang on to this PR?

I think the idea of this PR is definitely correct and if there are load issues that block this PR from being merged they should be addressed (e.g. if we need to throttle or prioritize dagruns between different DAGs that should be addressed regardless of this PR). I'm a little bit sad that this PR stalled and didn't make 1.8.0.

@vijaysbhat Please rebase and let me know if you still want a review!

@KevinYang21 do you think it might be worth resurrecting this PR?

@ashb I do think it worth resurrect this PR, but the change needed would be more complicated than what was proposed in this PR.
I don't know how this change is related to the workers got saturated issue from @bolkedebruin, maybe the code base was very different back then. I'm curious to know what was the concerns back then but from my point of view we should be good, only that we need to be careful about the way we create new DAG run--the current implementation would be problematic if we have DAG with large number of dag run pending as we do the max_active_runs later on and creating all the pending DAG runs one by one is not the most efficient way.
About the concern of task scheduling, I'm 100% following what @vijaysbhat was describing but this change would definitely be very helpful for Airflow to schedule task faster. Esp. for those DAGs want to catch up from an old execution_date and those cluster with long scheduler DAG file parsing interval.


Replace RE_JOB_NAME with RE_JOB_PROJECT_NAME

rpc-gating is incorrectly setting the value of RE_JOB_NAME, for example
the job
PM_rpc-openstack-master-bionic_mnaio_no_artifacts-swift-system_staging
has RE_JOB_NAME set to
experimental-asc-rpc-openstack-master-mnaio-postmerge. The value being
used is actually the name of the JJB project and not the job itself. To
enable this to be corrected, rpc-gating has introduced a new variable
RE_JOB_PROJECT_NAME to enable RE_JOB_NAME to be fixed while still
allowing access to the original value.
This change updates rpc-openstack to use the new variable to prevent any
updates to RE_JOB_NAME from impacting any existing jobs.
JIRA: RE-2031
(cherry picked from commit 585ea7b9bc339f1d698ad94a97a6a37a09db4425)
Issue: RE-2031

Thank you for submitting a pull request to this project!
Once all check jobs have passed and the pull request has received a
sufficient number of reviews, the repository's gate jobs can be triggered by
adding a comment of :shipit: to this pull request.
When the gate jobs have completed successfully, this pull request will get
merged automatically.

recheck_xenial_swift_deploy

recheck_all


At midnight all zwave node names lost

Home Assistant release (hass --version):
0.58.1
Python release (python3 --version):
3.6.3
Component/platform:
zwave
Description of problem:
For two days in a row now home assistant wipes out all names of all zwave devices. This morning, I noticed a tell-tale sign that I can't change the color of my aeotec zw08 bulb and with HA still running, I looked at the ozwcache*.xml file. Nodes had name attributes. Then I clicked "Save Config" it wrote out to the ozwcache*.xml with all nodes having an empty name attribute (name="").
Restarting HA with a backup ozwcache file restores the names.
Expected:
To not lose names over night.
** Steps to reproduce:**

Give a zwave node a name
Wait overnight

Traceback (if applicable):
2017-12-05 00:00:00 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 17301521}) on node 1
2017-12-05 00:00:00 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 31227923}) on node 1
2017-12-05 00:00:00 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>38579}) on node 1
2017-12-05 00:00:00 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>49235}) on node 1
2017-12-05 00:00:00 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>59895}) on node 1
2017-12-05 00:00:00 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>070551}) on node 1
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 55132176}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 63553556}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 64782355}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 64798740}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 64831508}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 65110039}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>93011}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>09393}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>20695}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>03667}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>20056}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>31351}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>14327}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>30705}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>624983}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>641364}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>352022}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>062680}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>773336}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>483988}) on node 3
2017-12-05 00:00:10 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>194646}) on node 3
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 105463824}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 113885204}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 115114003}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 115130388}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 115163156}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id': 115441687}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>24659}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>41041}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>52343}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>35315}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>51704}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>62999}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>45975}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>62353}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>956631}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>973012}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>683670}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>394328}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>104984}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>815636}) on node 6
2017-12-05 00:00:21 WARNING (Dummy-3) [openzwave] Z-Wave Notification ValueRemoved for an unknown value ({'id':<PHONE_NUMBER>526294}) on node 6

Additional info:
I also see in the logbook all nodes are "initializing" at midnight. Interestingly, the node names are present in the logbook:
...etc...
12:00 AM changed to initializing
12:00 AM Outlet-Dining-Lamps changed to initializing
12:00 AM changed to initializing
12:00 AM Outlet-Tmp-OutsideBathroom changed to initializing
12:00 AM changed to initializing
12:00 AM Sigma Designs UZB Z-Wave USB Adapter changed to initializing

My bet is you are running soft_reset service at midnight. Remove that automation, and all should be fine.

I have a pretty fresh install of HA and don't have any automations at this time. Is this something that HA puts in that I should disable?

What deos your zwave: entry in configuration.yaml look like. You can remove the network key if you feel like it.

Thanks for your help. Here it is:
zwave:
usb_path: /dev/ttyUSB0
network_key: !secret zwave_network_key
device_config_domain:
light:
delay: 1
refresh_value: true
[image: photo] ABE REESE
*Align Us, Inc. *Founding Partner 001 - President
<EMAIL_ADDRESS>•<PHONE_NUMBER> <3122123209>  •  www.align.us
On Tue, Dec 5, 2017 at 12:18 PM, John Arild Berentsen <
<EMAIL_ADDRESS>wrote:

What deos your zwave: entry in configuration.yaml look like. You can
remove the network key if you feel like it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/10972#issuecomment-349393558,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMOozqbRiVf033YPuz7QMAf3FyPiVk4hks5s9YkRgaJpZM4Q2ZT7
.

Try adding a line before device_config_domain:
autoheal: false

Will do! Any idea what's happening at midnight to lose the names?

Default behaviour in HA is autoheal at midnight. But by the look of the logs you provide it seems like a soft reset is run at midnight.  In other words, the zwave stick is rebooted.

Just FYI that my install was fine last night and the node names stuck after I added autoheal: false to the config. I've been using the Sigma UZB stick for about a month and haven't had that issue before, but anyway, your change fixed my issue. Closing the issue now...
Thank you @turbokongen !

You wouldn't by any chance running this on a rpi? If you are, the problem is the powersupply. Add an powered usb hub to it, and the problem should dissapear.

I'm running it on a gateway laptop. Let me know if I can provide any other info and thanks for investigating!
I will note that this seemed to be coincident with the latest update, but can't say for 100% sure it was the same day, but I think it was. I updated the day that HA told me an update was available...

I have the same problem and it's running on a PC. It happens for me after I restart HA. Haven't managed to track the actual reason yet. I've found that if I restart HA multiple times in a row, sometimes the names come back.

having the same issue here. pi3 pluged into 1a usb charger running v60.0
has been working fine up until 3 days ago. now the last few nights at midnight it removes all node names except for 3 devices.
only way i have found to get the names back is to copy the zwcfg*.xml back to config folder from backup..

The codebase for zwave have not changed for quite some time, only minor changes inside some components, which are not related.
Could you provide some 50-100 loglines before and after 00:00 from OZW_Log.txt?

OZW_error_log.txt
see attached log as requested.
happened again last night.

Ok, what I see in the log is that OZW detects a network change when the heal is run. This is fetched from the controller.
Could you try manually running a network heal, and see if that produces the same problem, and what USB stick are you all using?
I see the original author are using Sigma UZB stick.

i have a Aeotec zwave stick. i ran the manually when i noticed the change and it does the same thing. here is a snippet:
2018-01-01 09:45:31.858 Info, Node003, ** Network change **: ID 3 was assigned to a new Z-Wave node
2018-01-01 09:45:31.858 Detail, Node003, AdvanceQueries queryPending=0 queryRetries=0 queryStage=None live=1
2018-01-01 09:45:31.858 Detail, Node003, QueryStage_ProtocolInfo
2018-01-01 09:45:31.858 Detail, Node003, Queuing (Query) Get Node Protocol Info (Node=3): 0x01, 0x04, 0x00, 0x41, 0x03, 0xb9
2018-01-01 09:45:31.858 Detail, Node003, Queuing (Query) Query Stage Complete (ProtocolInfo)
2018-01-01 09:45:31.858 Info, Node003, Initializing Node. New Node: false (false)
2018-01-01 09:45:31.858 Detail, Node003, Notification: NodeRemoved
2018-01-01 09:45:31.883 Detail, Node003, Notification: NodeAdded


What is the end point in the call to gf_curveCP gf_getCurveCPs

A call to gf_curveCP gf_getCurveCPs (i, j) obtains the coords for the jth curve in the ith reaction. For the curve that is drawn to the product, what is the end point coordinate, is it the center of the product node? Is there a way to get the coordinate just before the curve reaches the node? This would make it convenient to add the arrow if I knew this coordinate. From my own experiments, the end point for  the curve that goes to a product node appears to end at the enter of the node? The docs are not clear on this.

This issue was moved to sys-bio/sbnw#12


BoxDecoration.scale

We don't currently scale:

[x] the borders
[ ] the background image values
[x] the gradient values

The shape doesn't need scaling.
This might depend on work in #771.

I'm going to close this; https://github.com/flutter/flutter/issues/12452 tracks the remaining work (DecorationImage).


Create ChatCraftAppMessage and AppMessage for ChatCraft messages

Fixes #103
This adds a new message type, ChatCraftAppMessage, and a new component to display them, AppMessage.
We now have two ways to work with the messages in a chat:

.messages includes all messages
.nonAppMessages all messages with app messages stripped out

The latter is suitable for sending to an LLM or sharing, the former for showing in the UI/db.

Later, we can build on this to put widgets into the UI for things like entering API key.

I like this, but i feel it would be cleaner for a sngle .messages() to include(includeAppMessages=true) param instead

Good suggestion, I've made the change.


Usage Document

It might be useful to include the full path name in you usage document.  We performed a git clone and SPDX-Git-Scanner/SPDX-Git-Scanner/ wasn't immediatly obvious to us.

According to the installation instructions you should not of done a git clone. You should of ran install.sh and let it take care of git clone for you.


Support non-streamed downloads

Description
Some hosting environments do not support streamed downloads (mainly environments running on lambda like Laravel Vapor or Bref). This makes the export functionality not work because the downloaders assume we can do a streamed download.
This PR adds a config to enable/disable streamed downloads. When disabled, the downloader will write the contents to one file and uploads it to the disk (so we don't have to re-do the generation on multiple downloads).
Visual changes
N/A
Functional changes

[x] Code style has been fixed by running the composer cs command.
[x] Changes have been tested to not break existing functionality.
[x] Documentation is up-to-date.

To get things working on Vapor, you need to add the X-Vapor-Base64-Encode header in the response. (See https://docs.vapor.build/projects/development.html#binary-responses)
I only use the XLSX downloader so I've simply subclassed XlsxDownloader, replacing the __invoke() function to add the header:
public function __invoke(Export $export): StreamedResponse
{
    return tap(parent::__invoke($export), function (StreamedResponse $response) {
        $response->headers->set('X-Vapor-Base64-Encode', true);
    });
}

$this->app->bind(BaseXlsxDownloader::class, XlsxDownloader::class);

Is there a way we can detect Vapor within Filament and do this on the users behalf? Instead of disabling streaming?

For Vapor: isset($_ENV['VAPOR_SSM_PATH']) || isset($_SERVER['VAPOR_SSM_PATH'])
For Bref: env('LAMBDA_TASK_ROOT') (detects Lambda runtime) or env('BREF_LOOP_MAX')
Will try to reshape this PR a bit with the given feedback. I'm afraid for Bref downloads larger than 6MB should come from a disk (s3), see: https://bref.sh/docs/use-cases/http/binary-requests-responses
Not sure if/how Vapor mitigates that though

Hi, please reopen this if you decide to implement the requested changes. Thank you!


Added checks for reservations

Coverage decreased (-0.2%) to 75.341% when pulling be09f449d0b7f44f2c7495546eea1369020bf670 on reservation into 093a2063aa46dd6b9bd66ca2f15088a83b688da3 on master.


Parking Card: Implement Neighborhoods

Time Tracking: https://its-pro.ucsd.edu/browse/MA-84
This is done when:
The Parking card allows user to select lots based on neighborhoods, as implemented at https://xd.adobe.com/view/8e0f007c-1896-49bd-a562-60409a96111a-db5c/
API at https://api-qa.ucsd.edu/store/apis/info?name=FIM-Portfolio&version=v0.0.3#/default/get_Neighborhood__id_
Related issue #1032

https://app.zenhub.com/files/62921972/b65f69d2-0647-4213-97ab-19901553b56c/download
In the Neighborhoods API, we can't seem to find any parking lots, only parking structures.

https://app.zenhub.com/files/62921972/35271d38-1b35-4b55-86b5-736e0e000222/download
/Neighborhood/(id)
For the La Jolla Campus, the ID = 129965164

Neighborhoods UI Demo :
https://images.zenhubusercontent.com/62921972/ac725898-17cc-40ed-818c-ff2d4c866eb2/final_demo.mov


🐛 Bug Report: Backend failed to start up Error: Invalid configuration schema in<EMAIL_ADDRESS>

📜 Description
Recently (without changes) I've been unable to start backstage with a proxy configured.
Backend failed to start up Error: Invalid configuration schema in<EMAIL_ADDRESS>the following definitions are not supported:
│
│   Partial<{[key:string]:string;Authorization:string;authorization:string;'X-Api-Key':string;'x-api-key':string;}>
│     at /app/node_modules/@backstage/config-loader/dist/index.cjs.js:348:15
│     at Array.map (<anonymous>)
│     at compileTsSchemas (/app/node_modules/@backstage/config-loader/dist/index.cjs.js:322:27)
│     at async collectConfigSchemas (/app/node_modules/@backstage/config-loader/dist/index.cjs.js:299:21)
│     at async Object.loadConfigSchema (/app/node_modules/@backstage/config-loader/dist/index.cjs.js:481:15)
│     at async Object.createConfigSecretEnumerator (/app/node_modules/@backstage/backend-app-api/dist/index.cjs.js:195:18)
│     at async Object.loadBackendConfig (/app/node_modules/@backstage/backend-common/dist/index.cjs.js:400:28)
│     at async main (/app/packages/backend/dist/index.cjs.js:540:18)

Found related comments:

https://github.com/backstage/backstage/issues/19443#issuecomment-1682596745
https://stackoverflow.com/questions/76923143/backstage-failing-to-start-with-schema-error

👍 Expected behavior
Backstage should start.
👎 Actual Behavior with Screenshots
See description for startup error.
👟 Reproduction steps
No changes made, see context. Removing proxy config allows for app startup locally.
📃 Provide the context for the Bug.

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

Hi @shoeletz, based on the version details you shared it seems you have a mix of packages from 1.15.0 and 1.16.0 for example @backstage/config-loader at 1.3.2 is from 1.16.0: https://github.com/backstage/backstage/blob/master/docs/releases/v1.16.0-changelog.md#backstageconfig-loader132
But I tried that version and the one from 1.15.0 and they both don't result in this error, I get the same error if I use 1.4.0 which is from the most recent release which is 1.17.0.
To help better understand this can you run yarn why @backstage/config-loader and share the results?

Sure. Ideally this is a versioning issue on our side, our build pipeline is currently held together with duct tape.
[1/4] Why do we have the module<EMAIL_ADDRESS>[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found "<EMAIL_ADDRESS>info Reasons this module exists
   - "_project_#@backstage#cli" depends on it
   - Hoisted from "_project_#@backstage#cli#@backstage#config-loader"
   - Hoisted from "_project_#backend#@backstage#backend-common#@backstage#config-loader"
   - Hoisted from "_project_#backend#@backstage#plugin-app-backend#@backstage#config-loader"
   - Hoisted from "_project_#backend#@backstage#backend-common#@backstage#backend-app-api#@backstage#config-loader"
info Disk size without dependencies: "2.7MB"
info Disk size with unique dependencies: "83.32MB"
info Disk size with transitive dependencies: "2.7MB"
info Number of shared dependencies: 77

LMK if you need any more details

Fixed by a version upgrade of backstage: yarn backstage-cli versions:bump


update ember-getowner-polyfill to remove deprecation warnings

this is less radical than #173

@ntodd What do you think about this PR? Go with this one?

@akatov 👍
@broerse That is the correct way to remove the deprecation.

@broerse Yeah, this way is correct.

@akatov @ntodd Thanks!

@broerse It would be great if you could publish to NPM with this change as I am getting an error "Could not find module ember-getowner-polyfill imported from ember-pouch/adapters/pouch" with the current NPM version and this fixes it. It might save other new users like me some headaches! Thanks.

@colinf @rwanyoike Sorry... v2.4.5 published now.


S3 and PostgreSQL instructions in README

Coverage remained the same at 58.711% when pulling 5d805d0cdb683d16762bb118c5f8b4697a0976a8 on CheViana:develop into 83fc415f9d6d2aa295a2508f654647a780835af5 on DistrictDataLabs:develop.

Coverage remained the same at 58.711% when pulling 36b338c6371076258e783f585fdfdc2dc779d574 on CheViana:develop into 83fc415f9d6d2aa295a2508f654647a780835af5 on DistrictDataLabs:develop.

Coverage remained the same at 58.711% when pulling 782ce6f1ea4bb821305338004af6eaf7898b9c91 on CheViana:develop into 83fc415f9d6d2aa295a2508f654647a780835af5 on DistrictDataLabs:develop.

Coverage remained the same at 58.711% when pulling 782ce6f1ea4bb821305338004af6eaf7898b9c91 on CheViana:develop into 83fc415f9d6d2aa295a2508f654647a780835af5 on DistrictDataLabs:develop.

Coverage remained the same at 58.711% when pulling 6e8d3a2b8f4aad766ffbcb11b587db6578049fc1 on CheViana:develop into 83fc415f9d6d2aa295a2508f654647a780835af5 on DistrictDataLabs:develop.

Coverage remained the same at 58.711% when pulling 5b35a82f947c573c93dd14aac53e51135fb79c90 on CheViana:develop into 83fc415f9d6d2aa295a2508f654647a780835af5 on DistrictDataLabs:develop.


Logspout drops the first few lines if nothing has been logged for a while

We recently upgraded to Logspout v3.2 from v2, and many things are better.
We have it running on a machine which runs jobs on cron twice a day. We noticed that the log entries for these jobs, which are usually only a few lines long, were truncated from the top or missing altogether when we used v3.2. Subsequent jobs, if run within a few minutes, are not missing any initial lines.
From https://github.com/gliderlabs/logspout/issues/309#issuecomment-306818766 I see that logspout is expected to drop logs while it is reconnecting, and we do see the reconnect successful message immediately before the truncated logs.
Is there anything we can do to mitigate this?

It looks like there are some suggestions in that thread you linked. The best thing would be to fix the issue in some way. I'm open to suggestions but even more would love to see someone jump in and take on the work. Unfortunately my $DAY_JOB is taking up all my coding time.

@michaelshobbs Thank you for your reply. I'm afraid I have no Go so I'm not going to be much use on the code in the foreseeable future, but if I find out anything interesting I will bring it back here.